Can a project manager refuse to make an estimate of when a project will finish?
Well it's reasonable to say. "I can't tell you when I'll finish until I understand exactly what you want.
But some sponsors want a completion date committment before the scope is clear. How should we handle them?
8 comments:
I stick to estimating project duration in days until the scope and start date is finalized in writing. My experience shows that once you have mentioned a completion date, it tends to be very sticky to the client - regardless of scope changes.
I have been managing projects for some time so I usually have a ball park idea of how long a project will take. So when I have a sponsor who wants a completion date, I pad the completion date by about 3 months to make sure that I don't over commit.
I ask them when they want to be done and then I plan backwards from that. Scope may need to be reduced but I work in a date-driven organization.
Interesting question, I have been in this situation several times. Customer always want’s a end date. Often, before the scope is clear. I will than only give an approximated enddate which will be more sharp when the scope is clear.
I have a new question. How do you spend enough time for Scope definition? Sales want’s to close the deal and the customer want’s to start with the real work. But no proper scope definition gives your problems in the project late on.
A number of project managers have comment about estimating in sales situations.
All too often we see major disconnects between what sales sells and what project managers have to deliver. The ideal situation is when salespeople sell business value instead of just features and functionalities. Then the customers's perception of what they have purchased is alined with the scope of the project.
These techniques create seamless handoff from sales to project teams which is why so many professional firms use them. It also creates better client relationships.
Our ADPM methodology was developed for defining scope in business value to the client. Then there is little ambiguity about what the project team has to deliver. It also supports very effective scope control as opposed to the more typical situation where we the PM has endless debates with customers or clients about what was included in the scope and what was not. That leads to change orders you don't get paid for and an unhappy client/customer. A bad combination.
Dick made an interesting point. Focusing on hard-edged deliverables is a great way to make sure the customer understands what you will and will not provide for them and then also provides the opportunity for you to actually be paid for changes to the scope rather than having that uncomfortable discussion about what is and is not included under the terms of the agreement.
I also use Dick's approach - I only issue dates in a written project proposal where the scope inclusions and exclusions are clearly stated.
I also put the resource committments required to make those dates, so that if I do not get the resource levels needed all dates are off. This also helps me leverage the sales folks' influence to acquire and retain those resources.
A very picky sponsor can be handled if we can make an analogus estimate by comparing with previous similar projects and to give an approximate estimated completion date along with providing a statement that also talks about more accurate estimate after confirmation of the scope statement and WBS. This statement would be an irremovable thorn in the sponsor's crown and would drive the sponsor to co-operate and wait for a final estimated completion date.
Post a Comment