The Written "Unwrittens"

My wife is a book collector and seller. At any given moment in time, she has somewhere around 5,000 books in her inventory stacked and shelved and scattered throughout the house. Occasionally, among the many thousands, a gem arises. Usually that gem takes the form of a rare or collectible book that can command a high online price-- but sometimes, the gem is even more special. Sometimes, it's a book that hubby wants to keep. Enter today's treasure: "The Unwritten Laws of Engineering," by W.J. King:

Published back in 1944 by the American Society of Mechanical Engineers (ASME), this little 50-page pamphlet is a truly fantastic read, and while the title implies it's an "engineering" book, the fact is much of the book is focused on team interactions, how to make and document decisions, and general project organization and structure. Said simply, the book is so germane to the subject of engineering project management that I intend to cover many of its individual lessons herein this blog over the coming months...

...but the bottom line for today's post is this: despite the myriad of technological and communication advancements in the nearly 70 subsequent years since this book's publication, the "laws" of engineering management have not materially changed. In fact, if anything, they've hardened. Said another way, the very things we PMs struggle with today are essentially the same issues and concerns that our grandfathers and great-grandfathers struggled with at the close of WWII.  I literally found myself nodding my head and mumbling agreement and "amens" to the words on the page as I read through booklet the first time. The more things change, the more they evidently stay the same.

This is definitely a collectible in the truest sense of the word. Stay tuned for some of its wisdom.

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

Scope and the Triple Constraints of Quality, Schedule, and Budget

In today's post, I want to expand a bit on the relationship between the scope of a project, and the three fundamental constraints that get placed on that scope: schedule, budget, and quality.

We've all heard the old management joke: good, fast and cheap; you can maintain any two. But what does this actually mean? And how does it relate to the scope of deliverables of a project? I've been pondering this a bit lately, and being the engineer that I am, I had to draw some pictures to articulate my thoughts.

Imagine that the Scope of your project is represented by a triangle. Further, let's equate the extent of the delivered scope to the physical area of the triangle; the bigger the triangle, the larger or more extensive the delivered scope.

Then, to pin down this triangle's area, we're going to place at each of the triangle's corners so-called "constraints" that lock down the vertices and therefore fix the area, or delivered scope.  For example, at the top of the triangle is the quality constraint of the delivered scope. The position of this vertice defines the quality requirements of the scope.

Similarly, at the lower left of the triangle is the required time constraint in which you have to deliver the scope. And at the lower right is the budget constraint which you have maintain while delivering the scope. These three vertices together are referred to as the standard management "triple constraints" of a project, and essentially define the extent to which the scope can increase or decrease. In a sense, these area the boundaries in which you, the project manager, have to work to deliver the scope to the customer.

If we try to increase the quality of the delivered scope, for example, we represent this by pushing down on the top corner of the triangle-- and, because we want to maintain the delivered scope (i.e., the physical area of the triangle), one or both of the remaining vertices has to shift outward. Said another way, it's going to cost more money and/or take more time to deliver a higher quality product than was originally scoped.

In a similar manner, if we want to speed up delivery of the project's scope, we have to either add more money or resources to the project, or we have decrease the acceptance criteria (quality) of the delivered product. Or both. And the same holds true for cost; if our budget gets reduced, one or both of the other two scope constraints has to give somehow:

And finally, to extend this area-of-the-triangle analogy further, if we want to expand the scope of a project (i.e., increase the area), one or more of its corner constraints has to move outward; i.e., you will likely need either more money, more time, and/or have to reduce the quality requirements of the project:

Note that most projects have a priority that can be assigned to the triple constraints, with one or two having higher importance than the third. For example, if you were in charge of building a nuclear power plant, the constraint of quality would probably be much more important than that of schedule (i.e., it's more important that the nuclear reactor is of high quality than it gets built on time). Similarly, if you were put in charge of organizing and hosting a major event with the associated construction of major infrastructure, such as the Olympics, the constraint of schedule  (i.e., opening on time) is probably much more important to maintain than cost, and perhaps even quality.

Every project is different, but they all have similar reactions when putting pressure on their individual scopes. Your job as a project manager is to define these four things (scope + the triple constraints) at the beginning of the project, and then do your best to hold them all fixed in position throughout the life of the project. And when pressure is applied to that triangle, keep in mind which of the vertices are more important than the others.

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

A Better View of the Top Ten

In my last blog entry (here), I discussed the ten primary roles/responsibilities of a successful project manager. While I think the post did a reasonable job laying out the jobs of a PM, I wasn't fully pleased with the graphic that showed them all tied together. And I apparently wasn't the only one-- I heard from a few readers that the image didn't really make a lot of sense and could be improved upon.

Which brings us to today's blog post, where I try to do a better job of graphically illustrating the responsibilities of a modern project manager. Along the way, I also did a slight reorganization and clean-up/re-clarification of these 10 roles and responsibilities (click to enlarge):

The ten responsibilities or jobs of a project manager include: Manage Scope, Manage Schedule, Manage Quality, Manage Cost, Manage Procurements, Manage the Project Team, Manage Stakeholders, Manage Communications, Manage Changes, and Manage Risks. Sounds simple, right?

To better understand this new graphic, let's break it down into discrete pieces, starting with the topmost four, which of course are deliverable scope (i.e., the "widget") and the triple constraints of quality, schedule, and cost (a.k.a. good, fast, and cheap):

Without question, these four items are the most important responsibilities of the project manager. You have to define what the widget is you're delivering, and you have to understand how good this widget has to be (quality), how fast it's needed to be delivered (schedule), and what your budget is to create it (cost). Defining these four things up front, and then managing them throughout the course of the project's life, are perhaps the four most important things a PM has to do.

Next is the job of ensuring that the components of the widget are actually designed, built, assembled, tested, and accepted. While you as PM may not actively perform any of these jobs, you will be responsible for ensuring they take place (on budget, time, and within the quality requirements discussed above):

Procuring the components of the widget, assembling, testing and accepting them can be done in-house, out-sourced, or a combination of the two. Regardless, your job as a PM is to ensure delivery of the widget via some procurement plan that you oversee.

None of the previous things, like procurement or ensuring quality can be done without good, qualified, hard-working people on staff to perform the actual work. As Project Manager, a fundamental role of yours is to plan, hire and lead this project staff from the top down:

The Project Team is the heart and soul of any well run project. Leading these people into (and ultimately out of) project battle is your responsibility as PM.

Like it or not, there will be any number of stakeholders (internal and external) that will have an influence over and/or are affected by your project. Identifying these disparate individuals and groups, understanding their respective powers and interests, and then managing their expectations is a vital part of success as a project manager.

Stakeholders come in many different flavors, including those for, against, and neutral re: your project. The stakeholders shown in this image are just an example of the types of groups and people that you must identify and "manage" during the course of a successful project. Every project is different, and every project will have its own unique blend of stakeholders.

Communications are so important that they end up getting their own spot in this list. This category not only includes meetings, correspondence, email, reports, and the like, but also all the related things like data archiving, revision control, and even travel.

Communication management is primarily focused on two key things: comms between your project and external stakeholders, and all the internal comms that take place inside your project. Ensuring the right people are hearing and understanding the right data at the right time is the name of this game.

The last, but certainly not least, roles of a PM are the  the management of changes and risks to the project. Change always happens on a project, in one form or another. Similarly, risks always occur, and can range from those that put pressure on cost, scope, and schedule, to those that threaten the very existence of the project itself.

Changes occur nearly constantly on a project, as do risks. Identifying, evaluating, and actively managing these two things are the responsibilities of a project manager.

Hopefully this visual breakdown makes more sense then the last time-- but please let me know if you'd like to see further clarifications. As I slog forward with this blog in the coming months, I will undoubtedly go into a lot more detail explaining these ten key roles of the modern project manager. Stay tuned.

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

Defining Project Success: The 9+1 Core Jobs of a Project Manager

Before we can succeed as project managers, we have to understand what it is that we’re actually tasked with managing. We literally can’t be successful unless we know what the definition of success is.

At first blush, this sounds easy. As PMs, we are tasked with planning and overseeing the creation of some new unique "deliverable." This deliverable is essentially the product or service or big-picture objective that will be the tangible outcome of a project. For brevity's sake, let's call it the “widget” that is going to be built. This can be almost anything, from a modest home addition, to a race car development effort, to an ambitious new software application, to an upgrade to an operating system, or the design-build of new billion dollar supercollider—it doesn’t really matter. The job of a PM is to ensure that all the tasks required in the creation of the widget occur on time and within budget, and the resulting product performs the way it was intended to perform. Simple, right?

Well, yes and no. While the creation of the unique deliverable is obviously the core raison d’etre of a project—and therefore should be the core focus of its project manager—there are a number of supporting tasks that also have to occur both sequentially and in parallel with its construction to ensure the project’s success. There are also always constraints—both internal and external—that dictate how and when the project can be brought to fruition; these can be fixed budgets, hard deadlines, required personnel, and so on. Said another way, every project’s specific deliverable may be different from the next, but all projects share common generic attributes, functions, constraints, and tasks that have to be managed in order for the widget to be created—and hence the project to succeed. This in fact is fundamentally the role of a project manager: to plan, execute, monitor, control, and ultimately ensure completion of all the discrete tasks and efforts that will lead to the creation of the deliverable/widget within the constraints and restrictions imposed.

So what are these common tasks, efforts and constraints? To fully answer this, we need to rewind and start with what the formal definition of a project is. I’m a certified Project Management Professional (PMP), so naturally I am inclined to turn to the Project Management Institute (PMI) nomenclature, where a project is defined as:

“a temporary endeavor undertaken to create a unique product, service, or result.” 

Other organizations have slightly different, but fundamentally similar definitions. For example, the highly-regarded British Standards Institute (BSI) defines a project as:

“a unique set of coordinated activities, with definite starting and finishing points, undertaken by an individual or organization to meet specific objectives with defined schedule, cost, and performance parameters.” 

Uh, okay, you might be thinking. What’s so earth shatteringly useful about these stilted definitions? Well, for starters, from these descriptions we can tease out those aforementioned key characteristics that all projects share in common. These in turn will lead to a core defined set of tasks and responsibilities that us, as project managers, will be responsible for organizing and overseeing during the construction of our respective widgets. It will also help us prioritize the work we have to do to accomplish these goals. So let’s break down the definition of a project to see what its constituent parts are and ultimately tells us what it is we have to manage. As it turns out, there are nine specific areas or core functions that you as a PM need to focus on:

1. Deliver the Widget. First, there is the unique deliverable itself. We’ve been informally calling this the “widget”, but "deliverable" is the more correct word. In fact, perhaps a better term might be the project’s over-arching "objective" or "goal." I personally like these alternate terms, as they leave open the possibility of creative technical solutions that still meet the customer or end-user's needs. In a bridge construction project, for instance, the design solution might ultimately be, in fact, a steel suspension bridge, but the objective is the more broad goal of providing a transport system that allows the movement of people and vehicles from one side of a river to the other. It doesn't specify the actual solution, which could be the bridge, or might be just the purchase of a ferry, which could cost a lot less money and meet all the requirements. But I digress.... the bottom line is that the deliverable is something new and discrete you are tasked with providing that has never been done before in exactly this same way. It is in fact "unique." If you don’t deliver this specific thing by the end date of the project and/or when the money runs out, you will have, by definition, failed as a project manager. When managers speak of “keeping their eye on the prize,” this in fact is the “prize.” At the very heart and center of managing a project is the need to define and create the deliverable. 
2. Manage Scope and Quality. Second, because the deliverable is unique, it will by definition have very specific attributes associated with it. If you’re building a physical thing, these attributes are usually specified by the form, fit, and functional needs of the deliverable. If it’s a software upgrade project, the attributes may be performance requirements or specifications for the graphical user interface (GUI). If it’s a new scientific instrument, the key attributes of the finished device are likely its technical science requirements. And so on. Regardless of what the deliverable is, we can divide these attributes into two related parts: scope (i.e., what precisely will and won’t be created) and quality (i.e., how good will the delivered scope perform). Note that these attributes are measurable, or testable. In other words, final project success is significantly defined by how closely your team creates a widget that literally functions and performs per the predefined scope and quality requirements set forth at the beginning of the project. 
3. Manage the Schedule. The various definitions of a project also always state that projects are temporary in nature. This means every project has a start and an end. Said another way, every project has a definitive beginning and a specific target end date, which in PM-speak means it has a schedule. Now, often the date of a project’s beginning may be somewhat fuzzy as an idea evolves into a true project and gains actual funded momentum. The end, however, must be clearly defined so that all the project participants agree on what it means to be complete. A project’s success is often determined by how well the PM does in managing the schedule and meeting the delivery date for the final widget. 
4. Mange the Cost. Besides Quality and Schedule, adherence to a Budget is a fundamental measure of how well a project is performing. (In fact, these three things together are often referred to as the “triple constraint” or “golden triangle” of project management: good, fast and cheap.) Someone—often the customer or sponsor or upper management—has agreed to commit financial resources to allow the creation of the widget to proceed. The project manager is tasked with allocating and spending this pot of money in a way that allows the creation of the widget to occur efficiently and in the proper sequence. If you overspend this budget before you finish, the project is typically viewed as a failure. The PMs job is to ensure this doesn’t happen. 
5. Manage Risk. The word “unique” in the definition of a Project also implies some measure of uncertainty. In other words, by definition, no one has created this exact thing before, so there is risk of unknown problems derailing or slowing or costing the project. This risk often spans the golden triangle of scope/quality, schedule, and cost, but it can also extend further into things like loss of personnel, external project factors, stakeholders, change, and the like. One of your key jobs as a PM is to identify, mitigate, and manage these risks that threaten your project. 
6. Manage and Control Change. Upper management and sponsors/customers hate to hear this, but the hard fact is a project plan is nothing more than a series of educated guesses as to how the work will unfold with time. And as military strategist know, no battle plan survives its first contact with the enemy; i.e., your management plan will change. External and internal factors will morph the project. Technical hurdles will arise. Customers will ask for new features to be included in the widget. Key personnel will leave. Contractors will fail to deliver. You will have to adapt and modify your plan to accomodate these issues. In other words: change happens-- deal with it. Said simply, one of your jobs as a PM is to manage this inevitable tide of change in a way that minimizes the effect on delivery of the widget. 
7. Manage Procurements. At the end of the day, you have to actually create the widget. This means you have to “procure” it and its constituent parts. This procurement can be via contracts with contractors, purchase orders with vendors, or perhaps the bits and pieces of the widget are to be fabbed/created in-house by your project team. Regardless, one of your key jobs as a project manager is to ensure these procurements occur in the correct order, on budget, on schedule, and that the delivered scope/quality is up to the appropriate standards. This in effect is where the rubber of the golden triangle hits the management road.
8. Manage the Stakeholders. Ah, stakeholders. Love ‘em or hate ‘em, these are the organizations, groups, and/or individuals that will impact and/or be impacted by your project. For example, the “unique product, service, or result” that is your widget is being paid for by someone-- and that someone cares and often wants to be in decision loops—or least informed of project progress on a regular basis... or else they might decide to stop supporting the project. Similarly, there are customers who will use the widget once delivered, and these people often have strong opinions about scope and quality and schedule. There can also be government regulatory entities who have a say in how you can procure the widget, trade associations and unions that want a piece of the pie, interest groups who want you to succeed or fail, suppliers, lenders, senior management, etc. that all have a stake, big or small, in your projects’ success. How you identify, monitor, communicate/inform, manage, and ultimately satisfy these stakeholders can have a huge impact on the perception of whether your project succeeds or fails. 
9. Manage and Lead the Project Office/Team. Lastly, but certainly not least, is the management of the project team/office that will perform the day-to-day work and ensure delivery of the unique widget on time and budget. Technically-speaking, the project team is a subset of the aforementioned Stakeholder group, but it is so fundamental and unique to the success of a project that I believe it should be treated as a standalone management entity. This project team can be just 1-2 people, including yourself, or it can be a cast of hundreds or even thousands. Your leadership of this disparate group is fundamental to your project’s success; i.e., these people are the heart and soul of a project, and everything from their technical abilities to their health and morale are factors that can and will ultimately affect the delivery of the widget. Managing this team is one of your key jobs as a project manager. 
10. [Bonus PM Function: Communicate. This one is a really important but under-sung function of the project manager. It also takes on many, many different forms, from formal reports to informal telephone calls, and everything in between, including meetings, emails, document repositories, task lists, and the like. Because it's so broad in nature, and because it stretches across so many of the previous nine PM functions/jobs, I don't include it formally in the list of core functions of the PM. But it's still vitally important. So consider this a bonus thing you have to master and perform for your project to succeed. :-) ]

The bottom line is that every project has limited resources (budget, personnel, schedule, etc.) to create the deliverable. Your job as a project manager is to spend your time planning and executing the usage of these resources in a way that best ensures the successful delivery of the widget. Keeping your eye on the prize by focusing on and actively managing these nine PM areas will help you do exactly that.

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

Time Management - Rolling Wave Planning

In my last post (here) I described the basic process of putting an Integrated Project Schedule, or IPS, together from scratch. Today I want to discuss a common trap that many Project Managers fall into when creating their IPS: adding too much detail to the out year work. 

On complex, multi-year projects with hundreds or thousands of tasks to define, sequence, and estimate, you and your team can spend significant time and effort putting together the IPS-- and some of this time and effort can be a waste of, well, time and effort. Said simply, detail planning of the work that is scheduled to happen in the near term matters a lot more than the detail of the work that will happen in the distant out years of the project. In fact, the details of those out-year tasks don't have to be perfect. Far from it.

Yes, it would be great if you knew for certain all the specific step-by-step things your team has to do during the third week of June four years from now, but the truth is you almost certainly don't know what's going to happen during that week. The truth is you probably don't know for certain what is going to happen four months from now, let alone four years. Heck, you're often doing well as a project manager if you know what's going to happen four weeks from now with certitude. You can guess the out year work--and a certain amount of guessing is indeed necessary--but far to many new project managers get hung up on trying to get those out years perfect. And in most cases, it's a waste of time to do so. In fact, it's costly to do so. Let me explain.

First, notice the word "guess" in the previous paragraph. Your boss and/or sponsor probably doesn't want to hear and/or acknowledge this, but a schedule is nothing more than an educated guess of how long and in what order the tasks of your project will need-to occur. You, as a project manager, get paid to make and hold your project to these guesses, but they're still guesses nonetheless. And the fact is that you can guess a whole lot better for the work coming up in the near-term than you can for the work that will happen months or years from now. Enter rolling wave planning.

Rolling wave planning is a type of progressive elaboration technique in which you concentrate you and your team's effort on adding detail and fidelity to the near-term "wave" of upcoming tasks and deliverables, and spend less time estimating details and durations for the out-year tasks. As time inexorably marches forward, your job is to push this rolling wave of guesses forward and add detail and refinement to the plan as the project's "event horizon" changes. At the beginning of the project, near term work is decomposed into individual subtasks and steps, and they are defined at the greatest level of detail possible. Schedule activities that will take place several reporting periods in the future are more broadly defined. For example, phases one and two of a project might be fully broken down in full detail, but phases 3-6 might be outlined only to the level of subprojects, and phases 7-10 are even more broadly estimated. While schedule activities for phase 1 are underway, the detailed planning for phase 3 would commence. As phase 2 is put in motion, planning for phase 4 would start, and so forth.

In this way, rolling wave planning permits work activities to move forward on current and near term deliverables while refined planning is still ongoing for future work packages. This type of project management approach is particularly useful when the availability of information needed to plan future work packages in detail is based and predicated on the successful completion of previous project phases. Here's a generic example of a rolling wave schedule to demonstrate (click image to enlarge):

Note that the near term work in this generic schedule has been estimated and sequenced down to a relatively high level of detail and fidelity. The mid-term tasks that follow the near-term are left as bigger blocks of medium-sized tasks, with less resolution. And the far out-year work is simplyl represented by big, rough blocks of effort.

Note, too, however, that reportable level-1 milestones have a regular cadence to them that is irrespective of the level of detail in the schedule above; this type of milestone is usually important to your senior management and/or your sponsor, so you often have to include all of them from the very beginning of the project. Most of these are tied to specific work tasks, but sometimes the out year milestones need to be artificially placed using educated guesses and/or expert judgement. As the rolling wave of time moves forward, you can refine and add logical predecessors to more accurately reflect milestone movement.

In almost all projects, the out-year task details are going to change and adjust as the project matures and progresses. Stuff happens, as they say. New information becomes available, tasks you thought would go easily don't, and vice versa. Delays happen. Technical problems crop up. External factors affect your internal work. Personnel leave and/or get promoted and/or move on. Change occurs. Spending a lot of time making the out-year work planning guesses perfect in your schedule is, frankly, a waste of that time. Not only are you spending valuable effort estimating things in great detail that are almost certainly incorrect and will change, you also have to continuously debug and refine and defend and explain all the resulting changes to those tasks as they move and shift in your IPS.

Instead of doing this, spend that same time and effort making the near-term and mid-term items as perfect as you can, and just estimate the out-year work via past experience on other projects, engineering rules of thumb, and expert advice. If possible, build in buffer on those out-year estimates to soften the blow of future changes. But then stop fretting that out-year work, and refocus the bulk of your attention on managing the near-term efforts. As time marches forward and the mid-term work starts to be creep into the near-term, you and your team will add detail and refine those new event horizon tasks. The wave of time marches forward, and so should your planning efforts.

For example, on my current project, for the first few years we left our enclosure (dome) site assembly and test work very roughly planned in our schedule. We didn't know for certain how this work would be sequenced, so we didn't waste time worrying about it. We knew from past projects that it took roughly a year to assemble and test an observatory dome, so we simply inserted a year-long estimate into the schedule and then focused our efforts on planning and managing the tasks that led up to that work. Then, when we were about six months from performing the site assembly and test work, we took the time to reexamine and break down the large generic tasks into more refined and accurate smaller tasks that we could track and manage as we moved into that phase. Here's the before and after shot from our schedule to demonstrate how this worked (click to enlarge):

This is a classic demonstration of how rolling-wave planning should function on large, complex projects. That's the good news. The bad news is we frankly didn't so well in a few other areas of our project. In fact, a couple of our subsystem engineers added far too much detail to their respective out-year tasks when laying out the original IPS, and we/they are still paying for that mistake; these engineers/workpackage-managers have to spend significant time every month changing and managing and explaining those bad guesses as things have changed. This all could have been avoided if we'd enforced the concept of rolling wave planning across the entire team on our project from the beginning.

Learn from this and try it on your next project. You'll probably be much happier if you learn to surf the wave!

 2014 Mark H.Warner. All rights reserved.

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.