Every developer or project manager has been in this situation. You are just about to finish a feature and you have put quite some time and effort into it. But when the client sees it the first thing they say is: "It looks great, there are just a few things we would like to have changed...". They might even argue that these changes are "small", This might feel like you are continuously redoing your work
After this you may feel slightly annoyed or down. You just thought that you were about to be done, but now you seem to have been kicked back to the starting point. You cannot put all the blame on the client, but something went wrong in our communication.
Now you ask yourself, how did you end up in this situation? First we will have to look at why you ended up in this situation and then what we can do about it.
1 - Why do change requests happen?
There are many reasons why you could end up in this situation. In essence: change requests come from bad communication or no communication at all. The communication could be flawed because of a limitation in time. Maybe the key persons on the project are not available for questions or the client is in a different timezone than those who develop the project or is overall busy.
On some projects, people are so eager to get started that they forget to make a plan. I have seen this multiple times. The parties think they have agreed on what should be done, but what actually happens is that they leave the meeting room with two different ideas of how the product should be. This leads to confusion if they do not work closely together.
Remember that communication requires two people.
It might be that the right questions have not been asked early in the process. Asking the right questions before starting is hard and it is something that comes with experience. Some of the biggest pains come when you make too many assumptions. One of my favorite quotes is: "It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So" (I learned it from the movie "The big short"). Make sure to ask questions about everything that you are unsure about and from time to time also what you are sure about.
Sometimes there are too many levels in the communication chain. The client talks to the project manager, who has to talk to the product manager, who asks the delivery manager, who gets this information from the team lead, who has to clear it off with the other developers. Some information has got to be lost in this process. This is often the case in big companies and it is often easier if the developers talk to the client directly. You have probably seen videos of the communication game or chinese whisper, which in simple terms demonstrates why it is hard to keep the integrity of the message in long chains of communication.
Other times we and our clients get lost in technical details. We end up with a technical error that we did not or could not have foreseen. This automatically forces us to make some changes to the product. Change request sometimes come from a lack of technical knowledge, it is possible to end up in a situation where you have sold something that is almost technically impossible. The more experienced the developers and project/product managers are, the smaller the chance is that you will end up in this situation.
There can also be a lack of communication internally on the development team. This could stem from a lack of defined roles, where the team members do not know who is responsible for communicating what. It can also be a cultural problem, where everything is left to the more senior employees or employees are afraid to bring problems into the light.
An entirely different reason can be that the client simply got a new idea. This is not a bad thing, as long as you tell what the consequences of implementing it is. Whether it is a delay of the product or more money needed. Clients who bring ideas and are engaged in the development process often get the best results. Act positive when they bring ideas to the table. I would normally say that you should embrace change, however if you are constantly changing and never delivering, then you need to start focusing on getting something done.
2 - What can you do to improve communication?
Now that we have covered some topics on causes of change requests and bad communication. Let us have a look at some potential solutions:
2.1 - Have a single voice
You may skip this advice if you are a lone developer with a single client. If you are part of a medium/large sized team keep on reading. Sometimes your client have several stakeholders in the product you are creating. The more stakeholders the more opinions and ideas you will be met with. One of the best ways to deal with this is for the client to get a single voice. Get a representative for your client. This works best if your client can nominate one of the stakeholders to care for the view of all, in Scrum or other agile methodologies this person is often known as a Product Owner.
An alternative would be for the project lead to make the ends meet, the idea here is to avoid contradictions reaching the development team. Also the development team will have one go-to person when questions arise. This does not mean that they should not speak to other stakeholders, but they know who should be available.
2.2 - Client goals and motivation
You should not think of your client as someone who just hands you a task. In order to understand the job you are about to do, you need to understand your client. You should focus on your main contact within the company. What is his/her position in their company? and what is the contact's motivation? A contact's motivation can be anything from "just overseeing" the project, to have a bonus depend on its success. This also ties into knowing what the clients business and domain is all about, without this knowledge it can be hard to create the right software and solution.
When you understand what motivates your client you will also know their goals. Your job is not just to do a job for your client, but help them achieve their goals. One of the most important things is to ask yourself: why are you doing this? If you do not feel that you are doing something useful, you will have a hard time being innovative and productive in the long run. If you do not know what the goal is, then you will not know if you have missed it.
Sometimes poor communication is not part of the task at hand, but in the fact that the long-term goal is not known.
Besides your main contacts motivation and goal, it will be much easier to build the right thing if you know how it fits into the overall picture. Some projects are started and along the way you figure out that no one wants the feature you are building or there are too few users who wants it and therefore it is not viable to be built.
2.3 - Do reviews often
This topic is very dependent on your situation. If you are in a large business you might be drowning in reviews and meetings, whereas if you are in a smaller company you might have too few. If you think your meetings are too long and not effective, read my post on how to make your meetings effective.
Presentations can be done on many levels. Anything from full scale meetings to a simple screen-sharing/video call. It could be that you are about to finish a feature - or that you are unsure of how to go about a feature. Create a quick check in with the client and ask what he or she thinks of your approach. This is the perfect time for feedback, but remember distinguish between change requests and what has been agreed upon, so you do not end up getting a new change request!
2.4 - Agree on deliveries
Your long term delivery might be on a contract, but if you are agile you will deliver continuously. During your check in with the client you should brief them on what you are working on next. This will give them some expectations on what will come next. This will also give the client a chance to reprioritise if there has been a change in prioritisation. Otherwise you might be ending up with 2 different ideas of what you will be delivering.
You can also help the client prioritise tasks. Sometimes it makes sense to take on tasks in a specific order due to technical reasons. Such as if you are going to work on the UI and there is a small task that you might as well get done while you are already working on the UI, as if you can get that done as well. If this saves the client time (money) they will appreciate it.
Do not follow tasks blindly: Having great documentation is not a reason to have no meetings. Sometimes there are contradictions or features that are not thought through. If you do not understand the requirements or you feel that they make little sense, contact the client.
2.4 - The unknown Customer
I have seen this on several projects, a development team is handed tasks directly from a project manager without ever meeting the client. Maybe they met at the kick off meeting, but since then they have never seen each other. As I wrote before it gives great value to know the client. Having some sessions with the client makes you see the project from their point of view and in return they will it from your point of view.
You need to understand the business in order to create a great product.
2.5 - Skip the middleman
If possible, make the client available to the development team. There is no reason for a developer to always go through the project manager. If a task has been agreed upon, but some details are lacking - why set up a whole meeting? Call or write an email, meetings do not always have to be formal. Sometimes a single call/email can save you hours of planning. Just make sure to document what is agreed upon and it is always a good idea to get this in written form.
2.6 - Spare them the technical talk
Sometimes meetings lose their value if the development team goes into "solution mode". This is when the team spends too much time on the how instead of the what and why. The client usually do not care much about the technical details - except if it has an impact on the product. Sometimes a team of developers can be caught in talking solutions in between them. This is a waste of precious time with the client, technical talks should be in a different forum.
2.7 - Definition of done
In order to know when something is done you will need a definition of done. Every task you take in, will need to have enough information for you to be able to complete it. Essentially you should be able to do it with no other information than there is written about the task. If you practice scrum you will already know all about this. It is important that we agree on when a task is done.
2.8 - Do what you are sure of
This is where you might step over a line. The client is the one to prioritize what is most important. But what if you are unsure of how the client wants the task solved? Maybe there are several uncertainties - maybe there is no design. Guessing here would be a gamble. What you can do, is to do what you are sure of. Then leave the rest of the work for later. The client will most likely be glad that you did not just sit on your hands. This will give you a feeling of moving forward, but we should also avoid opening too many tasks.
2.9 - Practice prototypes and workshops
Creating prototypes is a great way to get ideas down on paper. It is also a great way to make sure you and the client are in an agreement and aligned. As I mentioned earlier, often the client and you will have a different idea of the product. Let it be larger or smaller details, writing them down on paper forces us to discuss how they are going to be, which also creates some expectations for the customer. Now they have a better idea of what they are going to get.
2.10 - Be honest
This is more of a side note - but I cannot stress this enough. Having clean air between you and the client is the best way to go. Come forward if you are uncertain of something. You will find in most cases that they have the same worries as you. Maybe they had not thought of the problem you present. Sometimes there is no problem at all, and you can stop worrying right away. This also applies to the deadline, do not wait until the day before to tell the client that the product is not going to be ready.
That is all
That was everything I had on my list! Feel free to leave a comment down below with anything you would add or if you just enjoyed the list! :)