The project was running late. The programming was finishing and they were working towards testing in a few weeks. But, concurrently, the business solution was being checked with the business.
The project team was going through the system, as it had been developed with the business staff to verify nothing had been lost in translation, which would jeopardise the continuation of business operations. This requirements-checking process was generating a (relatively small) number of change requests.
The project champions had a mandatory requirement – freeze the specification, now!
Unless the requirements were frozen, there was no way the project could hope to finish on time, indeed the project was essentially out of control with all of these late changes.
The business champions had a different view – speed up the business checking so that all of the requirements would be known as soon as possible so that the final scope of the project could be finalized.
This conflict in views was between the sanctity of the project and its measures of success (on time/on budget) and the business purpose of the project and its measures of success (delivery of workable outcomes and continued business operations).
In Conclusion
Our view is that the delivery of a solution on time/on a budget that does not allow the business to operative effectively is of little value to the business. Yet, too often this is what projects (inadvertently) work hard to deliver by freezing requirements when it is unknown whether or not the project will meet the business needs.
We need to make sure our projects are not ‘frozen’ before we can be assured it will deliver real value to the business.
