1 / 20

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

Why IT projects fail (and what to do about it). Robert Barnes Director, iE3 (robert.barnes@xtra.co.nz). We all “know” that IT Projects. Are too expensive, Take too long, and are too-often Abandoned without completing. Estimation of Benefit.

luann
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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”

More Related