If requirements are gathered by someone who isn’t an end user, but who is an expert in the domain, there is the likelyhood that the requirements will be only roughly accurate. If that gatherer then leaves the project and you lose touch with the end users, your’e even more likely to lose your way.
On a number of occassions I have seen the end users arguing with the developers as a project comes to a close, over whether what was implemented was what was required.
More frequently than not, the system will do what is required, it’s just that it does it in a different way. There is more than one way to write a Word document for example! Systems that are complex naturally have more than one solution. It depends on how the persons implementing that solution think – their entire background, culture and education can affect the solution. A fully trained kitchen fitter might have a very different perception of how a kitchen design system should work compared to a software Architect, Developer or Business Analyst. But if the system allows them to design a kitchen, is it relevant if the dialogs, screens, functions and/or business processes of the system are different? Take an SAP system for example. These come preconfigured with thousands of business Processes, Forms, Dialogs, Data Models, etc. SAP allows for example, a company to implement a Supply Chain application. But there are many, many companies which have changed their business processes to match their new SAP system. That demonstrates that there really are many different ways to get to the end goal. Isn’t there a joke about asking 10 accountants to describe your companies expense policy and getting 13 answers?
So what to do with disappointed end users? Well, a rigorous training program will get them to understand what you have implemented and perhaps even why. This training should be hands on, and one to one (or no more than three). You can really show them how the system works, using real world examples.
NOTE: if you cant get the real world examples to work, its time to change projects.
The best solution however, and only in terms of getting requirements right, not say in terms of cost or time, is to work very very closely with the customer from the start. Frequent releases to them, so that they can play with the system and give instant feedback on what needs to change are extremely important to building a system that does exactly what the customer wants.
