Why Projects Fail

Photo by Dan Taylor (CC license)
Why Projects Fail
These are the slides for our Why Projects Fail

talk. Weve given it many times, and it always
gets a good response. If youd like us to come
and give it for your group or organization,
contact us at http://www.stellman-greene.com.
and what you can do about it
A presentation by Jennifer Greene and Andrew Stellman
Even if its no
t
your fault!
Who we are
Andrew Stellman started d
programming in the 80s, an
lost count of how many
languages hes worked with.
Hes led teams of

programmers,
requirements analysts
and process engineers.
Jennifer Greenes spent the

last 20 years or so managing
development and testing teams.
Shes currently doinging

consulting and trainlarge
for a group with a m.
(500 person) IT tea
Jenny and Andrew truly believe that with better development practices
and good programming habits, we can all build better software.
Our books
2007 (1st ed)

2009 (2nd ed)
2008 (1st ed)

2010 (2nd ed)
2005
2010
WARNING: This is NOT an

academic presentation
The 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
Not all failures are this easy to spot

but some
projects do fail
spectacularly.
The Tacoma
Narrows Bridge
project failed
before the first
yard of concrete
was poured.
ion.
t
c
u
r
st
n
o
c
e
h
t
h
it
w
g
n
o
There was nothing wdrly planned cost cutting 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
This time its different

Theres an old saying about how there are a million
ways to fail, but only one way to be right. When it
comes 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 youve
seen a few of them, you know that the first guy to leave the group is going
to get an axe in his head. Projects are the same way. People keep making
the same mistakes over and over, and it keeps getting their projects killed.
You know youre on a failed project when

A judge in 1964 said, I dont know how to define
pornography, but I know it when I see it. And the
same goes for failing projects - we all know when
were 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.
Sometimes failure seems normal

Nobody sets out to fail, but for some reason people just
accept that a lot of software projects wont deliver on time,
under budget with the expected scope intact. But talking
about 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?
Four basic ways projects can fail

There are plenty of ways that you can categorize failed projects. I
like 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
Things the boss does

Some problems start at the top
and when were managing teams
(or when were leading our
projects), that means a lot of
problems that affect other people
start with us.
! Unmanaged changes
! Micromanagement
! Over-reliance on gut instincts
! Tunnel vision
! An artificial wall that the
business puts up to disconnect
from the engineering team
Like it or not, when youre leading a

project team youre the boss!
Up close: A Vision & Scope Document keeps everyone on the same page
The Vision and Scope document is where you define who

needs the product, what they need it for, and how it will
fulfill those needs.
Things the team shouldve done

The team could have done the work
more efficiently, if only wed taken
the 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.
Up close: Wideband Delphi keeps estimates honest

Wideband Delphi is a repeatable estimation process that
guides your experts and team members so their estimates
converge accurately.
The
We cover Wideband Delphi in detail in the Estimation chapter of

Applied Software Project Management - download the PDF here:
http://www.stellman-greene.com/chapter3
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 find serious problems
after weve built them into the
software
! We have big, useless meetings
that fail to figure out what the
softwares supposed to do
! Scope creep
! 90% done, with 90% left to go.
Up close: Use cases can help you avoid requirements

problems
Use cases are a deceptively simple way to document every planned
interaction between the users (and other actors) and the software.
Learn more about use cases here: http://www.stellman-greene.com/usecase
Things that could have been caught

Which would you choose: a wellbuilt program that doesnt do
what you need or a crappy one
thats 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.
Up close: Dont overlook your acceptance criteria!

Its short-circuited far too often in favor of user
acceptance testing, but, acceptance testing is about
more than just user acceptance.
What you can do about it

Some easy ways to make sure your project
doesnt 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 right
way through the project
Repeat after me: Practices, practices, practices.

The solutions I talked about are only a few
small steps towards a better software
process.
! Process improvement starts with setting
concrete goals and making incremental
improvements.
! Theyre good solutions to specific
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.
One last quick note from the marketing department
Buy these
books!
And check out our blog, Building Better Software

http://www.stellman-greene.com/
Thanks for coming! Any questions?

Why Projects Fail - Risk Review

Uploaded by

Copyright:

Available Formats

Why Projects Fail - Risk Review

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Why Projects Fail - Risk Review

Uploaded by

Copyright:

Available Formats

Photo by Dan Taylor (CC license)

These are the slides for our Why Projects Fail

and what you can do about it

A presentation by Jennifer Greene and Andrew Stellman

Hes led teams of

Jennifer Greenes spent the

Shes currently doinging

2007 (1st ed)

2008 (1st ed)

WARNING: This is NOT an

If you want academic slides, weve got em:

Not all failures are this easy to spot

This time its different

Dont go in the basement!

You know youre on a failed project when

What does a failing project look like?

Sometimes failure seems normal

A show of hands, please

Are there any here?

Four basic ways projects can fail

Things the boss does

Like it or not, when youre leading a

The Vision and Scope document is where you define who

Things the team shouldve done

Up close: Wideband Delphi keeps estimates honest

We cover Wideband Delphi in detail in the Estimation chapter of

Things the software does (or doesnt do)

Up close: Use cases can help you avoid requirements

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

Things that could have been caught

Up close: Dont overlook your acceptance criteria!

What you can do about it

Repeat after me: Practices, practices, practices.

One last quick note from the marketing department

And check out our blog, Building Better Software

You might also like