In a previous post we discussed Fixed Price vs Time and Materials today I would like to add two other options to the discussion.
Service Level Agreements and Transaction Based Model.
In a Service Level Agreement (SLA) or sometimes referred to as service level objectives, you are designing a contract that is guided by the level of support you are brining to the table (% up time, time to response and resolution among others). In this model the client doesn’t care directly how many people it takes or the cost, but just wants to know their set cost to reach this minimum level of service as defined. This usually has a bonus and penalty around service level delivery. I really like this model for supporting steady state, maintenance, infrastructure and a few other areas. It can get very tricky. You have three levels of SLA:
- Service – an SLA that covers a service like web hosting or email that
pertains to a large audience and multiple customers. Relatively simple
to come up with moderately easy to manage and track. - Customer – an SLA with a customer segment – HR or Finance, where you are handling multiple specific services for that specific group
- Corporate level – this usually encompasses Service and Customer and multiple service levels.
One of the challenges that Project X see’s over and over with SLA based models is the client’s ability to monitor those SLA’s is often at the mercy of what the vendor tells them.
The benefit of the above three levels of approach, it gives the client to manage size and complexity. They will still need to put in governance and process to be able to come up with their own version of reality to compare to the vendors.
An emerging and interesting model is the Transaction Price Model:
In this model the vendor agrees to a set cost per transaction (per invoice processed, per call, per return, etc) where the people, process and technology are brought together as a set cost to the client. This creates some great opportunities for organizations who want to create scalable and set cost structures or when the internal processes and technology may be broken.
In this case the vendor is incented to do process improvement or bring best in class process, people and technology to hit their required price points. In this model, you can have bonus and penalties based on length of time to transact, accuracy and so forth, but this model is often easier to manage as long as the process and transaction is well set.
Both of these models largely move up the value chain well away from a commodity time and materials into more value added services. But both of these call for stringent contracts, communication and controls. Otherwise, you have just made it harder to know what you are getting and whether the intended value is achieved. I think that as we start to evolve service oriented architecture these models will be of great value.
