I see dead projects all the time.
They have status meetings.
We go to their Christmas parties.
Our children play with theirs.
And on the surface they look like regular, healthy projects.
But peer a little closer.
Lift the hood.
And you will make a grizzly discovery.
These projects are already dead – they just don’t know it.
They all have a story.
Many of them began with the best of intentions.
They started with the right budgets.
They had the right schedule.
Their future’s seemed golden and full of promise.
They appeared to do everything right.
And yet along the way, something went terribly wrong.
They lost the commitment of their stakeholders.
They forgot who they were,
what they are,
and why they began this journey in the first place.
They became lost.
They were everything to everyone – and nothing to no one.
They became the undead.
There are secrets.
We are not defenseless.
Ancient rituals and techniques whispered in the hallways of conferences and on blogs that talk of ways of keeping the undead at bay.
Ways of keeping stakeholders committed to projects.
Means of ensuring teams move as one.
Practices ensuring expectations are set.
And projects begin and end healthy and full of life.
Knowledge is the key.
This tutorial is a collection of techniques gathered from far away lands and brought together here, for the first time at this conference.
We will begin first be reviewing what kills most projects before they even begin, and a 45min review of the techniques themselves.
With this knowledge, we will then practice their application on a project that is not yet undead, but could be.
If you want to keep your projects healthy, and ensure they don’t succumb to the dark side, do not attend this tutorial at your own peril.
Note this material is also part of my Agile Project Management Training Course taking place this March in Calgary.
This was the title of talk I recently gave at CAMUG. The premise of the talk is that there are things we can do when serving clients to prevent our projects from going off the rails. Agile has many practices that inherently resist this (customer feedback early, deploying working software early and often). However, I feel there is a missing step that doesn’t often occur at the beginning of projects.
Mike Griffith, a fellow agile practitioner, has a great post for those interested in submitting proposals to Agile2008. If you are interested in presenting, or would like to help review existing proposals, head over to Mike’s for the details.
I submitted my proposal this morning.
Any and all feedback welcome.