13

I'm working as project delivery manager of a Software Development Company. Often before project initiations, a long time and loyal customer contact me directly to request 'estimate' for some works that is to be done on their system.

Often these requests come with a very high level descriptions. To be highlighted, they are not yet asking for Quotations at that point. They (the person, often my counterpart on the clients company or his team member) virtually ask me to do their homework in producing high-level estimates for their reports or meetings.

To give more fuller picture, my company have been servicing the client for sometime. Longer than some of the client's managers and engineers have been working there. We do not have blanket contract that cover out-of-contract requests such as this. So, on strictly a contractual basis, we are not required to entertain such requests. But my company owner advises me to entertain such requests nonetheless because it foster good relationship with the client and at least puts us ahead of the game when or if the project goes into open bidding. And frankly, I agree with her.

The problem here is that when I do issue estimates in numbers such as dollar cost, man-days requirements, or time frames. The number often come up in some budget meeting or some project charter. People inside make commitments based on it. And when it come the time to submit formal quotations my company is often held against those numbers. Often, the scope of work have grown somewhat.

My question is this: How best to communicate to the clients that the estimate is by no means binding. It is a 'ongoing discussion' thing. Any numbers arises from there be it dollar costs or time frames are not a commitment from me or my company.

Improve this question

6 Answers 6

Reset to default
17

Slight frame challenge: consider providing your estimates as the wide-end of a cone of uncertainty rather than a discrete number.

"I need a [vague thing], how long would it take?"

"Okay, I discussed it with my team, and we think it'll take somewhere between 2 and 7 weeks."

"I need an exact estimate."

"Then we'll need exact details. Our estimate for the details you have given is 2 to 7 weeks."

"Okay, what about [less vague thing]?"

"Oh, that would be 3 to 5 weeks."

Providing your estimates as a range bakes your uncertainty into the estimate itself so that there is then no need for a separate 'but we're not fully committing to this estimate' step.

Improve this answer
2
  • 2
    The difference between weeks and person-weeks is going to be important (and for elapsed time, when the clock would start)
    – Chris H
    Commented Dec 3, 2021 at 10:30
  • How long you think it will take, times two, plus one; there's your range. My favorite is in The Road Warrior. Most people probably think of Scotty from Star Trek, especially in the TNG episode where he berates Geordi for giving an exact estimate.
    – Mazura
    Commented Dec 4, 2021 at 0:35
10

To add onto nvogel's correct answer.

Besides for providing itemized deliverables, you need to add in the standard functions that are forgotten, overlooked but necessary and very time + resource consuming, hence they affect both the timeline and the budget.

Functions like design, functional spec, graphic design & sign off, integration, (bug fixing as a result of integration - needs to be given a name to hide the "bugs"), QA, (with a few rounds for bug fixing), beta/offline testing, go-live procedures, to provide some examples.

You may take these for granted, but, as you said, your "rough draft" becomes a working document, and therefore you want to prevent mis-pricing (and possible competitive analysis failure) based on a partial project plan.

Improve this answer
9

Attach each estimate to an itemised deliverable rather than a named scope of work, that way there's less room for doubt about what was estimated. Use relative estimation (points) at the item level and then aggregate the points values and convert to an absolute time and cost as required. The best estimates are usually created and owned by the development team, not by a delivery manager.

Improve this answer
6

Your issue requires two things that are 100% owned by YOUR company, and only these two things: 1) You need to insert legalese-type language that accompanies your estimate that this is a high-level, rough order of magnitude estimate based on what was known at that time that is subject to change when requirements become more known and firm; and 2) YOUR company needs to stand firm and push back if you experience pressure to stick to that ROM. Number 2 is critical because, without that, number 1 is meaningless.

Simply look at other industries like construction. If you approached a contractor to build you a home with some rough, high-level desires, and then try to hold them to that value--if they even provide it--they will laugh as they walk away from you.

For those of us in SW or other knowledge work, we seem to have difficulty doing just that. But no other intervention is really required except to say, "No!" Sellers of SW and other knowledge work have an equal seat at the table.

Improve this answer
5

Communication should be as clear as possible if you want to avoid misinterpretations, that's not impolite but simply professional. What about a prominent note

This is a rough estimate based on incomplete requirements.
It is intended to support your decision process, but it's not binding
and should not be used in budget or schedule planning.

in your reply e-mail? CC your boss so there's a clear trail that you did not commit to a definitive time or budget range.

Improve this answer
1
  • That is correct what you said. However, I had a long time ago a boss who took whatever I wrote, removed whatever he did not like, added things, modified content, and then delivered it further. Then I had to explain why I do not commit to whatever monster the boss created. What is funnier is that upper level bosses did the same kind of things, so what reached the "final destination" was pretty much independent of whatever information I provided.
    – virolino
    Commented Dec 2, 2021 at 18:41
2

One way to response to the question is to focus on risks inherent in the subsequent work. In the total, for a very risk project I would never give any estimate at all, instead I would suggest a pre-study.

Typical risk factors to evaluate and might be highlighed in the answer could be. Each of the statements could be given a number, say between 1 and 5 where 5 would be high risk -- too high sum -> suggest pre-study.

  • We understand the requirements
  • There are no important aspects of the requirements outside of our control that we have to handle, example: legal requirements, business logic, translation to other languages, ...
  • We do not expect the requirements to change during the project (feature creep can become very expensive)
  • We believe it is actually possible to build according to the requirements (the customer does not ask for the unattainable)
  • We believe we have sufficient knowledge and solutions to factors such as production environment, performance, security, ...
  • We have all the required technological knowledge in-house or readily available, say in using a computer language or framework
  • We have the required capacity available (programmers, testers, test systems, ...) at the right time to produce the solution according to the buyers time plan
  • We expect the buyers personnell to be available when needed (requirements people, decision makers, acceptance testing personell, ...)
  • Deployment at the users site will not be time-consuming or costly
  • add according to your experience
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.