The WBS - Intermediate

Two (or six) months into your project, you and your business owner disagree about whether a particular feature or component is included in the project.  You, of course, consider this controversial item obscure and expensive to include;  the business owner, in contrast, asserts that it is absolutely essential, the whole project is value-less without this item, and, further, that since it is in the original scope it shouldn’t cost more or take more time.  How do you resolve this dilemma?

Project Management success is determined by delivering both the project (what you promised) and customer/owner/stakeholder satisfaction (what they expected).  Failure at either of these is failure.  Even if you deliver the greatest technical solution imaginable, if the customer is not happy, you are not going to stay around long or get that next job.

Our success as project managers, then, is to get agreement up front for what we’re going to do, do it, and then get acceptance that we did it.  How then do we get agreement on scope up front?  How do we avoid the dilemma described in the opening paragraph?

The Work Breakdown Structure, which I’ve been discussing in the past several posts, is not an academic exercise.  It, along with the Task Dictionary, defines the scope of your project.  A well constructed WBS/ Task Dictionary agreed to at the start of the project by the key stakeholders will greatly reduce the kind of disagreements described above.  That is, the WBS becomes the basis for determining Project Change Management, and without the WBS it is just “I say – They say,” which ultimately leads to project failure.

Agreement on the WBS is more than just sending an email and asking for approval.  Sit down with your stakeholders, walk through each Deliverable and The Activities and The Tasks that comprise each deliverable.  Discuss what is included.  You’ll be amazed at the results.  Many misunderstandings will be cleared up here, early enough to easily resolve them and prevent acrimony later;  they will find that you’ve included activities that they disagree with;  they will identify missing activities;  and, most importantly, they will begin to take ownership of the mutual delivery of the project.

I’ll have more to say about Project Change Management in a future post, but the other essential value of the WBS is that it becomes the foundation for building the project schedule.  In the next series of posts, we’ll discuss what is needed to build a well-formed project schedule.

When was the last time you conducted a WBS walkthrough with your stakeholders?  How did it turn out?