1 / 20

Do Construction Methods in IT Lead to Rotting Systems?

Do Construction Methods in IT Lead to Rotting Systems?. Robert Barnes (robert.barnes@xtra.co.nz). We all “know” that IT Projects. Are too expensive, Take too long, and are too-often Abandoned without completing. In contrast, Building projects. Usually complete on time & budget

sissy
Download Presentation

Do Construction Methods in IT Lead to Rotting Systems?

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. Do Construction Methods in IT Lead to Rotting Systems? Robert Barnes (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. 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

  4. “We should run our IT projects like Construction Projects” • 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 • Project Manager is King! “Where Project Managers are King” – Project Management Journal, December 2001 “Who does it better – IT or Construction” - Robert Purcell, PMI NZ Conference 2002.

  5. But there are significant differences in our situations • Some construction practices would be helpful, But • Others are highly counter-productive

  6. 1 Understanding Requirements Who understands the client requirements better?

  7. 2 How important is “Getting it right first time” • Construction industry – later change usually impossible • Strong emphasis on DIFOTIS(Delivery In Full, On Time, In Spec) • IT – later change may be easy

  8. 3 Modelling Tools • Do we have an equivalent in IT? • If yes, does it communicate as effectively? • What is the Design/Build ratio • In Construction • In IT Do we have an equivalent in IT? If yes, does it communicate as effectively?

  9. 4 Iterative Design Can we use the same tools for design and building? Can we grow a Hut -> House -> Hotel? Can we grow a Personal System -> Department system -> Enterprise System Iterative design is not only possible, it’s a Best Practice! ? ?

  10. 5 Subcontractors Could we subcontract IT tasks? If yes, why don’t we? If no, why not?

  11. 6 Estimation Metrics

  12. 7 Experience Experienced Novice, Rapid Skills Increase Where (on this curve) do programmers work? What about builders?

  13. 8 Quantity Surveyors (= Estimators) Do we use independent estimators in IT? Why not?

  14. 9 Inspection and Building Codes • Are there any equivalent IT standards? • Should there be? • Why aren’t there?

  15. Conclusion – running IT like Construction might be the WORST thing to do!

  16. So what’s the IT Project Manager to do? Scope Cost. Time Cost Especially when faced with the usual management approach!

  17. 1 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

  18. Analyse Design Code Test Deliver 2 Use appropriate SDLC Model • Waterfall • Code and Fix • Prototyping • RAD • FDD • Spiral • eXtreme Programming Rapid Development, ch 7 “Horses for Courses”

  19. 3 Do Small Projects • Small projects • Lower risk • Lower cost • Conclusion • Break projects up • Version Releases, Deliver early, deliver often • Frequent REAL Milestones. Grosh’s Law (I think): - “If a project does not produce something useful in < 6 months, it never will”

  20. 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

More Related