Every developer or project manager has been in this situation. You are just about to finish a feature. 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 might feel slightly annoyed. You just thought that you were about to be done. Now you seem to have been kicked back to the starting point. You cannot really blame the client for this.
Now you ask yourself, how did I end up in this situation? First we will have to look at why you ended up in this situation.
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. The client might be in a different timezone than those who develop the project.
On some projects, people are so eager to get started that they forget to plan it. I have seen this multiple times. The parties think they have agreed on what should be done. They could leave the meeting room with two different ideas of how the product should be. Which leads to confusion if they do not work closely together.
Remember that communication requires two people.
It might also be that the right questions have not been asked early in the process. Asking the right questions before starting is tough. It is something that comes with experience. Some of the biggest pains come when you make too many assumptions.
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.
Sometimes we and our clients get lost in technical details. We end up with a technical error that we did not or maybe could not have foreseen. This automatically forces us to make some changes to the product. Therefore 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.
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 the communication (or other things).
It might also be that the client simply got a new idea along the way. This is not a bad thing. As long as you tell what the consequences are. Whether it is delay of the product or more money needed - depending on your contract. Clients who bring ideas and are engaged in the development often tend to 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 about causes for change requests. 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 project 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. 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 are the contact's motivation for the project? A contact's motivation can be Everything from "just overseeing" the project, to have a bonus depend on it's success.
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. If you do not know what the goal is, then you will not know if you have missed it.
Sometimes poor communication does not lie within the task at hand. But in the fact that the long-term goal is not known.
2.3 - Do reviews often
This topic is very culture depending. If you are in a large business you might be drowning in meetings. Whereas if you are in a smaller company you might have too few. I will not debate the benefits/drawbacks of meetings here.
Presentations can be done on many levels. Anything from full scale meetings to a simple screen-sharing phone 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 check in and ask what the client thinks of this. This is also the perfect time for feedback. But always distinguish between change requests and what has been agreed upon.
2.4 - Agree on deliveries
Of course you will have your long term delivery 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 to come. This will also give the client a chance to reprioritize if there has been a change in prioritization. Otherwise you might be ending up with 2 different ideas of what you will be delivering.
- 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. Requirements can also be misunderstood or misinterpreted. Ask when in doubt!
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 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. This in return will tell them 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. 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 have their own 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 - 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. 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 it down on paper forces us to discuss how it is going to be. This also creates some expectations for the customer. Now they have a better idea of what they are going to get. It also creates something physical that can be hold in your hands.
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.
That was everything I had on my list! If you feel that I missed something then please contact me - or you can leave a comment in the comments section below :)