Risk Management

I read a blog entry by Glen Alleman entitled “Risk Management is How Adults Manage Projects”. From the title, I get the impression that Glen has been on some projects that lacked adult supervision. The sad thing is that it sounds familiar. Glen had a lot to say about risks that hit home with me. I figured I would review some of his thoughts, and share some thing I learned after reading his blog.

You cannot hope that things will be done in software development. Estimates from developers are usually random. You need a risk management process, as well as a risk management plan. The factors involved include cost, schedule, and performance. If you do not mitigate risk, you are already failing.

Now I have been on some software projects which lacked risk management, and they turned out fine. That may have been luck. I have also been on project with both risk management plans and processes. However many of those project failed terribly. Therefore I would not say that the presence of such a plan does not guarantee success.

Perhaps you need to do risk management correctly. The first project I was with that bombed had a risk management plan. However it was taken straight out of Risk Management 101. And it was mostly lip service to impress the customer. I will say that the customer was not impressed when the project fell apart and was deeply behind schedule when they needed it delivered.

I have been on other disaster projects that had huge risk management plans. They did a little more than provide lip service. There were processes that tracked some top risks. However the mitigation plans were totally lacking. This too resulted in huge failure. Embarrassing.

Some people who commented on the original blog entry referred to the DoD handbook. I can say that I never heard of such a thing. So I researched it on the web. The official name of that document is MIL HDBK 1908B. It covers early risk reduction through prototyping. It defines risk as a “possible loss of function and/or degradation in performance”. There is a lot more to this handbook. I just skimmed it today. It might be required reading for managers.

Lead By Example

As the author of the Software Maintenance blog can attest, a great Project Manager will lead the troops by example. Developers often need to stay late due to strict schedules. This is accepted as part of the business. One would think that the project manager of such a developer would want to stay late as well. It does not matter whether the manager has any real work to do. There is something to be said about being in a tough predicament together.

Merely staying late does not immediately qualify you as a good project manager. A truly exceptional one will manager a project such that you normally do not have to stay later. However there are often circumstances beyond the best intentioned manager's control. So at the minimum you should be willing to stick around or pull the all nighter if your staff is doing the same. Otherwise the staff will be asking themselves why they should be making the sacrifice when you are not willing to do the same.

This principle is a specific case of the general one to lead your troops by example. You can make all the speeches in the world. However if your actions betray your words, even simpletons will see through your hypocrisy. Step up to the plate. Roll up your sleeves. Stay in the trenches with your developers. They will take notice.