Giving estimates on project effort are an unpleasant fact of life. Unpleasant in that the developer is not building the software that they enjoy, but also because they are usually being asked to say how long something will take without knowing all the facts. Estimates too can differ wildly between people – requiring a multiplication factor depending on the person.
Worse, the final accepted estimates are usually below how much effort the project takes – best illustrated by a scenario that takes place at the beginning of every project:
The Project Manager asked Frank to give professional estimates for how long development would take on the project. With perhaps twenty previous development projects under his belt, Frank estimated the project would take two man years to complete. The PM came to talk to Frank.
PM: “It's too high, reduce the estimate. The customer doesn't have that much budget”.
Frank: “I estimate that's how long it will take without reducing scope”.
PM: “No. We can't reduce scope or the customer won't give us the work”
So Frank reduced his estimates but next found himself on a conference call with the Customer and PM to justify each estimate.
Customer: “This item here, hooking in a new XML feed. How can it possibly take a week? It's just XML which is basically text.”
PM: “Yeah, explain this”.
Frank: “Well your last XML feed took a week each because we were given the wrong URLs, the header had the wrong character encoding name, and it did not validate. I would expect the new ones to be the same.”
Customer: “No, I still can't see it. Reduce the time on this one.”
PM: <dead silence, perhaps asleep>
The meeting continued with Frank's professional reputation as a skilled developer repeatedly called into question by the customer, without any support from his PM. The meeting should never have involved Frank in the first place.
After the meeting, Frank reluctantly reduced the estimates further and the company horribly under-quoted on the project. Development still took two man years to complete and the company lost millions. The project manager left the company before the project finished. As the one senior person remaining to shoulder some blame, Frank was reprimanded by the general manager and left soon after.
A few lessons to learn from Frank's experience.
Project Managers are under pressure to reduce estimates, it's their job to ensure the company is signed up to do the work.
Customers apply pressure to reduce costs, it's their job to get the project delivered as cheaply as possible.
The Project Manager's job is to resist the Customer's attempt to have the project delivered cheaper than it will actually cost. They are paid to be wordsmiths.
If sure about them, Developers should stick by their estimates when challenged.
Nobody has ever been fired for saying development will take longer than it did. They might find someone else to give estimates, but probably won't fire you.
