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
Jul 3, 2020
[From the last episode: We looked at CNNs for vision as well as other neural networks for other applications.] We'€™re going to take a quick detour into math today. For those of you that have done advanced math, this may be a review, or it might even seem to be talking down...
Jul 2, 2020
Using the bitwise operators in general -- and employing them to perform masking, bit testing, and bit setting/clearing operations in particular -- can be extremely efficacious....
Jul 2, 2020
In June, we continued to upgrade several key pieces of content across the website, including more interactive product explorers on several pages and a homepage refresh. We also made a significant update to our product pages which allows logged-in users to see customer-specifi...

Featured Video

Product Update: DesignWare® Foundation IP

Sponsored by Synopsys

Join Prasad Saggurti for an update on Synopsys’ DesignWare Foundation IP, including the world’s fastest TCAMs, widest-voltage GPIOs, I2C & I3C IOs, and LVDS IOs. Synopsys Foundation IP is silicon-proven in 7nm in more than 500,000 customer wafers, and 5nm is in development.

Click here for more information about DesignWare Foundation IP: Embedded Memories, Logic Libraries & GPIO

Featured Paper

Cryptography: How It Helps in Our Digital World

Sponsored by Maxim Integrated

Gain a basic understanding of how cryptography works and how cryptography can help you protect your designs from security threats.

Click here to download the whitepaper

Featured Chalk Talk

LPC5500 MCU Series

Sponsored by Mouser Electronics and NXP

Security is key in today’s edge designs, but where to start with designing-in security? Ad-hoc security strategies are recipes for disaster. In this episode of Chalk Talk, Amelia Dalton chats with Brendon Slade of NXP about the powerful new LPC5500 series of MCUs from NXP that have great performance and security designed in from the ground up.

Click here for more information about NXP Semiconductors LPC5500 Series Arm® Cortex®-M33 Microcontrollers