Graham Chapman
"It's possible to find defect, but impossible to find 100% correct functionality..."
In this article I want to present a simplified approach to risk management in Development Projects. More detailed information you may get from books and articles listed at the end of this article. My key idea is that every small IT Project shall perform proper risk management process, if Coding Group is looking for predicted outcome.
Recommended Risk Management Process For Small Development Projects
There are seven key tasks that I want to emphasize in risk management. Classic PMBOK-driven approach recommends 6 processes: risk management planning, risk identification, qualitative analysis, quantitative analysis, risk response planning, risk monitoring and control. I decided to show you seven simple steps, that will simplify the whole procedure.
If you're looking for more detailed information on this topic, I would strongly advise to read: [Rita03], [Rita5], and [PMBOK]. Notice, that I'm talking here only about negative risks. Positive risks are very important for Development Projects, but this will be a topic for one of my next articles.
If you perform all these seven steps properly, the whole risk planning will take 4 hours (240 minutes!) at the beginning of IT Project. I'm sure you understand, that everything described in this article shall be managed by project manager (PM). And you definitely understand, that if any of the described steps is not performed - this is a personal guilt of PM. There are no excuses for improper project and risk management.
The seven steps are:
- Step 1. Define Risk Sources
- Step 2. Define Risk Categories
- Step 3. Identify Risks
- Step 4. Qualitative Analysis
- Step 5. Plan Risk Responses
- Step 6. Define Contingency Plans
- Step 7. Monitor Risks
You can perform that steps in any order you wish. A result of your work is Risk Register (also known as 'Risk List' in Rational Unified Process, RUP and 'Risk Assessment Document' in Microsoft Solutions Framework, MSF). How you get this document and what activities you will do for this - it's your choice. Focus yourself and your Coding Group on Risk Register.
Before you start working with Risks, you should do this:
- Inform your manager about this process;
- Explain to your Coding Group that the more risks you find and analyze the bigger will be the project stability;
- Involve your Client by asking 'How do you think, what can go wrong with the IT Project?'.
If you ask me - where is quantitative risk analysis - my answer is 'We do not need it in small IT Project'. Don't waste your time with that numbers.
Define Risk Categories, 10 Minutes
You better use this simple list of Risk Categories for your IT Project - don't invent the wheel:
| Risk Category | Examples |
|---|---|
| Technical | Integration problems, API's, protocols, knowledge, skills, experience, etc. |
| Quality | Quality expectations, defect level, speed of delivery, quality of communication, etc. |
| Performance | Delivery dates, schedule compression problems, lack of resources, lack of personnel, etc. |
| Project Management | Improper planning, lack of risk analysis, vacations, communication issues, etc. |
| Organizational | Roll-over of personnel, organizational problems, salary, vacations, etc. |
| External | 3rd-party systems, APIs, operating systems, suppliers, etc. |
More typicall and commonly used Risk Categories you can find in [Rita03] - over 100 Risk Categories!.
Define Risk Sources, 10 Minutes
Risk Source is a person or some other entity that may become a cause of risk. Typical examples (you shall just list the sources, without explanations):
| Risk Source | Examples |
|---|---|
| Client | Client may have low priority on IT Project, may disappear constantly, Client may respond with long delays, may not understand the requirements, may have unclear business vision of the project, etc. |
| Coding Group | Coding Group may have lack or experience, lack of skills, may lose some Programmer due to staff roll-over, illness, family issues, Coding Group may have low morale and low motivation, etc. |
| Hardware | Server may crash, network connections may be lost in critical moment, data may be lost during development of IT Project, personal computers may be crashed with fatal loss of data, etc. |
| 3rd-party Software System | Integration with 3rd-party Software System may take much more time than planned, API's won't be defined properly, protocols will be missed, etc. |
List all Risk Sources - you will get 4-8 sources in your short-list. Don't spend more than 10 minutes for this. Be short and informative. Key sources are the same for all projects: Client, Coding Group, Software System and hardware. Usually, that's more than enough.
Qualitative Analysis, 30 Minutes
Qualitative Analysis - means that you shall define the quality of each risk. Quality of risk means the importance of the risk to your project. Risks with low importance shall be defined as 'residual' risks and you shall not bother your team with them. You should be focused on top-priority risks. Select 5-8 top risks.
Assign 'probability' and 'impact' to each risk. Use '1-5' scale for this. '1' means lowest probability - 'we think that this risk won't happen'. '5' means the highest probability - 'this risk is almost certain and will happen for sure'. Use the same scale for 'impact' analysis.
In order to calculate 'Risk Scope' you should just multiply 'probability' to 'impact' and the result will be the score (in range of '1-25'). Then sort the list and choose top 5 risks. Forget about the others.
Identify Risks, 60 Minutes
Conduct a brainstorming session with Coding Group and other stakeholders (sometimes Client, system administrators, PMO, director, etc.) Ask participants of this meeting to find as many risks as possible. And do it as fast as you can. Don't block anyone's ideas - just record them on paper. Do it very fast. During 60 minutes you have to find and identify 100+ risks.
Risks shall be very simple and short. Don't record global risks like 'Due to our lack of experience with .Net 3.0 we may fail the project'. This is not a risk that could be managed. Instead, record a number of such risks: 'Due to lack of experience with .Net 3.0 we may fail to implement module FileStorage in time'. This is much more specific. And if you have 50 modules - you will have 50 risks (however, I don't think you have such a huge lack of experience in .Net 3.0).
Remember the pattern for risk identification: 'cause-risk-effect'. 'Cause' explaines the situation that already exists, e.g. 'We do not have UI designer in our Coding Group', 'Joomla platform is an open-source and may have hidden defects' or 'API is not documented'.
'Risk' is what 'may or may not' happen because of 'cause'. Remember, that if the risk is certain (100%) - it's not a risk, for example 'Since we do not have UI designer (cause), we won't create GUI this week'. This is not a risk, this is an issue. Because the probability is 100% (you won't create GUI this week - it's true). Several examples of properly identified risks (cause+risk): 'Integration protocol is not documented, research may take more time than expected', 'Web parts are not delivered yet by supplier, Differences in architecture may appear later'.
'Effect' is the impact to project schedule and cost if the risk happens. Try to measure the impact in numbers. Don't say something like 'project will be failed' or 'delivery milestone will be posponed'. Use very specific and measurable 'effects': 'delivery milestone will be moved 5 working days ahead'.
Don't afraid of telling the truth now - reveal as many risks as you can find. Don't hide them!
Define Contingency Plans, 30 Minutes
Contingency Plan explains what you're going to do if the risk happens (even after you implemented your response plans). Contingency Plan is a plan of counter-fight, which is performed when something already failed.
Plan Risk Responses, 60 Minutes
Risk Response Plan is what you're going to do with the risk in order to protect your project. Risk Response Plans are necessary only for the risks that you're ready to mitigate. Some risks you may decided to accept. That will mean that you don't do anything with that risks - you just wait and pray. Maybe they won't happen. Sometimes, this strategy is the best. Instead of fighting - think about the defence.
If you decided to fight - you shall define a plan: you may either remove the 'cause' or mitigate the 'cause'. If you remove the 'cause' - you are 'avoiding' the risk. In any case - your plan shall be final, definite, and winning. Don't try to remove a part of the risk. Kill the whole risk.
Several examples of response plans:
| Risk | Response Plan |
|---|---|
| Due to lack of experience with .Net 3.0, Development of module FileStorage will take more time than expected, Delivery milestone will be moved ahead for 20 days | Involve part-time expert with .Net 3.0 experience, who will develop the prototype of FileStorage module before 11/5. Risk Avoidance. |
| Integration protocol is not documented, Research may take more time than expected, Life-Cycle Architecture (LCA) milestone will be missed (10-20 days) | We will build integration prototype before the 10th of June in order to test and investigate the protocol. Risk Mitigation. |
You may find more examples in your Development Projects. Be very attentive to your plans and understand the real causes you're fighting with. Also, your plans shall be very specific, with dates, numbers and results.
Monitor Risks
Risk monitoring is a very simple task. At the beginning of each iteration you should review your Risk Register and remove risks that already happened or won't ever happen and re-prioritize the list. The 'residual' risks will become active and top-priority.
You will find and identify new risks - this is a good practice. Do risk management in iterative manner and you won't have any problems with your project. Stay prepared!
First writen online on 7/27/2007
