When Ken Salchow Jr., who designs network security for a F5 Networks, defines risk management with the following simple equation:

he hits the nail squarely on the head. Risk management really is as simple as identifying possible things that could go wrong on your project, planning how to avoid them and how to deal with them – and then acting on your plan. Simple, right?

Okay, easier said than done. While every project is different and requires customization, there are a set of standard practices that you can follow to help you design and implement a risk management plan for your project.

Step 1: Do a risk analysis at the start of your project.

Before you can set about planning how to deal with risks, you have to know what they are and how they will affect your project. Your risk analysis needs three parts to be effective:

Identify all possible threats to your project, from a security leak to illness on your management team to a lightning strike that burns the building down.

Assess the vulnerabilities – where are the holes that will let those threats affect you?

Analyze the effects of each threat on your project or company. What’s the worst that could happen if the worst happens?

Step 2: Design a mitigation plan.

Once you know what dangers you face, you can start to plan how to mitigate the risks.

Mitigation consists of two parts:

1. Avoiding the Risk by plugging up those holes you found in your risk analysis
2. Lessening the Impact by planning how to deal with the effects.

Suppose your risk analysis identified the loss of a senior member of the project team as a threat that could derail your project. Your risk management plan might include:

• Regular updates and collaboration notes to ensure that a new person could step in and pick up the work
• An insurance policy to provide funds for a quick replacement
• Tagging a backup team member to work closely with each senior project member so that they can carry on in his absence

That’s the essence of risk management in a nutshell. Everyone wants to be positive when they’re starting off on a new project – but by imagining the worst case scenario and planning how to deal with it in advance, you can bubble wrap your work and protect it from the bumps and bangs along the way.

How to Bubble Wrap Your Project: Risk Management By the Numbers is a post from: Enterprise Project Management

Delicious Reddit Stumble This Post

Split Scope

Developing a new application may cause the need for new infrastructure, hardware, software, etc. If possible (and I highly recommend doing so), split a project into two separate projects. While the new infrastructure is being decided upon, installed and tested, separate projects can handle the development of the application, which also has its own set of design, coding and testing.

No TPM should have the burden of managing these as one project–especially when it’s never been proven in the organization. However, it’s probably smart to have the same TPM manage both projects, although it is not necessary.

Well – as long as both projects do not relate to each other, or the application development can happen much later, I am fine with this. Don’t get this wrong and start developing the customer’s needs on an application framework that is old or just crap.

If you need new infrastructure in your project, you need to build that new infrastructure – and wait for it to complete You would have a hard time explaining your clients that the application is 90% done, while you just have to migrate everything to the cool new infrastructure you just built “by-the-way” .. don’t you think? Also for your team it would be mega-frustrating to adapt their code to the new infrastructure… and don’t get me wrong: this has nothing to do with “refactoring” … refactoring refers to improving YOUR own code (hence a mental code cleanup as well…) – moving to a new infrastructure is the opposite – changing your code to RUN ANYHOW again with those new libs that the lab spit out after a few months of “creating a perfect world”

Pick Your Team

I know in a perfect world this would be possible. However, there are those projects that require key resources and it’s okay to be selective in forming your team.

NO - be as picky as possible – every team member IS a KEY RESOURCE every team member you take “because it could fit will cost you 20-30% team performance for the whole remaining team to bring him where you thought he should be… if you are to select new team members every hour NOT SPENT WISELY in selection process will cost you a BIG multiple in development / testing / rollout costs for re-writing or fixing of a bad developer’s results or even architects design… with that kind of effort you are better to do it yourself.

Manage Risks
It’s a good practice to manage the risks before they turn into full-blown issues. However, no matter how well you mitigate a risk, issues will arise. In this case, tackle all issues first. Make sure those involved in the issue are aware of the impact and consequences, then decide who the action agent will be for resolving the issue. And put a timeframe on the issue so as not to have the issue extended and prevent a future risk of creating a non-manageable issue.

Yes – manage risks. If you know nothing about risk management, then start reading

Set the timeframe for your own re-check. If you don’t manage the risks who would? ( unless you assign a specific risk manager to get you out of your optimistic PM views … )

Key Elements of a Successful Project is a post from: Enterprise Project Management

Delicious Reddit Stumble This Post

1. Analysis

Using Project management software will help you to be more efficient at your job.

More correctly referred to as impact analysis a key skill required toward the final stages of a project is the ability to analyse the impact of changes brought about by the project. Exactly the same as the well known ‘ripple effect‘ you must never underestimate the knock-on changes and effect that a major project can bring about. Being able to analyse and then manage these is yet another skill you need to master. Changes to the specification of a project after it has begun are all too easily overlooked and you will need to constantly revisit your impact analysis to incorporate them. Amongst other things any change to the specification could affect your previous analysis regarding legal, health, safety, and marketing or personnel issues. However, the ultimate reason for doing the analysis is – how the change will affect the end-date for the project? Project management is a complex task and the bigger the project, the more complex it becomes. You must be able to keep track of progress on the project from all the various sections of it that are on-going. This can be done on paper, but in all reality you need to learn and understand how to make the most out of one of the many pieces of project management software that are available. Using an IT based project management system will also help you to adjust timelines and priorities as the project develops.

2. Communication

Effective project planning underpins all project management.

If you can’t communicate, I’m sorry but you’ll never become an effective and successful project management. Any manager, but especially the project manager, has to understand that although you’re charged with ensuring the successful completion of a project – you’ll be dealing with a multiplicity of people and companies that you have to bring together in order to achieve the projects aims and objectives. If you don’t communicate effectively, either in speech, writing or presentations you won’t provide the information that your workers need to fulfill their jobs; be that in sharing knowledge, discussing ideas, providing solutions or making an executive decision.

3. Budgeting

Even if you have a team of accountants looking after the day-to-day running of the projects finances, understanding how to use a budget yourself is another essential project management skill to posses. The three key stages to a budget are preparing it, writing it and monitoring it. whilst your finance department may well be ostensibly charged with doing these things for you – as project manager you have the ultimate responsibility for the budget and need to be able to understand what you are being told about the budget. Unless your own background is in accounting you will feel obliged to accept what you’re told, if you don’t take the time to learn some basic budgeting skills. You will need these as at time you will need to know how to rationally and logically challenge budget over-runs that you become aware of as well as be able to sensibly monitor the budget as the project progresses.

4. Teamwork

Effective teamwork - will help you to manage your project most effectively.

The essence of any good project manager is to be a good team leader and, if necessary, be a good team player. Whilst decisions will remain your responsibility, that’s not to say that you shouldn’t encourage input from others or be prepared to work with them to help them achieve their goals too. Furthermore, by building a culture of teamwork into all aspects of the project, you will engender high self-esteem within all of the workers, meaning that they feel personally involved in ensuring the success of the project.

5. Intelligence

This doesn’t mean to say that you have to have a string of letters after your name as intelligence isn’t something you can learn. However, intelligence is something you can improve on and develop, so the more you study the chances are the more you’ll increase your intelligence. In the context of project management intelligence can be considered to be your ability to have a clear vision of all aspects of the project whilst at any one time being able to keenly focus onto a specific aspect of it. Put another way, just having the big picture will not help when you have a decision to make on a specific matter. You won’t always have the time to spend hours researching and re-reading material in order to make the decision at the time it is needed.

6. Calmness

It is almost inevitable that at times your job will be stressful, if not highly stressful. Being able to work calmly under such conditions is an absolute pre-requisite for a successful project manager. A key point to reducing your stress levels is your ability to move on from a setback. If something goes wrong or not according to plan, don’t waste time worrying about who’s fault it might have been or get involved in a cycle of what could have been different, that can come later in your project evaluation. Instead, move swiftly on to solving the problem or rectifying the situation.

7. Time

The Project Management Life Cycle.

Quite simply – are you a good time manager? Understanding the life-cycle for project management will help you to understand how to apply the key skill of time management to it. Your time management and you ability to organize yourself and others are vitally important. Time management is much more than simply allocating portions of time to certain jobs. You need to analyze exactly what it is you’re spending your time on and how important are those tasks and portions of time to the successful completion of the project. For example, you could easily spend up to an hour a day just reading emails. This is a task you can delegate to your PA, get them to be the person that sorts the important from the not so important, telling you what needs dealing with immediate and what can be left until later. That hour you’ve saved – you can use inspecting a part of the project checking on progress or quality etc. You should apply this time management philosophy to most things you do; do I need to attend that meeting or can I delegate someone else? Remember, you are the project manager, you are primarily there to do the strategic planning, overall monitoring and be creative and innovative in solving problems – not micro-manage everything.

7 key skills of a project manager is a post from: Enterprise Project Management

Delicious Reddit Stumble This Post

This is the latest incredible book by Tom De Marco and Tim Lister that was on my Amazon wishlist for almost 5 months now until Chris reminded me with a recommendation about it. Now having finished it I can just agree with Edward Yourdon (Creator of the incredible ) that this will become the bible for IT Project Managers.

It not only adresses the "Reason why" to cope with risk management in your projects, but for instance the anti-thesis, the "Reason why not" (if you live in a culture of fear for instance…).

Tom DeMarco and Timothy Lister provide an enjoyable to read, with great examples and their typical, somewhat sarcastic, view on the general issue of project management and the fact that a project – whatever risks it might impose – typically extends the first and most optimistic schedule by 150 to 200 % (that is 3-4 times more!).

Managing risks does not mean to manage the resulting problems or catastrophes alone, but simply the probabilities of these with adequate safety buffers and alternative strategies.

The visualization of a risk – a "we could maybe not make it"-issue is the first and probably most important step they motivate you to. Many organziations simply obey the "can do"-super-hero approach (I would call it CMM level zero) where not the infantile project plans and the resulting schedule and effort slips and therefore money and people loss are sanctioned, but the "questionable" behaviour to ask for possible bad outcomes and problems during the project path to take care of. (the organizations where there is always another dude with a "Hey Boss, I will deliver in your {impossible} schedule 100 pro, let me do it!")

From the practical viewpoint they even provide an easy to understand arithmetic approach to probabilty calculations aswell as some tools (Excel based) you can download from their web-page. Not the most important issue in my opinion but nice for the more detailled analysis. I will take a look at that later.

You can even get some sample chapters of Waltzing With Bears: Managing Risk on Software Projects at their website.

This is a must-read for every project manager, developer, customer and CEO.

You can also download from the October issue of IEEE Software, Lister and DeMarco's article on Risk Management during Requirements

I am currently reading the german edition.

Waltzing With Risk is a post from: Enterprise Project Management

Delicious Reddit Stumble This Post