Sunday, September 21, 2014

Work Breakdown Structures, Part V

As mentioned before (here), when putting together a WBS from scratch, it’s useful to think about how each of the various work package deliverables are going to be procured. Will they be built in-house, purchased, or will you have to implement a contract with a vendor to produce an item? Thinking this through now will greatly help with the organization of the WBS, helping/causing you to logically group items together in a way that aligns with your procurement strategies. Most experienced project managers take this approach, and in fact it’s what we did when producing the WBS on my current project. We literally sat in a room toward the end of our initial WBS brainstorming session and took a first pass through our procurement strategy for each element. The final layout and organization of the WBS elements into logical groups was almost a trivial task to undertake following this exercise; we had a very good idea of how items should be associated with each other once we understood our plan for procuring those items. 

Another thing that’s very useful to do at this point is to think about personnel required to support your procurement strategies, and if possible, align the WBS and org charts with each other. Sometimes minor changes in one or the other can reduce (or at least clarify) what personnel resources are needed. For example, our project org chart very closely lines up with our WBS, and has a single dedicated “Cost Account Manager” (CAM) aligned to each major deliverable in the WBS. There were a number of "TBD" names written into the chart at that point in time (because we hadn't yet fully staffed the project), but thanks to this exercise we knew who and/or what type of person we would need to hire to support each major area of the WBS. Some projects actually write the name of their CAMs into the WBS tree, which then serves as the de facto org chart as well.

Another useful step to take when finalizing the first draft of your WBS is to create an interface chart of the WBS elements. Sometimes known as an “(N^2-N)/2” diagram, “N2”, or "N-squared for short, this chart helps define and track all the necessary interfaces between WBS elements. (The name of the chart derives from the number of possible interactions, or interfaces, between WBS elements. For example, a project with 4 WBS elements can have up to [(4x4)-4)/2] = 6 interfaces.) I’ll write more about N2 diagrams in a future post on managing the systems engineering of your project, but for now, just know that creating this chart now will help immensely when it comes time to begin planning procurements, as it helps focus efforts on defining key interfaces and procurements in a prioritized fashion. Here’s view of a big telescope project's N2 chart (click to enlarge):

An N2 diagram (pronounced "N-squared") for a big telescope design/construction project. The elements listed along the diagonal of the chart are the major WBS elements. The colored ovals above the diagonal represent interfaces between WBS elements. This graphically shows which elements are dependent upon others for key interface definitions; this helps focus and define procurement strategies and prioritizing on a project, as well as affecting the layout and structure of the initial WBS, too. Taking a first pass on an N2 diagram prior to putting your WBS under configuration control at the start of a project is a very beneficial step for the project manager to take, as it may help inform the logical grouping of WBS elements.

I promise I'll move to a topic other than WBS creation in the near future, but I've wanted to spend these last few posts on this subject, mainly because it is so incredibly vital to success on a project. You cannot solve a problem until you define it. When it comes to project management, you literally cannot succeed if you don't fully define what it is that the project is going to deliver-- down to the lowest level work package. Spend the time up front getting 100% of your project's scope captured in a logically arranged work breakdown structure, and you have taken the first step towards project success. Don't do this, and you're almost certainly destined to fail.

© Copyright 2014 Mark H.Warner. All rights reserved.

No comments:

Post a Comment