How to lose a dream project in 7.5 hours 11:10 on Wednesday

We had a really interesting client project at our hands, with really interesting new technology and challenges involved. And we blew it. We blew it because when the project finally got the go ahead, our planned schedule did not fit in the given timeframe.

Emergency brake
Emergency brake, originally uploaded by realblades.

When the client told us the deadline had been set, we initially agreed to do what we could to compress the schedule and deliver our best effort in the available time. But the more we looked at it, we realized that completing the project in a hurry would have turned out to be an overly expensive choice in the long run. So we ended up not starting work on the project at all.

What went wrong, and more importantly, what could we have done better?

It could be we panicked a little at the thought of losing the project, and gave the client what they asked: a response detailing what we can deliver in the given shorter schedule. But when we said we can do it in the shorter schedule, basically without the benefit of being able to reuse the system later, we missed an important point. Faced with this situation, we should have asked ourselves is this decision ultimately good for the client, their client, and the end-user? And when the answer turned out to be “no”, we should have immediately decided to not do it, without even trying to sell the client a squashed and pared down version of the project.

Another thing we could have done better, and will do in future projects, was to keep the client better informed about the estimated final delivery date of the project.

We should have given the client an estimated delivery date right from the beginning, and updated the date regularly as the discussions proceeded. This would have also implied a starting deadline, which would have had to be met in order to keep the schedule, in effect creating a clear connection between the date of placing the order and the date of delivery. If the order is delayed, the delivery is delayed.

Additionally, our vacations were unexpected to the client, although obvious for us. We could have informed the client earlier about us being out of office for a month in a period which happened to be right in the middle of the project delivery schedule. Again, if we had calculated and constantly updated the client on the projected schedule, we might have thought about this a lot earlier.

Hindsight is flawless.

3 Responses to “How to lose a dream project in 7.5 hours”

    Links from my other posts:

  1. /personal » Blog Archive » No blaming please

  3. PM Hut Says:

    In my opinion, the 1 month vacation, in case this was “a dream project”, could’ve been taken later. However, I do understand that that the European mentality is different than the North American one when it comes to vacations having priority on everything else.

    I think committing to a schedule and then delaying the delivery of the project once it starts (due to mis-estimates) is a tricky game. You can do it, but will you be able to keep your reputation (especially with a client that probably will bring more and more jobs), additionally, big firms usually have penalties for late deliveries.

    I think losing that project was not a very bad thing, after all.

  4. Niko Says:

    There is definitely a European vs North American difference regarding vacations. In this case though it wasn’t a case of mentality, but instead practical time requirements for the vacation. As much as we would like, the world (as in family and their work, school, etc schedules) doesn’t revolve around our dream projects…