Time Management - Assembling a Schedule from Scratch

I want take a small break from Scope Management and V-Diagrams to talk about Schedules. Specifically, I want to discuss how some project managers place their emphasis on the wrong things when putting schedules together-- but before we do that, we first we need to understand how a schedule is assembled from the ground up.

Per the Project Management Institute, the basic process for putting together your project's schedule involves five sequential steps:

Nothing surprising here, right? If you're planning to build a house, you first create a list of all the things that have to be done. For instance, you know you have to dig and pour foundations, erect structural walls, put a roof on, install interior non-structural partition walls, install plumbing & electrical, finish out the interior, paint the exterior, landscape the grounds, etc. This is step one in the PMI process: defining all of the individual tasks and activities that have to occur during the course of your project. This step naturally is created from your WBS.

Next, you sequence all these activities in logical, dependent order. For example, you know you can't install the roof until the exterior framing walls are erected, so these two activities have to be logically linked with a predecessor-successor relationship. Conversely, you could start painting the exterior walls before the interior is completely finished, so there isn't a logical dependency required between these two items. You work through all of your activities and put in place these relationship dependencies. The result is a natural "sequencing" of the work that has to take place.

Once the sequencing of activities is complete, you next need to determine what resources are required to perform each of the activities. For example, you might determine that you need a team of at least three staff carpenters to erect the structural frame of the house, two contracted pipe fitters for the plumbing work, and a competitively-bid contract for the roofing work. These resource estimates are needed for the next, penultimate step in the process, which is to estimate the time required to perform the individual activities. In addition to the resource requirements and their availability, you also use things like past experience, vendor estimates, and other bottom-up analyses to refine the activity durations.

Finally, you assemble all of this into a so-called "integrated project schedule," or IPS. On bigger, more complex projects, the steps of putting an IPS together is typically done by a team of lead engineers who are expert in the various subsystems of the project. The PMI process ends up looking something like this:

The WBS, whose initial creation is typically led by Systems Engineering with input from Project Management, is used to define the major subsystem tracks within the IPS. The activities, sequencing, resource requirements, and durations of the subsystem track tasks are then usually determined by the individual lead Subsystem engineers, with input, guidance, and oversight from Systems Engineering. Finally, all of this is collected and assembled into a master Integrated Project Schedule by Project Management. During this last step, Systems Engineering has to play a key advisory role, to help improve efficiencies, minimize resources, and work to shorten and refine the critical path activities.

In the next installment of this thread, I'll discuss what I see as an all-to common problem that new Project Managers fall into when putting their IPS together for the first time. Stay tuned.

 2014 Mark H.Warner. All rights reserved.

The Correlation Between V-Diagrams and PMI Process Groups

I received a couple of emails from readers who asked if and/or how the "V"-diagram method I wrote about in the previous post (here) related to the standard PMI process groups. To paraphrase, they understood the PMI process, but were unclear on how the V-diagram fit into (or onto) that framework. For lack of a better word, the correlation between the two was muddy.

As a reminder, the Project Management Institute (PMI) espouses a five step sequential process for managing the typical project:

The Project Management Institute's five (5) sequential "process groups" or steps for managing a project. While simple in concept, this process is essential to understanding how projects should progress, from beginning to end.

Per the PMI, each of the five sequential steps contains a number of subtasks and deliverables that are performed and/or provided. For instance, during the Initiating phase of a project, key stakeholders are identified, and the founding project charter is created, which spells out such things as a) why the project is required; and b) what are the highest level deliverables of the project.

Then during the Planning phase, the project management plan(s) are written, the scope of the project defined and broken down into WBS elements, the schedule is generated, the budget established, key initial risks are identified, and so on.

Next, during the Executing phase, the bulk of the project's work is actually performed, including such things as acquiring the majority of the project team, and putting in place all the major subcontracts and procurements.

In the diagram, the Monitoring and Controlling phase is then shown coming on the heels of the Executing phase, but in fact it actually takes place in parallel with it. This is essentially where integrated change control takes place, procurements are monitored, and deliverables from those procurements are checked and verified for quality and scope. The feedback loop between M&C and Execution is where and when testing and rework take place.

Finally, in the Closing phase, all procurements are closed out and the project, well, comes to a close.

My readers wondered if and/or how the systems engineer V-approach fit into this 5-step scheme. The answers to these two questions are: yes, and quite well. Here's the V-diagram with the five PMI process groups overlayed to illustrate:

Note that the overlap and correlation between V and PMI sequences are quite clear. For instance, on the left side, up at Level-0 of the V-diagram, the customer's key requirements are developed and documented in the things like Science Requirements Documents and the Operational Concepts Document (I'm using a Big Science Project as the case example here). This aligns with the management task of creation of the project charter, and in fact the Science and Ops documents are essentially just sub-parts and/or references in the charter.

Similarly, the V-diagram Level-1 left-side tasks of design definition, system decomposition, and the creation of high-level systems engineering requirements are just the typical technical engineering tasks that a project's systems engineering staff carries during its Planning phase. (Of course, other key things like creating schedules, budgets and identifying risks also take place during this phase, but the V-diagram focuses solely on the technical systems engineering aspects of a project; those other tasks are carried out by the management team).

Moving down the left-side from Level-2 and -3 (design), then into Level-4 (fabrication), and then back up corresponding uphill right-side of the V-diagram (QC, integration, testing, commissioning, and verification) are essentially the technical engineering parts of PMI's larger Executing and Monitoring/Controlling phases. (Again in the bigger picture, other programmatic M&C things like performing integrated change control and managing risks, are also occurring in parallel, but aren't shown on the V-diagram because they're not strictly engineering tasks).

Still clear as mud, right? Actually, this is all just a long-winded way of saying that the technical design-build-test work that a project has to carry out is nothing more than what your engineering staff should be doing in parallel with your management work. In other words, the V-diagram is just a visual way of breaking down and illustrating the sequential nature of the technical engineering work a project has to undergo, but does so in a way that aligns with the PM's tasks. And, more importantly, the V-diagram hammers home when and the order in which that technical work needs to be performed. An all-to-common mistake many projects make is they move into the Execution phase before the Planning phase is sufficiently complete-- engineers love to jump in and start solving a problem, often before they've fully defined the problem. A key subpart of the project I'm currently working on fell into this trap, and as a result there has been a fair bit of rework and corresponding angst that has accompanied that area of the WBS ever since. In my opinion, properly following the V-diagram sequences would have significantly reduced this problem, if not eliminated it altogether.

In upcoming posts, I will expand on the deliverables of each of the individual Level-0 through -4 phases of work. Hopefully the mud will get a little clearer by the time I'm done.

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

V-Diagrams and Project Life Cycles

In my last post (here) I wrote about the need to define the requirements of each scope element in your WBS. In this post, I want to discuss a simple but powerful engineering tool to help define and manage these requirements: the V-Diagram.

The "V-Diagram" method is used extensively by Systems Engineers in large, complex science projects like major astronomy and particle accelerators design-build projects. It's also very applicable to medium and even small projects, too. In simple terms, the V-diagram is really just a means of graphically displaying the engineering-side of the life cycle of a project from the beginning, when you're defining big picture scope and requirements, down through system decomposition into WBS elements, creating subsystem requirements and constraints, through procurement and fabrication of the project deliverables, to assembly, testing, verifying the completed system works, and finally project close-out.

The flow through a V-Diagram corresponds with the five "process groups" that the Project Management Institute (PMI) espouses, but in my opinion it does so in a somewhat more useful fashion for your engineering staff. In other word, the PMI process groups reflect how "managers" think about a project's life cycle, while the V-diagram illustrates how systems engineers think, which means you as a PM need to understand it, too. Here's a picture of a standard Science-based V-Diagram (click the picture to enlarge):

You work your way through a V-diagram by starting at the upper left part of the "V", then dropping down along the left leg to the bottom, and then climbing back up the right leg. You also take the occasional loop back from the right side of the V to the left when verifying requirements compliance. In simple terms, you identify and define all the necessary project requirements as you move down the left leg, build to those requirements at the bottom, and then check the as-built deliverables against their requirements as you progress up the right leg of the diagram.

I once heard a very experienced and highly respected systems engineer describe this process as starting with high level requirements and then systematically "digging deeper" into the design requirements as you move down the V. This "digging" is captured by various subsystem documents that are derived from the high level requirements. This process continues down through the system architecture and WBS, to subsystem requirements, to conceptual, preliminary, and, eventually, to the final subsystem design specs and detailed ready-to-build drawings and specs of individual components.

At the bottom of the V, your team stops "digging" and instead starts building, sourcing, procuring, coding, and fabricating all the components and subsystems of the project. This is the point where all the requirements you uncovered on the way down the left leg of the V get turned into real hardware and software, either directly by your team or by contracted vendors or partners.

The right side of the V-Diagram is also known as the Assembly, Integration, and Verification (AIV) phase. This is when components and subsystems are individually tested, and then everything is put together and tested, and then overall system performance is proven. At the upper right topmost part of the V, the verification of the "customer" requirements (e.g., Science and Operations) is performed and the project comes to a close.

My aforementioned systems engineer friend calls this process of moving up the right side of the V as "climbing out" from the detailed depths of the fabrication and procurement phase. This is done by assembling, testing, and verifying the system with a progressively wider perspective and scope. As you move up the V-Diagram on the right, you test performance of each subsystem and assembly against the requirements you defined when coming down the left side of the V. By the time you get to the top on the right, you are testing very high-level system performance items; in the astronomy world where I work, this is where we verify that the proposed scientific investigations of the new observatory can actually be performed by the telescope that the project constructed.

[Note: If a component or subsystem meets its requirements during the AIV phase, it is by definition compliant and can be progressed further up the diagram into large sub-assemblies and assemblies. If a component or subsystem doesn't meet one or more of it's requirements, you then have to determine just how important those requirements are, and whether you can accept the non-compliance or not. This is a key concept, and I'll cover it in a later post, but for now just note that the power of the V-Diagram is that you can trace-back requirements at a low level up to their original sources higher in the V to help make decisions. Every requirement on the left side of the V has to come from somewhere above it or from somewhere like an engineering standard. This helps immensely when determining just how important a specific non-compliance is in the big picture.]

I'll break this all down further in the next few blog posts to make it clearer how you can use the V-diagram approach in practice to manage the life cycle of your own project.

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

Defining "Good Enough"

Okay, I lied. I stated in my last post (here) that I was going to move on to a topic different than Scope in my next blog post. Well, I can't quite honor that commitment, at least not yet. The reason for this stubbornness has to do with a conversation I had with a coworker last week. We were, ahem, "vigorously" discussing one of my favorite guiding principles in life and work: "Better is the enemy of good enough." I won't go into the difference of opinion we had about the validity of this adage, but underlying everything we were batting back and forth between us was the definition of "good enough." Let me explain:

You cannot manage a successful project without defining what the actual end goal of that project is. In other words how do you know whether you've succeeded unless you know what you were shooting for in the first place? When exactly have you achieved "good enough" status? Whether you're managing a software develop effort with a small team, writing a manual all by yourself, or overseeing the construction of a major infrastructure project with a large distributed team, you have to define the end goal right up front in the project. I.e., what is it that you are actually tasked with delivering? If you can't completely answer that question, then by definition you're going to fail.

Fine, fine, you say, rolling your eyes. We've talked incessantly about this over the course of the last 5 blog posts. It's all about defining scope, right? How about something new?

Okay, here goes: Defining the scope of a project actually entails more than just breaking down all the work into constituent sub-components and work packages and then adding all these pieces up. Doing this breakdown is vitally important, but it's just the start. Yes, it's an absolutely important start, but there's a lot more work to do up front before the end goal of "good enough" can be targeted. You have to define the requirements of each of the WBS components and sub-components. If you don't do this, then you can't actually know what it is you're tasked with building. Which in turn means you can't accurate schedule, resource, or cost your project. You also can't fully define project risks, nor can you decide on an procurement strategy.

For example, let's say you've been asked to manage a new design-build apartment building project. One of the first things you and your team do is break the project up into its constituent components. For example: land acquisition, permitting, infrastructure improvements, excavation and foundations, structural framing, interior partitions, windows, doors, roofing, insulation, siding, electrical, plumbing, HVAC, fit-and-finish, etc.. These are the key WBS areas that then get further subdivided, along with other important items such as Project Management, Architecture & Engineering, QA/QC, Safety, and so on, of course. We can then break these things down further and further until we're at the lowest work package level. The result of this of course is a WBS that fully details what is to be delivered.

This should be pretty well understood by now, but we're nowhere near finished defining the deliverables of this project. To do that, we have to define the  form, fit, and functional requirements for each one of the individual WBS building blocks. For example, under the category of windows, we can't just say we are going to have 100 windows. We actually need to define just how nice those windows are needed to be. Single pane, double, or triple? Standard sizes and shapes or specials? Aluminum, steel, or wood trim? Off-the-shelf or custom units? Hardware choices? Paint finishes? Inert gas fills? Warranties? Thermal performance? And so on.

Until you define the specific key requirements for each element of the WBS, you cannot accurately cost those elements. Nor can you fully understand the schedule implications of sourcing them, estimate the risks associated with procuring and installing them, decide on the manpower required to install, or even determine if you can get units that match your requirements or not.

In other words, defining scope is not just providing an answer to what and how many, but also answering the equally important question of "how good?"

As a project manager, I fully believe in the adage of "better is the enemy of good enough." I'll discuss this concept in a future post in a lot more detail, but for now just recognize that one of your chief jobs as a project manager is identifying exactly what is "good enough." Doing this step means you know what the end target of the project is supposed to look like and how it's supposed to perform. Failing to do this means you're just shooting in the dark without an actual set of requirements you're supposed to meet.

In the next installment, I'll talk about about something called a V-diagram, and how it can be used to help define all these requirements (as well as test them). Stay tuned...

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

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.

Work Breakdown Structures, Part IV

As promised in the last blog entry, here's my current project's WBS tree (you can click on the image to make it larger):

Is it perfect? Heck, no. There are any number of things I would change and re-organize if I were able to do it all over again, knowing what I know now. But it's not a huge issue. As I stated here, a WBS has to include 100% of your project's scope, but the organization and layout of the structure doesn't have to be perfect-- just good enough, which ours certainly is.

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

Work Breakdown Structures, Part III

Once you've completed a first detailed pass through your WBS and have reviewed it with your high-level engineering managers, the next step is to write a WBS Dictionary to accompany the breakdown. The process of creating this document can be laborious, but it's crucial; a WBS Dictionary serves as the one definitive document that explains and describes the full scope of your project. Without a WBS Dictionary, there can/will be ambiguity and uncertainty within your team over what is--and isn't--included in each scope area of the project. There can also be uncertainty over who is--and isn't--responsible for each element of scope.

The WBS Dictionary also serves as the jumping off point for performing your detailed cost and schedule estimates. Said simply, without a clear and detailed understanding of what is included in each WBS element, you cannot expect to be able to fully and accurately estimate the cost of that element, nor can you accurately estimate the time it will take you to complete the work associated with it. Risk identification, resource requirements, and so on all fall out naturally from a complete and accurate WBS Dictionary.

There are other reasons to create a WBS Dictionary, too. On our project, for example, each individual work package page (which are web accessible) also serves as the repository for other relevant information associated with the element. This includes such things as basis of estimate (BoE) calculations and spreadsheets, bottom up risk/contingency calculations, change request histories associated with the work package, plus links to other associated documents. In other words, ours is a WBS Dictionary on steroids, and it serves as the first place we tend to look for work package-related information. The Dictionary offers both high-level and very specific detailed information on WBS elements.

While you don’t have to go as far as we have, you still need a Dictionary. If you’ve never created one before, a good place to start is with a previous WBS Dictionary that your company has used. Alternatively, you can use a standard template, of which there are many just a Google search away.

For what it’s worth, some of the information our WGS Dictionary pages include are:

• WBS Name
• WBS Number
• Work Package (or Budget Account Code)
• Expected WP Start Date
• Expected WP Finish Date
• Current WP % Complete
• Responsible Cost Account Manager (CAM)
• Funding Source Earned Value Technique
• WP Description (both what’s included and what’s not)
• SOW for this element BoE for this element
• Change Request History
• Milestone Description, including weights
• Contingency Calculator
• All other relevant attachments

Each individual page of our WBS Dictionary also includes spaces for two required signatures. The first is the CAM, and the second is the Project Manager. These two entries are probably as important as any other on the page-- the two signatures represent that the information is agreed upon by both the low level cost account manager who is responsible for performing the detailed work associated with the element, and the high-level project manager who’s responsibility is to ensure the entire scope of the project is accounted for within the pages of the Dictionary.

I’ll have a few more things to say about WBSs in my next post, including the previously promised look at our project’s WBS. I’ll also include a same page from our WBS Dictionary as an example. Stay tuned...

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

Work Breakdown Structures, Part II

When creating a WBS from scratch, there are two major actions that have to be performed right from the start: 1) determining what scope to put in, what to leave out, and how far to subdivide things; and 2) sort, layout and organize the tree structure with this scope. While nowhere near comprehensive, here are some lessons learned and rules of thumb to keep in mind when doing these things.

• 100% of Project Scope. While the layout of a WBS doesn't need to be perfect, the content does. In other words, you absolutely have to account for 100% of the work scope of a project. You must strive to not leave anything out. If you do miss something, you'll have to either ask for additional money and/or time to perform that missing scope later when it's discovered, you will have to draw upon contingency reserves to pay for it, and/or you'll have to sacrifice other lesser important work scope to pay for the newly discovered scope. None of these options are good. One trick to doing this is the application of Progressive Elaboration. Hit the higher-level WBS elements first, then subdivide and breakdown the scope as you proceed. Visualize how a subsystem comes together; what are it's constituent components, and what is and isn't included. Start big and decompose.
• Brainstorm Scope. Early on our project, we held a series of WBS brainstorming sessions with the most experienced engineering and science members of our team. We did this away from our normal work location so that we could focus and work uninterrupted. We started by creating individual lists of delivered elements and subsystems of the new telescope. We used dry erase white boards, big sheets of "butcher paper," and lots of yellow sticky notes and index cards to capture this information in realtime. The key is to focus on listing and capturing everything, not sorting and categorizing them; i.e., identifying all elements of work scope at this point was significantly more important than deciding with absolute certainty where those elements should reside in relation to each other in the WBS.
• Don't Include Non-Project Scope. In addition to ensuring 100% of the project is contained in the WBS, it's just as important to exclude items that are not true work scope. A well constructed WBS should include exactly 100% of the project work scope, no more, and no less. On our project a number of items were ultimately rejected because they more correctly belonged in operations.
• Don't Reinvent the Wheel. One of your most powerful tools as a project manager is your ability to "R&D", or Rip-off and Duplicate from previous projects that are similar to yours. Look around and see if you can use a WBS from a previous project as a starting point, both for identifying scope as well as organizing it. Also look for templates that are used in your specific industry or field. The obvious benefit in doing this is it gives you a leg up in the process. Potential downsides, however, include: a) all projects by definition are unique, so the WBS for one project won't map fully to another; and b) organizational and content problems get carried over from project to project, essentially "in-breeding" errors and omissions. Definitely consider R&D'ing from other projects, but be judicious about it.
• Organize your WBS to Align With Your Team Strengths and Contracting Strategies. Once we had a fairly comprehensive collection of individual scope elements, we started organizing these into logical groupings and categories. Again, we used butcher paper and note cards to shuffle and move things around. (Another trick is to use so-called "mind-mapping" software to capture content. I've personally used products like coggle.it for this purpose on small and large projects alike with good success.) During this initial layout, management gave the engineers nearly carte blanche to sort and organize, but they did insist on one thing that served us well: when grouping items together, management asked that the team think in terms of contracting strategies and personnel to manage said contracts. We were a small team at the time, and the plan was stay lean for a while and try to leverage involvement from industry and partner institutions. This meant larger than typical contracted sub-packages for design and fabrication for many of the subsystems. Also, even if we knew we were going to self-perform a task in-house, we acted as if we were going to subcontract that package when organizing the WBS; this kept us focused on discrete, standalone "contract" packages for which we could readily write SOWs, specs, acceptance criteria, and interface control documents, as well as estimating cost and schedule.
• Recognize Perfect is the Enemy of Good Enough. While a perfectly structured WBS is what you're aiming for, the truth is that its organization doesn't have to be 100% ideal; much more important is content than structure. Like many things in project management, structuring a WBS is a balancing act: it's important to spend enough time up front to get to something that won't have to be changed later, but the truth is that things will change. Try to build in simplicity and flexibility in the WBS organization to accommodate these future changes. It's also useful to utilize methods like Progressive Elaboration; i.e., worry about the big picture items during the first pass through, get those nailed down, and then fill in details in each successive iteration. 
• Work Packages. At the lowest level of a WBS tree are the individual work packages (WP). When first planning a project you don't have to identify ever single one of these, but you will have to by the time you're ready to baseline your project. Again, Progressive Elaboration is the key to tackling the job of identifying WPs. The purpose of breaking down the WBS into WPs is that you will use these to produce realistic cost estimates and schedules for the project. You have to break the work down to this level of granularity to perform these steps, but it makes no sense to go further than this. Finding this sweet spot between too little and too much detail can be challenging.
• Size of Work Packages. Every project is different, but there are some rules of thumb that project managers tend to fall back on when determining how far to subdivide the work:
• 80-Hour Rule. For "standard" work products in typical projects, the lowest level of detail (i.e., work package) in a WBS should be something that takes no more than 80 hours to perform. Unfortunately, on big, complex multi-year science projects, this means there could potentially be thousands of work packages. This can often be overkill, and therefore this rule is really only applicable to simpler standard projects.
• Reporting Period Rule. Another rule of thumb to consider is that no single work package deliverable should take longer to perform than a single reporting period. For example, if you have to report to your customer on a monthly basis, the work packages should be subdivided such that the tasks associated with each WP can be performed in less than one month. Again, on bigger projects this may not apply very well.
• The Common-Sense Rule. Remember the goal of a WP is to allow accurate estimating, planning, executing, and controlling. If a WP doesn't fit within the 80-Hour or Reporting Period rules, then that is fine. Too much detail is often just as bad as too little.
• Don't Go Too Far, Too Fast. Be careful about over-subdividing, especially too soon. Once a WBS number is created, it's used in many places by many people; i.e., it becomes difficult to change later (due to all the impacted docs). For example, we made this mistake whebn subdividing our site and support facilities work into very low-level WBS items that we assumed would match a specific contract strategy we expected to employ. Unfortunately, our strategies and corresponding subdivison of the work changed later, but our WBS was so ingrained into the project at that point we had to live with the old numbering system. This caused significant confusion and bookkeeping issues in later years of the project that could have been avoided if we simply refrained from too much detail.
• Don't Worry About Numbering Systems Until You're Done. It's easy to get hung up on numbering systems and wondering whether a work element should be at the third or fourth level of the WBS. This is a waste of time early in the process and just serves as a distraction. In fact, the final numbering and sorting shouldn't take place until very near the end of the WBS process.
• Alternatives to Numbering Systems. I know of one major project that doesn't actually use traditional numeric numbering systems; the project uses 3- and 4-letter words, separated by decimal points as a substitute to traditional number. In other words, instead of element getting a number like 4.6.3.12  that element would get TEL.STRUC.BASE.FOUND, which would stand for "Telescope.Structure.Base-structure.Foundation. This makes it very easy for a newcomer to the project to understand the various pieces. I'm not entirely sure if this is the best route to go, as project members quickly learn numbering systems just by natural usage, but this is something that is worth considering if you find the traditional numbering systems to be confusing to your team.
• Wait to Apply Change Control.  While it's important to put a WBS under change control, as it will be used for the basis of any number of key project documents, doing so is a double edged sword. You have to get to a point where the WBS is fairly stable and unchanging, primarily so that people can begin working with it (e.g., cost estimating, scheduling, writing documents, etc.). On the other hand, it's useful to simply live with the WBS for a while and let it settle out with time before formalizing it. You will often find that scope items need to be moved from one area to another once you get into their specific details, including determining their contracting approaches, and this becomes harder and harder the more the WBS is formalized. It's a balancing act that is unique to each project.

In the next installment of the Work Breakdown Structure series, I'll discuss the need for a WBS Dictionary, and also include some additional tricks to keep in mind when finalizing your WBS layout and structure. I'll also include a graphic of our current project's WBS, and talk a bit about why it's not perfect (and why that's OK). Stay tuned...

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

Work Breakdown Structures, Part I

Create a WBS to help organize your project into manageable pieces.

Many new project managers (and some experienced ones, too) struggle with the concept of a work breakdown structure, or WBS. They put the wrong types of things into their WBS. Or they put too many elements in it, or too few. Or they treat it as a schedule, or a plan, or a chronological listing of actions that have to be performed. Or perhaps they eschew the need for a WBS altogether. All of these are (correctable) mistakes.

A well-constructed WBS is vital to proper project management. Without a WBS, the project manager cannot fully and correctly cost a project, schedule it, staff it, or even evaluate the risks associated with it. A WBS is a fundamental building block upon which a project is assembled and managed.

In simple terms, a WBS is a logical subdivision of a large project into smaller, manageable "sub-projects" that each have to be performed for the cohesive whole of the project to be achieved. Each element of the WBS represents "work" that needs to be delivered, conducted, performed, managed, or produced by the project team. Further, each element can be further subdivided into smaller and smaller pieces. The lowest level items in a WBS are known as "work packages."

A WBS is generally oriented toward "deliverables" of the project, but also includes all other work that the project has to perform to deliver the end product, such as project management, quality assurance and control, science support, and systems engineering. It often also includes items and services that the project has to pay for and/or secure, such as administrative services and outside legal support.

One guiding principle you should keep in mind when creating a WBS is that it should include exactly 100% of all project work, including all internal, external, and interim items. This principle is called, not surprisingly, the "100% rule" by project managers, and it is perhaps the most important thing to keep in mind when putting your WBS together. Said simply, a WBS should include all the work required, but nothing more; a WBS should not include any work that falls outside of the scope of the project. The 100% rule also pertains to sub-branches within the WBS. That is, every "parent" element in a WBS branch must equal the sum of all is "child" subparts, no more and no less.

Another guiding principle when creating a WBS is that of mutual exclusivity. It is vitally important that there be no overlap or ambiguity in scope definition between the different elements of a WBS. Overlapping and/or ambiguous scope leads to confusion of responsibilities and/or duplicated work. It also makes accurate costing and scheduling very difficult.

Besides knowing what goes into a proper WBS, there are some things that definitely are not to be included. For example, a WBS is not an exhaustive list of tasks to be performed. Instead, it's a comprehensive classification and collection of project scope, not tasks. A WBS is also not a project plan, or a schedule, or a chronological listing of tasks. Instead, it lists what will be performed and delivered, not how or when. Finally, a WBS is not an organizational hierarchy per se-- but note that a good one often aligns closely with a project's org chart.

In the next installment, I'll discuss a little more about how to create a WBS from scratch. Stay tuned.

A simplified Work Breakdown Structure (WBS) for the construction of an office building. There are many missing elements in this example, such as procurement of land, permitting, outfitting and furnishing, etc.

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

Meeting Minutes

Produce meeting minutes and distribute them afterward to all attendees.

Unless you write down all the findings, conclusions, and actions resulting from a meeting, then that meeting might as well never have happened. Said another way, you cannot assume that anything discussed during a meeting will be put into action-- or even remembered. To ensure accountability and follow-through, meeting minutes need to be distributed after the meeting-- and then agreed upon.

Said simply, people's perceptions and recollections fade and morph with time. We're human, so we're fallible and forgetful. Further, what one person thought was agreed upon in a meeting might be different than what another person thought. Meeting minutes help solve this problem. You and I get together to discuss a problem. After some back-and-forth, we agree on a solution. I get some of the action items, and you get some.  Meeting minutes document these findings and actions in a way that ambiguity and misunderstanding between us is lessened.

Good meeting minutes should be simple to read. They shouldn't be a verbatim accounting of the entire discussion. Making the minutes dense and wordy lessens the chances that anyone will fully read them. People are busy, and giving someone a long-winded recap of a meeting afterward, where they have to tease out conclusions, findings, and action items wastes that persons time.

Good meeting summary minutes should include:

• Date of meeting
• Subject of meeting
• Attendees
• Bulleted list of key findings, decisions, and conclusions
• Separate bulleted list of action items, including assignees and due dates
• A proposed date, time, and location for any required follow-up meetings.

Some other do's and don'ts:

• Be objective. Just state facts, findings, and conclusions. Avoid personal observations. 
• Write in the same tense throughout.
• If you need to refer to other documents, attach them or provide a link where they may be found. Don’t rewrite their intent or try to summarize them.

After meeting minutes are distributed, ask for everyone's email approval or comments/edits in writing. Give them a due date, typically a day or two, to respond. A simple written "Yes, I agree with the findings of these minutes and the assigned action items" email reply from the attendees is sufficient. Assuming someone agrees with your minutes because/if they don't respond is tantamount to them disagreeing. Get everyone's written buy-in.

Some projects use a formal template to document minutes. Depending upon the rigor and formality of your project, you can implement a standardized template or just use email.

On our project, we typically just use email for capturing meeting minutes, but once these minutes are distributed and approved by all the attendees, the action items often then get transferred into a more formal Rolling Action Item List (RAIL) so that they can be formally tracked and monitored.

A little bit of time turning your meeting notes into formal minutes, distributing them, and receiving written approval of them, will help ensure communications and responsibilities within your project are well understood.

Bottom Line: Take the time to produce accurate meeting minutes and distribute them after a meeting-- this reduces misunderstandings and ensures everyone knows what their follow-on action items are.

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

The Need for Travel

When planning a project, it's important to budget for travel.

Even in today's modern world, with high-speed internet connectivity, video conferencing, applications like join.me and go-to-meeting, Skype, email, IM, texts, smart phones, 4G hotspots, etc… there still is no substitute for face-to-face, in-person meetings. This is especially true for critical WBS items for which you're responsible. And even more so when you're remotely interacting with colleagues and contractors working in foreign countries, where nuances in language are literally lost in translation.

Presence matters.

Face-to-face matters.

Presence lends an air of conviction and importance that a telephone call or email normally can't carry with it.

If you can, meet face-to-face, and this in turn means you need to have sufficient budget to allow for travel. On our big, 50-person, international multi-year project, we have allocated just under $8M for staff travel over the 10-year life of the project. This works out to be about 2.2% of the entire $350M project, or roughly $16K per person per year. This might seem high to new project managers in the planning stages of a project, but on our project we have dozens of contractors located around the globe, including significant work that is performed in Europe. We also have four headquarters sites (three on continental US, and one in Hawaii).

When we started, we knew that we would be in planes, trains, and automobiles for significant periods of time. Our engineers performed bottom-up travel estimates on a work package by work package basis, focusing on the expected number of support trips needed, including the number of people we had to have at those meetings. Travel costs were then calculated and rolled up into a set of high-level management travel accounts; the estimates were performed bottom-up, but we manage the money top down.

Budgeting at these levels allows our engineers, managers, and scientists to be where they need to be to perform their job duties-- without management discouraging said travel because it's squeezing the overall budget. In other words, we planned for this expense from the start, so expectations in this area were managed from the beginning.

Allowing engineers, managers, and scientists to be where they need to be has paid significant dividends in the form of reduced errors, mistakes, schedule slips, and of course change orders. There is a marked difference is contract performance at those contractors that we support heavily with travel vs. those that we don't visit as often. Travel not only keeps the engineers well informed of progress and issues in near-real time, but it lets the contractor see firsthand that a) we care about what they're doing; b) we expect to see regular progress; and c) we're helping them solve problems as they arise, not afterward when it's often too late. Our contractors have told us they feel more a sense of being part of a team then just as a supplier. Presence lends conviction.

Bottom Line: Budget correctly for travel at the beginning of a project-- it is vitally important to success.

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