what do you do when during UAT the customer realizes something major that should be included in the system?

Question

during uat, the user realizes a major missing functionality that should be included in the system. this is not related to the implementation of the application, but with the design and the initial laid out initial requirements.

if you push the current state to production, the app will appear unusable since it is missing a key functionality (that the customer didn't included in the requirements earlier).

you can also continue to develop but this will extend the timeline for the accomplishment of the app. and it would appear that the developers are behind schedule.

how do I proceed with this one?

Answer 1

First off I think we have to say that this is not an uncommon thing to happen. Requirement gathering is hard and customers often expect programmers to 'fill in the gaps' from broad requirements.

From an agile point of view its not a problem at all. Simply add more requirements to the backlog and proceed as normal.

If you have agreed a fixed price or deadline with the customer though, obviously the business has a problem. either the customer or the business is going to lose out.

This is why agile was invented, requirements change in software projects A LOT. The solution for the business is to switch from a fixed price to time and resources billing. Or make sure your contract is just for the specced work and hope the customer doesn't blame you for bad specs

Answer 2

It rather depends on whose mistake it was that the requirement got left out.

If it was your mistake, then you have to negotiate a way out with the customer. Perhaps deliver an interim version of the software, followed by a feature-complete version later on. One way or another, you are going to take the hit.

If it was their mistake, then the mercenary approach is to see this as an opportunity, and not a problem. Offer to add the extra feature that the customer forgot about. Calculate an appropriate price for that extra feature, based on the amount of work you need to do to implement it, and a corresponding extension to the schedule. Done right, you can keep your employees working on a customer-funded project, and make more profits while doing so. And it's the customer's problem that the product is being delivered late, not yours.

Answer 3

When that happens, you let your manager sort it out. If “user” means paying customer, then the companies involved figure out between them who pays the cost for additional development. If it is an internal user, then your management some levels higher has to sort it out.

There is also the obvious possibility that the “user” just doesn’t want to use any fancy new software and is just being difficult; there have been cases were users have been replaced (user A finds the software unusable without feature X, user B can use it just fine, so user A gets pushed out).

So just let your manager decide. PS. You make no promises, no admission of fault to anyone. Don’t do anything that makes it harder for your boss to negotiate, block, or charge more money.

Answer 4

Everyone so far has commented on this from a process perspective. Moving towards a more iterative development process like Agile will certainly make adding additional features easier on the team but there are also architectural tricks you can employ during the planning and development phases of your lifecycle that will significantly lessen impact from UAT surprises.

When you encounter these types of issues, you can certainly sideline your releases until the new feature is added but likely then you will be forced to rely on long running feature branches which inevitably lands you in merge hell.

Alternatively, try adding the following concepts to your existing SDLC process so that when these types of events happen it is not the end of the world for your app team:

• Feature Flags (aka Toggles) are a great way to release features to production without actually "turning them on". Flagging basically amounts to wrapping all your new features in an on/off switch. You can control a centralized "switchboard" a variety of ways: through config files, admin screens or even a hosted webpage. This technique is great for operational preparation (such as business team training), for implementing multi-staged releases without disrupting production or (as in your case) for delaying releases due to late discovered issues.
• Modular Design - Investing a little time in planning your architecture up front can pay dividends later on during the SDLC process. By modularizing functionality and limiting architectural coupling you can encapsulate larger functionality (just as would an Object Oriented class) which makes individual features far less dependent on sister features. Many service based disciplines like SOA and Microservices rely heavily on these concepts.
• Branch by Abstraction - Sometimes you have to work on legacy code which has serious design problems or maybe even a high-functioning system which requires an invasive change. The method described by Martin Fowler in this article is a fairly basic concept but one that is tried and true. By creating a separate layer and slowly disconnecting and reconnecting parts of your application, you can deliver big design changes without significantly compromising your live project. Used in conjunction with the other methods above, this is a valuable way to roll out big feature changes that touch existing functionality.