Earned Value Case Study

Using the Earned Value method of monitoring and controlling budget as described in the previous post, I have had almost entirely positive experiences with my clients. One experience didn't start out so positive.

Our project was to validate a computer system. We proposed the project carefully, using past information but making some assumptions based on information given us by our client. One of these assumptions was that the requirements document was in good enough shape for us to write a functional specification. As always, we made these assumptions visible as part of the proposal. (I'll have to write a separate post about the importance of doing this but you'll see how it helped in this case study.)

When we started the project, we found that the specification couldn't be started because the requirements document was in no shape to use as a starting point. We would have to rewrite this and then move to the specification. This meant more time spent on the project and more money.

So, when I showed up at the first status meeting with the earned value numbers, I shocked the client by predicting that the project would end two weeks late and cost an extra $10,000. They were livid!
"You're one week into the project and already you're two weeks behind schedule and $10,000 over budget!" was their response.

They were used to vendors keeping quiet about the overages and schedule delays until the project was almost over and then asking for the extra time and money. My boss was angry at me also because, frankly, that was the way he was used to doing business and he had warned me that being open with the customers was a bad idea. He was afraid we'd be fired from the project.

I met with the customer and explained the situation. I told them it was a good thing to find this problem early because they had the power to do something about it now. By explaining the cause of the overage and delay, I gave them three choices on how to proceed:

1. Continue as we were going. We would rewrite the requirements, then the specification and continue the project. The project would cost an extra $10,000 and take an extra two weeks.
2. They could rewrite the requirements document while we stepped away from the project, then return to restart. This would take at least 2 weeks (the client was super busy) but would cost no extra money.
3. We would rewrite the requirements but the client would take over some of the later tasks (when their workload had diminished) to recoup the $10,000. This would cost them no money or schedule but would take some of their people's time later.

My client was amazed. They were given options on what mattered most to them: time, money or internal resources. They chose option 3 and the project finished on time and on budget. They confided with me later that they were so appreciative of the transparency of our methodology and their ability to influence the course of the project; something they had never experienced with any other vendor. The customer is loyal to us to this day.