How to discuss assumptions in proposals to your benefit

The ubiquitous Assumptions section

Each IT proposal has a section towards the end – just before the financials and pricing, there is a small section with a list of assumptions on which this proposal is based on. And when it comes to the discussion table, both providers and IT buyers fumble with how to deal with this section. From a provider’s perspective, this is their way of setting down the boundary conditions of the solution. It is their way of offering a solution that is based on certain parameters which if fulfilled will enable them to deliver the solution they have designed.

Should you remove Assumptions?

Well, yes – but not without a discussion.

From the other side of the table, assumptions look scary. All you see are hidden data points and conditions which can suddenly increase the price if this is not either discussed away or controlled. And the result is predictable: Often contract negotiators try to remove all the assumptions so that it comes down to a contract sans assumptions. I am not advocating making contracts with assumptions. But should you seek to remove blindly? That would be wasting a hidden opportunity to have an in-depth discussion that benefits both parties. But how do you start this discussion?

Question mark

Divide and Focus

First segregate the assumptions. There are multiple types of assumptions – there are those that have material impact on the solution since they drive the entire effort of the provider, and those that simply lay down the financial conditions on which the price is based (e.g. handling of lodging and travel costs). Focus on the ones that shape the solution or refine the problem definition.

Don’t insist on removing assumptions without understanding the impact – because the only way the provider can remove assumptions is to price it into their solution.
Discuss each of them using the following questions:

  • What is the basis of this assumption? How does this impact operations?
  • What happens if this assumption is proven wrong?
  • What happens if a value increases or decreases?
  • Who can control this value? what are the means of controlling these values?
  • What can either of the two sides do to control these values?

Have this discussion dispassionately without first assigning responsibility – after this find out which party can control this risk best – this will give you the optimum balance between responsibility split and price.

Can Assumptions help you?

  • Often assumptions can lead you to finding a solution to your problem.
  • If you release a list of goals that you want to achieve and ask for a solution – you will get a solution that is driven by assumptions.
  • Such assumptions are not a nuisance – use them wisely to bring more refinement into the definition of the problem, or the enrichment of the solution depending on which side of the table you are sitting on. More on this topic in this article on Request for Solutions.
  • A smart provider should also think of using assumptions to coach the IT buyer – but they should not do this by talking down to the IT buyer
  • A smart provider should coach the IT buyer into what should be added to the problem, what they have potentially missed, what they should be demanding in addition. Believe me, IT buyers value this coaching as it shows them that you are thinking for them.
  • Use this discussion to find out where the buyer want to draw the line to split the responsibility.

Assumptions work both ways

IT buyers should not stop at only discussing assumptions that the provider has raised. They should create a list of assumptions of their own as the solutioning dialog progresses. Use these questions as a kick-start:

  • What are you taking for granted?
  • What are you being promised? How can you verify this for yourself?
  • What assets are you relying on? What are these assets performing that will be useful to you?
  • How can you check and measure that this is actually the case?

Now use these assumptions to drive due diligence on both sides. Giving each party the possibility to check the assumptions will go a long way in avoiding any conflict situations after the contract is signed.

In summary

Often the actual persons that are available during the contract phase on both sides (the deal team on both sides) leave after the contract is signed, and this is then handed over to the delivery team on both sides. Discussing the assumptions on both sides, and documenting the results of the same by baking it into the problem definition or into the solution will bring the required rigor into the contract.

The parties on both sides that are forced to live the contract over the next five years will thank you for it.

photo credit: Marco Bellucci via photopin cct

The 5 Pillars of a successful Outsourcing Contract Pricing Model

Your organization is demanding more transparency in your Outsourcing operation and contract. The onus lies on your ability to study your operation and define your reasons for outsourcing. Then design a contract with your service provider in a way that you achieve the quality you need while forming a partnership with your service provider.
This post summarizes my last few posts of September and brings it together into the best practices that form the Five Pillars of an Outsourcing Contract Price model. The Five Pillars help you to model your operation into the pricing model – and can form the foundation and definition of your contract.

“STEER”ing your way to a successful Contract

The basis of a successful partnership with your service provider is a well-designed outsourcing contract. A successful contract stands the test of time if its pricing model is designed well. You can judge a pricing model by the way that it satisfies the following five best practices that I summarize with the acronym STEER (Scalable, Transparent, Encourage the Right Behaviour, Elastic, Risk-balanced):

5 Pillars Best Practice Outsourcing Contract

The 5 Pillars of a successful Outsourcing Contract Price Model

  • Scalable to handle Future Scope: the model should scale and accommodate all kinds of changes to the application portfolio over the duration of the service contract.
  • Transparent and Granular: Establishes a price per application and makes the price effect of each service easily calculable and transparent.
  • Encouraging the Right Behavior: the pricing should encourage good intent and reward good behavior from the service provider.
  • Elastic – the model should be flexible and breathe with the business and, at any given point of time, should reflect the effort required to provide the service.
  • Risk-balanced – the model should allocate operational risk to that party (IT Department or Service Provider) that can mitigate the risk best

Has the STEER model helped you?

Are there parts of your existing contract that you want to change after reading these posts? What will you do differently the next time?

The tricky balance of risk in your IT Outsourcing contract

Many Application Services Pricing Models today are skewed in terms of Risk-Modelling. The balance of risk between the service provider and the procurer of the IT Outsourcing services is usually lopsided. And this imbalance gets factored into the price. Is there a way to avoid this?

Today we look at Best Practice #5: Balance the risk in your Pricing Model

Balancing the Risk

There is no free lunch in Pricing Definition

An imbalanced risk leads to one of these two situations:

  • One ends up paying more than what is required for the service, or
  • one finds oneself in constant service management escalations arguing about who is responsible for ensuring that a certain thing happens.

Example: a standard T&M model keeps only staffing risks on the side of the provider – while this might be the desired mode of operation for some situations, this transfers a huge portion of the operational risk to the buyer. There are many situations where one would like the service provider to take over some of the execution risk. However if you ask a service provider to price in elements that he cannot influence, you are forcing him to add a risk premium. This is not always the wisest approach.

Operation Risk should be baked in where it belongs

The golden rule – Allocate risk in the pricing model in a way that the party who can best control the risk deals with it. If your requirements are volatile, do not try to bake in fixed efforts into your pricing model – there is no free lunch. Your service provider will recognize this risk and is forced to add a risk premium to his price.

If the dimensions of your service vary across time, do not demand a flat rate for the service. Instead model the varying dimensions so that you can specify them. At the same time, dimensions that constitute execution risk can be shifted towards the service provider in terms of a flat rate or fixed price.

In summary

Over the last five posts, we looked at the best practices of designing an application pricing model.

A best in class Application Pricing model has the below five characteristics:

Scalable to handle Future Scope: the model should scale and accommodate all kinds of changes to the application portfolio over the duration of the service contracts
Transparent and Granular: Establishes a price per application and makes the price effect of each service easily calculable and transparent.
Encouraging the Right Behavior: the pricing should encourage good intent and reward good behavior from the service provider.
Elastic: the model should be flexible and breathe with the business and, at any given point of time, should reflect the effort required to provide the service.
Risk-balanced: – the model should allocate operational risk to that party (IT Department or Service Provider) that can mitigate the risk best

Incorporating the above five best practices will go a long way in creating an Application Services Pricing Model that serves you well throughout the duration of your contract.


Have you incorporated the above in your Application services contract with your service provider? What has been your experience so far? How did you design the pricing definition in your IT Contract?

photo credit: Julia Manzerova via photopin cc

Can your IT Outsourcing Pricing Definition flex to the demands of your service?

A pricing model derives its elasticity from the scope of service being offered. The scope of services in turn derives its dimensions from the Application Portfolio for which the Outsourcing Services are designed. So how does one go about building this elasticity into a pricing strategy?

Best Practice #4: Your pricing definition has to be elastic to fit the various combinations of services across your portfolio.


Each Application Portfolio is unique. The service combinations across the usage of an application portfolio should be analysed keeping not only this in mind, but also the needs and spread of the user community.

If I had to summarize my approach to explore the elasticity demands of a service for an Application Portfolio, I would recommend the following steps. These steps are not necessarily sequential but rather iterative.

Step 1: Explore the dimensions of the Application Services

Analyse the dimensions which formulate the service. Typically these are the depth of the service, the hours of the service, the kind of service required, the days in which service is required, the regions of the world that have been supported, the languages being spoken etc.

Step 2: Analyse the parameters that define each dimension

Analyse the parameters that define each service – if you consider service time, check whether service is needed on holidays are not; check if the service distinguishes between regional and national holidays etc.

Step 3: Define the basic mode of service

After the above two steps, define the absolute basic mode of service across all the dimensions using the parameters. Establish this basic mode of service as the minimum scope definition. To continue our example, you might find that the basic mode of service is management of incidents from 9am-5pm on weekdays central European time. Feel free to include the IT Service Company you have or plan as a provider in the discussion.

Step 4: Design the add-on modes of service

Now study the service consumption across the regions, and user communities. Configure the rest of the parameters into add-on modes that make sense. In our example from above, you might find a community of users in Singapore and Thailand using a third of the applications in the portfolio. So you would design an add-on service that covers these working hours. These parameters would be additionally “turned on” for this part of the application portfolio.

Following the above steps would help you define a parameter & dimension system which will represent the elasticity you have in the service today. If these are now baked into the pricing model you have with your service provider, you will have a system that automatically ensures a close linkage between the ebbs and tides of your service and your pricing model. IT Outsourcing trends are also showing a movement away from traditional models into such elastic models.

Elasticity is only one of the areas you need to design into your pricing model. Refer to my previous posts on how to also design for scalability, transparence and encouragement of the right behaviour.

Next Post: Best Practice #5: Balance the risk. Stay in touch.

Is your current pricing model elastic? Have you defined the elasticity in the services that you require? Will your pricing model survive the duration of your contract?

Encourage the right behavior from your IT Outsourcing Service Provider

The long term success of your IT Outsourcing Contract and the accompanying Application Costing model lies in your ability to design it in a way that it encourages the right behavior from your IT Outsourcing Services provider. This is easier said than done.

In my previous posts, we have seen that an application management pricing model should be scalable, and transparent/granular.

Now we look at:

Best Practice #3: Encourage the right behavior from your service provider for Application Management.

220/365 [My name is Rubbish, Rubbish Bin]


Required behavior has to map directly to the interests of your Provider

  • Your Application Services pricing model should encourage the right behavior with a provider.
  • The right behavior can only be encouraged if you take the providers interest into consideration
  • You must consider that a providers interest is to either increase revenue or margin or both. The conclusion being that the only way to encourage the right behavior on the long term with a provider is to see that his interests are worked into the model.
  • You could argue and say that the right behavior can also be encouraged by strict SLAs and a penalization scheme. However if this is done in an unbalanced manner, this can backfire with other consequences. E.g. a strict SLAs on a ticket resolution time can encourage the provider to manipulate the system to see that the number of tickets increases and the percentage of easy to resolve tickets increases so that the SLAs are met.

Map the Outcome and not the Input

  • Be careful to interpret and express the behavior you want – this should be expressed as an output that should be achieved, and not the input that goes into the system.
  • Therefore develop your Application Services pricing model based on outcome-based metrics and not input metrics.
  • This might sound obvious and intuitive at first – but you will be amazed at how many contracts are based on ticket-based pricing models.

Ticket based pricing for Application Management can backfire

  • Ticket based pricing models sound attractive at first as it creates the illusion of a flexible outflow of cash as opposed to a fixed price contract.
  • But tickets are an input based metric – if you pay a provider based on the number of tickets he solves, you should not be surprised when the number of tickets in your operation increase or at least not reduce. Do not encourage the provider to increase tickets…..rather encourage him to reduce them.
  • Distinguish between effort drivers and outcomes – your pricing model will have to be mapped to effort drivers but do it in a way that you encourage the outcomes.
  • So this means let your provider baseline his efforts based on the number of tickets today, measure him by the reduction of tickets, reward him by giving him the opportunity to redirect any saved effort in other value adding activities – like new implementation efforts. Don’t let your provider lose revenue in this way – as you will pay on the long run anyway.

Have you implemented pricing models in your organization which encouraged the right behavior? Did they succeed or fail? And why?


Next –  Best Practice #4 : Your Application Services Pricing model should be elastic. Stay tuned!

In this series, see also:

Best Practice 1: How to design a scalable IT Outsourcing contract
Best Practice 2: How to design a transparent and granular Pricing model


photo credit: Jiuck via photopincc

How to design a transparent Application Management Services pricing model

Best Practice 2: Your IT Outsourcing Contract should be transparent and granular – and this should show in the pricing model

Transparence and granularity in an Application Maintenance contract directly translates to a price per application. An ideal model goes further and prices the service depth required on the application.


Let’s look at transparency and granularity from various viewpoints to understand the needs of the design.

Viewpoint: Application Business owner

  • In the midst of signing a maintenance contract for an Application portfolio, the effect of the contract on an application should not be lost.
  • While a total price might make perfect business sense from the perspective of portfolio management, there are business owners who use and sponsor these applications. The pricing structure should be able to translate the costs and benefits of the entire portfolio bundling program to an individual application.
  • Else such an overall program could be stalled by the business department which feels that the costs to its applications have not been correctly allotted.

Viewpoint: Application Maintenance Contract Manager

  • A granular pricing structure – which means applications are either priced individually or according to a scheme that is laid down – greatly eases the job of a contract manager.
  • Granularity should go beyond just price for application and also model the various ebbs and tides that the service could take. Explore all the dimensions of your service whether it is service depth or service time e.g. some applications might need only level 2 support, other applications might need 24/7 support.
  • The more granular your model, the less discussion the contract manager would have while discussing portfolio changes during the contract duration.

Viewpoint: IT Procurement

  • Valuable procurement bandwidth can be saved if all service conditions are laid clear and separately priced in the form of factors.
  • Procurement can then concentrate on the larger ticket items and leave the management of the pricing to the contract manager of the application portfolio.

Viewpoint: CIO

  • A CIO will normally highlight the overall savings that have been achieved through the clustering of applications into an overall application portfolio.
  • However, he also has to demonstrate these savings to individual business departments – and showcase the overall benefit that they have achieved by taking part in the clustering program. He needs their support.
  • A transparent and granular pricing system serves such a cost allocation in a seamless manner. No more clumsy Excel sheets as an after-thought.

Effort put ahead of the curve in defining a transparent and granular pricing system, calibrating your application portfolio against it, and signing contracts based on this pricing system will go a long way in keeping the contract and change management smooth and frictionless.

Next –  Best Practice 3 : Encourage the right Behavior – stay tuned!


In this series, see also:

Best Practice 1: How to design a scalable IT Outsourcing contract

For a background of this topic, see:

The hidden inflexibility in IT Outsourcing Contracts
Are outsourcing pricing models skewed towards service provider needs
Do Standard Application Pricing Models really cover today’s needs?

photo credit: marcomagrini via photopincc

Wordpress SEO Plugin by Wordpress SEO Plugin