September 1, 2009

A Project Goes Over its Time Estimate: Lessons Learned

Recently the CEO of a new client called me to ask why his project with us was at day 85. This was a reasonable question since it had been originally scheduled for 24 person-days!

This client had interviewed us last summer for a position to help them develop some software they viewed as critical to their business strategy. They were very picky about whom to choose and interviewed at least twenty companies. We were honored that Waverley got the nod.

Part of the selection process was to estimate a small project. Our team looked at a simple description, some specs, asked some questions and came back with a 24 person-day estimate. Everyone agreed that this was reasonable.

We started with a single resource, an expert lead developer who specializes in the area our partner was interested in and off he went. So far the project was pretty straightforward.

Day 85

Now we are at day 85. What happened? It’s a common tale, but a cautionary one.

First of all, the client admitted that they changed many requirements (some multiple times), including some API’s that had to be redone and significant changes to the UI requirements.

On our end, we all knew that the development schedule had run over and that the team had not addressed the delay directly since the relationship with the client was going well.

The client also specifically stated that we had been doing a great job. They were very happy with the quality of the work and the commitment of the developer and client manager. Still, we were at day 85. Not good.

What lesson can we learn?

Is the lesson here that clients shouldn’t change their requirements? This is unlikely, given the dynamic nature of business applications. Or perhaps it is that developers should sound the alarm each time a small delay occurs, even when the client causes the delay and approves the changes? That doesn’t seem very practical either.

Here’s what I took away from the experience. It’s important to have a healthy discussion at the beginning of the project about how the project team should respond to changing requirements. Because with business applications, everyone should assume that requirements will change. It is only be seeing early versions of an application that customers can evolve their understanding of the is really required.

Assume that requirements will change. Make plans about responding to those changes. These steps will go a long way to keeping the balance between the three dimensions of all custom software development projects: schedule, cost and quality.