Understand the Players
It is important to enter a negotiation with an understanding of what the business or customer has at stake. What is driving the need for the software project in question? Is it necessary to keep the business afloat or is it a new product attempting to fuel growth in a new or expanded market? Determine whether time to market is a key driver or whether it is more important to have a feature rich offering. Also come armed with an understanding of which features the business considers critical to the success of the software and which ones could work their way onto the ‘nice to have list’ if necessary. The more you know about the business’ expectations and goals for the final product, the better you will be able to offer solutions that optimize satisfaction.
It is also important that the negotiator understand what’s at stake for the leaders engaged in the negotiation – which is not always the same as what’s at stake for the business. Is this someone who has rode herd over more than one unsuccessful project and needs desperately to have a win? Is it someone who is new to the company and wants to make themselves a reputation? Is there a personal angle to this person’s interest in the project – maybe it is their innovation or pet project. Understanding what the negotiator (or negotiating team) has to win or lose makes you much better equipped to know where the wiggle room might be. It is also good to find out beforehand what the negotiator(s) familiarity with software development projects is as well as his or her perception of their mastery in this area (these might not be the same). If the negotiator is a former software project lead, negotiations might go more smoothly because they understand the issues. Or the fact that it has been some time since they were in the trenches may make them insensitive to the complexities of developing software in the current decade.
Prepare a Strategy
Begin preparation by taking a good hard look at your estimate. Imagine that it is your job to evaluate the estimate and view it through the eyes of the person who is paying for the software. What aspects of the project would you expect to raise eyebrows? Identify these areas and be prepared to explain what it is about them that make them more effort intensive than intuition would suggest. Your understanding of the negotiators software development expertise should help in this exercise. For every potentially questionable or puzzling aspect of your estimate – be prepared with a credible explanation as to why it is the way it is.
Enter negotiations ready to educate the negotiator about the nuances, complexities and risks of your project. Examples of such issues might include:
- Team is using a new tool or technique – make sure they understand that even though they read a study touting 50% productivity increases in agile development projects (this is just an example – the author is not proposing to have evidence of this) this does not mean the first project for which your team applies agile practices will be any more productive than your last project. In fact, expect the opposite until the new tool or technique is institutionalized.
- Team has new members, either new to software development or new to the product or market.
- New technology or market – if the software being proposed is ‘out of the box’ for this particular team they need to understand that this increases the complexity of the project and increases the amount of time and effort needed to implement the software.
- Non functional requirements that push the state of the art. It may be the case that most of the functionality is pretty straightforward but that there are non-functional requirements in the area of security, performance, reliability, etc that will make their implementation more complex.
- Team is planning on including Commercial Off the Shelf functionality – while this generally tends to reduce overall effort and schedule for a project, it does not eliminate effort and schedule and activities related to the selection, preparation and integration of these capabilities, and is an important part of the project plan.
And the list goes on. There are many factors both technical and logistical that drive the costs for your project. Some of them are obvious and don’t require much discussion. It’s important to make sure that the less obvious ones are highlighted and understood. Additionally it should be made clear what, if any risks are inherent in the estimate based on uncertainties in the technology or the estimate itself.
An invaluable tool in negotiations is good historical data. As mentioned earlier, your estimate should be based on data reflecting the historical performance of your team, your organization or your industry. This same data can be used to sell your plan to the business. Having a good visual representation of this historical data – such as a scatter plot of previous projects – which shows your current project on or need the trend line is a great way to get across the point that this estimate was well thought out and informed by history. It may also be useful, though not always advisable depending on the circumstances, to come armed with evidence of past failures of the organization, especially if those failures can be linked to previously unsuccessful negotiations. If multiple methods were used to arrive at an estimate it is good to show how they are similar and be able to explain away any differences in a logical manner. In the absence of organizational data, industry benchmarks are available and should be used to show that your estimate is in an expected range.
Projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as scope, time, cost and quality. They are also used to define the Project Management Triangle, with each side representing a constraint and quality in the center. A passing familiarity with geometry tells us that one side of the triangle cannot be changed without impact on the others.
Understand and respect the Project Management Triangle, and educate your adversaries about it when necessary. Project managers understand the implications of the Project Management Triangle but still there is often a disconnect. To be more effective, organizations need a framework that respects the triangle and creates a trade space that brokers this negotiation – void of bias, emotion, optimism and personal agenda.
The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to the content that must be delivered to ensure the project meets the intended end result. These three constraints are normally competing constraints: increased scope typically means increased time and increased cost; a tight time constraint could mean increased costs and reduced scope; and a tight budget may require an increase in time and a decrease in scope. Quality sits in the middle of the triangle as a reminder that changes in each of the three legs can be made but as these changes are made the area of the triangle will be effected – in other words if you’ve shortened the schedule, even if you’ve made some cost adjustments as well, the quality may not be the same.
The Project Management Triangle is an excellent negotiation tool if it is understood and respected by both sides of the negotiation. A project leader is well advised to come to the negotiation intending to rely on the triangle. In his back pocket should be a set of well thought out cost/schedule/scope trade-offs that can be proffered if necessary. In other words – understand the cost and schedule implications of eliminating or down scoping the features or requirements most likely to be expendable. The ability to speak authoritatively about the various options coupled with visualization around the triangle lends a sense of credibility to the negotiation.