17

In the seldom cases where your project (or milestone) completion estimation was too pessimistic, do you deliver results right away? If not, which tasks do you assign your team members in the meantime?

From my point of view, there are two contradictory thoughts involved:

+Delivering earlier most likely increases costumer satisfaction.
+Depending on the contract, it may even decrease costumer costs, which even more contributes to costumer satisfaction

-On the other hand, delivering earlier may significantly weaken your position when working with that costumer again ('10 Months? Last time it was a third less anyways, so nevermind').
-It may question your capability to estimate ('This guys estimate was wrong by a third last time either, maybe better find somebody more suitable...').
- Furthermore, even though if it was a fixed contract, you may be in bad position to justify the price. If not, may be even worse, because company management will be unhappy because of lower project value than expected.

Looking forward to hearing your thoughts on that topic.

Improve this question

5 Answers 5

Reset to default
11

An early delivery date for a final deliverable shouldn't come as a surprise to the client, because the project manager should've been in touch with him/her all along during the phases of the project, right? You should certainly be able to account for the earliness, but it should be a granular part of the overall project schedule. It wasn't that the whole project was 2 months early, it was that things added up.

  • The customer was unexpectedly reasonable in their requirements. The specification was drafted a week early. The pm adjusted the schedule.
  • The customer was responsive and signed the specification immediately after receiving the second draft. The specification was approved and agreed upon by all parties a week early. The pm adjusted the schedule and informed the customer.
  • A developer stumbled upon some prior work that shaved two weeks of additional planned development time off the project. The pm made sure the code-base was license-compatible with the customer's requirements and adjusted the schedule, informing the customer.
  • A second client canceled an engagement early on so resources were redirected into this project. Estimates accounted for a net project time savings of one week. The pm noted this in the project log.
  • The alpha was very similar to the documentation team's first draft, so they were able to shave a week off the documentation phase by skipping a draft of documentation. This did not in itself affect the project schedule because it was in parallel with development; however…
  • …The two members of the documentation team were available to help test for an extra week during the alpha and release-candidate phases of the project. (Unit and automated integration tests were built into the development schedule.) The extra two testers shaved a week off development time. The pm adjusted the schedule and informed the customer.
  • The customer was unexpectedly responsive and available for user-acceptance testing. They accepted and signed off on the final release a week ahead of schedule.

etc.

If you haven't been informing your client all along then the best thing to do now is go ahead and deliver. That said, in project management, surprises are never really a good thing, especially when the project manager has to deliver them.

Improve this answer
0
4

If it's possible - deliver. If not to give something more to the customer, do it for the sole purpose of finishing the task on your side. You won't have to come back to that when the deadline is coming etc.

Also delivery itself can introduce some issues so the earlier you are the more time you have to fix those.

If the customer needs explanations you should find them easily. They can vary from the honest one (we might have been too optimistic, but when we are too pessimistic you don't get charged additionally) to some smoke and mirrors (we used more people on the project and that is why we're early). My personal favorite is honesty as it build long-term relations.

I don't really find argument against telling the truth valid. If the customer decided to pay x dollars to get something it was worth the money for them. No one stolen that money from their pocket. They did sign the agreement, didn't they?

To some point the next negotiations can be more difficult, but I wouldn't expect much change. You should gain more on better relations than you could potentially lose there.

Improve this answer
1
  • Thank you, especially "the sole purpose of finishing the task on your side" I consider quite wise (while agreeing to establishing long-term relations as well). It might be good for the entire team to know that "it's done, period". Time to move on.
    – bonifaz
    Mar 24, 2011 at 21:22
2

When you are finished, deliver. Delaying delivery serves no purpose except provide some sort of smoke screen that your customer will likely learn and then develop distrust in you down the line. Deliver and use the developed slack in your schedule to make up for those packages where you were too optimistic.

Improve this answer
2
  • Sorry, I understand your answer as 'delivering provides smoke screen and costumer develops distrust' -- isn't that rather an argument against delivering?
    – bonifaz
    Mar 21, 2011 at 20:48
  • No. I meant to delay delivery causes the smoke screen.
    – David Espina
    Mar 21, 2011 at 22:22
2

Tell the truth. You finished earlier than expected. As long as there isn't a pattern of sand-bagging your estimates, no client should [rightly] fault you for this.

There are a few bad outcomes of delaying: 1) Project team members already know the work is complete. Delaying delivery will hurt productivity on the next project, as the team will work slower next time. That's bad news. 2) Your client might find out. If you're trying to hide the fact that the project is complete, and your client finds out via some other source, this will severely undercut their trust in you. That's really bad news.

Improve this answer
1
  • For 1): May be true, but I guess in most cases project members won't be allowed to idle the rest of the time, but rather to spend the time on innovative tasks they might personally feel motivated by (or allocated to some tasks of other projects in the meantime, which may not translate in that much of a motivation gain, though).
    – bonifaz
    Mar 24, 2011 at 21:15
0

I up-voted the leading answer. But I have an answer of my own:

  1. Comb over the spec and ensure it is fulfilled.
  2. Look for places to exceed expectations, exceed the spec. (thanks jmort)
  3. Make all this a team activity.
  4. Take a little time to build a "lessons learned" doc that is suitable for your team, and for the client. (Or two different docs, if that is more appropriate.)
Improve this answer
4
  • I think 1 and 4 should be performed in any project-closedown, right? 2 is very interesting, therefore I opened another question: pm.stackexchange.com/questions/1264/… Thank you for that interesting answer!
    – bonifaz
    Mar 26, 2011 at 16:35
  • Well, now that you said that, they ALL look like normal stuff. Smile. But thanks for the affirmation.
    – Smandoli
    Mar 26, 2011 at 17:01
  • I disagree with exceeding the spec. What you see as exceeding may actually be wrong in the eyes of your client. Additionally, if you add extra features you are responsible for maintaining them. In the long run, that's not good for business and will make you look bad if your so-called exceeded features break and require constant maintenance.
    – jmort253
    Mar 26, 2011 at 20:08
  • Oh, yes -- point well taken. I should have said only "exceed expectations." There are so many ways to do that, of course.
    – Smandoli
    Mar 26, 2011 at 20:18

Your Answer

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

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