Software Project Management, The mission impossible, Part.3, The secret sauce…

kinopoisk.ru

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…

Trade-off triangle

Good Luck

Advertisements

Software project management, the mission impossible, Part.2, Challenging situation

tom-cruise-wait-who-s-coming-back-for-mission-impossible-5-now

In part.1 we described the situation as building a plane in the air, and mentioned some of the challenges we always face. Here we going to discuss some of these challenges in details:

Requirements are not clear.

Always happening, customer usually has a problem and usually does not know the root cause of it. In best cases customer can has a vision with defined objectives. When you meet customer stakeholders, everyone of them has a different story to tell, everyone has a different expectation. And you are trying hard to listen to all of them to form your own vision, or a common vision that can meet most of stakeholder’s requirements.

Requirements always changing.

Remember when we said in part.1 that:

” The best ever written requirement document represents only 80% of customer vision”

When you form your vision that you think is the most close to everybody’s vision and then start to develop the requirements, customer will continually gives you feedback  and ask for enhancements.

This is normal, Customer can’t judge the system without seeing it at work.

As a development team we have to consider that and accept it as a fact an axiom in software development domain. Resisting it will result in project failure.

Project is out of budget and time.

This is a logical result of requirements being changed all the time. Although the customer himself never stops asking for new requirements, but after a while he gets bored of the project, and sometimes he loses his enthusiasm and motivation and may cancel the contract.

Happened to me many times 🙂

No time for test.

If the project reached that situation, where requirements are not managed anymore, and project is out of schedule and budget, and customer is complaining, Development team usually sacrifices wit the testing time to deliver and get paid…

You can imaging what would happen next.

Time is spent on Junk.

An academic study in 2003 mentioned that

“53% of project requirements usually be cancelled as stakeholders found that these requirements are not of much value for the project, or the situation itself has been changed where they don’t need these requirements anymore”

“64% of requirements built are not used, and in best cases they use once a year”

On the personal level, i once had a project where we were developing a campus management system for a college. we build more than 120 reports according to the customer requirements. After we finished, and while we were monitoring the system at work, we found that only 10 reports are being used periodically, and more than 50 reports have never been used all over 6 years.

So,,, what shall we do ?!

In the next blog, i will follow with you best practices and learned lessons.

follow the blog to get it on time.