Who should give high-level project estimates?

Question

I've just come from a discussion about who is best placed to give estimates on a given piece of work.

At a detailed level I'd always say that the best estimate comes from the person who actually has to do the work as they have the full understanding and this gives them complete buy-in to the , however at a higher level of abstraction (i.e. at overall project level) I'm not so sure.

I'm reminded of chapter 5 in Peopleware which gives the results of an Australian study from 1985 - best link I could find is here.

I'm particularly interested in your focus here - are you answering as a developer, architect, prject manager or whatever?

Answer 1

1. Developers generally should make the initial estimate. The Manager should be able to add a risk factor to it depending on who implements it. (for example : If the developer implementing it has a better knowledge than the one who gave the estimate, the risk would be lower). The developer also may not have an idea on the other development areas of the project(assuming its huge). This is where a Manager's estimate comes into picture. IF the project is small then a developer estimate is good enough.

Answer 2

The person responsible for signing off of an estimate should really be the project manager. That's their niche.

I'm not saying that PMs should make up the estimates however.

I'm saying that the PMs will need to take estimates from a variety of sources--technical, business, etc--for different parts of the project. In any project there'll be large parts that aren't technical.

Anything technical should be estimated by someone technical.

But, by the same token, anything non-technical should be estimated by an appropriate expert (CPA types call these SMEs--subject matter experts). An architect could estimate the technical solution. A BA the gap analysis. A manager could do the business process implementation. And so on.

But a PM is really needed to tie all those together into a high level estimate, particularly in terms of resourcing and working out the interdependencies and the critical path.

Answer 3

I think it depends on the piece of work. A lot of times the project manager is more than capable to estimate how long it would cost to say, add some additional data on screen, change layout, you name it.

However, there are times when things are more complicated, especially if they deeply touch the architecture of the system. In that case, the project manager should consult the developer, architect, or both for their estimate, and exactly why it takes that particular time to implement.

Moreover, I think project managers should use a developer's estimate to get to the final estimate, like schar says. They should add a percentage of overhead, test time, risk factors, etcetera.

Answer 4

I'm answering this as both manager (present) and developer (past).

High level estimates should come from the team/project leader, but with input from the developers. They should also be given in the form of a range - most likely to worst case with an indication of the confidence level of each.

There's no way the team lead can know everything about the project in sufficient depth so they will need some input from the developers, but the danger with this is that you get bogged down in the details too early in the process. Equally, individual developers will not have a broad enough knowledge of the project (unless it's really small) to be able to give estimates on everything.

The manager then integrates these estimates and looks for conflicts and synergies to get the "big picture" - after all that's what we're paid for.

As a developer I wouldn't trust a manager who gave estimates without checking with the developers, but equally I wouldn't trust one who just asked the developers and passed that information on without "editing" it in some way.

Answer 5

Everyone should give an estimate to the project manager: functional analysts, test analysts and the senior developers.

It's the PM's task to make sure they are somewhat realistic and to sum them up.

Answer 6

I'm answering this as both manager (present) and developer (past).

In our company developers are always involved in making estimations. We do high-level estimates on user-stories created by a business consultant.

The business consultant communicates the user-stories to me (technical teammanager) and a developer.

We schedule an estimation meeting to discuss the user-stories and the context of the project (three people, business consultant, developer, technical manager). Within the meeting both me and the developer make notes and write down needed hours per user-story.

After the meeting the developer fills out an estimation form and we make sure we both agree on that estimation. When finished the estimation form goes back to the business consultant.

Usually a high level estimation will be given in a range from x to x times 3 days.

For example: 40 to 120 days.

Obviously we only estimate development/test/deployment time which is needed. X percentage will be added for project management and technical management, risks and overhead.

Answer 7

The tongue-in-cheek Agile answer is: nobody should, because it will be wildly wrong anyway.