Ever heard the quote "if you fail to plan, you plan to fail'?  It's one of Benjamin Franklin's most well used quotes.  I've heard it many times throughout my life.  I've heard it from my parents, from my teachers, in boardrooms, and community meetings.  Often, it's said with a knowing, cautionary gravitas.  But where, exactly, is the warning in these words?

I had some pre-conceptions about project management going into my formal learning and application of it.  I thought that planning a project was basically some way to keep track of a timeline; the control and management of a schedule of milestones.  Like you would throw it all on the wall, order it, put dates on it, commit some resources and off you went.  Boom.  Easy. Done.  Right?

Not quite.

I've seen many groups working for common cause want to get off to the races quickly.  They often do so for all the right reasons: they want to create value, they want to be productive, they're excited about what they're doing.  So they bust out the calendars, start scheduling tasks, and rip off into a starry future.  Yet, either days, weeks, or months down the road these same teams are often embroiled in conflict, confusion, and missed deadlines.  

THE ROOKIE MISTAKE

It sounds great and feels action-oriented to get right down to assigning tasks on the calendar.  But this can be a cart-before-the-horse exercise.  Specifically, it's putting the How before the Why and the What.   Tangibly, it's not enough plugging into strategy and vision to get a set of specs as to what exactly the deliverables are, or the clear outcomes to be achieved.  In project management speak, the team has not taken the time to clearly scope their requirements.  It is these requirements which constitute the necessary and sufficient conditions for success.

A clearly scoped project sets up the boundaries, the playing field for the work of any project.  It lets spectators know how to follow the game.  It clearly lays out how the score is counted, how long the game goes for, what capacities are needed to play, and what is considered to be a win.  Only then can you set a schedule, plan logistics, and take your team out onto the road.

The joy of creating a thoughtful space to delineate requirements is that it gives you an initial benchmark to evaluate the efforts of your project against.  Who hasn't worked on an endeavor where the end goal shifts from week to week, or even day to day?  It's confusing and disheartening in its uncertainty.  Who hasn't been in a meeting where conflict and arguments happen when new information comes in, either from management or from market, which might require a change in the goals or deliverables of the project?  Without clarity on what is, or is not, part of the project, team members and management can have different takes on what the vision of the undertaking was to begin with.

Taking the time to formally charter and layout your project's deliverables in the form of specific, tangible requirements can save it from the potentially nasty pitfalls below.

  1. Project cost spirals upward.
  2. Time needed to complete is longer.
  3. Conflict is created between team members.
  4. Communication to stakeholders is unclear.
  5. Management becomes dissatisfied with performance.
  6. The project fails.

To get started in a proper requirements gathering and scoping process, you ideally have an authorized project with some end-goal to achieve.  The organization has approved it, likely with an initial budget and some committed resources.  It doesn't matter if the "organization" is a couple looking to do a home renovation, or a multi-billion dollar corporation looking to bring to market a disruptive software technology -- the principles remain the same.

The basic process I follow when beginning to scope a project's requirements is:

  1. Have the team look at the overall end goal, the major end-of-line deliverable for the project. 
  2. Ask: "what are the necessary and sufficient conditions of success in meeting this goal?"

... and you record the responses.  All of them.  You get specific, you name the beams, struts, rivets, and foundations.  You continue looking at your overarching goal, and you ruthlessly ask the question, over and over, until every last piece has been documented.

Then you find commonalities, overlap, and fuzziness.  You continue to break these down, to decompose them into smaller, clearer parts.  

And then you make all of your requirements SMART - Specific, Measurable, Actionable, Realistic, and Timely.  For example, if some kind of inspection will be needed to ensure the success of your project, instead of "bring in a regular inspector", say "have an inspector check this part of the project at monthly intervals starting April 1st, 2016."   By making the requirements of your project SMART at the outset, you will have a list of tangible, measurable items that you can use to evaluate yourself and future changes to the project against.

By committing to this process before getting into task assignment and scheduling, stakeholders in a project -- whether it's your team, management, or client -- have a clear, detailed view on what it's going to take to deliver it.  Adjustments can be made, pieces added, modified, or taken away, before the logistics for execution are laid out.  Many of the nasty pifalls can be avoided, or at the least, worked through more constructively when they do come up.  

In the end, what we're doing is updating Franklin's quote:  "If you fail to fully know what you're planning, you plan to fail." 

Certainly not as pretty, sure, but likely more complete.  

 

 

Comment