Tale of a project manager at a bank and how he solved problems with a remote contractor

Once upon a time there was a project manager. He worked in a bank. They commissioned him to make an external product for the bank of this. It was necessary for the manager to find a remote development team that would make it to him. He found the development team, TK wrote. They began to work together. Work at first went well. Sprints closed on time, quality did not suffer.

And then something happened to the contractors. They changed the manager's roofing felts, developers threw the roofing felts onto another project and left him the juni, something else. Processes began to be carried out more slowly, the deadlines for production, the quality became worse. The manager began to think, what happened and how would he solve his problem? He went to his old friend, whose company is engaged in IT outsourcing. He told about his problem. And a friend remembered that he had recently written a document for his team, where he painted on how to communicate with the customer so that it would be effective and the quality would not suffer. He shared the document with the manager. And the manager read it and, with minimal edits, sent a letter to the contractor.

Colleagues, hello

I don’t know about you, but it seems to me that we are now out of sync and the current state of affairs only aggravates it. In the future, this will necessarily affect the quality of the tasks, the deadlines that will increase. In turn, you will not be happy with the fact that we paid for one time, and you spent on tasks quite another. In the end, all this can lead to our separation, which is not beneficial for our companies.
')
To avoid all of the above, I have prepared a small list of principles and rules of our interaction with you.

1. Stand on the side of the customer. This means that you need to wear a customer's cap and, being in his skin, present the motives of his requirements and tasks. Motives may be obvious, and may be hidden. If you feel that there is no additional information in the task for complete understanding, you need to ask about it and record it in the source document about the task that is placed on Google disk. Everything should be transparently clear.
   
   
   • for peems: if in the process of receiving a task or user of history you feel controversial moments or you are missing something, then try to get all the information to be with the customer on the same page. The customer can say one thing, imply the other, and expect the third.
     
     
   • for the rest: for developers / designers guys, it is also useful before starting work on the task of presenting yourself as a customer and understanding its motives. This is such a simple and short-lived thought experiment and it will help you to understand the task deeply and clearly. If you received the task and it is, in principle, understandable, but you do not see the overall picture and do not feel how it will affect the process as a whole - be sure to inform the peem about this.
     
     
2. Honesty, respect and restraint.
   
   
   • honesty: talk about problems and backlogs in time so that the customer on his side can mobilize. No one is immune from mistakes, but their silence is regarded as non-professionalism.
     
     
   • respect: the customer can be with his cockroaches in his head, can sometimes be blunt. But since he works with you, it means something.
     
     
   • restraint: try to restrain your emotions in communication and in correspondence.
     
   
   
3. Communication! Communication! Communication! (I would like to immediately note that under communication, in no case is idle chatter and thoughtless negotiations). Below are excerpts from the book Remote, since we are working remotely:
   
   
   • Tell the client more often what has been done on the project. This is the best way to relieve him of a completely natural alarm. Listen, he pays you decent money, and some of the anxiety that he feels from the moment he’s parted in advance is understandable. So show him what he pays for. When customers regularly see the results of your efforts, they feel much better. But in order to avoid constant calls, it is necessary to work clearly and structured on the tasks in our tool - Trak:
     
     
   • The task must be completely framed (what needs to be done, how to do it, criteria for readiness, etc.).
     
     
   • The task must have all the items (milestone, planned deadline, components, release number, date, etc.).
     
     
   • The task should have visible progress, that is, if the developer has assigned the task to the status of inProgress and is working on it, I expect to see what he did on it during the day (this is at least 2 comments to the task per day, which will clearly reveal the essence of what has been done) .
     
     
   • Be stressed for communication. Since we do not have the opportunity to meet in person, it is better to call back in time, respond to e-mail, respond to instant messengers, and so on. These are the basics of business ethics, and their importance is increased tenfold in the case of remote work. If you are working remotely, customers are more suspicious of unanswered calls and “lost” mail. Be in touch, it is in your interest. In order to swim in the same channel, now every day we will have a video conference at 9:30 (this will be a stand-up for no more than 10 minutes to check hours, hear problems and understand where we are going) The presence of the entire team is required.
     
     
   • Connect the customer to work, let him see the whole process. Let him feel that this is his project too. Yes, you were hired because of your experience, but he also has enough experience. Show half-baked, barely moving prototype or service, it is better to understand at the initial stage what is wrong and spend less resources and forces on rework. As a customer, I understand what a prototype is and what things you shouldn’t pay attention to, it’s important to have a basic understanding of the work, and the details are the details.

As a result, things went well. And while the development team was pleased with this regulation more than the author of the letter. Without clear rules and discipline, any interaction process falls apart. It would be nice for the development teams to have within themselves and stick to them, and not wait until the user makes it.