Dealing with Unexpected and Difficult Client Changes

In the world of Project Management, one of your principal duties is to manage client relations. Making sure everyone is fully aware of expectations and communication flows like the Danube is no easy feat, and it takes skill, patience, and experience. Oftentimes you may find that the client with whom you work does not always cooperate towards these goals in the way that you may like, leading you to label this as a ‘difficult project.’

Many things can happen with a project to garner this maligned moniker, and it does not behoove us to generate an exhaustive list here. For our purposes, a difficult project is simply one marked by any unforeseen event that does not cooperate with you and your timeline/budget for quality deliverables in the manner that you wish, thereby making your dealings with the client more difficult than you perceive as necessary. When we look at it this way, we realize the subjectivity of the matter in stark contrast to the very superlative and categorical ways in which we often think about them.

We are going to take a look at two very common scenarios that generate friction between the Project Manager and client, how they come about, and ways you might think about addressing them.

The client changes process

You have a process that you like to follow or have established in a custom manner befitting the needs and parameters of the project, but the client differs or strays from the process to suit unexpected needs, asks for other internal stakeholders, or for seemingly no reason at all. Oftentimes this is a sign that your client is lacking experience. Other times it is a sign that you have failed to either properly establish your process, or your client does not trust you. In any case, the question is, what to do about it?  

The first step is going to be to get the client to agree in principle with the need for agreement about what the process is and that straying from the said process should be avoided in all but the most extreme cases. Most people understand this intuitively, if not from past experience, making obtaining a verbal buy to avoid straying from the agreed-upon process a (hopefully) simple task.

Next, you want to open up the discussion to invite the client to voice their opinion about what changes they would like to see made. If you have reached this step it is because something impactful has happened which threatens the success of your project, and getting buy-in means compromise. Be careful and tactful in this discussion — understand that while what you want to achieve is important, you must be willing to compromise and the success of the project should be the guiding start for all decisions made, never ego or a simple personal preference. For a few other reasons, I would advise you to never look at overhauling your team process mid-project save for where it can be used to increase production efficiency. The more challenging aspect is to implement the necessary rigor to stay within the agreed-upon boundaries of your new process. If it was broken before, it becomes easier to do in the future. 

It is beyond the scope of this article to run down all possible scenarios, but a few things to keep in mind are:

1. These individuals are your partners, and neither you nor they are above the other. You must always balance what is best for the project with what the client is asking to be done.
2. The aforementioned agreement is your friend — stick to it closely and you will always have that to cite even when things get hairy.
3. Do not become obstinate and intransigent, be flexible and accommodative wherever possible, and cede small easy wins to your client with gusto, saving your credibility for push back where it really matters.
   

The client changes expectations 

Let’s first be clear on what we are talking about. We do not mean that the Acceptance Criteria of a ticket was changed, or the color schema for the app has been modified. We are talking about wholesale changes to functionality, budget, or time scope. Again this can happen for myriad reasons, from internal requests on the client’s side to changing marketplace to project progress not accelerating to the anticipated velocity. Regardless of the reason, it is important to recognize that this can and probably will be a defining moment of the project. Some clients will use this as an opportunity to try and push more responsibility to the dev team, some will use it as a chance to renegotiate the project terms, and still, others will use it for whatever ends best suit them. 

More responsibilities on the dev team, renegotiated project terms or reshuffling of the dev team are not by themselves bad things. But it is your job to make sure that whatever changes are made that you understand them and the impacts they will certainly have on the team, deliverables, and budget. Do not rush this, take your time to understand what changes are being requested, and what the knock-on effects will be throughout the project environment. You do not have to agree to anything during the course of one meeting; take your time and let the client know you will get back to them before agreeing to any changes. Use this time to consult with colleagues, and really consider what your preferences are and how best to achieve the goals of the project. 

Some things to keep in mind:

1. You can say ‘No’. Too often I have seen good PMs fall into the trap of trying to please their client and not recognizing the gravity that a request like this can have on all project areas, only to regret it later. Pushing back on the client is part of your job, and you are in no obligation to always answer ‘yes’. Keep the project goals first in mind, as well as the satisfaction of the customer, but do not be afraid to point out unreasonable requests or expectations.
2. Ask for help. Run the request by your team and colleagues, gauge their reaction to the request and take their input seriously.
3. Get it in writing. You should be documenting changes of all kinds from clients, and this is no exception. You want to be sure that this change is documented heavily so that you can come back and reference it should you need to in the future.
   

There is no such thing as the perfect project, but you should always be striving to make your communication and deliverables as good as you can. If you keep a calm demeanor and are paying attention to the day-to-day of your project, then you should be in a good position to begin to address these issues when inevitably they eventually come up on a project.

At Fullstack Labs we have a clear and defined process for development and always make sure to do what’s best for the project taking into consideration the clients’ wants and needs.