How can I make a boss (or colleague) be more careful when estimating the complexity of a task/project?

Question

I am a software developer, and I work in a small web development company. It seems to be a recurring theme that a middle-manager will ask me how long something will take, and when I give them my estimate, they think it is too high. If it's a more technical manager, or another developer, they will usually already have in mind an estimate of their own, and start trying to implement it in their own way because they think they can do it faster.

There is a trend, though, where the other developer(s) have ended up using significantly more time than they quoted. They will get half way through their budget, then realize that there is some business need that their implementation plan cannot properly address. More times than not, my plan would have addressed this need, but it was shrugged off as a "You ain't gonna need it" feature.

Worse yet, when they hit this wall, they will usually come to me to help them get out of the corner they have painted themselves into, but there are only so many hours in my day.

Best case: These interruptions cut into the time that I have allocated for my own development work, resulting in other projects being delayed, or me having to work overtime because I am "the only one that can do X".

Worst case: I end up having to take over the task/project as my own, and by that point there's no time left in the budget for me to do it "my" way. I have to try to finish what they started in the way they started it, so "the company doesn't lose any more money". This always comes back to bite me because then it becomes "my" hacky code, and when it breaks people ask me why it was created the way it was (after all, they have no idea who actually created it.)

So my question is: How can I help these colleagues to understand when things aren't as simple as they are envisioning, and they need to re-evaluate their understanding of the client's needs?

Unlike this similar question about Convincing management to deal with [existing] technical debt, my question seeks strategies for helping the team to realize [proactively] before they are about to incur technical debt, in an attempt to prevent it from happening to begin with. These two things do go hand in hand, but they are distinctly different in my mind. The other question's answers suggest adding refactoring time into estimates for future features. This can never work if other developers (and therefore managers) always think that said future feature will take less time than it actually will, and I cannot convince them that my estimate is more realistic.

Answer 1

I love this question because every day I'm either dealing with coming up with an new estimate or suffering from a previous estimate.

The answer depends on how big of a project/task you're talking about. There are books and methods for dealing with estimates. Estimating project for a 50-person development team with a 1-million budget takes a different approach than working on small '80-hour projects' -- here are some 'real life' points for the later:

• "Bottom-Up" Estimating -- The smaller you can break the tasks down, the better your estimate is. You can estimate the smaller parts independently which has the added benefit of identifying missing functions. Let say you are handed mockups of a website and asked to asked for an estimate. Don't go by the number of pages, go by the number of features. For example a shopping cart may be '1 page', but can be made up of 10 different features.

• "Three-Point" Estimates mean to make three estimates as a range. You can then respond with "40-80 hours, depending on how complicated the xxx features need to be." This is a good way to introduce risk in your estimate. It's also a good idea to get estimates from others on your team so if somebody says 50 hours and somebody else says 100 hours, you can discuss the difference.

• Meet the Budget / aka Set Expectations -- If you know the budget is for 100-hours and you think it's a 200-hour project, you can help set expectations before you are committed. "Everything you asked for is a 200hr project; if we limit feature-x, we can do it in 100hrs".

• Development Time vs. Testing Time vs. Project Time vs. Calendar Time -- These are all different and if you're team of one it's easy to get it all mixed together. If you need to spend 8 hours figuring out requirements, then 72 hours of development time, it's going to take you a lot longer than 2-calendar weeks to complete the project. Especially if you need to balance other tasks, interact with a team, wait on customers or spend hours writing via emails. In this case, tell your boss "100 hours, which is x-hours of development time, y-hours dealing with the client and z-hours of initial support." This will help show that you're including time other than just your code.

IMPORTANT -- I don't think estimating is your primary problem, I think external and internal communication is. If feature X was so important, then the customer should have communicated it at the beginning. When the request came in for feature X your project manager should have said "it's out of scope but we can re-allocate current hours or expand the budget".

Internally you need to make communicate so your higher-ups are aware that you are over budget/schedule well before it's "too late". When a task is being handed to you, you should know the time (as in hours) and time (as in on a calendar) that you have to work on that task. If the task doesn't fit within those constraints, then you need to make them aware -- "Feature A & B will require me doing C. This won't leave time for either X or Y".

No Surprises -- You also need to make sure you communicate back along the project. Be sure to report the good stuff, but if something is taking longer than expected make sure you say so right away. Fifty percent of the way through the project it is responsible to say:

"Feature X is taking me longer than expected, I might not get to feature Y".

On the due date, it's not responsible to say:

"I didn't do feature Y because I ran out of time"

PERSONAL MOMEMNT -- This can all be really hard when managers still want to hold on to being coders and when everybody wants to please the customer.

Answer 2

Do good and make it known.

If you have to fix other people's problems because they did not listen to what you said before, or because they are too inexperienced to understand what you were telling them, make sure those people and your bosses get to know what the reason was when the expected time frame was missed, and what kind of planning failure was made. And be patient, if your colleagues are not fully resistant against learning from mistakes, situation will probably become better over time.