In part one of this post we built the case that models are general tools used to help us make decisions, noted that plans are only good or bad in comparison to the work you want to manage, and observed that fixed process cannot serve a range of needs efficiently.

So how do you build exactly the plan that your particular situation requires? Simple – apply the same engineering insight you would to design any other product.

Engineering a Great Plan

If you think of planning as a design process, it becomes much easier to recognize and apply engineering parallels to conventional planning tasks. More importantly, when you treat planning as a design task, the quality of the plan can improve tremendously.

Viewing project planning as a design task, not simply a management one, is the secret to leveraging available engineering training and experience.

Needs Drive Design Strategy

Any design task benefits from clear understanding of who the stakeholders are, what they want to do, and how they define success. Not only are those factors likely to be different on every project, they can also change during the life of a single project. That means that ongoing maintenance of the project plan must be designed into the plan.

Failure to account for all significant stakeholders is a common project planning mistake. You may not be able to make all of them happy all of the time, but you should avoid being surprised.

The design process is always tuned to meet different needs, and that principle applies in project planning as well. You need a flexible plan if your environment is undergoing rapid change. If outside variables are fixed and you’re going to do something hundreds or thousands of times, invest in absolute control.

Inertia applies to plans too – the bigger they are the harder it is to start, stop, or turn them. The ideal plan is the smallest that effectively bounds the work, characterizes its true nature, supports decisions, and is maintainable as scope and environment change.

Trust Einstein on this one – “Things should be made as simple as possible, but no simpler!”

Bound

A project objective, like a set of engineering design requirements, can also be thought of as a simultaneous equation to solve. The first step is to establish the set of terms within that equation. It is the outer boundary that matters here; everything within the boundary is significant, and everything outside is irrelevant.

Another way to think of this is a wall dividing the universe up into piles of “care” and “don’t care” stuff (aka, “needs” and “wants” or “required” and “desired”). All systems need boundaries, and Project Scope is merely the PM community term for the overall system of project requirements and deliverables. At first, it’s more important that stuff go on the right side of the wall than it be understood in detail.

Failure to account for true Project Scope dooms many plans to an untimely end. Breadth must be established before depth becomes significant, and it is far better to cast a wide net and later pull back than to overlook key responsibilities. Define what the project is AND what it is not.

Characterize

A smart way to design a system is to seek the “smallest number” of “simplest possible” interfaces. That same wisdom applies in project planning. Your goal is the most useful organizing view you can impose on the responsibility contained within the project.

Want to solve that simultaneous equation? Understand relationships among the individual terms and look for ways to substitute or otherwise reduce the remaining number of terms. Once you’ve “whittled away” as much as you can, the remaining “core variables” are highly interdependent and thus must be dealt with as a set.

Your goal is to expose the underlying nature of the work itself, both in the number of tasks and the dependencies that exist among them. The most important aspect of this work is the essential core, those interactions that cannot be further dissected or addressed independently.

Constrain

Ever encounter a design specification that offered you unlimited power, space and pricing flexibility? Maybe it’s an electronic component with unlimited gain and no instability issues? Been offered “all the time you need” lately?

In the real world, every project is a mix of fixed characteristics embedded in the required scope plus a complex mix of constraints that exist only in a given situation at a given point in time. One is static and relatively permanent, the other is dynamic and often in continuous flux.

All projects have a fixed nature, arising from the required work itself, to which situational constraints must be added in order to obtain a point-specific project plan.

Balance

In effect you are dealing with an immovable object, the underlying nature of the work itself. That work runs up against an irresistible force, the evolving series of constraints over time. The combination leaves you in the middle trying to maintain equilibrium. Understanding stakeholders and their needs is critical to selecting the right balance of cost, schedule and technical trade-offs.

Great project plans, like great product designs, arise only from the artful balance of conflicting objectives.

Think Functionally

What you want to do, which can also be called the desired function of a task, is far more valuable than how you did it last time or how you chose to do work this time. The function remains constant over long time periods, whereas the means of accomplishment can vary.

Think function first, and make sure that function is actually required for project success. Only then debate how you want to perform that function, this time, given this set of constraints.

Maintain

When you mix a static set of conditions with a time variable set of constraints, you inevitably end up with a series of evolving baselines. In engineering, a common starting practice is to sample at a rate 10x the rate of change you are trying to observe. Less frequent samples may not give you the resolution you need to see waveform details. More frequently adds effort, but little or no new information. The “10x rule” is simply a compromise between the two. This same principle can be applied to project planning.

Two rates of change drive project baselines. One is the relatively slow rate arising from formal scope modification, the other is the much faster rate at which constraints evolve. Failure to maintain plans lowers efficiency and increases risk.

If your project changes daily but only updates planning status quarterly, you are in trouble. If the project changes quarterly and you change the status daily, you drive everyone crazy and accomplish nothing.

The “clock rate” for any project must be sufficiently fast that sampling and control actions are responsive to project needs.

Explore

All of your personal and organizational skill at building models can be tuned to designing a great plan. As you begin thinking in this way you will see countless analogies emerge. Concepts such as signal to noise ratio, control theory, damping, resonance, oscillation and many others have direct counterparts in the art of designing effective plans.

In future posts we’ll explore these and many other ways to leverage your design/engineering insight in pursuit of highly effective project plans!