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 was 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 MSF implementation example, but case is general.
1. That’s 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 real problem – potential reason why there can be a slip. Lead developer will be sick. Our last tester will change a job. Program manager is taking holidays during last two weeks of timeline. A reason should be named, not a result. And remember many reasons leads to the same result, so in this case naming a reason will bring more detailed risk.
2. That’s too detailed – I don’t understand a problem. That’s another problem with defining a risk: if it’s too detailed, e.g. “problems with multithreading in new API function will result in overrunning 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 project when coffee is over. 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.
3. 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 emergency plan. But when you don’t equip your risk with good avoidance plan it’s almost worthless. OK, we can be late with the project, but what to do to ship on time? The answer can’t be just: “work harder,” it should be something different from things you’d do if there were 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 with anything reasonable here. Then you just accept the risk is going to materialize – you aren’t shipping on the end of the month. There’s nothing more to do. Shit happens.
4. 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.
5. 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.
6. I don’t believe in that. That’s the most important and hardest to resolve issue. When you invite 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. What more, even when it starts working, results are usually seen from management level – most of the team doesn’t see a difference even if you’ve ruled out an overrunning the deadline risk. 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 works. Personally I started to believe in risk management after more than a year of participating. We ruled out two top risks only because we were working on them during whole development cycle and that was because they were topping during risk management sessions. When something like that happens show it to the team: “Look, after first sessions we feared this and that and when we were finishing a version do anyone even remember that?”
The key thing is 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. The hardest thing is improvement in people’s confidence.