We are all aware of the importance of timing in telling a good joke, but timing is also crucial in a business context.
If you get the timing wrong you can waste effort and potentially damage your reputation.
Today, I was discussing with a fellow consultant the situation at a large organisation we both know. This organisation have spent time, effort (and money) to develop a clear and agreed set of system requirements for a large corporate system.
It has been identified that there are a number of issues relating to data, process and culture in the organisation which should have been assessed prior to developing the system requirements. However, the current focus of the organisation appears to be focused on delivery of system improvements (“Will it do this…?”, “When will it be operational"?” etc.) Attempts to bring the discussions back to data and process are not successful as the discussions tend to revert back to system related discussions.
As so much has been invested in developing system requirements, any activities to optimise processes and data may ‘undo’ some of the work that has already been completed. This would be a difficult message to give to the Board and may result in the messenger being shot.
Additionally, this organisation, like many large organisations these days, is going through almost continuous reorganisations, therefore, it is likely that many of the current team will have moved to different roles before the project approaches completion. They do not, therefore have a great incentive for highlighting such concerns.
It is worth remembering the ‘rule of thumb’ about the costs of change:
- If a change is identified at scoping stage, it could cost £1 to rectify
- If this change is identified at design stage, it may cost £10 to correct
- If a change is identified during coding, it may cost £100 to rectify
- If this change is identified during testing, it may cost £1,000 to correct
- If this change is identified during implementation/production, it is likely to cost £10,000+ to rectify
Clearly, when a project is already well established, the best time to discuss the scope of a project has passed. Sadly, it is likely that this project will be another contributor to the statistic that 68% of IT projects fail. These failed projects will end up taking more time and budget to complete and are less likely to deliver their intended business benefits.
The use of competent Business Analysts and suitably robust requirements methodologies helps reduce the risk of such problems.