The common picture of requirements elicitation looks like this. Which of course is an example of doing stupid things on purpose. When this picture is used as an example of not doing something because it doesn't turn out right, is a further example of doing stupid things.
Let's see where the gaps appear that results in the outcome in the last panel:
- How the customer explained it - was there a Concept of Operations? How about a Statement of Objectives? Some narrative of what the system would do when it is working? Use Cases? Scenarios? NO? Then what the customer explained cannot be tested in any meaningful way.
- How the project leader understood it - here's where the failure starts. There is no confirmation in units of measure meaningful to the decision makers on what DONE looks like. What are the Measures of Effectiveness that are the goals the customer can assess and agree to?
- How the analyst designed it - what is the baseline description of the system the analyst starts with. What are the Measures of Performance of the system? How will those be measured?
- How the programmer wrote it? - what's the build to plan? How does the developer know what to build? How will it be tested?
- etc etc etc
The wheels fall off when there is no description of DONE shared between the customer and the provider. If the customer doesn't know what DONE looks like, who does? The developers? Probably not. Is DONE emerging? Then the customer has to pay for that?
There is no way out of the need to know what DONE looks like in Measures of Effectiveness, Measures of Performance, Key Performance Parameters, and Technical Performance Measures. Without these the success of the project is in doubt from the start.
The notion that requirements emerge is will established. But the capabilities the customer needs to be stable enough to establish an Estimate At Complete and an Estimated Duration to Complete. Without these the customer has no understanding of the all in cost of the project. These change as the requirements change. That's part of the project management process. This can't be ignored if the customer is to have any confidence in the project providing value at the needed time at needed to be put to use.
So a reminder one more time...
You can't assess the value of the project outcome without knowing something about the cost to deliver that value and the time frame for that delivery.
No matter what anyone says, this is an immutable business principle. Anything is simply fooling yourself into believing that the customer doesn't care how you spend her money or when you spend it.
Focus on value, that's what the customer bought. Actually they bought a capability to do something to improve their business or mission. But ignoring the cost of delivering that value is ignoring the balance sheet of the business.
