How I have failed to project manage projects

AgileCowboy

#Fails in managing projects

All project management is about writing a list of tasks a glorified to-do list and having everyone in agreement about executing it.

Written like that it sounds so simple doesn’t it?

Hell yeah!

Well no actually. See the trouble is getting real people execute your to-do list is a lot like cat herding.

There’s two approaches to creating a plan… write it all down up front and bark at people like a sergeant major or write some loose description and coax it out like a trendy high school teacher.

But projects can and do fail whatever way they have been organised. I know because I’ve failed using both methods. Let me tell you the reasons why so you don’t have too.

Managing a project is a lot like herding cats

Check out this awesome super bowl advert from a few years ago.

Waterfall or traditional management

Traditional management is kind of easy to sell in as it preaches what most people presume is common sense. The to-do list is fixed and the manager is brought in like some cow hand to herd the team until all the elements are complete.

It relies on “experts” to be drafted to guess how long, complex and costly each to-do list element is to make. This understanding becomes execution plan. The start button is pressed when everyone agrees that the assumptions are correct.

Deviation from the plan results in a heap of upset and a change to either the timings and/or cost of the project.

Agile management

The alternative approach is much harder to sell in. Agile management turns the notion of a fixed plan on its head.

Agile people start with a notion of fixing how much cash and time to invest in the project. They prioritise how important each element on the to-do list by sorting them into order. The top one is the most important and the last is the least important.

When the start button is pressed this time, the top set of features are completed in 2 week bursts of activity in order until time and/or money run out.

Assumptions are made with both systems!

Each approach requires all members of the team management or otherwise to realise that there are a set of assumptions made with each approach. Sometimes these assumptions are not spelt out clearly and this misunderstanding can result in heartache and crashed projects.

Waterfall Assumptions

Whilst Waterfall is the natural way to build a project, it relies on a set of understandings that people take for granted. Failure to illuminate and make these assumptions understood will lead to disaster.

Waterfall Assumption #1

The plan should be comprehensive enough to cover every eventuality. It should completely understood by the people executing it too.

Waterfall Assumption #2

The to-do list will not change significantly during the execution of the plan. Any change allowed should be small enough to not affect the time or costs.

Waterfall Assumption #3

The to-do list does not contain any elements that require research and development. Ie all elements have been executed previously and therefore are predictable.

Waterfall Assumption #4

The to-do list does not have any reliance on unpredictable third party assets. Any third party integration should be based on a fixed system with which the execution team has experience.

Agile Assumptions

Of course Agile is not free from risk and requires buy-in for the following assumptions.

Agile Assumption #1

The to-do list is prioritised by ONE individual with the authority to carry those decisions to upstream management.

Agile Assumption #2

The customer is able and motivated to give quick and regular feedback every couple of weeks to the evolving project.

Agile Assumption #3

The people executing the plan must understand that it is perfectly acceptable for the prioritized to-do list can change as customer learns.

Agile Assumption #4

The team are transparent in communication with each other as well as with the customer. Sometimes teams hide progress or lack of it from key stakeholders.

Agile Assumption #5

The customer presents the to do list as a set of problems and does not become distracted by designing and then prescribing the solution to the execution team.

Conclusion

So what’s the best way to manage a project?

I have talked about Ralph Stacey’s complexity model as a way of choosing this in the past.
In general, if you have to figure out how to do a significant amount of the work in the project because you haven’t done it before, so you cannot estimate accurately, go with an agile process.

If you’ve done it many times before, and know how to do it again, go with a waterfall process.

FURTHER INFORMATION

I hope you find this article interesting, check out my ebook,  Agile Fu Its a short sharp read as to how you and your team can use Agile to develop you innovative ideas into reality.

Agile Fu

Image Copyright : Sascha Burkard (Follow)

2 thoughts on “How I have failed to project manage projects

  1. Hi, I think your site might be having browser compatibility issues.
    When I look at your blog in Ie, it looks fine but
    when opening in Internet Explorer, it has some overlapping.

    I just wanted to give you a quick heads up!
    Other then that, excellent blog!

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>