feature article
Subscribe Now

Time Trials

The Modern Myth of Scheduling Engineering

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?

2 thoughts on “Time Trials”

  1. A quote I’ll never forget from an IC design manager (for whom I had immense respect): “If I don’t say I can get it done in this timeframe, then they’ll fire me and hire someone who will say he can.” Doing it on time isn’t required; saying you can do it on time is required.

    On the flipside, when trying to manage a complex hardware/software project (one I came into when it was well underway and not well managed) and trying to figure out when one of the software elements would be ready, the programmer just sort of shrugged and said, “How about I just call you when it’s ready, m’kay?” (OK, he didn’t say “m’kay,” but it helps illustrate the body language.)

  2. Sooooo how do you present a non-waterfall plan to management that demonstrates the interdependency of all these tasks ?

    For management that only cares about major milestones a simple spreadsheet with end dates (avoid start dates like the plague) seems to satisfy most, but for the detailed oriented we’re pretty much doomed.

    Having said the above; the bottom line is still the bottom line. While most of us love what we do, and would probably do it for free, we still need to pay the rent and feed our families. At some point we do have to finish so our company makes money so we get paid.

    I would like to hear from anyone who uses a tool that has proven effective when presenting project information to the pointy hairs. At the moment we’re playing with the BPMN 2.0 tools, but haven’t found the definitive guide on making it into a project reporting device.

Leave a Reply

featured blogs
Oct 16, 2018
At advanced nodes, there'€™s always a deep conflict between power, performance, and area (PPA) and design turnaround time (TAT). You already know Innovus Implementation System very smartly delivers PPA advantage and accelerates digital design TAT through various features, i...
Oct 16, 2018
EDI CON USA brings together RF, microwave, EMC/EMI, and high-speed digital design engineers and system integrators for networking, product demonstrations, training, and learning opportunities. And as you have probably already guessed, Samtec will be attending EDI CON.  We wi...
Oct 16, 2018
  IC Insights has just published the September Update to The 2018 McClean Report, and one figure (reproduced below) puts yet another nail into the coffin for poor old Moore'€™s Law. Now please take care. There'€™s a vertical line between the 200mm wafers on the left ...
Oct 12, 2018
At the end of the day, your products are only as good as their in-the-field performance. It doesn'€™t matter how well they performed in a controlled environment....