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.
The Non Scrum - I recently joined a newly formed team at work. The whole project was changing how they tracked work. We were going to have a daily scrum. Great. Sounds li...