How to complete more projects.
My Director walked in to the conference room where my team was assembled.
“We have a problem. We don’t finish any of our projects. I have just received the project list for this year from Head Office, and I want to finish everything we start. I’d like your help in a planning exercise.”
My Director was a maths graduate and took a very logical approach to sizing up problems. He read off the first project on the list to our team.
“You don’t know these specific projects but you have seen projects like them before. I’d like an educated guess on how much effort is required. How long do you think this first one will take?”
Our technical expert replied with a considered response. “About 80 hours.”
“Hmmm.” The Director mused. “Do you think you think one person could do this on their own in two weeks?”
“Errr, no.” The technical expert looked embarassed.
The Director was reassuring. “It’s ok. 80 hours sounds like a big number, so maybe we should use a different metric, one that’s easier to wrap our minds around. Let’s use ‘days’.'”
One by one we moved through the list of projects from Head Office and guesstimated the level of effort. The Director wrote our our estimate alongside each project on a white board. When we got to the end of the list he drew a line under the final number and calculated the total.
“Ok. Halfway there,” he said. “Next, there are 1, 2, 3… 6 of you in the team, so we need to add in your annual vacation and possible sick leave. I also know about 30% of your time goes towards operational commitments, and based on the past three years about 15% of our time goes to projects that weren’t foreseen at the beginning of the year….”
He worked away on the white board, performing the calculations. He underlined the final figure and then stood back.
“Great! Thank you all. Your numbers look right to me. It seems we need to drop about eight projects. I’ll get in touch with Head Office and ask them which ones we can cancel.”
I couldn’t believe that last part. No one pushed back on Head Office like that. This was a very hierarchal organization. I could imagine their eyes popping out of their head at the sheer bravado, but our Director was new, his logic was irrefutable, and cleverly, he wasn’t challenging their authority, the numbers were doing that; he was merely the messenger.
Of course Head Office responded that all the projects still needed to be completed, even through there were insufficient resources to finish them. By the ended of his conversation our Director had at least emerged with a list of the priority projects, and by the end of the year we were finally able to complete the ones we had prioritized.
The events above related to smaller projects, which were easier to guess – the resource planning exercise was comparatively simple to undertake, and should have been undertaken sooner. But estimating duration and effort for an individual project is both an art and a science. For most of the larger projects I have been involved in the planning process helped clarify milestone dates, identified where scope could be shaved, and laid out dependencies. After that the project manager may have monitored against this plan but day-to-day work was managed to the milestones. The plan wasn’t important, but the planning process itself was.
Two of the planning issues I struggle with most were described in a Freakonomics podcast: Here’s Why All Your Projects Are Always Late — and What to Do About It.
The first is optimism bias. This is where we fail to allow for adverse events. For a project it could mean assuming our suppliers will always deliver problem-free products and services, and will always do so on time. More topically, we might have failed to allow for adverse weather events, or a global pandemic. Some events are rarer than others, and you don’t know what they will be ahead of time, but something will come up – it always does.
One way to address optimism bias is to conduct a pre-mortem. Pre-mortems take place during a project. Participants in a pre-mortem imagine the project has failed and asks why it may have done so. This kind of exercise forces us to confront bad news head on, and to talk about the likelihood of each situation arising. It can serve as a counter to our brain’s preference to focus on good news over bad, an inclination which probably lies behind our bias.
The second problem in project estimation is coordination neglect. We know long it takes to do a job, but when a job requires a team we need to allow time for that team to coordinate with one another:
If five different project tasks must be completed, and each task takes 10 hours, we would expect 50 hours to pass before a single, suitably competent person can complete all the tasks.
Contrast this with a scenario in which the tasks can be completed by a team of five people. If those tasks can be completed concurrently, we might allow one hour for everyone to coordinate beforehand, 10 hours each to complete the tasks, and then two hours at the end for three people to assemble everything. Five people could now complete the work in only 13 hours, but it took them 61 hours to complete it. Delivery time was shorter, but effort was greater (by over 20%).
There are more failings in our planning processes than the two above, but the two I just mentioned are the ones I have struggled with most. We will often bake contingency into a project but this is commonly a broad percentage figure to cover all eventualities. Not all projects are alike, and it would serve us to spend a little time considering how that contingency might be consumed rather than slapping a 20% figure on top of our bottom line and then just moving on. Projects vary, but so do we, and there is no better way to gain insight than to plan, measure (record time), analyze, and then adapt the next plan based on lessons learned, and to do so diligently and consistently.
