An IT project is a complex system of software, data, people, and requirements.  Software goes through versions, data points move, and people evolve, but requirements stand out as the most fluid element of a project.  If we study how requirement changes impact software, data, and people, we can better understand how to avoid the problems of endless requirement changes.

Kitchen Sink Syndrome, Loss Aversion, and Scope Creep

Anyone who has remodeled a kitchen knows that it is difficult to have restraint when the project gets started.  What starts as a simple sink replacement ends with heated floors and a smart refrigerator.  The same problem appears on IT projects.  The allure of new features and a sleek interface could tempt project members into scope changes, even where there is not a strong business case for the feature.

Another psychology concept at play on IT transformation projects is loss aversion.  In some cases, customizations serve a real business value or could even be a competitive differentiator for the enterprise.  For example, you could be a furniture manufacturer that will configure finished products with any one of ten thousand fabrics – something far beyond the standard number of options.  This level of variant configuration may go beyond the limits of many out-of-the-box ERP's but because it is a competitive differentiator for the company, it might merit implementation in the new system despite the complexity.

In other cases, however, a legacy customization goes against best practices and should rightly be dropped when migrating to a new system.  The fear of losing a feature could tempt functional leads to demand its inclusion in scope.  Together kitchen sink syndrome and loss aversion contribute to scope creep.  Features, and sometimes entire modules, are added for emotional reasons instead of demonstrated business value.

The Risk of Cascading Failures

Enterprise scale software is a perfect example of a complex system.  One property of complex systems, is that small disturbances can have outsize impact on the entire system.  Consequently, seemingly minor changes to requirements or configuration create risk for the entire project.

For example, consider the common task of emailing specification changes between team members, like a new code value to be used in a Contract conversion.  If this code value happens to contain a hyphen, then Outlook might automatically update this to be an em dash in the outgoing email.  This updated value is copied to the documentation, cross-references, and the conversion program while the original value is configured in the system.  When the conversion program runs this simple mix up would lead to massive failures in the Contract conversion, which impacts other areas like Customer-Item Cross-Reference selection, and lead to Sales Order lines having incorrect pricing.  A single character can make the difference between a healthy test cycle and a disastrous one.

Even simple changes can be high risk because of the impact they have on the wider system.  As the go-live date approaches, the risk associated with code changes grows.  For project managers, it is critical that the team understands there is a cutoff date – well in advance of the final go-live – at which point all changes must stop.

Asking the Right Questions

Avoiding endless requirement changes require discipline and a strong adherence to project management principles.  A solid project plan will define the scope of your project, establish milestones, and will be referenced throughout the life of the project. Unforeseeable complexities might arise, but a strong foundation will mitigate many challenges.  

As your project progresses, requirements change and additional wants are added to the wish-list. Ask yourself a list of questions:

  • How does a newly proposed task fit into the scope of the overall project?  
  • Will it affect the budget?  The schedule?
  • Do we have resources to assign to this task?
  • How will this change affect other aspects of the project?

Even the smallest change to a data mapping element can, as seen in the Contract example, affect all sides of the project. Force a conversation with others – not just your own team – about the change or task you want to add. Additionally, talk about why you are not doing something. These conversations can save hours fixing missteps that could have been avoided.

Communication – The Key to Good Juggling

It can seem overwhelming to juggle all the moving parts of an IT project while addressing continual changes from multiple tracks. Documentation and communication are imperative in keeping the project on track, within scope, and under budget.  On day one, when laying out the project goals, your team should also lay out a method of tracking changes.  Changes should only be implemented after proper documentation and written approval. You will then be able to trace the source of new failures, hold team members accountable, and understand how the project has evolved from the initial plan.  

Specification changes should be documented in a way that all team members and management can access the information.  The corresponding technical changes should also be documented through comments within the relevant code. Code comments can highlight how a small tweak affects pieces of code further down the line, and in turn, the converted data. This makes risk more visible within the technical team and helps highlight a potential point of failure ahead of time.

Good documentation allows team members to share how they have contributed to the project. However, it will not prevent a project from deviating from the original scope.  Scope maintenance requires ongoing communication between all project members.  This includes contract discussions and cost overruns. Approach these conversations earlier rather than later.

Ultimately, avoiding endless requirement changes means establishing and promoting the mission of the project.  A project meant to standardize business processes will look different than one seeking to improve customer relations.  A project meant to minimize IT spend is different from one that optimizes the supply chain.  Understanding and communicating the project goals increases buy-in from the entire team, helps establish scope, and is the foundation for your team’s success.