3.8 Risk in IT and Agile Project Management
The IT world faces a slew of risks related to the complexity of the products and services it provides. As a result, IT projects are notoriously susceptible to failure. In fact, a recent survey reported a failure rate of over 50% (Florentine 2016). This figure probably under reports the issue because it focuses on the success rate for IT projects in the short run—for example, whether or not developers can get their software up and running. But as software companies rely more and more on a subscription-based business model, the long-term life cycle of IT products becomes more important.
Indeed, in a world where software applications require constant updates, it can seem that some IT projects never end. This in turn, raises more risks, with obsolescence an increasing concern. Add to this the difficulties of estimating in IT projects and the cascading negative effects of mistakes made upfront in designing software architecture, and you have the clear potential for risk overload.
By focusing on providing immediate value, Agile helps minimize risk in software development because the process allows stakeholders to spot problems quickly. Time is fixed (in preordained sprints), so money and scope can be adjusted. This prevents schedule overruns. If the product owner wants more software, she can decide this bit-by-bit, at the end of each sprint.
In a blog post about the risk-minimizing benefits of Agile, Robert Sfeir (2015) writes,
“Agile exposes and provides the opportunity to recognize and mitigate risk early. Risk mitigation is achieved through cross-functional teams, sustainable and predictable delivery pace, continuous feedback, and good engineering practices. Transparency at all levels of an enterprise is also key. Agile tries to answer questions to determine risk in the following areas, which I will discuss in more detail in a future post:
- Business: Do we know the scope? Is there a market? Can we deliver it for an appropriate cost?
- Technical: Is it a new technology? Does our Architecture support it? Does our team have the skills?
- Feedback (verification & validation): Can we get effective feedback to highlight when we should address the risks?
- Organizational: Do we have what we need (people, equipment, other) to deliver the product?
Dependency: What outside events need to take place to deliver the project? Do I have a plan to manage dependencies?”
Keep in mind that in all industries, simply identifying threats is only the first step in risk management. Lots of time and money could be lost by failing to understand probabilities and consequences, causing your team to place undue management focus on threats that have a low probability of occurrence, or that may have minimal impact.