Frozen out
by jed simms on April 21, 2010
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 process being used was to go through, with the business staff, the system as it had been developed to check that nothing had been lost in translation that would jeopardise the continuation of business operations. This 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 are known as soon as possible so that the final scope of the project would be finalized.
The conflict in views was between the sanctity of the project and its measures of success (on time/budget) and the business purpose of the project and its measures of success (delivery of the outcomes and continued business operations).
Our view is that an on time/on budget delivery of a solution 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, whether or not they’ll meet the business needs is unknown.
We need to make sure our projects are not ‘frozen out’ too soon.
© Jed Simms, Australia, 2010.
Leave your comment