One of the many challenges facing software projects is customers modify requirements. Changing requirements is not only frustrating but also leads to major project delays (which we talk more about in this post).
Luckily, there are specific steps you can take to avoid this. Overcoming this obstacle requires gathering requirements that don't change from the get-go. This streamlines the process while also allowing you to deliver faster, more efficient services to your clients.
Today, we'll talk more about specific steps you can take to avoid changing requirements, making life easier not only for consultants but for their clients too.
Regardless of the system you, the consultant, are implementing, identifying the root cause or driver of the project from the customer’s perspective is key.
How do you do this? Start by asking these questions:
These will all factor into what kinds of requirements you gather.
Once you have an idea of what the customer is trying to do and hoping to achieve, set up a personalized demo of their actual use case.
It's tough for most people to grasp what software will actually do until they see it on a screen. At the same time, a canned/standard demo isn't enough to avoid changing requirements. People have a very hard time extrapolating a generalized use case to their specific problem.
So, what can be done? Instead of showing a basic demo that just highlights the features of the software, set up a demo specifically for what the customer is trying to do.
And to clarify, this isn't a sales activity. Instead, this should be part of the design. (This is something we do at PorterLogic. Learn more about our onboarding process here) This initial demo does not have to be perfect. But, it should show the customer how the new system you're about to implement solves their problem.
As for why it works, this is radically different from how most design phases go (most people don't want to show a demo during design until the entire system works perfectly). But it goes back to getting the customer thinking about design and requirements early on and in a real context.
It's not just words on a page, and it's not just pictures in a presentation. If you can show even just a rough version of the actual system solving the customer's problem, it will lead to far more productive design sessions down the road. The customer will have a better grasp on what's possible and will even help with a solution by architecting their own design (they will suggest things more in line with the system they otherwise would not have thought about).
(This is a critical component of your business processes. Learn more about transforming your business processes into a competitive advantage here)
Taking notes on everything you learn during every design discussion you have, in particular this initial demo, will serve you well in the long run. These notes should include enough information to put together an initial design document.
Now, you may be saying to yourself, "You just said words on a page are hard for people to grasp, and now you're talking about design documents?" Yes, but we're using the term "document" loosely to refer to any method appropriate to document the design. This might take the form of a long written document but could also be UI mockups, user stories, or any number of other methods of documenting requirements.
Still, it's important to put it down "on paper" somewhere. That way, you have a record of it, and both you and the customer can agree this is what you're building towards.
No matter whether it’s a word document or UI mockups, the customer is going to need your help walking through it in detail to fully understand. After all, you cannot expect your customer to review this document and fully comprehend all the details it implies.
As the consultant, it's your job to connect the customer's expectations with the system you're implementing. Sure, if you just send an email with a long document and they reply and "approve the design," you can check the box saying they approved it. Then, when they have changing requirements down the road, you can point back and say, "Well, you approved it on this date."
But that doesn't make the implementation go any better overall.
The best consultants want to make their customers successful, and it's not enough to just CYA on the design. You need to walk the customer through this design document in detail, so they understand exactly what you're about to build.
In fact, this may be the most critical part. It's this review that can really help you iron out any details that may be missed. Depending on this project, this review could take days or months. But no matter what, it's better to identify issues during design before everything is configured.
Once you have the configuration done, changes are just bandaids. If you identify issues during design, you can design a cohesive solution that works with all the requirements.
Band-aid solutions after the fact are never as good.
And finally, it's your job as the consultant to push back on changing requirements. Don't take what the customer says at face value.
Instead, listen carefully to the customer to understand what they really need (below the words they may actually be saying) and then recommend an action based on that.
If the customer tells you they want the system to work in a particular way, work to understand why they want that. In some cases, you may have to push back on a requirement because you know that a different configuration might actually solve their problem better. That's why customers pay hundreds of dollars an hour for consultants.
They might not say it at the time, but they want you to tell them the best approach. And they'll thank you when you do!