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.