A systems engineer and project management consultant, Payson Hall is a founding member of Catalysis Group, Inc. During his thirty-year profesisonal career, Payson has been a writer and featured speaker on topics of systems integration, project management, and risk management.
Noel Wurst: With "project failure" being an obvious potential result of poor risk management and analysis, why do you think companies have continued to fail to efficiently adress the need for risk management?
Payson Hall: Many organizations hesitate to candidly confront how difficult large software projects really are. System size and complexity, project duration, the number and ongoing evolution of external interfaces, diversity of end user populations, complexity of governance, the challenge of working with systems integration firms... all these factors push our capability to deal with uncertainty and risk to; and sometimes beyond; reasonable human limits. It doesn't have to be as dramatic as huge-smoking-crater-failure-and-cancellation.
If we define "large" projects as those that cost over $25M USD and last 18 months or more, I think most in the industry would say that the majority of those projects either finish significantly late, over budget, or with less functionality than originally anticipated - the majority of them! Large projects that finish on or ahead of schedule, under budget, delivering all promised functionality are the rare exception, not the rule.
But that's not the story many organizations tell themselves or their sponsors. If we can't admit there is a problem, then allocating resources to dealing with the problem is hard to justify. It seems to me we are slowly making progress on this front, but it is an ongoing challenge.
Noel Wurst: Your upcoming Better Software Conference East presentation mentions "Twelve Risks to Enterprise Software Projects" - this sounds like a lot! What's the best way to make sure that each of these risks are addressed and handled before beginning such a project?
Payson Hall: Large scale software development or implementation projects often begin with dozens of risks. Many of these can be addressed with effective planning, but before you and your team can effectively address risks, you must establish a cultural environment where it is ok to talk about them so they can be identified.
If you can get past the taboo about admitting that you don't have perfect information and that some project elements are beyond your control, a good team can often identify several alternatives to reduce the likelihood and impact of significant risks.
Noel Wurst: You've mentioned that a positive attitude is simply not enough and that "failure is not an option" cannot be an option. How do these two things each prohibit effective risk management.
Payson Hall: Some organizations have difficulty admitting that they can't completely control all of a project's variables. Others seem to believe that positive thinking will overcome all obstacles. Either approach results in difficulty openly discussing risk. Ironically, if risk can't be discussed - it is much harder to invest in prevention and remediation and the potential danger is much greater.
Imagine trying to teach someone to drive a car in a universe where you were not allowed to discuss ways that a car can fail and what might be done to prevent the failure or respond. You can't discuss how to fix a flat or potential causes and how to avoid them. You can't discuss how a car might behave if it blew a tire at freeway speeds. You can't mention the value of properly inflated tires or the wisdom of periodic tire inspection. The result will be a poorly prepared driver who is less safe and unprepared for situations that most of us know can occur.
Noel Wurst: What is the first step involving risk management that a company beginning an enterprise software project needs to take in order to get off on the right foot?
Payson Hall: Have an open dialog, first with executives and then with the team about previous project efforts, including what worked and what could be done better. One of the best sources of risk information for an organization trying to get serious about risk is the "surprises" and "issues" experienced by that same organization on recent projects. These risks aren't theoretical, they are real and confirmed by recent, relevant experience.
It is much easier to sell management on avoiding making the same mistake twice than selling them on advanced theories of statistical risk management. I think the key is to start small, but START. An organization's own history is a great starting point.
The other important point is, don't oversell your efforts. Some of the risks you try to defend against may occur despite your best efforts. As we discussed earlier, some risks will occur that you didn't anticipate. It's important to set realistic expectations with project sponsors and the team. Risk management has a cost. There is a business decision about trade-offs that must be made.
For example, your car probably has a spare tire. You pay a price in storage capacity and fuel economy to carry that spare around with you. If you own your car for five years and never need to use the spare, was it a bad idea to have one? Most people who have had a flat tire and needed a spare in the middle of nowhere will tell you that the spare is a good idea whether it is used or not. If one spare is good, are two spares better? At some point, it's an odds game. The likelihood of two tires failing at the same time is judged by most people to be small enough that making the investment and devoting the space to a second spare doesn't seem cost effective.
Noel Wurst: Is there something that companies can do to ensure that they've explored every risk before beginning a project, and that something isn't going to sneak up and catch them off guard?
Payson Hall: One of the challenges of risk management is that you can never identify ALL possible risks. There will always be surprises. What you can do is try to identify things that have been issues on similar projects in the past, where "similar" means projects delivering similar function, or working with similar organizations, or working with similar processes or tools.
One of the things I encourage my clients to do is give themselves permission to make mistakes, but try to fail for reasons that no one could have reasonably anticipated. Don't be the team that is late because it underestimated the effort required for data conversion. .. that excuse is worn. Be the team that is delayed because a meteor destroyed your project site over the holiday break... THAT is a really good excuse that you can't have been expected to defend against.
Then when you point out that losing the site only cost the project a two month delay because you had offsite backups of all significant system components, people will begin to suspect the the value of risk management.