Risk Management in Software Projects

Risk Management in Software Development Projects
A Straightforward Approach to Project Risk Management by Mike Harding Roberts

Have you ever used a Monte Carlo simulation to gauge project risk? Or employed probability theory to hone your risk management plan? Maybe you manage large complex projects and have found real value in these techniques. But for most projects a simple approach to risk management, designed primarily to keep the project manager's eye on the ball, may be all that is required. This article describes a straightforward approach to risk management: how risks might be assessed and managed and how experience might be fed forward to help future projects. A little risk management saves a lot of fan cleaning. A disciplined, though simple, approach to risk management can reduce crisis management and the clean ups that result. It will also increase the chance of project success and probably reduce the project manager's stress level into the bargain. We will summarise the process under these five headings: Measure, Minimise, Mention, Monitor and Modify, which you will notice make the easily remembered acronym 'mmmmm'. 1. Measure The project manager needs to measure, assess, understand: the risk that the project will exceed the budget he is thinking of committing to the risk that the project will miss any dates he has in mind the risk that the project will fail to meet any other commitments he is about to make. Many organisations have checklists - things that have gone wrong in previous similar projects - which are therefore things that might cause problems in future projects. Some organisations have several checklists reflecting the various types of project they undertake. However, checklists (and I've met PMs who have done this) can lead to the PM "filling in the checklist", filing it away and believing they have "done risk management". Not terribly useful. A better approach might be to invite the team and other stakeholders to a Risk Identification Workshop. Brainstorm: "team, what do we think could cause us problems, or even cause us to fail?" When that has been exhausted, zip through any checklists
you've managed to lay your hands on to see if they prompt anything you hadn't thought of.
Project Risk Management

Stakeholder managers who may have no direct project role will need to be involved. Only a manager from the relevant business department can tell you whether a user provisionally assigned to your project has the required skills, will genuinely be available, and will be empowered to represent their part of the business. Prioritise the risks, listing first those which would cause major problems and are most likely to happen. These high impact, high probability risks will clearly need most attention. You may well decide to ignore low probability low impact risks to avoid cluttering up your risk management process. Tools which employ risk weighting and which calculate an overall risk score in an apparently scientific way may add value, but can obscure the fact that one single risk, which may not even be considered in the tool, can make the whole project a complete non-starter. Whatever techniques you use to assess, measure and understand the risks brainstorming, checklists, tools - remember that the main aim is simply to focus the attention of those involved in running the project on those things that are most likely to cause grief or even failure. 2. Minimise Do something about it! There's no point in assessing risks if you don't then take action to reduce them. For example: define that user's role in writing, get a written commitment from his boss that he will be available and empowered to make decisions on behalf of his department. Line up backfills for people you think might leave the team during the project. Increase the budget to include contingency tasks for risks that you can't eliminate at the start, i.e. tasks that describe what you'll do if the risk bites you during the project. Now, if you are an experienced PM you'll know how to deal with most risks. If you're a novice you may have no idea how to reduce the risk that, for example, too much change to the Requirements during the project might cause you to miss the proposed end date. Some companies record how projects deal successfully with risks and make this information available to future project managers. Getting a list of the dozen or so ways PMs have reduced that change risk in the past could give you some very useful pointers as to how you might reduce the risk in your project. 3. Mention
Who owns the project risk, who ultimately is taking the risk? The Project Sponsor. But many sponsors have no idea what the risks might be, particularly if they are sponsoring technical, e.g. IT, projects - and why should they? Project managers have a duty to explain the risks to the sponsor before the sponsor gives the go ahead. (Image you don't mention the risks and when it's all going wrong you tell the sponsor that you knew all along it was high risk - you're going to get shot and quite rightly too.) But there are good ways and bad ways of presenting risks to sponsors. Do not go in with 50 overheads listing hundreds of risks. No. The way to do it is briefly to explain the process you have used to identify and analyse the risks and then to describe the major risks you initially foresaw. Then explain what you have already done to eliminate or reduce some or most of these major risks. This builds real credibility for the next bit where you tell the sponsor about the high risks that remain, the likelihood of their coming to fruition and the consequence if they do. If you were sponsor and you're told "this risk is almost certain to happen and when it does your 5M project will be a total write off", would you give the project the go ahead? Probably not, unless the benefits are measured in billions and it's worth the gamble. But the sponsor may accept the position that if a particular risk should happen it would delay the end date by a month - although he will of course exhort you to meet the end date in spite of the risk. 4. Monitor But that isn't the end of it. Far from it. Clearly we must make sure we monitor and manage risks during the project to make it less likely that they will happen and to minimise the impact if they do. Create a Risk Register which lists risks in priority order. For each risk, the register might include: Risk number Description Consequence if risk happens Probability (high, medium or low) Planned actions to mitigate the risk Contingency plan (what you'll do if the risk happens) Risk owner (a member of the project team) Status (e.g. closed: no longer a risk)
At weekly team meetings risk owners report, briefly, on the status of their risks. What planned (or unplanned) actions are being taken to reduce the risk. Is the risk receding or growing? This should ensure that the team is involved in risk reduction activities and in refining the risk management plan. Keep the register updated - relegate receding risks, promote growing ones. New risks can always crawl out of the woodwork as you go along - if they are significant add them to the register.
Each month the project manager should report to the sponsor on the status of key risks. With any luck you'll be reporting your success in dealing with the risks, but if risks are growing you should obviously alert the sponsor to that. Copyright M Harding Roberts 5. Modify At the end of each stage of your project hold a post mortem. Look at the risks you identified at the outset. Record what you did successfully to deal with each risk, what you tried that did not work, and what you would do next time with the benefit of hindsight. These ways of addressing risks will be useful not only to you and your next project, but also to other project managers. Some organisations have a Project Support or Project Assurance or similarly named project management 'centre of competence'. If such exists in your organisation, send your list of addressing factors to them. When a future project manager is starting a project and has identified a risk he has no idea how to mitigate, he can call up Project Support and ask "what has worked well in the past?" Ideally Project Support will be proactive in modifying the organisation's risk checklists. They will add new risks that are actually being experienced and delete risks that are no longer applicable within the organisation. Ideally they would also seek out successful strategies for addressing risks and proactively feed these forward to future projects. Remember: No risk checklist will list all the risks that your project faces: projects are all different, which is why project management is such fun. Project risk assessment is a "brain in gear" activity: it is not about filling in a checklist and forgetting it. Risk assessment doesn't reduce risks: you must do something to reduce them - if you don't attack the risks, the risks will attack you. Reduce risks at the start, but continue to reduce them throughout the project. Finally Managing risk is not the same as being afraid to take risk. On the contrary, doing very high risk projects is sometimes the right thing to do. But if the project is very high risk everyone must be aware of that and the project must be wrapped in cotton wool to make it succeed in spite of all the risks. And with appropriate management attention, contingency and whatever, i.e. with proper risk management, very high risks projects can be perfectly successful.

Risk Management in Software Projects

Uploaded by

Copyright:

Available Formats

Risk Management in Software Projects

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Risk Management in Software Projects

Uploaded by

Copyright:

Available Formats

Risk Management in Software Development Projects

A Straightforward Approach to Project Risk Management by Mike Harding Roberts

Project Risk Management

You might also like