As an engineering services provider, Cardinal Peak gets an opportunity to peek inside a range of engineering organizations. One thing that is striking is the range of approaches to scheduling accuracy: How tolerant is the organization of schedule slips? And therefore how aggressive are engineering planners encouraged to be?
The insight that I’ve only come to recently is that this attitude toward scheduling aggressiveness is very much cultural. A culture works because it is mostly a set of unwritten expectations, and it’s those implicit, unstated assumptions that can cause huge communications difficulties.
Regardless of whether a team is still using a classic waterfall-based approach, or has thrown in completely with agile methodologies — and almost everyone is somewhere between these two extremes — there is a fundamental level of uncertainty for an individual engineer when he or she estimates a task’s duration.
Unlike hanging drywall, say, engineers are almost always doing something that they haven’t done before, and so for any task, there is a possibility that some completely unforeseen problem will emerge. Perhaps the Android API call you were planning to use doesn’t work in the way you expected. Perhaps the code size is unexpectedly pushing up against a memory limit on the embedded Wi-Fi part you’re using, and it will take you two weeks to go through and slim down the project. Even if you meet or beat most of your individual estimates, if your overall project encompasses enough tasks, there’s a high likelihood you’ll find a schedule gotcha along the way.
On top of the fundamental uncertainty in engineering planning, there is clearly a psychological bias that tends to drive all teams — our team very much included — to an unreasonably optimistic view of how long something will take. The recent book Thinking, Fast and Slow (Kahneman 2011) offers one of the best explanations for why this bias exists. It’s not explicitly about the problem of expert engineering estimation, but I think every engineering manager should read it.
Visually we can graph project duration against certainty, something like this:
Here’s where the organization’s culture comes in. Some cultures — call them the aggressive schedulers — encourage each task to be planned optimistically. Schedules tend to slip more often in these organizations, plus you see more of the types of things managers do when they don’t want to allow a schedule to slip: The team gets pushed to work nights and weekends; features are cut; quality is compromised. Behind closed doors, senior executives within companies that are aggressive schedulers are likely to secretly plan for the inevitable slips, while bemoaning their engineering team’s inability to hit a date.
The more self-aware of these aggressive companies understand in advance that in pushing for tight schedules, a high percentage of their projects will come in later than the estimate. (The less self-aware companies push for the aggressive estimate and then get angry, over and over again, when half their projects are late. People who don’t learn from history are indeed destined to repeat it.)
Meanwhile, other cultures — I’ll call them the careful planners — approach scheduling very conservatively. Senior management supports longer schedules up front, but then normally holds the engineering team accountable to hitting the dates.
In actual practice, my belief is that both the aggressive company and the conservative company will spend the same amount of resources (schedule and budget) for their projects in the end, holding quality and features constant. Although it’s hard to estimate a priori, a given project is generally going to take a competent engineering team a certain amount of time once they get into the details. I offer this as a bald assertion because I don’t even know where to begin to collect data, but what I think we see in practice is that the aggressive company usually ships sooner but with lower quality and perhaps a more exhausted engineering team.