Your Project is You

The body lies unrecognized in the hallway.  People hurry past on their way to somewhere, holding their breath until they get upwind.  Some step gingerly over it.  Some tiptoe around it.  One or two glance at you, hesitate, then think better of it.

Soon, the whitecoats will scrape the body from the floor and conduct a speedy autopsy.  The cause of death will be assigned.  The perpetrator is predetermined.  You already know who it is.

The body is your project.  It appeared to be perfect when it was born.  Nobody knew it had any enemies.  Certainly no-one expected that its enemy was you.

The body is also your career.

How could this have happened?

The project seemed to start ok.  Where did it go wrong?  If it was like most projects, failure happened long before any signs of ill health were visible.  In fact it probably happened right at the moment of birth when you defined the project objectives. 

What?!  You didn’t define the project objectives?  The goals were obvious to everyone, you say?  You couldn’t get all the stakeholders together because the timeline was so fast?  The project was too small to warrant that much bureaucracy, and besides, we’re supposed to be lean?  Let’s see, what other excuses can you find?

Ok, we’ve found the problem, and you’re not alone.  The most common cause of project failure is that the objectives were not clearly defined.¹  In study by Geneca Research less than 10% of IT teams said that the goals, roles, and accountabilities were clear in projects that failed.

What are Projective Objectives?

The Project Objectives Statement is, quite simply, the success criteria for the project.  In FDA regulated industries it is called a User Requirements Specification (URS).  In other industries it may be called the Design Basis.  It will certainly include all aspects of the project that its customers want to see in the outcome.  If the project is a new website, for instance, all the functionalities would need to be listed.  The degree of user-friendliness should be specified.  But these examples are just the customer facing requirements. What about the infrastructure that would be needed to support the new website? 

• Who will build the site?  Will we do it in-house? Or will it be contractors? 
  • If a contractor, will there be performance incentives?  Who is our interface with the contractor?
  • What is the mediation process for disagreements?
  • Who will write the contract?
• Technical support?  Will the site need to be updated frequently?  Who will do that?
• What about servers and data transmission?  Will your current installation handle the additional load?

The list can go on, but I think you get the idea.  All of these questions do not need to be answered in the Project Objectives Statement.  What’s critical is that we recognize that at some point in the project they will need to be answered.

A key point is that there are obvious objectives, like the functionality that the user gets from the website in our example.  But there are also implied objectives, like the infrastructure that has to run behind the scenes in order for the site to work.  Both have to be recognized in the project objectives statement.  In fact, more often than not, it’s the implied objectives that get lost and eventually end up killing your project.

Every objective should be stated in measurable terms, so that you can determine whether you have actually accomplished it or not.

The Project Objectives Statement is like the pitch pipe that your fourth grade teacher used to start the class singing a song.  With the pitch pipe, there was at least a chance that everyone would start somewhere near the right note.  If the project starts right, there’s a decent chance it will end right.  If it starts wrong, it will surely end in chaos.

Every assignment you receive should be treated as a project.  The bureaucracy that you build into it should be commensurate with the size of the project.  But, one bit of administrivia that should never be omitted is the project objectives statement. 

The best way to keep your project from dying an agonizing death is to give it a good start in life.  That means doing whatever is necessary to define its goals at square one.  That may mean that you will have to pull some reluctant stakeholders together to get them to commit to what they want from the project. 

Extricating the stakeholders from their busy day long enough to get them to commit to the project objectives can be a tooth grinding process.  Be persistent.  Anyone who squirms away is a potential finger pointer later on.

Did your boss tell you in the elevator to put together a short report?  Before you get off, clarify when it needs to be done and what the content should be.  Be prepared for some discomfort on your boss’s face.  Why?  Well, you’re making your boss think.  People don’t like to think.  But you need this information in order to get the job done right.

If it fails, it’s your failure.  Why are you automatically guilty when your project craters?  Simple, your project is you.  Its success or failure is your success or failure. 

¹ESI International Survey  http://www.slideshare.net/MariannaAlmakaieva/10-reasons-why-projects-fai...