Why Projects Fail…

…and what you can do about it.

Even if it’s not yourfault!

A presentation by Andrew Stellman and Jennifer GreenePMINYC Breakfast RoundtableJanuary 23, 2008

Pho

to b

y D

an T

aylo

r (C

C li

cens

e)

Who we are…

Jenny and Andrew truly believe that with better development practicesand good project management habits, we can all build better software.

Jennifer has managedlarge software teamsdistributed overmultiple continentsfor billion-dollarcompaniesShe is a PMP-certifiedproject manager witha strong backgroundin qualitymanagement andsoftware testing

Andrew is anindependent consultanthired by softwareengineering contractingcompanies to managelarge-scale, globallydistributed softwaredevelopment teamsHe is a graduate of theSchool of ComputerScience at CarnegieMellon University and isa PMP-certified projectmanager

Andrew and Jenny each have over15 years of experience in softwareengineering, and have been workingtogether since 1998

Textbook on software projectmanagementUsed as a textbook inuniversity graduate softwareengineering coursesFocuses on practices aimed atsolving specific projectproblems(…like the ones we’ll talkabout in this presentation!)

Applied Software Project Management

Head First PMPSecond-best selling PMPpreparation guide, after less thana year on the marketThousands of copies sold in thelast quarter aloneRave reviews from members ofthe PMBOK® Guide leadershipteam (“by far the best PMPexam preparation book I havereviewed” - Dennis Bolles, PMP)Uses a unique style with humor,graphics and an emphasis oncognitive learning principles tohelp people understand theconcepts without rotememorization

Head First C#A brain-friendly guide tolearning the C# programminglanguageCovers basic C# syntax, objectoriented programming,debugging, and good habitsLots of great exercises, puzzlesand programming projectsTeaches about animation andwriting video gamesOne of the top-sellingprogramming language bookson the market

Coming Soon: Beautiful TeamsA follow-up to the bestsellingbook, “Beautiful Code”Stories from a wide range ofpeople about software teamsthey’ve worked onStories from programmers,project managers, academics…our goal is to get as wide a rangeof experiences as possible for ourreaders to learn fromRoyalties will be donated toPlayPumps InternationalWe’re still looking forcontributors! If you knowsomeone with a compellingstory to tell, please see meafter this talk.

What we do…We provide customized on-site training for project managersand software developers, tailored to your team’s specific needs:

PMP PreparationHands-On Estimation WorkshopsTime Management with Microsoft ProjectEffective Management and LeadershipProject Management for Distributed TeamsProgramming and Software Engineering Training

http://www.stellman-greene.com/training/

WARNING: This is NOT anacademic presentation

The topics we are about to cover maybe deadly serious, but we won’t be

If you want academic slides, we’ve got ‘em:http://www.stellman-greene.com/slides

Not all failures are this easy to spot……but someprojects do failspectacularly.

The TacomaNarrows Bridgeproject failedbefore the firstyard of concretewas poured. There was nothing wrong with the construction.

Poor design and badly planned cost cutting in

materials led to an unfortunate end.

“This time it’s different…”There’s an old saying about how there are a millionways to fail, but only one way to be right. When itcomes to projects, nothing’s further from the truth.Projects fail the same few ways over and over again.

Don’t go in the basement!Software projects are a lot like cheesy horror movies.After you’ve seen a few of them, you know that the first guyto leave the group is going to get an axe in his head. Projectsare the same way. People keep making the same mistakesover and over, and it keeps getting their projects killed.

You know you’re on a failed project when…A judge in 1964 said, “I don’t know how to definepornography, but I know it when I see it.” And thesame goes for failing projects - we all know whenwe’re on one that’s sinking.

What does a failing project look like?You know your project failed if it got aborted and everyonewas 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 doesn’t do what it was supposed to.Nobody is happy about it.

Sometimes failure seems normalNobody sets out to fail, but for some reason peoplejust accept that a lot of software projects won’t deliveron time, under budget with the expected scope intact.But talking about what causes failure makes peopleuncomfortable, because nobody wants to give ortake that kind of criticism.

A show of hands, please…We’ve never met a single professional projectmanager with more than a few years of experienceworking on software projects who hasn’t been on atleast one failed project.Are there any here?

Four basic ways projects can failThere are plenty of ways that you can categorizefailed projects. I like to think of them like this:

Things the software does (or doesn’t do)How your project doesn’t quite meet the needs of thepeople you built it forThings the team should’ve doneOnce in a while, it really is the team’s faultThings that could have been caught…but weren’t until it was way too late.Things the boss doesClassic management mistakes that can damage the project

Things the software does (or doesn’t do)It seems pretty obvious that youshould know what the software’ssupposed to do before you startbuilding it... not that that stopsus.

We only find seriousproblems after we’ve builtthem into the softwareWe have big, uselessmeetings that fail to figureout what the software’ssupposed to doScope creep90% done, with 90% leftto go.

Up close: Use cases can help you avoid requirements problems

Learn more about use cases here: http://www.stellman-greene.com/usecase

Use cases are a deceptively simple way to document every plannedinteraction between the users (and other actors) and the software.

The team could have done thework more efficiently, if only we’dtaken the time to think it through.

Padded estimates compensatefor unknowns.Project teams will just pick adeadline and stick to it, nomatter what basic reason andcommon sense tell them.Somehow non-programmingtasks always seem to get cutwhen the deadline gets closer.Misunderstood predecessorslead to cascading delays.

Things the team should’ve done

Up close: Wideband Delphi keeps estimates honest

We cover Wideband Delphi in detail in the Estimation chapter ofApplied Software Project Management - download the PDF here:

http://www.stellman-greene.com/chapter3

Wideband Delphi is a repeatable estimation process that guidesyour experts and team members so their estimates converge accurately.

Which would you choose: a well-built program that doesn’t do whatyou need or a crappy one that’sirritating to use and does?

Getting a few tech supportpeople to “bang on thesoftware” is not testing.Maybe we could’ve caughtthat design problem before thecode was built.Maybe we could’ve caughtthat code problem before wewent to test.“Beta” does not mean “use atyour own risk.”

Things that could have been caught

Up close: Don’t overlook your acceptance criteria!It’s short-circuited far too often in favor of user acceptance testing,but, acceptance testing is about more than just user acceptance.

Things the boss doesSome problems start withsenior managers, others startwith us PMs. But they canall sink the project.

Unmanaged changesMicromanagementOver-reliance on gutinstinctsTunnel visionAn artificial “wall” thatthe business puts up todisconnect from theengineering team

Up close: A Vision & Scope Document keepseveryone on the same pageThe Vision and Scope document is where you define who needs theproduct, what they need it for, and how it will fulfill those needs.

What you can do about itSome easy ways to make sure your project doesn’t fail:

Tell the truth all the timeTrust your teamReview everything, test everythingCheck your ego at the doorThe fastest way through the project is the rightway through the project

Repeat after us: “Practices, practices, practices.”The solutions we talked about are onlya few small steps towards a bettersoftware process.

Process improvement starts withsetting concrete goals andmaking incrementalimprovements.They’re good solutions tospecific problems, but theymight not solve your problems.There are lots more solutionswhere those came from. And theones we chose were the ones thatwe could explain quickly.Make sure the solutions youchoose address the problems thathurt the most.

One last quick note from the O’Reilly marketing department

Buy thesebooks

And check out our blog, “Building Better Software”http://www.stellman-greene.com/

We’ll post these slides in the next few days.