Est. reading time: 5 mins
A productive relation between you and the software house needs to be profesional and built and mutual understanding. It is not a typical sales relation like that between the shopkeeper and a customer. Not only is is longer-lasting but also requires greater commitment. The IT consultant gets to know your needs and certain details relating to your business. You want to believe your intentions will be correctly understood and the developed solution built in accordance with them. What if the client-software house relation comes into a conflict? It may lead to failure of the whole project. It is worth to be aware of the most common reasons for misunderstandings as this will help to avoid them. Read on to find out 8 of them.
8 most common reasons for conflict
1. Different preferences in terms of communication methods. By that I don't mean only the fact that some people prefer writing emails while the others would rather speak over the phone. The issue here may be the level of honesty or lack of the ability to show dissatisfaction in a constructive way. Say the client is reluctant to ask technical questions to avoid being perceived uncompetent. As a result, such a client might get a final product, which they may not know how to use. Also the software house representatives may sometimes show impatience or lack of understanding towards the client's point of view. If we fail to notice such an issue in time and it remains unresolved, it may turn into a greater misunderstanding.
2. Different visions of the project management. When you sign an agreement with a software house, you agree on a certain way of delivering the final product to you. If you then question the steps taken by the company you hired, it can make the work on the application more difficult. It might also be that the software house is reluctant to agree on a give-and-take in certain areas of the project if it differs from their standard procedures. This problem can be easily resolved by a well-written agreement, which will represent and protect both the parties.
3. Ineffective communication. Prolonged periods when one party awaits the other's response or acceptance of a part of the project can significantly delay the whole process. This applies to both of the parties, e.g. when the agreement is negotiated or the mockup designed. Without establishing effective ways of communication it is not easy to have good cooperation. Some discipline and preciseness in this area will positively affect the course of the whole project. How? Agreeing on certain dates and times for consultations, deadlines for accepting or rejecting particular parts of the project, consultation periods, application development and testing periods – all these actions will help to outline clear rules on collaboration.
4. Vagueness of the identified needs and the presented point of view. IT advisor helps to find ways to streamline the areas pointed by the client. To avoid problems, those areas need to be well-defined. E.g. when creating a table within the system, it is important to determine what elements are to be displayed and what should be the layout. It's the same when a technical issue needs to be raised – it is crucial to desribe it in detail, preferably attaching a relevant screenshot. This enables quick reation and continuation of the work on the project.
5. Different definitions of the same concepts. The most problematic are the vague terms such as: 'completed', 'urgent', 'pending completion', etc. Escpecially those, if not clearly defined, can cause a lot of frustration. Let's assume the client wanted to have a table within the system, which would show certain amount of data. They thought it would be possible to choose desired positions using a checkbox. It is possible but only after choosing to edit the table rather than viewing it. The client may think the expectation was not met, while the programmers will say it was. That is why it is significant for both parties to understand what certain terms or concepts mean as this is key to effective cooperation.
6. Too little/much information provided by the client/software house. No extreme will be beneficial in this case. Information overload will make the most important acpects, which aim at improving your work, look blurry. On the other hand, if there is not enough information provided, it is not possible to build a well-tailored system. It is key to ask questions and get valuable feedback. It is worth to clarify even the seemingly obvious questions to avoid misunderstanding while the project is being developed.
7. Technical issues. What is characteristic about dedicated systems is that those are unique and built to individual order. It means those are not free from technical errors, which are then eliminated during multiple tests run by the software house and also performed by the client. It may happen that an error is detected once the application has been delivered to you. Some companies, including Kamee, deliver their software with a 12-month guarantee, which includes technical support and fixing potential errors. However, it is difficult to do it without a detailed description of the issue. It is not enough to say "warehouse module doesnt' work", your should rather explain, e.g.: "I cannot generate a GR document, please see screenshots attached." In this case, we get all the information we need and we can react quickly.
8. Different characters. Sometimes the problem may be caused by the personal traits rather than difficulties in communication or reluctance to ask questions. What can be done in such case? Some will resign from collaboration, others will limit the contact to professional enquiries and the correspondence to short informative emails. It is the choice of both parties whether to work together and how will such collaboration look like.
How to work effectively?
To achieve effective cooperation between the client and the software house it is essential to:
- Work out a way of communication, which will keep both the parties informed in terms of the project course and the expectations of both the client and the software house.
- Clearly convey thoughts. This includes among other things the expectations towards the designed solution and feedback regarding every completed part of the project.
- Prepare a well-written agreement, which will protect both the parties and define the key terms in a detailed way.
More articles:
Why is it worth to work with programmers who use Ruby?
Will an investment in a custom web application pay off?
How to choose a software house?
See our work:
Intranet - E-commerce - UK, US, Brazil, Singapore, Russia, Turkey, UAE, Poland
Bespoke Manufacturing Execution System with extra modules of WMS and APS - Wroclaw. Poland