« Incorporate Contingency Buffers in Your Project Schedule
Project Steering Committee Responsibilities »

The Main Issues with Project Risk Management

September 15, 2008 | Author: PM Hut | Filed under: Risk Management

The Main Issues with Project Risk Management
By Pawel Brodzinski

When you try to implement a methodology or invite a habit in your organization it won’t ever go without any problems. People don’t like to change, albeit their adaptation skills are high. Someone has to overcome the resistance and make whole thing working. He needs to find out what exactly doesn’t work and why. MSF is no different here.

One of hardest parts of MSF to implement is risk management. It’s funny because when you read about that it looks so reasonable and it all makes sense. We unconsciously manage risks in our lives whole time. Unfortunately, people’s attitude changes when it comes to a bit more formal process, which involves regular participation. Here are some typical issues with risk management. It’s based on an MSF implementation example, but the case is general.

  • This is too general – I don’t see how it can work. That’s one problem with defining a risk: if it’s too general, e.g. “new version will be released late” it says nothing about the real problem – potential reason why there can be a slip. Lead developer will be sick. Our last tester will change jobs. Program manager is taking holidays during the last two weeks of the timeline. A reason should be named, not a result. And remember many reasons lead to the same result, so in this case naming a reason will bring a more detailed risk.

  • This is too detailed – I don’t understand the problem. That’s another problem with defining a risk: if it’s too detailed, e.g. “problems with multi-threading in the new API function will result in overrunning the code complete milestone”, no one understands it. This risk is probably understandable by two or three developers actually using the function. For the rest of the team there will be a bigger impact on the project. They don’t understand the risk and that’s why they won’t rate it high, so you can spare some time with not adding it to the list. Either make it understandable or throw it away.

  • Where’s the avoidance plan? That’s the hardest way of inventing a risk. Usually it’s easy to name the threat and rather not difficult to find an emergency plan. But when you don’t equip your risk with a good avoidance plan it’s almost worthless. OK, we can be late with the project, but what should we do to ship on time? The answer can’t be just: “work harder,” it should be something different from the things you’d do normally if there was no risk. Recruit someone, plan some bonuses for working overtime, switch some tasks between people, negotiate deadlines with customer, do something new. Of course sometimes no matter how hard you try you won’t come up with anything reasonable here. You just have to accept the fact that the risk is going to materialize – you aren’t shipping on the end of the month. There’s nothing more to do.

  • I don’t see any change. OK we have our nicely crafted risks, we vote for them and discuss them on weekly basis, but where’s the difference? In the top 5 list there’s always the same set of risks, the same set of people responsible for them and the same things told. “This week nothing changed.” If really nothing changed person responsible for the risk should be ashamed, but usually something changed but it’s not reported because it doesn’t seem important. “Most of planned tests in accounting module were done, number of bugs increased, but we finally closed the tricky issue with deadlocks. In my opinion risk still stands high, even a bit higher as we’re a week closer to the deadline, but we’re moving forward.” Do you see a change now? There can be another reason – when often nothing changes and it doesn’t need to be the problem with people, it’s possible that you evaluate risks too often. I don’t say that weekly basis will work for every project.

  • Hey, that’s another thing I have to do. That’s obvious. Evaluating risks takes several minutes per week, but still it’s another thing to do. No one wants more bureaucratic work. Unless people believe that it really works it’ll always be something they do because they have to.

  • I don’t believe in it. That’s the most important and hardest to resolve issue. When you apply the risk management process it doesn’t work perfectly from the very beginning. I’d even risk a statement that risk management on the very beginning doesn’t work at all. Even when it starts working, results are usually seen at the management level – most of the team doesn’t see a difference even if you’ve ruled out a risk overrunning the deadline. After some time it becomes another duty which has to be done but gives nothing in exchange. You can’t tell the team to believe in the process. They have to see it working.

The key thing is to have confidence that risk management works. If you can convince the team that it’s helpful you’re more than halfway home. The rest can be and will be altered during risk management sessions.

Pawel’s experience in software development covers a bunch of positions in both rank and file and management roles. He worked in quality assurance, software development, design, support and implementation teams. He also managed different teams from small group of testers up to ERP system development department. While spending most of his career working on enterprise and carrier grade systems, he did play some roles in micro-ISVs. He’s currently the Chief Operating Officer in Wind Mobile (www.windmobile.pl). Pawel’s blog can be found at: blog.brodzinski.com.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Monday, September 15th, 2008 and is filed under Risk Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories