I have seen technical risk described in many ways. One definition that I am particularly fond of was written almost ten years ago. In 2008, Mike Cottmeyer wrote:
Technical risk deals with those unproven assumptions in your emerging design that might significantly impact your ability to deliver the solution. Are we planning to use any unproven technologies to build the solution? Have we exercised the significant interfaces between systems? Can we demonstrate a working skeleton of the system? What about performance? What about security? Any technical decisions not validated by working software count as technical risks.
Technical risk is, arguably, the most dangerous type of risk that a project team could face because it is often the least understood. Identifying the risks may prove to be nearly impossible without concerted effort, let alone attempting the establishment of sufficient reserves in time or funds. Despite the fact that so many organizations readily acknowledge the threat of technical risk on a project, few follow-through by establishing a methodology that can successfully address it.
I have been asked, does technical risk only apply to software projects? The answer is no, it can apply to anything where we have gaps in our knowledge. These gaps may result from some aspect of the project that we either do not fully understand or through the depth of complexity we have failed to acknowledge. The Wright brothers spent four years developing the first airplane, and then a further two years improving it enough to be useful. Boeing’s Everett factory has a 49 day average build time for a 777.
This time lapse is awesome to watch but I can’t help but imagine the stress that the project management team is under during it. But as we watch the work proceed, does it look like it they’re having any issues figuring out what to do next? The AIDAprima was not a first, even though its $645 million price tag and two-year delivery time may lead you to believe it was the only of its kind. This video shows you what a complicated project, effectively managed, looks like.
The difference between complicated and complex is an important one. The construction of the AIDAprima was complicated, but they knew exactly what they had to do, and when they had to do it. They could account for risks that had been experienced on previous, similar projects. They were using tried and tested technologies and techniques that were implemented by experienced practitioners. It is hardly surprising that the project made for a great time lapse.
The description of the AIDAprima in the previous paragraph is sufficient to demonstrate that technical risk was not present, at least in any significant amount. Think about how the Wright brothers were not just building a deliverable, but also learning how the deliverable should work as they were pioneering the application of aeronautics. Contrast the construction of the AIDAprima with the Wright brothers as you consider the following questions as a high-level means of determining technical risk.
- Has our organization ever managed a project of this type before?
- Have the technology or the techniques to implement it been successful anywhere else previously?
- Are we able to clearly articulate how requirements will be fulfilled?
Needless to say, if these answers are in the negative, then your project is likely facing a lot of technical risks. Addressing it effectively and developing realistic timelines and budgets are still possible, but take a far different approach than most organizations use. There is no ‘one size fits all’ so organizations must tailor an approach to address complexity.