- 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?