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’.
I’m not sure any of us really thought we’d be negotiators when we entered into the PM field. But it seems to come up regularly on projects. We’ve examined Scope Negotiations in detail here. In the next article on this subject, I’ll discuss Timeline and Budget Negotiations and look at examples of each and how to deal with those both with your customers and within your own organization.
This article was authored by me (Brad Egeland) and originally published on the PM Tips blog site here. It is being used with permission.