Know what you're doing (Part III)

Engineers should be the best project planners in the world. They aren't, but they should be.

The problem is, planning is rarely presented to engineers in that way that they can attack. Planning is viewed as some mystical art that few people have the skills to master. People who are naturally good planners employ a process (many without even realizing it) to decompose a problem into a plan. If you don't understand the process they followed, they may appear to be Mystic Planners.

Once we peel back the shroud of mystery, we can see that planning is an engineering problem -- you have to engineer a plan -- and no one is better skilled to solve an engineering problem than an engineer.

To master the process, we first must understand it. I'm no big fan of Six Sigma, but I will admit that the Six Sigma guys were great at inventing new acronyms (I suspect they spent most of their time creating cute acronyms, then desparately trying to come up with words that fit them). Several Six Sigma acronyms have the form DMAxx, where the letters DMA stand for define, measure, and analyze. The last two letters depend on what you're doing: IC to improve and control a process, DV for design and verify a new process. The first three letters basically mean "know what you're trying to do" and the last two letters mean "go do it."

I'm going to borrow some of the Six Sigma letters to define a new acronym for engineering a plan:

    DMADE: Define, Measure, Analyze, Design, Execute
Each of these terms are common engineering terms, and whether we realize it or not, these are the steps most of us follow whenever we engineer a new product, and a plan is just another engineering product.

DMADE And Engineering a Product

To help define the DMADE terms, let's first consider a concrete product engineering example. Consider, for example, my first engineering project back in college: To design an adapter board for a PDP-10 minicomputer to an off-the-shell floppy disk controller. Sure, I had had many labs and term projects, but this was really my first engineering project. We hadn't studied the PDP-10 bus architecture, nor the floppy disk controller architecture. We were given the assignment, the reference manuals, a wire wrap extender card (I still have my wire wrap tool, right on the desk in front of me), and a bag of lsi chips, resistors, and capacitors. [Now, don't laugh too hard. The PDP-10 was already obsolete by the time I went to college. Why else would they allow undergraduates to fiddle with it.]

I remember being so lost, so adrift with this project at first. Where to start? In earlier classes, you would get a simple lab assignment, then immediately sit down and start wire-wrapping. So I sat there with my wire wrap tool in hand, staring at the blank board for what seemed like days (of course, 19 year-old boys have notoriously short attention spans, so in hindsight it was probably more like two minutes before I gave up and headed out to the Copper Mug for some fried mozzarella sticks and a beer. Oh, back then 19-year-olds could legally drink, too, which made this project all that more challenging). Finally, after nearly six days of procrastinating (and the night before the project was due), I decided I needed to attack this problem like an engineer.

First, I needed to define what I had to do. Something like: Convert I/O read/write cycles at a specific address into read/write accesses to the FD controller board. Down the left side of my page I wrote the list of signals coming from the PDP-10; down the right, the signals into the FD board. But that was still too general. I then broke the problem down further into block diagrams -- how to handle the address/data bus, how to handle the read/write enables (I seem to recall one interface had separate read and write signals, while the other had a combined read/~write signal). Then the clock had to factor into these blocks as well. Soon I had a well-defined problem. I could look at a block and know what it had to do, how it would use its inputs, and how its outputs related to the other blocks. I had decomposed the problem into quantities I could handle.

Next, I needed some measurements, that is, some quantitative data. There were set-up and hold time requirements, clock pulse width requirements, fan-out limits, and of course the logical relationships of inputs to outputs. I added that information to my block diagram, and I really started to feel like I understood what I was doing.

Next came analysis. I had to figure out how to synthesize the logic in each functional block, while also meeting the timing and loading constraints. Analysis came easily. That's the area where most of our training had been so far -- taking a simple block diagram or a set of equations, analyzing the relationships, and producing a small schematic representation.

Now I was able to finish the design. The functional blocks got mapped to real chips, and the chips were mapped to a physical layout. There was some back-and-forth with previous phases, when I realized I didn't have enough NOR gates, or I had spare NAND gates I could use instead to save me from wiring up another chip. But mostly this design phase was the inverse of the define phase. In the define phase, I decomposed the problem into small, easy-to-quantify and analyze chunks; now I was combining those chunks back together into the final product. At least on paper.

Finally, it came time to execute the design. I placed chips on the board, and wired them together based on my design. I powered on the board with a benchtop power supply and probed for proper voltages and signals. Then I plugged the board into the PDP-10 and powered it up and made sure there was no smoke and the monitor program ran normally. Then I inserted the floppy disk controller and powered it all back on again checking for smoke. The final step was verifying that the product was complete -- I had to format a floppy disk and write a file with my name on it as as proof that our design worked (this was a course in hardware design, so thank goodness the drivers were provided for us).

DMADE And Engineering a Plan

So, that long story was about product engineering, with the point being that all of us engineers go through the DMADE steps all the time. They are engineering steps. These same steps can be applied to engineering a plan.


In planning, you must define what you're doing. The first step is identifying the product requirements.

Product requirements may be in the form of the features or functionality that the product must provide. Such requirements need to be concrete and testable. An acronym used to describe good requirements is SMART: Requirements must be Specific, Measurable, Achievable, Relevant, and Time-bound. And of course, any requirement that isn't SMART must be dumb. In many cases, projects go awry because the requirements are not specific or measurable.

Requirements may also be non-functional, such as quality requirements, staffing limitations, and cost constraints. And as I've said many times, requirements should be prioritized, and a line drawn between must-have requirements and nice-to-have requirements. Plan to deliver all of the requirements, but make it clear to your customer (your manager, your marketing department, your venture capitalist) that your plan can only guarantee the must-have requirements.

But so far we've only defined the input/output requirements, much like the first step in the product engineering.

Definition also includes identifying the tasks that must be done to achieve the requirements. We analytically break down the requirements into high-level deliverables, then decompose high-level deliverables into smaller tasks, and identify the interdependencies along the way. In effect,t the tasks are blocks in a block diagram. Peers review and inspect can be benificial in helping to ensure that we didn't miss any tasks; just as peer review is essential in product engineering.

Task definitions must also be SMART: Requirements must be Specific, Measurable, Achievable, Relevant, and Time-bound.


When people were "taught" (and I use the term lightly) planning, there was usually an emphasis on estimation. But good plans are not based on estimation; they are based on measurement, that is, quanitative data.

In the Define phase, we identified the individual tasks that need to be done. Now we must measure them. And how do you measure something? If we don't know how big something is, we compare it against something we do know (a yard stick). We don't always need a physical yard stick. For example, when we meet a person on the street, we know almost immediately how tall they are; we instantaneously compare that person against our own high (the yard stick), and if they are slightly taller or shorted, we can fairly accurately measure their height. When a person is significantly shorter than I am, I'll compare their height against my wife's.

Similarly, when measuring tasks, we must use a yardstick. We need to pick a task that we've already done, and compare it to this new task. If the new task is twice as big as the old task, then we know how long it will take.


In engineering a product, the analyze phase involved looking at the various functional blocks, and dealing with non-functional requirements such as timing and loading. When engineering a plan, we also must analyze the non-functional requirements and how they impact the tasks.

In my posting Know what you're doing (Part I), I used the example of a drive to the airport. We easily identified that all of the tasks (return rental car, bus to terminal, check-in, security, walk to gate) should take 30 minutes. But when we analyzed the situation, we realized we needed two hours -- there could be traffic, a breakdown, detours, lines at the rental car return, delays in security, and so forth.

In a more general sense, our analysis must take into account many things that might affect our team members' ability to complete the task, for example:

  • Team member efficiency. Depending on the development environment, training, how often you've done projects like this in the past will significantly impact your efficiency.
  • Team member availability. This is the team members' ability to spend time being productive. Reading email, attending general staff meetings, signing up for health care, taking Six Sigma training, reading the Boston Globe online all impact a person's efficient. A weekly, one-hour departmental staff meeting, for example, alone consumes 2.5% of your time. I typically assume at least 10% of a person's time is lost to inefficiency, at best.
  • Vacation and sick time. A typical employee may get 15 days vacation a year, and may be sick an additional 5 days. Twenty days of absence per year equates to 7.5% of a person's time.
  • Sometimes people are unable to dedicate 100% to one project. They may have worked on another product and need to lend support periodically. Or they may be experts in a specific field and need to help other projects in times of emergency. And generally speaking, the better the engineer, the more likely they will get pulled off to work on other projects. Let's assume they spend 10% of their time helping other projects.
  • Finally, there's planning for emergent tasks, the unexpected tasks that always arise. They may be as mundane as your PC dying or taking a training class to learn how to use a new development tool, or as critical as solving a race condition in some multi-threaded code that only happens once every three days. No one plans on these tasks, but we can plan for these tasks. On a small, low risk project, emergent tasks may be a small percentage (10%); on large or high risk projects, emergent tasks may consume half your team's time. For a general number, let's assume a typical figure that 20% of your team's time will be spent on emergent tasks.
After this quick, back-of-the-envelope analysis, we can see that team members may only be able to spend half of their time working on planned tasks. And in order to accurately measure the time it will take to complete a task, we have to know the person who will be working on it -- we have to know how productive they are, how well they work in the team environment, how well they know the task at hand.

I think analysis is the most critical step in engineering a plan, and it is often overlooked. New project engineers will sum up the task durations, measure how long it would take them to do each task, divide the total time by the number of people in the budget, and promise a product in X weeks. The product ends up taking 2X weeks or 3X weeks, and they just don't understand why.

As an aside, one of the best tools for analyzing a plan is CoCoMo. I've used CoCoMo in one form or another for over twenty years. An easy-to-use online version is available at


Design is the opposite of definition. In the definition phase, we decomposed a problem into tasks; in design, we construct a set of tasks into a plan.

But a plan isn't a schedule. It isn't a list of milestones. It isn't a gantt chart (and you don't want to get me started on gantt charts!).

A plan must address the who, what, and when questions about the project. It must also address the "what if" questions. Contingency planning is critical in the design phase For reference, see Everything I needed to know about project planning I learned from my little league coach.

When you're done designing your plan, you should be able to identify:

  • What will the project deliver, and when.
  • Who will be working on the project.
  • What task is each person responsible for.
  • When is each task expected to be complete.
  • How much is this going to cost.
  • What equipment and tools are needed.
  • Where (lab space, office space, etc) will the work get done.
  • What do you depend on from outside the project team.
  • What will you do if anything that can go wrong, does go wrong.
A well-designed plan answers all of those questions.


I'll cover plan execution in my blog entry, "Know what's going on".
Copyright 2007, Robert J. Hueston. All rights reserved.

Post a Comment:
Comments are closed for this entry.

Bob Hueston


« July 2016