IT projects still have an interesting track record. The chaos report (2009) from the Standish Group reports 32 % of IT projects are successful, 44% are challenged and 24 % fail.  Small projects (< 500 $) are more successful and big projects tend to fail more.None over 10 M $ are successful. These figures can give responsible managers a serious headache. Failing can have serieus budget implications for may years to come. In this post I will use research on cost mechanisms in IT projects and show how Scrum can be used to get IT projects in control.
Chris Verhoef investigated investment decision making in 600 project. He found out development cost tend to exponentially grow depending on the duration of the project.
He deducted a simple formula to check if the projected development cost makes sense:
D= duration in months
R= cost (tariff) one developer a day
W= workable days in a year
The formula for development cost in fact confirms the findings of the Chaos Report. Small project are more successful than big projects. The effects of budget overruns for development on the Total Cost of Ownership have a multiplier effect. Development Cost are 20 % of the Total Cost of Ownership. There are examples of organizations who have learned this lesson. In the Netherlands the Laures Group (supermarkets) got into serious problems because of the failing of an IT project (and other issues). The Laures Group had to sell supermarkets to survive.
Research on the use and the need of features gives a look under the hood of IT projects. In the DuPont study Jim Johnson concluded 25 % of the features where must haves and 75 % were nice to haves. Other research states that around in one year 25% of the features are changed because of the dynamics in business.
There is also evidence that up to 60% off features are never used (over-production). The reason for excess features in software development is a direct result of traditional waterfall methods. Product managers got one shot to get all the requirements out a the beginning of the 18 month project. So we forced them to think of absolutely everything. As a result we a spending large budget on nice to have features or features not used. Sadly it is difficult to determine upfront which features are the must haves. This is where Scrum comes in.
Scrum focuses on delivering the most important features every sprint. A sprint takes the maximum of 30 days. In a sprint a team develops potentially shippable software. After a sprint the software can be used in production and the cash inflow starts. In the next sprint the next important features can be build or depending on the experiences in production the business can decide to build other features or stop developing.
In a Scrum project the following metaphors are used for implementing features. At First we build a sandy road to implement a feature. This implementation can be deployed in production and the business can start using it. Based on their experience the implementation can be upgraded to asphalt road or high road. Upfront it is possible to determine the sandy road, asphalt road of high road implementation of a feature. Implement the sandy road and get the business on the road and use the feature.
Example:We have an IT project for developing 100 features in 12 months. In waterfall approach this project will cut in the phases design, develop, test and deploy. Hopefully after 12 months the system is delivered in production. The business will start using it. In an scrum approach the project is cut into 17 sprints of 3 weeks. After 6 sprints the sandy road implementation is delivered in production. Business can use it and decide on the asphalt and high road implementation.
Comparing these approaches and the researches the change of a budget overrun in the waterfull approach is higher because the duration is 12 months. In the scrum approach the change of bugetoverrun is smaller because the project is broken up in small projects with a duration of 3 weeks (in this example 18 weeks). In a waterfall approach there is no mechanism to prevent over-production of features. In the scrum approach this is possible because of in theory after every sprint a feature can be deployed in production and business can learn.
Summarizing: A scrum approach on IT projects gives the tools to prevent the mechanisms of overproduction of features. The focus on developing top business value features in short sprints prevents budget overruns. Lost projects can be determined in 3 sprints instead of 12 months. Deploying your first implementation after a few sprint in production has a nice side effect: cash inflow. In short :for financials a scrum approach get your it project in control
Notes:
The Standish Group, Chaos Report, 1994-2009
C. Verhoef, Quantitative IT Portfolio Management, 2002
Jim Johnson lecture at XP2003 conference, 2003″
