All tools are summarized in Tools for a Consultant’s Work - Summary.
The work of a programmer is vastly different from that of an IT consultant. As we write lines of code, we often focus more on design patterns than on the real-world use of our code by users. Many of us have argued with colleagues about using this or that library because it’s easier to unit test, has a richer API, or is recommended by our favorite blogger. We treat our projects like playgrounds, but instead of shovels and mounds of sand, we have new databases and frameworks. We forget that our project needs to function and provide value to the client, and only afterward should it cater to our programming egos.
This behavior is impossible when working as an IT consultant and creating solutions directly with the client. In that case, you need to understand how to solve their problems, putting programming ventures aside. It’s crucial to fully understand the client’s business processes and work appropriately with them.
As a programmer transitioning into a consultant role, obviously I made typical mistakes as someone who is just learning about these things. I’ve gathered them to show how to better understand our clients and fulfill our work.
Understanding the Client’s Language
It’s always worth listening carefully to the language the client uses during conversations with us. They may use specialized, industry-specific terminology that might initially seem strange and off-putting. However, we shouldn’t try to impose our own language on them. Things that seem synonymous to us often are not. The client may have a detailed vocabulary for describing their business process, assuming minimal discrepancies. Attempting to change terms will then result in unnecessary misunderstandings. In our conversations, we can even try using the same phrases multiple times to ensure we fully understand what the client means. Only then can we achieve a linguistic unity and fully understand the client’s business goals.
Continuing the Current Process
Very often, the application we are writing is not the first system the client uses. They may have a system that we are rewriting for various reasons. Sometimes the client works with extensive Excel sheets sent back and forth, or everything relies on ordinary paper sheets filled with pen ink daily. It’s important to understand current processes well to correctly translate them into our new application. The change will be easier the more our new system mirrors the client’s current behavior. If we know the domain well enough to impose certain solutions, we should explain this well to the users of the system so they understand the changes and what we aim to improve in their process.
Starting with Small Steps
Many projects have failed because they tried to reorganize the work of entire departments from scratch. Often, a better solution is to gradually adjust the application to the client’s requirements, as they will be able to provide feedback on whether the development is going in the right direction. This way, we will have quick feedback on whether we should change our development direction and focus on other aspects. Additionally, the system users will have more trust in us and will be more willing to share further comments. They will see that our work brings them tangible benefits, and they won’t have to wait months for the next implementations.
Understanding Users' Concerns
Every new program brings changes. People generally don’t like change. Everyone has their comfort zone where they feel good. By implementing our program, we deprive them of this zone, which is why they may not always approach our system enthusiastically. It’s important not to take this negatively—every concern has its reasons, and understanding them allows us to better develop the system by addressing them at the root. Employees, seeing that we try to understand their arguments and resolve them, will be more favorable towards us. Otherwise, it could even lead to project sabotage—employees constantly ignored might try to ensure the project gets canceled because it brings them no benefits and only adds unnecessary work.
Balancing the Order of Features
When planning an application, it’s worth carefully considering which elements will give users the most value and which are merely optional. It’s easy to fall into a business domain where we feel comfortable and keep adding features one after another. However, at the same time, other departments of the company may suffer because their part is not being developed as quickly. It’s helpful to recall the Pareto principle, which states that 20% of the time will cover functionality providing 80% of the value. Balancing the implemented features across departments is important for the program to work as a whole. Naturally, the department bringing the most benefit to the company will be developed the most, but often small changes in a supporting department can significantly improve application usage efficiency, thus supporting the entire process. Since our client often may not know the proper order of new functionalities and we, in a sense, impose the next steps of development, it’s worth focusing on those that will complete the MVP of the project and then move into details.
These are just a few thoughts that came to mind during my recent project work. If you would like to add anything to this topic or disagree with something, I would love to read your opinion on the matter.
