A Milestone is an Output, Not an Outcome!

Do you hear the words “I don’t care how you do it – but we need the job done.”, as a bottom line for the projects?

Is your procurement department or your IT vendor misinterpreting the Outcome-based contracting model?

Are you not getting the expected business results from the Outcome-based contracts, although your vendor had promised that it will?

Do your procurement teams have a right mental model to leverage Outcome-based purchasing method?

The answer to these questions will help you distinguish the ‘Eyewash-Outcomes’ and ‘Business-Outcomes’, and apply the mental models that are necessary to get optimal business value from the Outcome-based approach of delivering IT projects.

There are a lot of interpretations and practices about the contracting methods that the procurement departments and IT Vendors leverage to carry out the IT projects.

#NoOneSizeFitsAll - Context is the new oil!

Play to your strengths!

source: https://blog.gardeviance.org/2015/02/on-government-platform-purchasing-and.html

Each method depicted above, has its own merits and the context in which they can be applied effectively. Simon described these purchasing methods and the appropriate contexts, in this article.

In my post ‘Traveling towards the business outcome!’, I have described how a seemingly T&M project may actually be a good fit for an Outcome-based method.

However, I have noticed a discrepancy in the interpretation of 'Outcome-based' method, which inspired me to write this article.

The traditional and standard practices of T&M are being challenged to deliver the ‘outcomes’, while the discussions are majorly focused on the system requirements, instead of business outcomes.

The customers realized and expressed the necessity of tying the efforts from IT vendors to the outcome, in order to get the value for their money. To adapt to this pressure, some IT vendors are force-fitting T&M onto the Outcome-based method, and selling the ‘Milestones as an Outcome’, while the T&M meter runs between the milestones or T&M becomes the basis of the Fixed Price paid in parts upon achieving the pre-determined milestones. One immediate constraint that can be identified, is that there is very little scope and incentive for introducing a change in the path, once the milestones are set. The focus is more likely to remain on achieving the milestones, rather than reflecting or critically evaluating the direction, and course-correcting along the way.

There is nothing wrong in the approach of considering milestones to hold IT vendors accountable for their work, if it works well for the customers and the IT vendors in a given context. However, it is critical to note that ‘Milestone’ is not an outcome, it is an output!

Completing a website could be a milestone, but it is not an ‘outcome’, let alone the term ‘business outcome’. The business value would be realized when the intended business outcomes are realized after the users leverage the website as intended.

The intention of building something may not be very clear sometimes, but it does not mean that it cannot be figured out through further exploration. In fact, if someone thinks that they need a website, then they must have already got a good reason and an intention behind it.

We don’t start with ‘Lets build an App’. We start with a problem and a solution. The application is part of a solution. While some of the heavy lifting on solutioning and architecting may be done by the in-house IT department of the customers, there is always a chance to challenge that approach with IT vendors when engaging them in the implementation phase.

The need for customers to ensure accountability from their IT vendors, have forced Vendors to superimpose the T&M pricing onto the Fixed Price model, and package it as Milestone-based Fixed Price contracting model. This is especially prominent when an explicit timeline is set for the project and scope is well defined. The calculations under the hood of such a price quote for a given project timeline and scope is still T&M.

While this approach may be beneficial for customers, there is a possibility that they may be missing out on a potential to achieve more from the endeavour, due to the constraints of the Fixed Price model that do not incentivise the IT vendors to go above and beyond the expected output!

What is the litmus test for an Outcome-based project?

If the stakeholders (including the customers and IT vendors) are consistently focused on the business value, while they work towards creating and maximizing the business value through a value metric, then it is truly an Outcome-based project. Everything that they do, should revolve around the business value that they are trying to create and maximize.

What is a Value Metric?

A measure of business value. It must be measurable, and has a correlation to the profitability of business. It is NOT a reflection of Output or a Milestone. A Value Metric must correlate to business value, otherwise it will become a Vanity Metric. Ex: In Scrum methodology, the Velocity of a team is NOT a Value Metric. The story points are sold as value, but actually, they are a reflection of efficiency of the team, not the effectiveness. Your team may deliver 100 story points or have an average velocity of 60 story points, but it may not yield a meaningful business outcome.

The challenge is to articulate the purpose and business value of the endeavour and reflect upon the worth of doing it.

The Outcome-based contracting method is strong towards custom-built and early product stage. As the product moves towards majority, the Fixed Price / COTS approach becomes stronger. As the product evolves further, to become a service/commodity, the Utility-based pricing is more applicable.

I have attempted to map the essence of an Outcome-based project using Wardley Mapping technique.

N.B. If you are unaware of the concept of Wardley mapping, then you may take a course from an amazing teacher of Wardley Mapping, Ben Mosior @ https://lwm.events/gofast. If you have patience too, then you may also read the book from the inventor of Wardley Mapping, Simon Wardley @ https://lwm.events/book.

In the Map below, I have added T&M and Value-based pricing as two methods that can be used at appropriate stage of the development cycle. Considering that the project is built from the scratch and the requirements are not very clear in the initial stages, it makes sense to build it using T&M and course correct along the way. However, the real value is in operating the systems to achieve meaningful business outcome.

We can improve IT, only if we can measure IT!

The map above, depicts high-level components that are needed to for an Outcome-based procurement.

A customer needs to make profit from their IT efforts which are expected to generate business value, and can be measured using a Value Metric. As a result of those efforts, the necessary software solutions are developed (not necessarily built from scratch). The Value Metric is a result of Exploratory Sessions.

Exploratory sessions are focused towards,

1. Knowing the users, customers and other stakeholders and focusing on their needs.

2. Relentlessly challenging the assumptions with an open mind, and remove bias and

duplication. Challenging the existing business process is a good example.

3. Knowing the details. having systematic way of learning, with a bias towards data.

4. Understanding and applying appropriate methods based on the context.

Exploratory Sessions are NOT meant for requirement gathering, requirement analysis or estimation of efforts.

To build software systems, the customer may need IT Vendors and need to pay them for their work. However, the pricing models must be carefully chosen by the customers. While it is lucrative to do T&M and then have an Annual Maintenance Contract (AMC) in place or Fixed Price with Milestone-based payments, these models do not incentivise the IT vendor to go above and beyond the expected output as defined in the output/milestone focused contracts.

The business value is NOT in building the systems, but in operating them to satisfy user needs which are considered valuable, for which the users shells out their money.

The T&M with AMC/ FP with Milestone models do not give any incentive for IT Vendor to ensure continual focus on the user needs and have skin in the game. In such cases there is a high likelihood that the system gets neglected and accumulates technical debt / does not evolve based on the changing needs of the user. There may be an argument that Milestone based Fixed Price model makes vendor accountable, but if you look at it closely, you will realize that the vendor will only focus on achieving the milestone, and not care about the business value that it will bring to the customers.

The ‘Change Requests (CRs)’ are often considered as a mechanism to cater to the changing needs of user after the system is in operation, but it does not provide any incentive for IT Vendor to delight the customer either, because most of the energy is spent in discussing whether it is a CR, or part of initial requirements, and how much should be paid to deliver the changes.

In one of the projects that I was involved in, the ERP team quoted a higher amount for customization to achieve a critical functionality in an order management system. To save the cost, the leadership decided to build a hack into the upstream application, and dressed it up as a feature. The cost of making a change and requirement specifications became a driver for the discussion, rather than challenging the assumptions and choosing an option that could yield highest value to the user at a given cost. There was no consideration given to the complexity that was added to the system, as a result of this quick fix!

The focus on cost, time, and quality alone, does not ensure that the optimum business value is created by the system. Lack of focus on value metric, hampers the ability of the team to make pragmatic and valuable decisions to maximize the business value.

N.B. Quality implies conformance to specifications. It is not an indicator of business value.

Outcome-based contracting is not a mechanism to shift responsibility to IT vendor. It is means to achieve collaboration and co-operation between customer and IT vendor, in order to realize meaningful outcomes that generate business value. It is an operational model that requires a strong relationship between customer and IT vendor that fosters trust by sharing risks and rewards. It brings customer and IT vendor on the same side of the table.

The requirement gathering, analysis, project scope and other relevant activities are important and applicable to Outcome-based projects, but those activities are the means to an end.

The Value-based pricing for an Outcome-based project, is influenced by a well-defined Value Metric. The Value-based pricing is a portion of value agreed and shared by the customer with their IT vendor, in exchange for the contributions from IT vendor in maximizing the Value Metric, and risks that the vendor is willing to take if the system did not create the expected business value. The shared responsibility of the risks and rewards serve as motivation for IT vendor to operate the systems at an optimum cost, while trying to maximize the Value Metric, for the benefit of business, and eventually maximize the profitability of their customer. The efforts to enhance the system to maximize Value Metric, is in the interest of the IT vendor as well as the customer. In the Outcome-based model, the ‘Tug of CR’ is no longer beneficial for both parties, there is a natural alignment that incentivises continuous improvement of the system to satisfy the needs of the users, and gain as much business value as possible.