First of all, no one can say “I have the perfect solution”. We are not dealing with a mathematical equation where we can have an exact solution. Rather, we deal with human brains, we interprets thoughts. It is a human interaction that can possibly carry different meanings and hence different results. That is why we just provide you some best practices and learned lessons.

Actually, all agile frameworks and methodologies are somehow best practices and learned lessons. It only gives you guidance and let you choose your way freely. Here i will share with you some of my best practices and learned lessons in requirements negotiations.

1. Before you contract, just document the customer vision and high level objectives not the detailed requirements. we said in part.1 and part.2 that customer will always change the requirements and ask for new requirements, this is an axiom that we have to consider.
   As a development team, we usually like to have as much documented requirements as we can before we contract. We do that because.
   – We think that this will reduce future conflicts with the customer. Actually it will not 😦
   – We need to have more accurate estimation for project budget and schedule as early as we can.
   – This will help in building a robust solution architecture.
   It is good to have all of that, but documenting requirements early, will not result in that 😦
   From my experiences, i found that it is better to draw a frame for the project scope. what is inside that frame is accepted, and what is outside is not. The frame is defined by project vision, objectives, functional areas, system stakeholders and some high level user stories.
   “The vision and scope template of Microsoft frame work is a good reference”
2. Raise customer awareness of software development challenges, but after contracting.
   It is not wise when you first meet your prospect to tell him about the tough and challenging nature of software development. He will most probably search for another company.
   After you contract with your customer, start raise his awareness about the nature of software projects but easily and slowly. Don’t give it to him in one shot. Be smart.
3. Always Negotiate. Although in the vision document you defined a frame for the project scope, but still you will face many situations where you conflict with the customer about a requirement, wither it is inside the frame our outside it.
   When you face such situations, always think of the Trade-off triangle and negotiate based on it.
   – You have to make a trade with your customer about the new requirements. Ask for money or time.
   – Accept some requirements that are easy to implement without any trades, but after you negotiate it. Let the customer feel that he won the negotiations with you, and that you sacrificed for him.
   – In some cases when the customer is insisting on a requirement that is hard to implement, remind him with the situations when you sacrificed for him. This will make the negotiations easy for you.
   – Help the customer focus on high priority requirements and keep reminding him with project objectives…

Good Luck