“We have found out what the software should do for us. Here are the requirements, which we know you will ask for; and here is the systematically documented design specification!”, says the client. “All you have to do is write the software and give it to us!!”.
At times, a client, especially a new client, feels that they have already figured out the requirements and devised the solution. They have spreadsheets, loads of documents and examples of what others have done to indicate the solution they need. All they ask from you is to write the code, test and give it to them. This should save them money and time because they have done a lot of stuff themselves. Right? Wrong!
The big disadvantages of such an approach is that they ignore some factors that are extremely important from software development perspective, and secondly they are not fully aware of the technical possibilities that can help in building the ideal solution for them.
There are some clients who have not kept up with the developments in software world. For example, some companies are still not aware the progress done in online publishing. So they build their solution around uploading PDFs. They are overwhelmed when they see the possibilities of publishing, feedback from readers and interaction. This usually leads to devising a new solution, which makes their earlier effort a waste. Or, they end up with a solution that does not provide ROI to its potential.
On the other hand there are those who feel that they should get all the bells and whistles that the software can provide. Unfortunately, the ideal solution rarely equates to that. Again, they end up hurting themselves by either paying a lot more than they should or redo it.
Software development, like many other engineering disciplines, is an act of devising the solution by identifying the right balance of all the factors. And it starts from identifying what those factors are. Most of the times the client’s documentation misses out on this and the software project turns out to be a failure.
In my opinion, the underlying reason here is the initial lack of trust, because of which they try to show that they know enough to not be cheated by you and to exert some control over the project. The challenge here for software developers here is to convince them about this. What has worked out, sometimes, for me is to hear them out and take a couple of days to brief them about other possible solutions and why their solution might not deliver. Have you experienced this? What do you do?