Estimates
Estimates are tricksy
And communication is a good thing
Once upon a time I ended up managing an operations team I’d previously been working in as a senior network engineer.
This resulted in me learning a number of lessons, amoung which was I really enjoy leading technical teams, and I’m apparently not bad at it (assuming the sadness expressed by my team on my departure was sincere (which I choose to believe based on the quality of cake they produced for my farewell)).
The topic of consideration today, however, is a different lesson; that of estimates for how long a piece of work will take, and how a difference in perspective can result in a lot of wailing and gnashing of teeth.
The situation was this; my team was a combined build and operate team - we were responsible for both BAU operations (that’s ‘business as usual’ for the non-initiates) and project work. The BAU work was a mix of fixing faults, and the day to day business of building, modifying, and removing customer circuits - generally all tasks that could be finished in a few hours. The project work on the other hand was major pieces of work; everything from a major customer rollout that didn’t fit into our BAU processes to building a new network core.
In theory our time was split 50/50 across the task set, but in practice, (as equipment is seldom so courteous as to schedule its failure in advance) the balance fluctuated wildly on a day to day basis; sometimes we’d get all our BAU work done in an hour or too, sometimes it’d eat the whole day.
Our project work was assigned to us by the Project Management Office (PMO) team; they were responsible for wrangling the assorted projects, prioritising the work involved (which was a whole thing about which I have stories to tell), and in general attempting to ensure that the metaphorical cats were herded to their destinations roughly on budget and hopefully on time.
This concern around timeliness was a consideration where conflict often arose. The primary conflicts occured at the two ends of the process:
Unsurprisingly, the project managers who were responsible for on-time delivery of projects wanted to know how long it would take us to do our work. Unfortunately, many of the projects wwe worked on involved doing things that were completely novel to us, which made accurately estimating how long they’d take to do extremely difficult.
This lead to unproductive back and forths where a PM would demand an estimate, and the engineer would say they couldn’t give one.
At the other end of the process, we missed our estimates. A lot. This made the PMO sad, and as with many such things, this sadness was communicated vigourously.
Of these, the problem of setting estimates turned out to be the easier of the two, and the solution came of out a burst of frustrated snark, when one of the engineers moved beyond saying “I can’t tell you how long that’ll take to do” to saying “It’ll take me at least eight hours work to tell you how long it’ll take me to do the task”, at which point the PM leapt upon this with joy. The outcome was it became pretty standard to deliver estimates along the lines of “There are two steps to this task. The first task will take 16 hours. The second task is novel, and will take somewhere between 8 and 160 hours to complete. After about 8 hours work we should be in a position to give an accurate estimate of time remaining”. This made the PM’s lives slightly harder, as they couldn’t map out the entire project until it was in flight, but had the advantage of allowing the engineers to actually tell the truth in our estimates.
The second issue, that of us missing our estimates, took longer to resolve; I met weekly with the head of PMO to review the project prioritisation, and he’d often complain to me about people running over their time estimates. I felt that he was being pretty unreasonable - my gut feel was that our estimates weren’t perfect, but we weren’t bad; we were coming in under at least as often as we ran over. So I went and ran some numbers.
Turns out I was right - we were coming in under our estimates slightly more often than we were coming in over them. And by roughly similar amounts. So, feeling pleased with myself, I took this to him, only to discover this didn’t thrill him nearly as much as it did me.
Because as they were being used, the estimate of completion wasn’t a mean; it was a deadline.
It wasn’t ‘here’s when we’ll be done, give or take’, but ’this will be done by this date, so you can schedule dependent tasks to start straight after then’. In retrospect, this is perfectly reasonable; the estimates were being used for task scheduling, after all. At the time, though, it was a lightbulb moment for me. He didn’t want a mean time to completion, he wanted something more like a two sigma ‘95% chance for completion by this date’.
What we had here was not actually a task estimation problem, but a communication and requirements problem.
The happy result of this was I was able to go back to my team and say ‘when you’re asked for an estimate of time to complete things, don’t give a ‘give or take a bit’ estimate, give a ‘pretty damn sure I’ll be done by then’ estimate. People adjusted things accordingly, and that particular source of conflict went away (though challenges of prioritisation remained…).
This remains one of my more visceral professional experiences of minor miscommunication / misunderstanding of terminology resulting in disproportionate pain and frustration.