No Zombies! (Controlling Project Scope)

Damn Zombies!My team often hears the mantra “NO ZOMBIES” from me. If you run in Project Management circles surely you know what I’m talking about… The projects that just won’t die. No matter what you do you can’t put them down, they just keep coming at you. The undead.

What causes these zombie projects?  How did they transform from the good wholesome initiatives you started with into these creatures from the crypt that torment you so?

In a word… scope creep.  (yeah, I know that’s 2 words).

You never meant for it to happen but you’ve let your project get away from you and it’s taken on a life of it’s own. All the things you thought were agreed to, all the things you assumed were “understood” have gone out the window. Your customer is now talking about features you’ve not planned for and requirements you’ve never heard of. All you can do now is slip your schedule and ask for more resources to get it done.

Does this sound like your project?  If so, then it may already be too late…

Zombies are notoriously hard to put down.  You will need tenacity, bravery, and stamina to survive.  How can you prevent these otherwise nice projects from turning into zombies in the first place?  It all comes down to controlled project startup.  Getting your project off to the right start will put you in control for the duration and control is what keeps a project tamed and resistant to zombie tendencies.  Here are the basics you’ll need to put in place:

  1. A clear business case defining why the project is being undertaken

    It’s critical for you, your project team, and your project board (#3 below) to be in agreement on the project’s business case.  If you don’t understand why a project is being done then you can’t make good decisions when issues arise or the environment changes.  Should you add more resources to pick up speed?  Should you slow down and focus on quality?  Should you stop doing the project altogether?  These kinds of project management decisions can only be made when you are fully informed about the business case for the project.
     
  2. A clear list of requirements detailing what is to be done (scope)

    With the business case well understood you must turn your attention to the project’s scope.  This need not be an exhaustive list of every possible deliverable and characteristic, but it needs to have enough detail that it’s clear what you are to do (and as importantly, what you are NOT to do).  If you’re installing servers in a datacenter, do you need to setup the network first?  If you’re building a rocket, are you responsible for finding the fuel source?  If you’re designing a bridge are you also in charge of the landscaping around it?  You need to have a solid definition of what the customer expects before you can deliver to those expectations.                       

    In my opinion, this is the most common failing among PMs.  The typical scenario: The project sounds straight forward enough, everyone already knows what needs to be done, and the customer is anxious for you to get on with it.  The PM often succumbs to these pressures and launches into the project without ever taking the time to document what is really being asked for.  Later your customer will want changes or more features and you’ll find you’ve really got nothing to support your position that these changes aren’t what you’d agreed to previously.
     

  3. A project governing board with representation of the business deliverables, the customer needs, and the resources who’ll do the work.

    PMs typically do a good job of identifying their customer (usually the business) and some stakeholders (typically users) but they often miss bringing in an equally critical and balancing role, that of the supplier.  If your governing board is made up only of the customers and users they’ll be quick to agree to any change that gets them more features or earlier delivery with little regard to how that will impact the team doing the work.  You have to have the supplier at the table to represent the other side of these project demands.  The supplier has to have the authority to add resources to a project if changes are agreed to and the seniority to not get over-run by the customer or user representatives.         

     

  4. A signed agreement by all the people in on the board on the business case and project scope (as well as schedule, budget, quality expectations, initial risks, etc).

    It’s not enough to know your business case, define your scope, and install a properly designed project governance board.  You must get them to sign an agreement to all of this.  The business case, scope, schedule, budget, and project board operating roles and responsibilities must all be documented and signed if you want to be able to enforce them later.   Project executives are busy people with lots of demands on them and they’ll be quick to forget the date they agreed to or the pot of money they promised you.  If you have the documentation trail to hold them accountable to those agreements, then you’re in control and that’s a good place to be! 

 

PRINCE2 (Projects IN Controlled Environments) has an absolutely fantastic section on Project Startup (SU) that covers all this and more.

Now when your customer wants to change the rules, or add new features, or modify the schedule, or slash your budget, you are in a position of power rather than on the defensive.  You have something to help keep everyone on track and not let them get distracted by shiny new interesting bits of work.  And if you should decide as a project governance team to accept a change, all you have to do is update your document to capture the new state of the project expectations and get everyone to sign-off on the new agreement. (Don’t forget that step or you’ve just flushed all your good work down the toilet)  

With these things in place, when the time comes to put your project to rest you won’t be plagued by questions of whether or not you’ve delivered everything and if you’re really done.  You can put your project away peacefully without a single zombie sighting.

Happy hunting!

No Zombies

 

NB – if you’ve already got a zombie project, is it really to late for you?   I’m so glad you asked!  The answer is “of course not!”  Here’s how put a zombie down:  Set-up the same controls described above!  This time instead of doing a project start-up what you’ll be doing is defining “here’s what’s left to be done”.   You draw a firm line and let the past be the past, setup a new “going forward” agreement and drive to that agreement.  It’s never too late to document expectations, and once you have them, you have control.  

Zombies Be Gone!

Advertisements

~ by brianherman on June 6, 2008.

One Response to “No Zombies! (Controlling Project Scope)”

  1. Awesome article, thanks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: