1. These are the slides for our Why Projects Failtalk. Weve given it many times, and it alwaysgets a good response. If youd like us to comeWhy Projects Failand give it for your group or organization, contact us at http://www.stellman-greene.com.Photo by Dan Taylor (CC license) and what you can do about it Even if its no t your fault!A presentation by Jennifer Greene and Andrew Stellman

2. Who we areJennifer Greenes spent thelast 20 years or so managingdevelopment and testing teams.Andrew Stellman started dprogramming in the 80s, anlost count of how manylanguages hes worked with.Shes currently doing ginconsulting and trainlargefor a group with a m.Hes led teams of (500 person) IT teaprogrammers,requirements analystsand process engineers.Jenny and Andrew truly believe that with better development practicesand good programming habits, we can all build better software. 3. Our books 2007 (1st ed) 2009 (2nd ed)2008 (1st ed)2010 (2nd ed)2005 2010 4. WARNING: This is NOT an academic presentationThe topics we are about to cover may be deadly serious, but we wont be If you want academic slides, weve got em: http://www.stellman-greene.com/slides 5. Not all failures are this easy to spotbut someprojects do fail spectacularly. The Tacoma Narrows Bridgeproject failed before the firstyard of concretewas poured.t n.r ong with the construcg ioThere was nothing wdly planned cost cuttin in Poor design and bato an unfortunate end.materials led If this video doesnt play, try using a newer version of Acrobat or you can download the video here: http://www.stellman-greene.com/GallopingGertie 6. This time its differentTheres an old saying about how there are a millionways to fail, but only one way to be right. When itcomes to projects, nothings further from the truth.Projects fail the same few ways over and over again. Dont go in the basement!Software projects are a lot like cheesy horror movies. After youveseen a few of them, you know that the rst guy to leave the group is goingto get an axe in his head. Projects are the same way. People keep makingthe same mistakes over and over, and it keeps getting their projects killed. 7. You know youre on a failed project whenA judge in 1964 said, I dont know how to denepornography, but I know it when I see it. And thesame goes for failing projects - we all know whenwere on one thats sinking.What does a failing project look like? You know your project failed if it got aborted and everyone was laid off. But there are other, less obvious kinds of failure:! The project costs a lot more than it should.! It takes a lot longer than anyone expected.! The product doesnt do what it was supposed to.! Nobody is happy about it. 8. Sometimes failure seems normalNobody sets out to fail, but for some reason people justaccept that a lot of software projects wont deliver on time,under budget with the expected scope intact. But talkingabout what causes failure makes people uncomfortable,because nobody wants to give or take that kind of criticism.A show of hands, please Jenny and I have never met a single professional developer, tester or project manager with more than a few years of experience working on software projects who hasnt been on at least one failed project. Are there any here? 9. Four basic ways projects can failThere are plenty of ways that you can categorize failed projects. Ilike to think of them like this:! Things the boss does Classic management mistakes that can damage the project! Things the team shouldve done Once in a while, it really is the teams fault! Things the software does (or doesnt do) How your project doesnt quite meet the needs of the people you built it for! Things that could have been caught but werent until it was way too late 10. Things the boss doesSome problems start at the topand when were managing teams(or when were leading ourprojects), that means a lot ofproblems that affect other peoplestart with us.! Unmanaged changes ! Micromanagement ! Over-reliance on gut instincts ! Tunnel vision ! An articial wall that thebusiness puts up to disconnectfrom the engineering teamLike it or not, when youre leading a project team youre the boss! 11. Up close: A Vision & Scope Document keeps everyone on the same pageThe Vision and Scope document is where you dene whoneeds the product, what they need it for, and how it willfulll those needs. 12. Things the team shouldve doneThe team could have done the workmore efciently, if only wed takenthe time to think it through. ! Itll take about three weeks ! Padded estimates compensate for unknowns. ! Project teams will just pick a deadline and stick to it, no matter what basic reason and common sense tell them. ! Somehow non-programming tasks always seem to get cut when the deadline gets closer.! Misunderstood predecessors lead to cascading delays. 13. Up close: Wideband Delphi keeps estimates honestWideband Delphi is a repeatable estimation process thatguides your experts and team members so their estimatesconverge accurately.TheWe cover Wideband Delphi in detail in the Estimation chapter ofApplied Software Project Management - download the PDF here:http://www.stellman-greene.com/chapter3 14. Things the software does (or doesnt do) It seems pretty obvious that you should know what the softwares supposed to do before you start building it... not that that stops us. ! We only nd serious problemsafter weve built them into thesoftware! We have big, useless meetingsthat fail to gure out what thesoftwares supposed to do ! Scope creep ! 90% done, with 90% left to go. 15. Up close: Use cases can help you avoid requirementsproblemsUse cases are a deceptively simple way to document every plannedinteraction between the users (and other actors) and the software.Learn more about use cases here: http://www.stellman-greene.com/usecase 16. Things that could have been caughtWhich would you choose: a well-built program that doesnt dowhat you need or a crappy onethats irritating to use and does?! Getting a few tech support people to bang on the software is not testing.! Maybe we couldve caught that design problem before the code was built.! Maybe we couldve caught that code problem before we went to test.! Beta does not mean use at your own risk. 17. Up close: Dont overlook your acceptance criteria!Its short-circuited far too often in favor of useracceptance testing, but, acceptance testing is aboutmore than just user acceptance. 18. What you can do about itSome easy ways to make sure your projectdoesnt fail: ! Tell the truth all the time ! Trust your team ! Review everything, test everything ! Check your ego at the door ! The fastest way through the project is the rightway through the project 19. Repeat after me: Practices, practices, practices.The solutions I talked about are only a fewsmall steps towards a better softwareprocess. ! Process improvement starts with setting concrete goals and making incremental improvements. ! Theyre good solutions to specic problems, but they might not solve your problems. ! There are lots more solutions where those came from. And the ones we chose were the ones that we could explain quickly. ! Make sure the solutions you choose address the problems that hurt the most. 20. One last quick note from the marketing department Buy thesebooks! And check out our blog, Building Better Softwarehttp://www.stellman-greene.com/ Thanks for coming! Any questions?