Why IT projects fail (and what to do about it)

1. Why IT projects fail(and what to do about it) Robert Barnes Director, iE3 (robert.barnes@xtra.co.nz)

2. We all “know” that IT Projects • Are too expensive, • Take too long, and are too-often • Abandoned without completing

3. Estimation of Benefit • Our ability to estimate project cost may be poor … • But it is brilliant when compared to our ability to estimate benefit! • The real difficulties:- • What do we want the system to do? • What effect will this have on our business?

4. In contrast, Building projects • Usually complete on time & budget • Usually meet expectations • Are rarely abandoned • Different companies quote broadly similar amounts for the same thing

5. So why don’t we do in IT as we do in Building:- • Specify EXACTLY what we’re building • and prepare a detailed contract and plan • Sign off specification, and don’t change the target without proper change control

6. But this can be the WORST thing to do!

7. So what’s the project managerto do? Scope Cost. Time Cost Especially when faced with the usual management approach!

8. Size/Cost Project Size

9. Size/Risk. Some Industry Data Project Size (Function Points) Software Productivity Research (Capers Jones), 1996

10. 1 - Small Projects • Small projects • Lower risk • Lower cost • Conclusion • Break projects up • Frequent REAL Milestones. Grosh’s Law (I think): - “If a project does not produce something useful in < 6 months, it never will”

11. Standish Group - Risk Index www.standishgroup.com/visitor/voyages.html www.standishgroup.com/visitor/chaos.html

12. 2 Involve Users • How do you involve users? • Getting sign-off on voluminous specifications doesn’t do it • Need to communicate well • New system - need a prototype • Package - work closely with similar customers • Implement in stages

13. Versioned Releases Benefits • Force closure on project issues • Set clear and motivational goalswith all team members • Manage the uncertainty and change in project scope • Encourage continuous and incremental feature delivery • Enable shorter time to market

14. 3 Use Incremental Product Releases Plan Plan Develop Develop Market Market Support Support

15. Fast vs Good Efficient vs Simple Economical vs Well documented and maintainable Extensive (expensive?) project management and on-time vs out of control and late They’re (largely) wrong! Many believe that you have to choose:-

16. Effort and error rate Only life- or mission- critical projects Most projects Project Effort Efficient projects Percentage of Bugs Removed before release After the Gold Rush P 52 Capers Jones - Applied Software Measurement

17. 4. Build in quality • It is cheaper and faster to build quality it, through • Code Inspection • Documentation AS YOU GO • Avoiding or deferring $$ on quality is very false economy. • Focus on lifetime net benefit • not project actual cost/budget cost

18. Relative Cost of Change • Later Change is MUCH more expensive SDLC’s attempt to solve problems earlier

19. Risk increases with leading-edge systems Does “On-time, On-budget” imply “Routine Project?” New Business New Tools Reward New Business Old Tools Business understood, New Tools Routine, Old Technology Risk

20. Analyse Design Code Test Deliver 5. Use appropriate SDLC Model • Waterfall • Code and Fix • Prototyping • RAD • Spiral Rapid Development, ch 7 “Horses for Courses”