Three ways to build a hardware schedule

So you’re in the early stages of planning your hardware project. You ask the team, “How long is this going to take?” They fire back with “How soon do you need it?” and you’re caught in a circular conversation.

A good schedule is essential for budgeting, planning, judging progress, and keeping everyone coordinated. The problem, as that circular conversation illustrates, is that it’s often hard to tell whether the schedule is wrong, or if the team is underperforming or getting sidetracked.

One of the weird things about schedules, especially for knowledge work like product development, is how much human psychology matters. For example, Parkinson’s Law states that work expands to fill the time allotted. Student Syndrome describes the tendency to procrastinate and leave work until the last minute. A focused, motivated team can move mountains to hit deadlines, while a dejected, distracted team will consistently slip dates. The difference often comes down to building a schedule that the team actually believes in and is committed to.

That being said, there’s more than one way to build a schedule. Here are three approaches I recommend:

1. Figure out what needs to be done and how long each step will take.

This is the classic approach: Break down the work into steps and estimate how long each will take. The challenge with hardware products is that it’s impossible to know all the steps upfront, or to predict exactly how long each will take. There’s also a circular reasoning problem: If we knew how long something would take, we might make different design choices or tradeoffs that would change the duration.

Financial and performance incentives can also distort estimates. Teams might estimate low to win work, or estimate high to pad schedules. And there’s a natural human tendency toward optimism bias and underestimating complexity.

Rather than trying to arrive at a strict series of estimates and dates, I recommend asking for low-bound and high-bound estimates. This approach shortcuts some of the circular logic and better exposes risk and uncertainty in the project. It’s unlikely that everything will go wrong, or that everything will go right, but the truth will probably fall somewhere in between.

If you want to get sophisticated, you can run repeated simulations of how long tasks might take, an approach known as the Monte Carlo method. Running the simulation with a log-normal distribution of task times is the best modeling approach for accurately capturing real-world behavior. In a pinch, though, you can skip the simulation and take a Root Sum Squares approach to calculate an “average” number of things going wrong, which will give you a “most likely” target date to shoot for.

The bounded approach also creates early psychological “deadlines.” Once the low-bound estimate has passed, there’s pressure to deliver before the high-bound estimate arrives. With a single-point estimate, it’s much easier to protest that the original estimate was wrong.

(Fun fact: I worked with informal to implement this schedule-building process, which is now incorporated into their low-bound/high-bound quote process.)

2. Pick a calendar date and work backward.

The second approach is to pick a date on the calendar and work backward from there. The  caveat is that this approach isn’t for the faint of heart. It means finding ways to make things work and often requires long hours.

The key is that the date must be of real and significant consequence, or the team won’t believe in it and won’t be motivated. Examples of real dates include Black Friday, Christmas, industry trade shows, investor demo days, tax and regulatory deadlines, and financial runways. 

I’ve often seen leaders make the mistake of picking the last day of the quarter. This is an error because the team knows it’s an arbitrary point in time. When the milestone slips and there’s no real consequence, it destroys credibility.

There are a few more caveats to this approach. Even if the date is of real consequence, it still needs to be grounded in reality. Check in with the team about whether a date is feasible. Even if full shipment isn’t possible by the target date, you might be able to deliver a prototype or make a public announcement about a release date.

As an aside, I’ve discussed with informal cofounder Sam Holland situations where truly hard dates may not exist. In these cases, I suggest analyzing the cost of delay — the opportunity cost of not having the product by a certain point in time. Often the cost is linear, where time is directly proportional to lost opportunity. But sometimes, when compounding effects, market share, or other factors come into play, it can be entirely nonlinear. Rather than hitting arbitrary dates, the goal is to empower the engineering team to understand how hard it’s worth pushing to achieve a certain deadline.

3. Disregard the schedule in favor of continuous progress.

In certain situations, like very early-stage startups or for solo hobbyists, teams are short on money but long on time. Project direction may change frequently. In these cases, the most important thing is making constant, continuous progress.

I define progress as the generation of tangible artifacts. There’s no “percent done” or “nearly done.” You either have the artifact, or you don’t. Artifacts can include things like physical builds, demonstrations, analysis reports, and emails. The key is that there’s something real to point to that demonstrates work is being completed. (If this sounds like an Agile mindset to you, it is!)

Perhaps this approach is best summarized by the analogy of driving at night: “You can only see as far as your headlights, but you can make the whole trip that way.”

Wrap up

So there you have it: three ways to build schedules. The right approach depends on your situation, whether you’re working with a well-defined scope, facing a hard deadline, or operating in an environment where flexibility matters more than dates. Of course, there’s more to it than this — like formal techniques for identifying the work needed and generating estimates — but that’s outside the scope of this article. The common thread across all three approaches is that a schedule only works if your team believes in it and is committed to making it happen.

In his own words, mechanical engineer and informal member Sam Feller is a “pathologically curious, highly technical, creative product manager.” He has deep experience delivering both hardware and software products. His superpower is motivating and rallying a team. You can follow Sam at AwkwardEngineer.com. 

informal is a freelance collective for the most talented independent professionals in hardware and hardtech. Whether you’re looking for a single contractor, a full-time employee, or an entire team of professionals to work on everything from product development to go-to-market, informal has the perfect collection of people for the job.