Professional Services Negotiations

Finding the Win-Win in ALL Customer-Facing Situations

This week on Rethinking Professional Services we tackled Rethinking Customer Negotiations (watch replay). In doing so I proposed a number of tricky customer-specific situations such as fixed fee versus time and materials, design stage sign- off and user acceptance.  While preparing for the webinar I discovered something interesting.

Almost all of my negotiating positions come from one single defensible framework. From this basic framework, I’m able to determine a stance on almost any negotiation point not just because I believe it, but because the framework is consistent from beginning to end which makes it plausible to those with whom I am negotiating. This element of plausibility from the ground up, is key to negotiating a mutually fair agreement.

I started to wonder if I could write it down and keep it short. I did, so here it is.

THE PS PRINCIPLES'

FRAMEWORK FOR PROFESSIONAL SERVICES NEGOTIATION™ 

1. We make money from the provision of an expert’s time to paying customers.
2. Our experts learn from both our investment in them as well as the time they spend in the field. What we learn, adds to our value and we have every right to retain it within the bounds of never possessing any customer-specific information.
3. The time our experts spend with our customers is either:
   1. “of value” in progressing the customer towards its goals; or
   2. “not of value” in progressing the customer towards its goals.
4. Time that is “of value”, should be paid for. Time that is “not of value”, should not.
5. Time spent achieving a substandard result should be fixed for free
6. The value of the time we have spent is validated by testing the solution against the specification from which it was built
7. Errors found in testing, within limits, are a normal part of the development process, however there is a limit beyond which we must consider how “of value” the time was.
8. Our job is to listen to the customer but to always lead as the experts. Our expertise is supposed to guide us to more success than failure.
9. Paying customer get priority on the assignment of resources.
10. We aim to maintain a resource assignment balance between under-assignment (producing low margin) and over-assignment (producing burnout).
11. Service Providers should never be working in a customer’s production environment because we cannot own the liability of any mistakes made within it.
12. The above challenges and risks are shared amongst all professional services businesses.
13. Failure to manage this framework will result in project overruns, rework, dissatisfied customers and experts that have no value and we will be unsuccessful in our endeavor.

1. Every customer must own the risk of changing their business. We are there to mitigate that risk, but we cannot own it.
2. The customer’s definition of what is required for success forms the project’s baseline (price, budget and scope). It must be representative of what is required in production.
3. Customers are usually not experts and as such they are likely to not understand the impacts of the decisions they are asked to make. This is why the service provider must lead and it is also why the customer is not always right
4. The customer wants the greatest possible outcome for the cheapest possible price. This is the demand of EVERY consumer and it is fair, but it is also dangerous because of 2c.
5. 2b, 2c and 2d combine to make the customer the largest variable in the “project success equation”. In other words, the impact of the customer’s behavior on the project’s ability to be successful is the largest element of the project that we do not know.
6. The customer has the most at stake. People’s careers are riding on the success of the project. This must be treated with care and reverence.

1. A project is a journey of discovery. At its beginning, we know the direction we are heading, but we do not know exactly where we will finish. Our project process is purpose built to define “Done” along the way in the most effective way we know (refer 1b).
2. A project can only ever contain one version of “Done”. That version of “Done” will change and become more detailed as the project progresses.
3. Project estimates are linear and imprecise. That means that even in Agile, the estimate includes the time to do something once (even a specific iteration) but is speculative until we know exactly what work needs to be done.
4. 3c extends to account for 2c which means the customer’s impact on the accuracy of the estimate has not been taken into account.
5. Projects are terminal by nature. They consume resources for every instant that they exist. As such, they cannot be placed “on hold” or “temporarily de-prioritized”. They are either alive and have resources (from both parties) assigned or they are dead, and they do not.
6. Every project carries a dangerous amount of risk for both parties. Hence, if necessary, projects must be dragged kicking and screaming across the finish line. The only good project is a “Done” project.
7. The parties’ project teams do not own the project. The project’s executive stakeholders do!

DOES IT WORK? LET'S TEST IT.

Let’s consider a typical, yet tricky, customer and service provider argument about a solution’s acceptance. For many service providers the customer’s argument that the solution does not do what they want, leaves them in a difficult position when trying to negotiate for increased funding to complete the work. This is because the customer’s argument, in isolation, sounds plausible.

Essentially, the issue is that after agreeing a specification with the customer, the service provider built the solution to that specification. But in testing, the customer is unable to validate the solution’s readiness for production use. Do you see the inconsistency with the framework? Many don’t.

If we step back and apply the framework, we might see it a little differently. In terms of the framework we could restate the issue as follows.

The value of our effort was not validated against the specification upon which we built the solution (violation of 1f) but was tested against the customers unstated requirements for the solution’s readiness for production (violation of 2b).

With regards to Fixed Fee or Time & Expense (or any other commercial approach) , the framework doesn't dictate one over the other. I would argue that the larger and more complex the project delivery method becomes and the more impact the customer's decisions have on the project, the more likely the market will push the service provider to a Time & Expense approach. With so many variables at play, a limitation in the upside will be accepted in exchange for limiting the downside (if ran properly). 

The goal of the framework is not to suggest one specific commercial model, project methodology or party to blame, but to provide clarity so that negotiations can be more effective in identifying the win-win.

CAN YOU PUT IT TO THE TEST YOURSELF?

I’ve picked an example that is usually considered tricky for parties to agree on. I think the framework allows us to present the problem with clarity which should, if the parties agree with the framework, help them agree to a resolution.

Can you apply the framework to other project situations? Are you going through one now? Does it help? Let us know how you go. Our goal with developing the framework is to begin a dialog on how we can position and negotiate common professional services issues with clarity. Which in turn, will help both service providers and customers achieve project success more often.