When the Client Said “This Isn’t What We Wanted”

Sometimes software is built according to the requirements and processes defined at the beginning of a project, but after using it for some time, the client or users feel that the system is not what they expected. In such situations, project documentation and approval of the processes can prevent many misunderstandings and help resolve disagreements.

A Real-World Experience: When the Client Said “This Isn’t What We Wanted”

In one of my projects, after about a year of using the software, the client said that the program was not what they had expected.

In response, I explained that the software’s algorithm and workflow had been approved by the company’s management and technical specialist before implementation, and that I had developed the software precisely according to that approved process.

Therefore, the existing approvals helped them understand that the main issue was not with the software’s design or implementation.

So Where Was the Problem?

Further investigation showed that one of the company’s employees had been accustomed to traditional, paper-based methods for years, and changing the way he worked was difficult for him. As a result, he resisted using the software and raised various issues and problems in an attempt to continue working with the previous method.

This created the impression that the software could not meet the company’s needs.

What Was the Solution?

Once I realized that the main issue was resistance to changing the way of working, I told the employee: “I am a programmer, and I implement the software based on what you and the organization need. If any part of the program needs to be changed or improved, just tell me exactly what you want, and I will develop it for you.”

However, even after this offer, the resistance continued, and he was still unwilling to accept the workflow of the software.

Later, it became clear that he had also discussed developing new software with another programmer, but that did not lead to any result either. The main issue was not the absence of a specific feature in the software; it was the acceptance of a change in the way of working.

This experience taught me an important lesson:

Documenting requirements, processes and algorithms is not only important during software design and development; if disagreements arise in the future, these documents can show what was agreed upon and what the software was built around.

On the other hand, building good software alone is not enough to make a project successful; users also need to accept changes to their way of working and be prepared to use the software.