When your project suffers from Requirements Syndrome

Until now, IT project failure was bordering on the proverbial for reasons project managers could never quite pin down. Introducing the signature effects of Requirements Syndrome, which can turn an innocent project into debilitating failure.

It was a bruising encounter. None of the team was spared and the injury toll was high. This wasn’t a football match, it was the steering committee meeting of the company’s ERP Implementation Project as the project entered the user acceptance testing phase.

Mike ‘Indiana’ Jones, the hapless project manager, dusted himself down and set about looking for answers. How could the project team have seemingly failed to deliver on the expectations of the project sponsors? The requirements hadn’t changed since the project was initiated three years ago. Until now, there had been no project too difficult for this highly successful project manager. Indy wondered how the hell we got here.

Unwittingly, Indy had become the latest victim of the Requirements Syndrome, the strangely counter-intuitive syndrome that can condemn a project to failure in spite of the best efforts of all concerned and the strictest of adherence to project methodologies.

We don’t yet know a lot about Requirements Syndrome, but indications suggest the symptoms present when some or all of the following conditions prevail:

• There is a lengthy amount of time between the initial gathering of business requirements and the commencement of the eventual technology implementation project.
• The same requirements that were used to procure the software solution are then used as the sole determinant of solution scope for the implementation.
• The project governance structure detaches business end users from hands on involvement in solution architecture design during the early stages of the project.
• Input from end users is not sought until the user acceptance phase of the project.
• Change management expertise is introduced at or after the completion of the design phase of the project.

Had Indy been aware that the perfect conditions were present for Requirements Syndrome, what could he have done to prevent it from derailing the project?

1. Establish a dedicated change management stream solely focused on helping the business to navigate the journey to their desired future state.
2. Obtain direct input from key stakeholders to refresh the original requirements with a future process model approach.
3. Seek active contribution to the project from the project sponsors, not just tacit approval or oversight
   Position the project itself as a business transformation initiative with a technology component so that all stakeholders appreciate the need to focus on transitioning to future state and not just passively engaging with a technology solution.
4. Make the achievement of business outcomes the objective of the project, not just getting to go-live.

Like us, Indy hopes we may one day find a cure for this insidious affliction. Until then, don’t let your next project suffer from Requirements Syndrome. Look for the signs early and take action to prevent it from taking hold.

We’d love to hear your views and experiences below.