Have you ever been on a project that seems to be in a perpetual spiral of planning, re-planning, schedule extensions, scope creep, missed milestones and incomplete deliverables? Was the major failure point an inadequate Work Breakdown Structure (WBS)?
As an experienced Project Manager, I am well aware of the potential for IT projects to go awry despite our technical proficiency in planning and executing the work. There is no question in my mind that many such project failures can be attributed to a poorly thought out, poorly constructed WBS. I have personally served on projects for which a badly defined WBS became a significant contributing factor to project setbacks and outright failure.
The WBS is foundational to how we build project plans to contain project scope and to execute the project well. However, from what I have seen over the years, many Project Managers are extremely challenged by the development of an effective deliverable oriented WBS to plan their project activities. Is it any wonder then, that these same PMs have difficulty in transitioning from using the WBS as a planning tool to using it as an effective decision-making tool during project execution?
I’ve also heard PMs criticize deliverable-based WBSs as irrelevant to the way they manage projects. I’ve heard their complaints that they don’t have processes in place to effectively apply deliverable-based WBSs to project scheduling. This reluctance becomes a major obstacle to schedule development and effective scope management. Is it any wonder then, that PMs who struggle with this concept might be spending (read, “wasting”) too much time in planning, and not enough time focusing on their client needs?
This struggle directly feeds into my premise regarding the creation of the WBS; that is, we spend far too much valuable project time in attempting to develop the technically perfect WBS and Project Management Plan (PMP). Or, alternatively, we spend too much time complaining and criticizing why we can’t build the technically perfect WBS and PMP. Regardless, it is valuable time spent by the most senior project resources, and it comes at the expense of working with the client to define successful project execution from their perspective. (Refer to my earlier post, “Why You Should Build The Project Plan Around Your Client’s Viewpoint.”)
My recommendation is that we spend valuable Project Managers’ time in focusing more on the people aspects of project management than on the laborious grunt work that comes with refining the WBS to a state of (perceived) perfection. The following table illustrates this by comparing the differences in using by-the-book process to define the WBS, versus defining that same WBS using a people-focused approach. The tweaks to making the WBS more people-focused are subtle, but effective. At the same time, it is more probable to attain a more successful project outcome using this approach.
say and do
|Develop a deliverable-oriented set of project elements||Ensure the deliverable-oriented project elements are as client-focused as possible||Team members loaned to the project by the client more readily acclimate to the project when deliverables are based on their objectives|
|WBS is created by the IT project team tasked with doing the work||WBS is created in conjunction with client’s project team members||Client’s team members are quickly assimilated into the project, and invested in executing their tasks correctly and timely|
|WBS decomposition follows the 100% rule of the work to be completed||Client team members are educated on the decomposition process as the WBS is developed||Client team members are less likely to initiate scope creep|
|WBS is presented in an outline format that is readily adaptable to a project schedule||WBS is presented in a format understandable to client team members in a way that relates the WBS decomposition to the project schedule||Client team members, given a full understanding of the project schedule layout, will work their task responsibilities as judiciously as the IT team does|
|WBS uses nouns and adjectives to describe the decomposition||WBS uses verbs to describe the decomposition into activities and tasks that drive the deliverables||Client team members respond more effectively to action words in dictating the tasks that they are responsible to execute|
|WBS evolves with progressive elaboration and change control||WBS developed according to the people-focused principles defined above allows for better progressive elaboration and change control||Client team members familiar with the WBS / PMP more readily understand the progressive elaboration and accept change control|
|WBS elements are coded to clearly identify the decomposition of the various project elements||WBS elements are coded in a client-understandable format to clearly delineate the different levels of the decomposition||Client team members more quickly grasp the task-level hierarchy of the overall PMP and work their tasks accordingly|
Over my career, I’ve seen the full gamut of project delivery – from a “seat of the pants” style during my early years as a developer, to the more sophisticated project planning of today’s more complex projects. What I firmly believe is that the earlier we involve the client team in the project planning – in this case in the development of the WBS and the resulting PMP – the better will be our project implementation success rate.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.