OK, show of hands – who is currently working on a project that is behind schedule? (And, what are you doing here reading, then? Get back to work!) Project scheduling and estimating might be one of the most important skills that we are not taught in engineering school. In fact, our engineering school experience often leads us down a garden path that hinders our future ability to realistically schedule and estimate engineering projects.

After all, most engineering school projects are repeated and recycled year after year. Projects that consistently prove to be too difficult to finish within the boundaries of a school semester or quarter are culled from the curriculum, leading to an evolved repertoire of nicely-scoped, proven solvable problems for our budding engineers to tackle. We walk into class at the beginning of the term, read through a well-conceived requirements document, and enthusiastically embark on our three-month engineering adventure, confident that we’ll burn some midnight oil along the way, but equally secure in the notion that we’ll have working hardware on our lab bench and PowerPoint summary slides on our laptops come the end of the term. 

Then, we enter the real world.

In the real world, we almost never get a clear, concise engineering specification at the beginning of a project. We usually get some vague preliminary idea of what we’re going to need to accomplish, and the only thing we can say for certain is that the requirements will change before our work is done. Most of us end up creating specifications and schedules based on best-guess compromises between our interpretation of the initial requirements and our swag at what is possible to achieve with current technology. If we are smart, we pad that with some generous helpings of extra time to account for all the changes marketing is going to toss our way, and to give us some breathing room to solve all of the unexpected problems we will encounter.

That’s all assuming we get to make our own schedule in the first place.

Unfortunately, in many cases, we have no input into the schedule at all. We get a deadline (just like in school) by which our work is expected to be complete. This deadline might come from anywhere. It might be arbitrary – the whim of some executive-level manager. It might be derived from the amount of time our startup funding will continue to pay our salaries. It might be marketing’s guess of when our competitors will have a comparable product ready for market. Of course, this is not school. We have no assurance that our project goals can be achieved by humans in the allotted time – or in any amount of time, for that matter). We are blazing new trails in unexplored territory.

One popular management trick is to sending engineers and engineering project leaders to project management school. There, we learn PERT diagrams and GANNT charts and other classical project management techniques. We graduate with a nice certificate – suitable for framing. We then waltz confidently back to our cubicles ready to take on our next assignment. “This time,” we say, “we’ll get it right. We will deliver on time with all the requirements met.” Armed with our new skills, we will tame the terror of slipping schedules. Our team will be tight. We will NAIL it!

The problem is, most of those project management techniques we just learned evolved from industries like construction. In construction (unlike engineering) people are typically repeating the same (or very similar) processes over and over again. They know how long it takes to pour a certain size foundation. They have seen how much time it takes to frame the structure. Plumbing and electrical may vary slightly from job-to-job, but overall the sub-tasks that make up a complex construction project are well understood and can be fairly accurately scheduled based on past experience.

Construction project scheduling is therefore primarily about dependencies and resources. (That’s why we learn about PERT charts). You can’t do the framing until the foundation is poured. You don’t drywall until the framing is finished. Likewise, the roof can’t go on until the structure is sound. Construction projects are filled with nice, well-behaved, end-to-start dependencies and clear, predictably-sized tasks. That’s why classical project estimation and management techniques work – in construction, that is.

When you sit down at your engineering desk, however, armed with your newfound project management skills, you almost immediately run into a problem. It’s often difficult to even create a list of the sub-tasks involved in a new engineering project. If you manage to get past that hurdle, you find that it is near impossible to guess the size and duration of any of them. And finally, when you fake your way through that exercise, you realize that – instead of crisp end-to-start dependencies like our friends in construction use, we have fuzzy middle-to-middle dependencies that defy all known graphing techniques. You end up with things like “The graph interpolation algorithm and the data model design project have interdependencies that make it so neither project can be finished before the other.” Hmmm… how do you show that on a PERT chart?

If the engineering project you are managing is a software development project (or contains one) – these problems are amplified exponentially. This is compounded by the fact that individual software engineers almost never have any ability to accurately estimate the amount of time required for even simple tasks. I managed software engineers for over two decades. During that time, I learned that most software engineers, given a description of a moderate-sized task, will give an estimate of “three weeks” for completion. It doesn’t really matter what the task is. Software engineers have a surprisingly hard time imagining anything they can’t finish in three weeks. Oddly, once they’ve spent five or six months finishing the task and working out those last couple of nagging bugs that just wouldn’t go away, if you ask them how long it took them, they will usually tell you, “I think three weeks or so…,” which completes a feedback loop that reinforces future inaccurate estimates.

While it’s always fun to make fun of software engineers, the challenges of meeting engineering schedules is hardly their fault. The key underlying issue is that almost all engineering involves invention. We are called upon to invent new solutions to problems that have not been solved before. Invention itself is impossible to schedule. Therefore, when we create an engineering schedule, we are usually weaving an elaborate latticework around the futility of scheduling invention. We are quietly hoping that the plausible-looking estimates we provide for most of the more mundane tasks will obfuscate the fact that we really have no idea how long it will take us to invent solutions to all the new problems that we will discover on the way to finishing our task.

So, next time you find yourself behind schedule, try to take some comfort in the fact that it’s not all your fault. The system is broken, right? And how could you be expected to make up for that? Certainly not all by yourself. I mean, except for those of you that are still reading instead of working. Sheesh! What’s that smell? Is your soldering iron still on?