I work as a project manager for Live Typing. Last year we wrote in our corporate blog that if the deadline breaks down, then the main thing is not to make this a surprise and warn the client. But the longer we work, the more we realize that worse than broken deadlines can only be complex, emotional clients and teams burnt out under their pressure.
Those companies that have acquired a couple of regular customers during their work know how to filter suspicious leads even at the stage of the first call, and can afford it. Young studios, in the pursuit of experience and earnings, alas, can not do without such clients.
Before getting into the top ten of various industry ratings, our company worked with a client who demotivated the team so much that people started to leave the company. Due to the reasons that I will discuss below, we agreed with the client again. Fearing a new crisis of relations, I developed a special management tactic to keep the team safe and sound. Itâs difficult to find a cool developer, and training and adapting a new employee is more expensive than keeping an old one. In addition, the specifics of the outsourcing are such that after this project, developers will take the next one, and it is important that they do it with brains that have not been completely blasted out.
About how I did it, read the article.
For obvious reasons, I will call the client simply âclientâ. Even on the project, with repeated cooperation, we inside the team did not call it anything else. Why? About it below.
Background
Two years ago, a project came to us. Before getting to us, about five teams worked on it, and he accumulated a decent legacy code.
The clientâs relations with previous teams were far from partnerâs, so with him he decided to automatically take an offensive position and fence himself off with a wall of mistrust.
To speed up communication and development, the first project manager made the chat in Slack common for the client and the team - the application was not developed by us and raised a lot of questions that had to be quickly addressed to the client. In most cases, this methodology speeds up the transfer of information between team members, but our client did not deny himself the opportunity to make rude comments either in the chat or in a personal message to a specific person.
The client turned to personalities, which resulted in open conflicts, and his name was heard even from those who were not involved. As a result, the company lost at least one employee who could not put up with this attitude, and several more left after a couple of months. The formal reasons for leaving seemed to be different, but we know something.
When the client ran out of money, we broke up. The money, it is worth noting, went, including support for legacy-code and the development of functionality for the sake of functionality.
The customer later returned. He convinced us that he wanted to develop the application from scratch, abandoning outdated code, reducing functionality and communicating in a different style. We accepted it, but after some time the story began to repeat.
The client did not trust our ratings and offers. He had his own idea of ââhow the product should work. We also had an understanding of how to, but the client did not perceive the arguments and instead of a partner with expertise in application development, he saw in us only the working hands that turn his Wishlist into life. We donât know the reasons why the client put himself in such a position and we wonât be guessing.
The situation was heating up. Remembering how events developed in the past, we prioritized in an unusual order for us: first of all, you need to save the team, and only then successfully close the project and, if possible, maintain customer loyalty.
Protection tactics for complex customers
Now letâs take a look at the techniques that helped us achieve our goal, mistakes that you should not repeat, and conclusions that you can use in your work.
Explain the value of design
So, the project started from scratch. In the context of this decision, a proposal arose to do MVP and pay for our work according to the fix price model. This seemed logical, because if there is no someone else's code, then there are no risks with it.
The minus of the fix price as a payment model is that it deprives the project of flexibility: while the functionality that the parties agreed on in the technical task is being implemented, the market may change and the result of work will no longer solve actual user problems. It is possible to develop MVPs at a fix price only if you have thoroughly and thoroughly tested all the hypotheses, designed the technical specifications, and written the detailed documentation. Our client just neglected the design, or rather, took it upon himself.
The story with the choice of a service for chats is indicative. The client investigated the possible technical solutions himself, and gave us a choice of several services: "Which is better?" We chose service A because it was suitable for the project using a set of API methods, and from the point of view of development and integration it was better than service B. We did not design the service to work with our infrastructure and did not check anything else besides these formal criteria: neither stability , no response speed, nothing - there was no budget. Chat ended up responding more slowly than it could if there was time to check.
Do not fall for manipulations in the spirit of âIf you need it to complete a task, do it for free! You have to do it well! âIf there are such: the essence of outsource development is to solve client problems for client money.
The analyst must design. He has the knowledge that allows him to understand and clearly articulate what exactly the client needs in the finale, and to construct a common system architecture: what services will be in the product, whether there are integration with third-party systems, how requests go between services, where information is stored, how it is delivered, etc. This is necessary, firstly, for the clientâs product to work quickly and reliably, and secondly, in order to advise on what you can save on and which definitely isnât worth it.
Make the meaning of MVP the same for everyone
What MVP meant to us:
- we agree on the basic functionality of the application and polish to the ideal only those features that relate to it. Other features should work so that there is no desire to close the application;
- we make a minimum of functionality needed to solve a business problem, and no designed admin area;
- we postpone customization until later, that is, we use components in the design that can be reused on multiple screens, refuse complex layout elements and simplify the design if necessary.
But MVP clients have different interpretations. What did it mean for ours:
- minimal functionality for minimal money.
In the future, it somehow happened that âminimal moneyâ remained and the position âwe know how to do it, so do as we sayâ was added.
Such a position threatens a normal partnership. The threat can only be removed by design and a functional task, which spells out everything that the application should be able to do. Are there new uncommitted requirements and suggestions? Refer to the Federal Law and offer to buy time. Maybe this is formalism and not about customer focus, but it is fair in relation to your company.
Once again: MVP is combined with fix when there is design. We didnât have it, but you should have it.
Let the developers argue with you
And never work with an uncommitted design from the client, how we worked.
Developers are most often bonded: as soon as the task is set, they will do so. But on projects with a limited budget, the implementation of each potentially complex task must be called into question in order to flex it and meet the deadline.
The source of such tasks was unexpectedly the design that the designer was doing on the client side. Our developers were told that if they ask for some corrections, they will be promptly submitted, so we started working not with the static version of the design, but in the Figma editor, where this design was created. The developers gave an assessment and got to work.
And then one by one in the design elements began to appear that were not originally - this could be seen from the backup, which I made just in case. But before starting development it is impossible to check whether a particular piece of design has changed - at least because the developer takes tasks in a convenient order for himself.
Identify inconsistencies helped that same freedom of speech. The developer could come up to me and appeal not only the elements that cannot be quickly made up, but also the elements that are in the clientâs design - this is understandable, because the designer himself secretly introduced them there - but not in our copy. These elements were not included in the assessment, which means that we should not deal with them at our own expense.
In the world of healthy development, fix price does not allow to increase the amount of work and change conditions on the go.
Keep the client away from the team
Last time, we connected the developers and the client directly - there are teams where it is believed that the manager should first of all monitor the terms and budget, and not serve as a transmitter of client requirements.
This is an excellent methodology with its advantages: the reaction of each side is faster, the team better understands the business task, its authority grows, and the manager does not die as a transmitter. But knowing that the client can become personal, I isolated him from the team. Only the client, account manager and project manager, that is, me, remained in the chat.
What did it give us? I moderated communication and did not allow personal relationships to poison the work routine. In moments when the client criticized the team in their manner, I replied that we would take action and punish the employee. Observations show that in order to reassure some customers it is enough to sacrifice someone from the team even for fun, so the employee continued to work calmly and did not even know that he was punished.
If you suspect that the client is restless, then do not bring the team with him at least for a while, until you are convinced of the opposite.
Reformulate the feedback from the client to the team
In an atmosphere of constant mistrust and criticism, the team no longer manages to process the feedback in the form in which it enters, and the client begins to think that the team comes to work only with evil intentions - and embodies them.
What to do with this manager? Cosmetic editing does not hurt: I removed the personality assessment from the feedback, leaving only the wording of the error without loss of meaning. And since you donât get any praise from the client, I didnât forget to give my team my own feedback - for those tasks that did not raise questions, which means that they were performed well from the clientâs point of view.
It was: âThe application does not work payment. What hands did you do? â
It became: âGuys, the application has something to pay, the client asks to figure it out, here are the screenshots. And with the animations that lagged a week ago, everything was fine. â
Do not rush to get bugs
Entering bugs into the task manager as soon as they were received from the client is from inexperience. Armed with a critical eye, the manager will help save hours of work for developers and testers. Just talking to the client or asking to play back the actions that lead to the error and record the video, you can understand that the bug is not a priority or appeared because the client was doing something wrong - and now, you no longer need to edit it. So I sifted out a quarter of the incoming bugs, and another part was related to the integrated service support service - there were enough third-party SDKs on the project.
Do not mention customer name
Perhaps the most important insight. According to the old memory of part of the team, voicing a clientâs name provoked a biased attitude to any remark on his part, no matter how adequate it was. And I came up with calling the client just the client, which reduced the negative. It seems that everyone understands who they are talking about, but believe me - this nuance has improved the ecology of the project.
Output
For clarity, I decided to reduce all of the above to a table on the principle of "How not to and how to do it."
But our advice will be useful to you to a minimum if the person responsible for working with incoming clients in your company, or the account manager reveals client flaws at the stage of negotiations.
Here are a few important points that we are now paying attention to:
- What the client says about the previous contractor, if he was. If he speaks negatively of him, there is a possibility that he does not perceive any opinion other than his own and will impose his decisions.
- Does the client have experience in IT. For a client with experience, the development process raises fewer questions.
- Whether he bargains for every penny or not. The higher the clientâs desire to pay less, the more willingly and stubbornly he argues.
I hope this article will be useful to someone. And if you were already in my place, then tell us how you resolved such difficult clients.