As a software development partner, we don't want to see our clients ordering "something" from us, getting that "something", and then being disappointed when they realize it isn't what they really need.
Why would the service being ordered not be what the client needs? Isn't requirements gathering supposed to find out that need and define a solution that would meet that need?
Unfortunately, there are a couple of things preventing a completely accurate up-front definition.
As humans, we are not very good at defining what we really want until we see something that we can touch or use. Thus, once we see something, we realise new needs or better solutions. Instead of trying to define everything up front, we need a continuous stream of software versions, each of which gives us an opportunity to review the current outcome and refine our understanding of needs and solutions. This has nothing to do with how good or intelligent we are; it's just our nature.
And whenever we are exploring something that has not been done before – which we do very often – we are entering the great unknown without an accurate map. It is impossible for us to dictate the right path up front, when we don't know the landscape in detail.
The way we use computers now is different from how we used computers five or six years ago. Roughly within that time, we've seen the birth of the iPhone, iPad, and a proliferation of wireless access. We've participated in the growth of Twitter, Facebook, LinkedIn, photo sharing, and other forms social media. Internet technologies have become more immersive. In business applications, people are demanding ease-of-use, mobile access, real-time operation, etc. And it seems that change is increasing in pace.
Related to that, when we develop digital solutions, just copying the analog way of doing things is not usually a sensible approach. We use computer interfaces differently than analog ones (for example, compare using paper and pen with a display, keyboard and mouse). Also, digital approaches often require different business processes, and doing certain things can be more or less difficult than in analog. Digitalisation opens up new opportunities to integrate data or services, too.
Designing software is a learning process, for everyone (including our clients). We have to understand the right problem (which isn't always properly understood even by the client, for the above reasons). Then we have to explore possible solutions and refine them through feedback from client and users, usually learning something new along the way.
It's impossible to say in detail how long that will take. We will guess, based on experience, the likely effort within some reasonable margin of error that includes the assumption that some requirements will change. As we go, we will track progress to understand how quickly we are moving compared to our expectations.
Armed with these, we can embark on a shared journey with the customer, to seek the best possible solution within the constraints of the customer's environment. Such constraints may be, for example, budget, schedule, milestones, features, knowledge, interfaces, architectures, technologies, legal issues, people, or organisational structures.
None of the above means that we wouldn't want to plan for the future. Every project needs a vision, a goal to strive for. Something that defines what we want to achieve, how we know that we've achieved it, when do we expect to get there, what constraints we have, how do we want to work together, and so on.
All of the above just means that we have accepted the fact that many of the best ideas emerge after we have embarked on the journey, and we want to plan our projects and operations in a way that lets us capitalise on those ideas (and drop the ideas we realise weren't that good after all). We can't make many of the decisions ourselves - we need to collaborate actively with our clients.
So rather than promising "we'll do what you ask", we promise "we'll work with you to deliver what you need".