So might read the subject line in a memo to business users from IT staff responsible for implementing a new application system. Changing requirements in a project is one of the most frustrating (for both business and IT staff) and time-consuming activities in a large project; so much so that sometimes it is the cause of massive project delays or even cancellation. But there is something wrong with the subject line; it presumes that the business users are to blame. They are not. Let’s explore the real root causes and the solutions to them.
The perspective from the project team responsible for implementing the users’ wishes is simple; tell me what you need, and stop changing your mind before we’re finished building it. But why do they change their minds? There are three key reasons.
The first root cause is that time passes. I may need something today but not a year from now. Or I may not need something today that I will need it in a year. To start a requirements definition, we should make it clear from the outset that we are asking for requirements for a future point in time (possibly 12-18 months or more in the future) and we should recognize the challenges in accurately predicting the future.
The second reason is that new information becomes available such as:
- “I just learned what our competitors are doing” or
- “The customer survey results just arrived and show that we are totally missing the point with our mobile app” or
- “Now that you’ve told me what it’s going to cost and how long it will take, I need to look at other options” or
- “Is that the data that is really in that database? That won’t work.” or
- “Is that how the data entry screen is really going to work? That won’t work with our channel partners.”
So the second root cause is that getting requirements right is a learning process. This is like the blind men and the elephant parable. The current system business owner knows exactly how the current system works, but needs to learn the nuances of the target system. The vendor bringing in the target system knows exactly how the new system works, but doesn’t understand the nuances of the current business process. One data analyst knows the data from source system A, another is familiar with source system B, while a third has a deep understanding of the target system data model. The Infrastructure team knows the idiosyncrasies of the hardware, network and operating systems – but not the applications. The application specialists know how the ins and outs of the business system, but not how the performance or functionality might change on different platforms. The solution architects are expected to pull it all together, but they are working with abstraction models which don’t contain all the details. Each one of the experts is looking at the solution through a keyhole so they only see a piece of the elephant and may make assumptions about what they don’t see.
The third root cause for changing requirements is external shocks. This one could be classified as a special instance of either of the other two root causes, but it’s worth calling out separately since it is about risk of major changes that are hard, if not impossible, to predict. Examples include a merger, acquisition or divestiture, regulatory change, vendor bankruptcy, recession and associated budget cuts, business strategy changes, organizational shifts or new leadership with differing priorities, and the list goes on.
So now that we have the root causes, we start to establish solutions. This article is already quite long, so I’ll keep the solutions brief.
- First, shorten the project life-cycle to address the time problem. This is why Agile and Lean methods are so effective. They break a big project into multiple smaller more focused projects (iterations / sprints) so that the time delay between when the users are asked what they need and when the results are delivered is very short. There just isn’t time for requirements to change.
- Second, accelerate the team learning process. Notice I said “team” and not business users; everyone needs to learn from each other. Learning is an iterative and interactive process. Some techniques that can accelerate learning include a) prototype the user interface and get feedback, b) mock up the report to confirm format and content, c) profile source data to see what is really in the database, d) simulate business processes using a modeling tool, or e) conduct a proof of concept on new technology platforms. Notice that all these techniques involve not just interactions between team members, but also interactions with computers. If the team is only learning on paper (by reading requirements documents) or in meetings, it just won’t be as real. Imagine trying to learn golf by only reading a book. You will do much better if you interact with an expert and try hitting a few balls on the driving range and putting green first.
- Third, adopt a flexible architecture and project methodology. External shocks by their very nature are hard to predict and plan for – so don’t try. Rather, use layered architectures, integration strategies that decouple components (like the Vibe Virtual Data Machine), and a flexible adaptive methodology like Lean Integration.
So if you are in IT, the next time you feel like blaming the users for changing requirements, look in the mirror first. And if you are a user and the project team asks you to participate in a prototype review or daily stand-up meeting to review progress, please do. You need to learn from them and they need to learn from you.
For further reading, check out the Lean and Agile best practices in Informatica’s Velocity Methodology.