real risk doesn't have a tremendous amount to do with building software. That's not a very difficult thing. The difficult thing to do is understanding what software will correctly fit into an organization and then causing that software to do its work on the organization, which means changing the organization. Organizations are resistant to change and any executive who decides, "Gee, we ought to change in the following way-- we ought to centralize sales or decentralize accounting" or something like that. The very first thought they have as to how to do that is, "We'll call in the software folks and get them to build a piece of software that does the dirty work." So, building the software is the easy part and doing the dirty work (i.e. effecting a change) on an organization, that's what you built the software for and that's where all the risk lies. So, it's not just the experts that tangle with risk; it's virtually every software project leader has to come face to face with this risk because software effects change and organizations have change-resistance, change-reluctance.
CAROL: So, you are talking about more than just doing project management. The project manager who has taken all the project management courses and goes through and lays out their schedule in Microsoft Project or in some other thing, and...and goes through and has the user meetings... that's not risk management.
TOM: No...no, in fact, a very simple test for risk management is to look at the project plan laid out in Project or in any other scheme, and ask the people involved, the people who understand the project, to point to a task that might not happen at all. In most projects the personnel will stare at you in complete lack of comprehension. They say, "Well, why would we have something on the project plan that wouldn't happen at all" and my answer to that is because that's a risk. It's something that may happen or may not happen, and if you don't have a plan for what happens, if it happens, what your response is going to be, then you're not doing risk management. So, putting together a schedule of all of the things that must necessarily happen on the project doesn't include all of the things that might happen on the project, and therefore, it's not really managing risk.
CAROL: Right, and there are probably people saying, "Well, if we had to lay out in a project plan every possible eventuality that could possibly happen, we would never get software developed in the first place."
TOM: No, that's true. There are always risks that you cheerfully ignore. I mean one of them was cited as an example by the people in our risk management course. What's a risk that you would be willing to ignore, and he said, "Sun goes Nova." The sun explodes...
CAROL: Right...
TOM: There's a certain probability would happen, it would have disastrous consequences, but I'm gonna ignore that. So, there are lots of low probability situations that you ignore. On the other hand, there are some core risks common to all projects. I think that there are five or six core risks common to all projects. For instance, inflation of the product; it grows from the time it's first specified until between that time and the time when the first delivery is made that the requirement has grown. Now, that...that core risk is common to all projects, and if you had a risk list that didn't include that one or any of the other core risks, then I would say
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
