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):
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