Is negotiation part of the Project Manager’s role? It certainly is. In fact, without realizing it, the act of negotiating things on a project probably infiltrates just about every role occupied on a project…but it’s certainly most prevalent in the Project Manager role.
Reasons for Negotiation
Let’s take a look at reasons the need to negotiate may arise on an IT project.
- Out of scope work that needs to be included in current timeline
- Customer request for a different resource or skill set
- Customer training
- Budget issue vs. Timeline issue
- Functionality needed earlier than expected
- Data management issues and who handles them
The list can go on and on..these are just a few of the ones that I’ve personally run into on my projects. The issues usually fall into three different categories: Scope, Timeline, or Budget. All of those topics above, when looked at in detail, can be slotted into one of these three categories. For this article, let’s look closer at Scope Negotiations and how best to handle them with your customer.
We all know that scope issues can abound on any given project – especially if some loose ends weren’t properly tied up during the sales process. Again, my plug for inserting the Project Manager into at least a portion of the sales process. When I worked at Rockwell Collins in the late 90’s and early 2000’s and all the projects were internal projects for internal business units – I WAS the sales process. As was the case with all the PMs at RC, I handled meeting with the customer, documenting the business need, pricing the engagement and finalizing with the customer – and then presenting the proposed solution to a technology council for approval. Sorry…enough plugging for the PM role in sales…for now.
Back to reality. It will always happen that there will be scope issues. When the customer says, “but I thought that was included”, you have to look at it from their side as well as your own. Do some investigation. Maybe Sales told them it was included. Maybe the line was a little grey. Or maybe you can see some bigger work that is coming down the line on the project in terms of scope and now is the time to negotiate.
At any rate, it’s about the give and take. For most scope issues you’ll draw up a change order, identify the budget and timeline hits, and present the customer with what it is going to cost to add the additional scope. If they balk, there may be some room for negotiation – for example, price the implementation of the new functionality but throw the training in for free. Of course, you may need senior management approval for this – another form of negotiation, possibly. Explain the need for customer satisfaction, retention and referral or possibly your vision for some bigger add-on work that you can see in the offing.
Another issue that can lead to major scope concerns and the need to negotiate is the lack of previously defined customer business processes or poorly defined customer requirements. As the Exploration Phase gets underway, this issue really can come to light – if it hasn’t already. As the PM, this is when I look for the opportunity to negotiate with the customer in terms of creating additional revenue for the delivery organization in the form of a change order.
It’s obvious at this point of the project that (for example) a two week Exploration Phase is not going to cover everything that is needed. Explain to the customer that in order to properly document the requirements and create a meaningful Business Requirements Document (BRD), Functional Design Document (FDD) and ultimately a Technical Design Document (TDD), then more time and effort needs to be dedicated to Exploration resulting in additional hours and $$ in the form of a change order.
Explain that the increased effort added up front helping the customer define their business processes and requirements will result in a more solid solution being deployed to the customer at the end of the project. It shouldn't be too hard of a 'sell'.
So I discussed negotiations for Scope impacts on your project. I identified that issues requiring negotiations on projects usually fall into one of three main categories: Scope, Timeline, or Budget. Now, we’ll look closer at Timeline Negotiations and Budget Negotiations and how best to handle each type with your customer.
Negotiations on timeline issues can take on many forms. For me, the most common one has been the request for functionality to appear earlier than previously expected. While this can sometimes be a major issue depending on the project, I try to take the phased approach if it is appropriate. By this I mean, negotiating with the customer on implementing functionality in phases. To do this, I follow these steps:
- Review the request for functionality
- Discuss with the delivery team experts
- Re-work an alternate project plan to move the requested functionality to early in the timeline
- Document a narrative for the customer outlining what needs to be pushed to later in the project to make it happen
- Conduct a formal meeting with both teams to present the proposal
So, basically my proposal is usually to restructure priorities and move the needed functionality to an earlier point in the timeline, implement it, and create later phases for the remaining functionality. It may also impact the budget, but if it gets the customer the functionality they desperately need when they desperately need it, then they’re probably very willing to accept the budget it. They always have been from my experience.
The most common budget negotiations I’ve run into have been with either higher-priced resources needed or requested on the project or the need for some unexpected customer training.
In the case of the resources, if it is warranted by the project due to some undocumented needs by the customer, then I’ve often been able to ‘sell’ the customer on the higher-priced resource. If it’s the other way around – meaning the delivery organization wrongly assessed the resource needs, then the push needs to be to get senior management to agree to give your project the more skilled resource and bill the customer the same lower rate. As the PM, you still need to explain that to the customer – never miss an opportunity to gain additional customer satisfaction by letting them know you’re always fighting for them.
In the case of the customer training – I’ve run into this several times. And it doesn’t have to be customer training – you can insert any one of a number of similar items here. But for me it’s usually been customer training. The customer hasn’t realized the need for some training (usually due to a communication issue during the sales process), but it’s still needed and it isn’t cheap. Work with the customer and determine options. For me, it’s worked well to coordinate with both the customer and the training department to price a training session onsite for the customer rather than have the customer send everyone to the training department. This results in significant customer cost savings while bringing in new streams of revenue to departments in your own organization.
For the most part in this series I’ve dealt with customer negotiations. However, the need to negotiate also comes up regularly in your own organizations as you work to obtain resources, equipment, budget, etc. The good Project Manager draws on experience from a history of customer dealings to enable them to effectively negotiate for things on their project with everyone involved in it.