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.
- 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”
- 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.
- 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…
If project management is difficult, then software project management is more difficult. Actually, it is exceptional. Software development teams are usually trying to figure out a situation, analyze problems in this situation, listen to stakeholders, try to figure out stakeholders vision and thoughts about the optimum way to deal with that situation. Development team should translate outcomes of all these inputs into a running software program that works properly and solves problems.
Software development team deals with a customer vision. A vision that is not even clear and well defined. Customer only realizes that he has a problem, but in most cases, he does not know where exactly the problem is. As a result, customer always updates his requirements with time.
Software development team tries to figure out this vague vision and document it. Then works on developing a solution using technologies that keep changing every day!.
The customer environment and infrastructure is also hybrid, different running operating systems with different software solutions that are based on different database engines. And it is required that the developed system works in harmony with this hybrid environment.
And in most times, the customer has limited time and limited budget….
EDS once had a commercial that exactly explain this situation…
Yea, Software development team are actually building a plan in the Air!
Think about it:
- Vision with vague requirements.
- Requirements keep changing.
- Tools we use to build the solution keeps developing.
- Solution need to be built while customer is running.
- Solution need to be installed in a hybrid environments.
- limited time and budget.
In order to succeed in software project management, you have to deal with these mentioned issues as facts and axioms, do not ever try to resist them, deal with them … Good luck
in part.2 of this article we will discuss samples of situations a software team would face with customers.
In software development projects, one of the most hated sentence by customers is when you say to him “This is a new requirement” … when we say this sentence -as a project manager or business analyst- we usually wait for an unexpected behavior from the customer 🙂
Actually both hate it, the customer and the development company. Customer hate it because it -definitely- means extra cost and time !.
The development team hate it for the following reasons:
- Project manager knows that he will get into a lot of arguments, debates, and negotiations with the customer and the development team lead about the new requirements.
- Team leader will check if this requirement needs a major or minor changes in the system architecture. Major changes mean higher cost and also some team depression.
There is a rule in software engineering saying that
“The best ever written requirement document represents only 80% of the customer vision”
I strongly believe in this rule and i consider it one of the axioms in software development, and one of the major reasons why agile development methodologies are introduced.
Development team has to deal with this rule as a fact. Customer always asks for new requirements. This is normal, and it happens all the time. Team should think how to deal with it rather than resisting it. Team should have tactics and best practices to deal with it.
One of the management tactics i followed over years, is to manage the customer expectations and psychology. I want the customer to get used to this sentence, not to hate it. Customer should be aware that we develop his ideas and thoughts, we help him get these thoughts and ideas into real life. As a result, each time he sees part of his ideas come real, he will have comments, feedback, changes and enhancements.
Also we will let him know that not all changes require extra cost and time, but in all cases, we should fill a new requirement form. We want the customer to get used to this document and this sentence too. So when you come at a time and ask him for extra money or time, you have something to negotiate with, as you did him a lot of enhancement without any trade-off.