"It wasn't in the requirements" - Navigating Issues When They're Not in the Project Requirement.

Your project is in one of its last stages, UAT (User Acceptance Testing) and you report an issue (a bug) only to have someone close it out with the comment "It wasn't in the requirements", or some variation of that.

How do you react to this as a customer? What is the right thing to do as a service provider?

From a customer's point of view, it might seem very reasonable to 'expect' certain things to just be there or work.

For a service provider, additional functionality impacts effort and resourcing. Ultimately impacting cost.

I've been through this many times and it's always a tricky one to navigate but I've found a few ways to mitigate the situation before it gets to that point, and a few strategies to de-escalate if it does.

Here are five (5) ways I manage this and project requirements as a service provider:

1. Set forth clear success criteria and ensure that you spend enough time educating all key stakeholders and your own team about how and what success is to this initiative. For example, If you are doing a custom website build:

   1. Define and align the user experience across the most important device types and browsers.

   2. Look at benchmarks for site speed and performance in your vertical.

   3. Be clear about standards for compliance. (ADA Compliance, CCPA, SOX, GDPR, etc.)

   4. Make sure you are not just focused on the end consumer experience but also the internal roles, such as merchandising, CRM, etc. They are your customer too. Agree on how much flexibility is needed and required.

   5. Make sure that these guidelines and standards are part of each and every requirement being captured.

   6. Be extremely clear on what constitutes a launch blocker.

2. Understand that your customer may not be thinking too far beyond launch.

   1. Remember that you or your company were hired because of the expertise brought to the table. The customer is focused on their business and your job is to help them grow. Help them think through the maturity of their product/site.

   2. Be your customer's advocate - ask the right questions and ask as many of them.

   3. Draw upon prior experiences from your customer portfolio. Bring cross-domain expertise to the table: What you built for a luxury fashion house, may be applicable to a high-end cosmetics client.

3. Plan for additional scope.

   1. When creating project plans and proposals, have an overall contingency, but also plan for additional feature build requests coming through in the closing stages. This will make the discussions around "It wasn't in the requirements" a lot easier to handle and diffuse.

4. Launch day is day 0.

   1. Often times customers feel like they have to get every single feature and request in by launch day. However, it's not always the case. There are exceptions, but even the best products go to market and then iterate upon data and feedback. So set a clear schedule for post-launch for when additional features and requests can be brought to life.

   2. Provide your customer with a confident and clear schedule of post-launch releases. Try to get into these conversations as early as it makes sense. This will help tremendously when those little surprises come up at the end as you can

5. Don't discount the impact 3rd parties can have on your overall deliverable.

   1. It's quite normal to have 3rd party products or applications plug into what you are delivering. However, they can be complex to navigate and may not always provide the experience you had hoped for or thought. While this might not necessarily result in an "It wasn't in the requirements" comment, it ends up in a less-than-ideal experience.

   2. Do not pass the buck. If you are responsible for the overall deliverable, then it's your responsibility to engage with the 3rd parties and understand the limits and constraints early and communicate that with the client and set expectations early.

As a service provider, we are in the business of customer service just as much as building and delivering. Our businesses need to be profitable, thus we can't have an open-ended definition of scope but taking adequate time to plan and drive clarity on success criteria upfront is vital to success and long-term partnerships. Don't just throw in some long-winded jargon in an SOW (that you know the customer won't read or remember) that you can pull up to show the customer all your points of defense and why if "It's not in the requirements" as signed-off, you won't build it or have to issue a CR.

What are your thoughts and what other strategies do you use to mitigate this?