It's that easy and it's that hard. If you don't have a handle on what risks are going to impact your project, those risks will still be there, you just won't know it.
The first step in increasing the probability of project success is to have some notion of what is going to prevent that success. This means asking what can go wrong, rather than what can go right. In order to answer the question what can go wrong we need to know what we are doing. What is the project about? What are we trying to produce? When do we need to produce it? How much money will we need to spend to produce this things call DONE?
Let's start with some obvious risks that we have to handle for any hope of success of the project. These are obvious because they occur on every project, in every domain, using any project management method.
- Do you have any notion about what DONE looks like in units of measure meaningful to the decision makers? This is the starting point. If we don't have any notion, in meaningful units of measure, of what done looks like, we won't be able to recognize DONE when it coms through the door, other than we ran out of time and money and what is left has got to be called done.
- To start to recognize done, let's write done some capabilities that will be produced by the project for those providing us the money for our work.
- A capability is the ability to do something. This something should make an impact on those using this capability. They can get work done. They can learning something new. They can prevent something from happening. Something will change as a result of possessing the capability.
- If we know what capabilities we'd like to possess as a result of the project, can we know how much it will cost and how long it will take to produce these capabilities for those who want to use them?
- I'm not a big fan of biblical versus applied to project management, but here's one that provides good advice to anyone suggesting we just get started. For which of you, desiring to put up a tower, does not first give much thought to the price, if he will have enough to make it complete? Luke 14:38
- So let's test this advice with the inverse. We desire to put up a tower, but let's give no thought to the price of doing that work. Doesn't sound like the basis of success does it.
- What's the confidence we'll need on the cost and schedule for our work at the beginning of the project? The simple answer is how much do we have at risk? If we start and it turns out that we don't know what DONE looks like, who much are we willing to risk.
- We could spend money to find this out. That's be a good approach. But that expense needs to be included in the total expense for the project and those paying for the project need to acknowledge this. This is the essential basis for Agile projects. The customer is paying you to discover what DONE looks like. If they don't know, someone has to know. And someone has to pay to know.
- With that out of the way, what resources are we going to need to produce the capabilities, on the planned time for the planned amount of money? Notice we have a plan. The plan is a strategy. The strategy is a hypothesis. The hypothesis needs to be tested, just like we were taught in High School science class.
- Plans are meant to be tested. Plans are not carved in stone.
- Schedules some us the order of the work needed to implement the plan.
- The order of the work might - and many times should - test that the plan is credible
- The notion that plans are somehow fixed, that schedules can't be changed, that commitments are immutable is simply bad project management.
- Changes must take place for the project to success. Changes must be managed in the same way all elements of the project are managed - with full understanding of the impact of the change.
- With our capabilities, the resources needed to implement the capabilities, the strategy for the implementation, we are ready to explore what can go wrong. This is the Risk Management part of the project processes.
- Let's start with Tim Lister's quote Risk Management is How Adults Manage Projects. In Tim's presentation he has several other quotes. The purpose of risk management is to make decisions, not sit around and admire the risks. This can be extended to not sitting around an admiring the dysfunctions of the project. If you see dysfunction do something about it. Name the dysfunction and name the possible ways for taking corrective action.
- So start with Tim's presentation on page 19 and see if there are things that you've heard in the past that simply make no sense and end with page 29. From this you should see that all project work is probabilistic.
- Probability and statistics are at the heart of risk management for the key project elements - cost, schedule, and technical performance.
- We have to learn how to manage in the presence of the uncertainty that creates the risks to our project success. To ignore these uncertainties or to attempt to wish them away will not work. They are always there.
- With our list of capabilities, the plan to deliver them, or resources needed to make this happen, the risk that impact our ability to deliver, we now need a way to measure our progress. The simpliet and best way is to state what physical percent complete we plan to be on some day in the future and when that day comes measure the actual physical percent compete against our planned physical percent complete.
- Technically this is the basis of Earned Value Management.
- If you're not a fan of EVM, then the process of measuring planned versus actual physical percent complete should still be used. It's simple common sense.
- Tell me what you're going to do on the day you plan on doing it, for the cost you plan to spend. Then measure what you actually did.
- These plans and measures have statistical variances of course, like all project elements. So set the boundaries on the plans and the measures to be within your tolerance for uncertainty. Not 50%, you can get that by flipping a coin. But somewhere in the range of 75% early in the project and tighter as you move left to right.
