However it is inevitable that the customer will need to provide feedback on the software and will be very keen to make some changes. In the above scenario the client is going to find themselves giving their feedback at a time towards the release date when they actually get to see the software. These changes are unlikely to be very welcome to the Software Development Omnia app company at this point. In practice these requests for changes results in friction between the customer and the Software Development company, possibly bringing about arguments between the company and the customer. The company will believe that these requirements wasn't specified originally when the contract was signed and demand additional cash to implement these changes. If the customer agrees, a new contract will need to be negotiated. On the other hand the company may agree to do these changes for free given that the customer is without a doubt quite upset that the software does not do what the customer wants. The more often these changes are handled for free; the company gets closer to generating a loss on the project. In both of these scenarios, the project is sure to be late.
If the development team itself is trying to be Agile and is developing the project in iterations, the case is often improved through getting feedback from the customer earlier on in the project. But if the contract remains to be the same, these changes will still be unwelcome to the business people associated with the project. They will be seen as an extra expense and the developers are going to be instructed to extend the time on making these changes until a new or revised contract can be negotiated. Once the business people perceive that changes will be happening between iterations and that this needs addressing, they should recognise that a new approach will probably be required in future for making new contracts with customers. An effective option that they might choose is to try to break down the 'development' of the project into separate, ready planned phases and then make this the substance of the contract. This approach doesn't challenge the customer's expectations of being certain of the outcome of a project, and so it appears like a safe option. At the start of a project, a customer is frequently quite positive that they know what they aspire to. In practice, actually seeing and using the software might most likely make the customer consider the project in a whole lot more depth than they had previously.