,When talking about negotiation on software teams, often we are referring to how to handle ‘change requests.’ Let’s look at a few strategies you could consider using when a client is asking to add a feature to a website or an app which was not in the original project scope.
In the video below, Derek talks about these three strategies on how to approach work-related negotiations:
As the strategies discussed in the video (on YouTube) are related to generic situations anyone could face, below the video, I will share some examples of how to apply these tips specifically to discussions with clients who request changes to their deliverables.
Typically, the client has a reason for asking for something to be added or changed. Though our initial internal reaction may be to cringe and say no (it’s not in the original scope!), it may be wise to take a step back and find out why the client is asking for this. Typically, clients (or anyone, for that matter) have good reasons for asking for changes. Let’s look at three ways you can take the perspective of the client that can build business relations while helping everyone to save face:
When exploring the reason behind the change, keep in mind the technical expertise of the client. I have consulted with US client-facing dev teams who have applied these techniques only to find out in the exploration conversation that the addition the client wants is actually already a feature to be added to the website, but the client did not really realize it because it was different or did not look as they have seen it on other websites, etc. Or, in other cases, they were able to talk with the client to adjust features already in the scope of the project to the enhanced requirements the client requested. In cases where the client lacks the technical expertise or doesn’t know technical jargon, it’s going to be critical that when describing these details to the client, that you as the developer have the verbal agility to describe technical concepts in everyday English (this is something we help you to achieve). Remember clients come to you for your technical expertise, so use your consulting skills to your advantage!
While it’s critical to understand the technical aspects of any project, it’s equally important to understand the client’s business and related outcomes they expect from this project.
It may be helpful to ask any of the following questions:
If you can talk to them in their business language, the client will relate to you easier and realize you are taking the time to understand their deeper needs that extend beyond the technical solution. When you are able to do this, this may lead to more projects from the same client, secure support contracts with the same client or could bring additional business from new clients from client referrals.
Now that you’ve established your technical expertise and an understanding of the client’s business domain, don’t forget to get to know who your client is as a person. I also always advocate for building a ‘personal relationship’ outside of the business relationship through the use of small talk. Making small talk with your clients can help you to understand their mood, temperament and reactions in a way pure business talk does not. Read more about how small talk can improve client relations on global projects.
When hearing this tip, client facing developers may think this doesn’t apply to them as this seems to apply to the sales or contracting team. While it is true that this does happen during initial contract negotiations, this strategy can come in handy during projects as well when negotiating timelines, resource management, change requests and more.
In some cases, the client will ask for more than they want, need or can practically get from the scope of the project. However, when your team negotiates with them, using some of the above tips, it’s always handy to keep in mind that a change request not only means a change to the output or final product, but how your team manages their time and resources. It is wise, if and when needed, to ask for time to assess how your team can apply a change request and the additional time or resources that may be needed to make it happen.
In some cases, you may be able to blame your project manager or contract for the no. Depending on your team dynamics, the Project Manager could the final say for any and all changes.
Additionally, depending on the technical scope of the project, sometimes a no can be blamed on the technical parameters of the project. In such cases, the client would be looking to your expertise and knowledge as leverage to back up these claims. In such cases, it may be wise to not only explain the technical limitations, but suggestions for alternatives that could work in it’s place, and the pros and cons of these alternatives. Back up your claims with technical case studies in addition to knowledge of how the alternatives fit into their business case or user profile.
Jennifer Kumar, author of this post, is a solution-focused trained coach that specializes in cross-cultural working on virtual teams with US clients. Take a look at our programs, Managing Client Expectations or Deliver Impressive Status Updates. We work with individuals and teams.
Original post: Sept. 2013, Updated: April 2019, April 2022
Find your ideal program in just a few clicks.
Select Industry > Learning Level > Skill, to see 1-3 suggested programs.