managementMost of our clients are rather surprised when we explain to them that they will have full access to the source code from the first day of the project. We let them see everything that is happening in the project, including the Git repository, bug reports, discussions between programmers, continuous integration fails, etc. They often tell me that other software development outsourcing teams keep this information in-house and deliver only final releases, rarely together with the source code.
I understand why other developers are trying to hide as much as possible. Giving a project sponsor full access to the development environment is not easy at all. Here is a summary of problems weâve been having and our solutions. I hope they help you honestly show your clients all project internals and still keep them on board.
He Is Breaking Our Process
This is the most popular problem we face with our new clients. Once they gain access to the development environment, they try to give instructions directly to programmers, walking around our existing process. âIâm paying these guys; why canât I tell them what to do?â is a very typical mindset. Instead of submitting requests through our standard change management mechanism, such a client goes directly to one of the programmers and tells him what should be fixed, how, and when. Itâs micro-management in its worst form. We see it very often. What do we do?
First, we try to understand why itâs happening. The simplest answer is that the client is a moron. Sometimes this is exactly the case, but itâs a rare one. Much more often, our clients are not that bad. What is it, then? Why canât they follow the process and abide by the rules? There are a few possible reasons.
Maybe the rules are not explained well. This is the most popular root causeâthe rules of work are not clear enough for the client. He just doesnât know what he is supposed to do in order to submit a request and get it implemented. To prevent this, we try to educate our clients at the beginning of a new project. We even write guidance manuals for clients. Most of them are happy to read them and learn the way we work, because they understand that this is the best way to achieve success while working with us.
Maybe our management is chaotic, and the client is trying to âorganizeâ us by giving explicit instructions regarding the most important tasks. Weâve seen it before, and we are always trying to learn from this. As soon as we see that the client is trying to micro-manage us, we ask ourselves: âIs our process transparent enough? Do we give enough information to the client about milestones, risks, plans, costs, etc.?â In most cases, itâs our own fault, and weâre trying to learn and improve. If so, itâs important to react fast, before the client becomes too aggressive in his orders and instructions. It will be very difficult to escort him back to the normal process once he gets âmicro-managementâ in his blood.
Maybe the client is not busy enough and has a lot of free time, which he is happy to spend by giving orders and distracting your team. Iâve seen this many times. A solution? Keep him busy. Turn him into a member of the team and assign him some tasks related to documentation and research. In my experience, most clients would be happy to do this work and help the project.
He Is Asking Too Much
A technically-savvy client can turn the life of an architect into a nightmare by constantly asking him to explain every single technical decision made, from âWhy PostgreSQL instead of MySQL?â to âWhy doesnât this method throw a checked exception?â Constantly answering such questions can turn a project into a school of programming. Even though he is paying for our time, that doesnât mean we should teach him how to develop software, right? On the other hand, he is interested in knowing how his software is developed and how it works. Itâs a fair request, isnât it?
I believe there is a win-win solution to this problem. Here is how we manage it. First of all, we make all his requests formal. We ask a client to create a new ticket for each request, properly explaining what is not clear and how much detail is expected in the explanation.
Second, we look at such requests positivelyâthey are good indicators of certain inconsistencies in the software. If itâs not clear for the client why PostgreSQL is used and not MySQL, itâs a fault of our architect. He didnât document his decision and didnât explain how it was made, what other options were considered, what selection criteria were applied, etc. Thus, a request from a client is a bug we get for free. So, we look at it positively.
Finally, we charge our clients for the answers given. Every question, submitted as a ticket, goes through the full flow and gets billed just as any other ticket. This approach prevents the client from asking for too much. He realizes that weâre ready to explain anything he wants, but he will pay for it.
He Is Telling Too Much
This problem is even bigger than the previous one. Some clients believe they are savvy enough to argue with our architect and our programmers about how the software should be developed. They donât just ask why PostgreSQL is used, they tell us that we should use MySQL, because âI know that itâs a great database; my friend is using it, and his business is growing!â Sometimes it gets even worse, when suggestions are directed at every class or even a method, like âYou should use a Singleton pattern here!â
Our first choice is to agree and do what he wants. But itâs a road to nowhere. Once you do it, your project is ruined, and you should start thinking about a divorce with this client. Your entire team will quickly turn into a group of coding monkeys, micro-managed by someone with some cash. Itâs a very wrong direction; donât even think about going there.
The second choice is to tell the client to mind his own business and let us do ours. He hired us because weâre professional enough to develop the software according to his requirements. If he questions our capabilities, he is free to change the contractor. But until then, he has to trust our decisions. Will this work? I doubt it. Itâs the same as giving him the finger. He will get offended, and you wonât get anything.
The solution here is to turn the clientâs demands into project requirements. Most of them will be lost in the process, because they wonât be sane enough to form a good requirement. Others will be documented, estimated, and crossed-out by the client himself, because he will realize they are pointless or too expensive. Only a few of them will survive, since they will be reasonable enough. And they will help the project. So it is also a win-win solution.
For example, he says that âyou should use MySQL because itâs great.â You tell him that the project requirements document doesnât limit you to choose whichever database you like. Should it? He says yes, of course! OK, letâs try to document such a requirement. How will it sound? How about, âWe should only use great databases?â Sound correct? If so, then PostgreSQL satisfies this requirement. Problem solved; let us continue to do our work. He will have a hard time figuring out how to write a requirement in a way that disallows PostgreSQL but allows MySQL. It is simply not possible in most cases.
Sometimes, though, it will make sense; for example, âWe should use a database server that understands our legacy data in MySQL format.â This is a perfectly sane requirement, and the only way to satisfy it is to use MySQL.
Thus, my recommendation is to never take a clientâs demands directly to execution, but rather use them first to amend the requirements documentation. Even if you donât have such documentation, create a simple one-page document. Agree with the client that you work against this document, and when anyone wants to change something, you first have to amend the document and then have your team ensure the software satisfies it. This kind of discipline will be accepted by any client and will protect you against sudden and distracting corrections.
He Is Questioning Our Skills
When source code is open to the client, and he is technically capable of reading it, it is very possible that one day he will tell us that our code is crap and we have to learn how to program better. It has not happened in our projects for many years, but it has happened before, when we werenât using static analysis as a mandatory step in our continuous integration pipeline.
Another funny possibility is when the client shows the source code to a âfriend,â and he gives a âprofessionalâ opinion, which sounds like, âThey donât know what they are doing.â Once such an opinion hits your clientâs ears, the project is at a significant risk of closure. Itâll be very difficult, almost impossible, to convince the client not to listen to the âfriendâ and continue to work with you. Thatâs why most outsourcers prefer to keep their sources private until the very end of the project, when the final invoice is paid.
I think that an accidental appearance of a âfriendâ with a negative opinion is un-preventable. If it happens, it happens. You canât avoid it. On the other hand, if you think your code is perfect and your team has only talented programmers writing beautiful software, this is not going to protect you either. An opinion coming from a âfriendâ wonât be objective; it will just be very personal, and thatâs why itâs very credible. He is a friend of a client, and he doesnât send him bills every week. Why would he lie? Of course, he is speaking from the heart! (Iâm being sarcastic.) So, no matter how beautiful your architecture and your source code is, the âfriendâ will always be right.
In my opinion, the only way to prevent such a situation or minimize its consequences is to organize regular and systematic independent technical reviews. They will give confidence to the client that the team is not lying to him about the quality of the product and key technical decisions made internally.
To conclude, I strongly believe it is important to be honest and open with each client, no matter how difficult it is. Try to learn from every conflict with each client, and improve your management process and your principles of work. Hiding source code is not professional and makes you look bad in the eyes of your clients and the entire industry.
