I’ve always hated managing projects. For me, it’s too much whip-cracking and tattletaling, but it’s an unfortunate chore that I’ve been unable to avoid. If you worked on a project I managed, I’m really sorry. I was in a bad place then.
One of the toughest skills a software project manager must have is the ability to understand estimates and know when they’re over- or underestimates. Every project has an end date, and generally, it’s the project manager’s job to make it fit into time parameters that come from on high.
The funny thing is that having development experience yourself won’t get you all the way there either, since writing code is more art than science.
What’s that you say? Why not just accept what your developers and plan according to their estimates?
This can work, but it’s risky and unreliable. Why? Because your developers lie to you.
Maybe not intentionally or maliciously, but every developer has an idea of how much time it will take to do a unit of work. Rarely, if ever, will you know that estimate because there are other forces at work that drive the number the developer will commit to up or down; the good news is that working with the same team on multiple projects helps you understand these reasons and plan for them.
The key here is to know what type of estimator each of your developers is and adjust up/down accordingly. I’ve observed two types; let’s call them the hacker and the scientist.
These are broad characterizations provided for amusement not documentation, and I’m applying the types here to how the developer estimates, not how the developer codes or the quality of said code.
So, take it easy and enjoy.
Even though hacker generally has negative connotations, in this case, it refers to an enthusiast, someone who writes code for fun and for work. Someone who probably contributes to an open source project and has more than two machines, at least one with Linux installed.
The hacker is a chronic underestimator. Beware and always plan for at least double the effort.
The hacker underestimates because s/he wants to kick ass and move on to the next piece of code. It’s the enthusiasm the hacker has for writing code that leads to underestimation. This is good for the product, but dangerous for the project plan.
In contrast, the scientist follows methodical process to estimation, analyzing the task in its parts, probably writing psedo-code before committing to an estimate.
The scientist always, always, always overestimates. Usually by double, sometimes more. The scientist expects a negotiation with you, which is why the original estimate is so high.
Enthusiasm for coding isn’t necessarily lacking here; it’s just dampened by the overall project plan and the prospect of unrealistic expectations, i.e. the scientist doesn’t want to get burned by missing a date. It’s classic CYA estimation.
You Really Need Both Types
The ‘Lab has been around for about a year and a half, and we’ve had the same team for a year. In that time, I’ve worked on several projects with Rich and Anthony, and by now, I feel like I can identify their types.
Rich is a self-described hacker, and surprise, he’s a recidivist underestimator. Keep in mind, this isn’t a bad thing; it’s good to know when Paul asks me to make a plan for something.
Anthony is an overestimator. I knew Anthony from our days in EBS development with David, so I knew to expect this. He’s been through the fire on projects with impossible dates, which has inflated his estimations.
I like having one of each type on a project because it helps me find a balanced estimate. As the project manager, it really helps to have opposing views of the same work, e.g. what Rich says he can knock out on his iPhone at Tahoe in a weekend, Anthony says might take a month of full-time effort.
Of course I exaggerate. The most accurate estimate lies between what they say. Each of them is a rockstar developer, they just come from different schools of estimation.
So, thoughts? Which school of estimating do you follow? Are you a project manager with some other insight?
Find the comments.