The Importance of Dates

Or: A project without an end date never finishes

The project I am working on is moving into the grey area where it will never finish. There are new releases every week, and while each release is better than the last, it isn't perfect.

The problems are caused by two things. The first is the lack of a project plan. Without a project plan, no one knows when the project is late. This was done intentionally by the customer's project management team to avoid internal political problems with not meeting a date.

However, this has a couple of flow on effects. Without a schedule, the development team (who is 12 timezones away) doesn't feel any pressure. They don't know if the software is good enough for delivery or not. They don't know if they should be pushing back on additional features in order to bring the project to completion.

Without a hard, or semi hard, end date, there is no common focus. There's no way to cause the customer's team to start making hard choices. They don't seem to be thinking "If I get one more feature, I'm delaying the project by 3 weeks". Without a date, they have nothing to fix their sight to, and there is no reason for them to not ask for more features. There's no weighing of the value of a feature, only a push to get everything included.

Finally, without a date, customers become frustrated. The parts of the customer's organisation not asking for new features begins to wonder why the project isn't finished. They look at the software and see it just as buggy between releases because the focus is still on additional, customer requested features. The people who are then waiting become frustrated, and express that frustration up their management chain. This then results in a disconnect between the customers view of the software and the development teams view. The developers look at the project and think they're doing well, they're responding to customer requests quickly. The customer looks at the software and sees something that isn't finished and they don't know why.

I believe that while there may be political reasons to not have a fixed, communicated end date, the various parts of the team do need to have one. Without that, there is no way to tell if things are achievable or not.

This could also be a failure of communication between the customer and the developer, or even internally at the customer. A harder line on change control would help with the creep, but it tends to result in frustration for the customer because they want their important changes implemented quickly. The trick is to get the customer to do the filtering, and accept the impacts of their decisions.

One final thing. Always make sure that your external milestones are not the same as your internal dates. Otherwise, if there's any slippage in your internal date, it becomes immediately visible externally. It is always best to have a little bit of room between those two dates to buffer the customer from the slips and recoveries in the dates.