Using Scrum in Procurement: 3 Steps to spend less time, achieve less complexity, and spend less money

 

A number of years ago I was asked by a client to help them procure and implement a COTS product - but I had to use Scrum to do it.

That being said, when I got there I was handed a 246-page RFP that a similar organization had issued for the same kind of procurement. That did not look very like it was very agile approach to me so I said ah, I won't be producing one of those!

So how did do we do it? Here are the three steps:

1. Figuring out why the business needed the COTS product

Step 1 was to figure out why the business though they needed the COTS product. To do that I introduced outcomes mapping (which is a variant of Benefits Mapping) to help them more clearly articulate why they were needing to do the project from a business perspective rather than from a technology perspective. The 246-page RFP document I was handed was mostly technology-focused which is why I felt we needed to avoid a similar trap.

As soon as we had the first draft of the outcomes map created we printed on a 3x4 foot sheet and put it on the wall in our war room for the project (see David Maynard's excellent post on how war rooms can help any project).

Having a visible map of the “why” enabled both the business and the IT teams to add details or ask questions using sticky notes anytime they walked by the map. We would then stand around the map as a team every day and review the content of the latest stickies to figure out where we needed to update our map with our now emerging understanding of the business problem we were solving. Once we agreed on what needed to be changed, we would update the map, reprint it and put the newly revised map back on the wall.

This created an opportunity for serendipity for both the business and IT as they would walk by and study the map. As they stood there looking at the map this often led to others stopping as well which of course led to them to talk about the map together. These ad-hoc conversations led to some of the most insightful additions to the map.

Over the period of about 8 weeks or so the big visible map of the why for the project led to the identification of:

• Four major new business process areas that had to be designed, developed and implemented that the business had not previously recognized.
• The fact that the intended COTS product was only one of five different tools that were actually needed and was only one of two in the business process area where it was to be used

As you build an outcomes map there are natural structures that emerge that help you categorize different parts of the map. As this picture emerges it also helps you identify what you need to do (projects/initiatives) satisfy the why you are doing it (the outcomes)

2. Figuring out what the product to be procured needed to do

I facilitated the business groups in identifying the required business capability areas that the product needed to address along with capability statements within each capability area as to what they needed the product to do.

This enabled them to rank each capability statement according to a scale of business importance (Very High, High, Medium, Low, Very Low). This took about 8 weeks or 4 Sprints. The business was solely responsible for these prioritizations of business importance.

We created a Business Service Canvas for this step which was a derivative of the Business Model Canvas. As with the outcomes map we printed the canvas on a 3x4 foot sheet and put it on the wall for the team to use stickies to capture their additions or questions. The Services on the canvas started with those that the Learning and Development group (the business group) already provided to the rest of the organization. It then morphed into those that it would need to provide in order to satisfy the business outcomes from step 1.

We then led the business team through a series of pair-wise comparisons of "buy-a-capability" for each of the statements in each priority level within each capability area as follows:

• Let’s say Capability area 1 had 4 capability statements ranked at Very High.
• We would have them compare the first two by asking if they only had $1 and could only buy one of them, would they chose one over the other or would they say I guess I don't have enough money.
• If they chose one over the other, then the losing statement would be changed to High from a Very High.
• If they could not choose one over the other, they would both stay at Very High.
• We did this for all capability statements for all priorities for all capability areas.

Once all of the capability statements were re-prioritized, we asked them to consider the Low and Very Low ones and whether they wanted us to include them in the RFP seeing as they had already said they were not all that important based on their assigned level of business importance.

After some discussion the business decided to remove them from the RFP. This allowed us to end up with an 8-page RFP document augmented by pre-populated spreadsheets with the capability statements organized by capability area. We provided room in the spreadsheets for the vendors to fill in their actual responses which had to refer to their own product documentation that supported their statements of product fit. The vendors were not allowed to submit bound or printed responses to the RFP.

Using the Business Service Canvas also helped the business identify the need for role re-evaluations based on newly realized skills gaps as well as missing roles within their organization.

This step took about another 4 Sprints to get through.

3. Run the Procurement

Now that we knew why we were doing the project and had a solid understanding of the what the COTS product needed to we were ready to run the procurement itself which meant:

• Issuing the RFP
• Evaluating vendor responses
• Running a boardroom demo for the vendors to show how their product satisfied the required business capabilities
• Selecting a winner

Vendor responses to the RFP were received after being out for 8 weeks. The entire response evaluations took less than a week which included the boardroom demos for the top-3 ranked vendors.

The boardroom demos also led to a switching of the initial number 1 and 2 ranked vendors which rarely happens in traditional procurements. Implementation of the COTS product took an additional six months.

(Note: while some some internal delays stretched the overall delivery timeline to 18 months it was within the original expected time which was also 18 months. Without these delays we would have finished about 4 months early)

Actual expenditure on the procured software was only about 2.5% of the original expectation of expenditure as we only evaluated those things that the client really needed – the business spent a mere $25,000 of the original $1 million originally allocated for the product.

The vendor selection process also considered the ability of the vendor to help with an incremental deployment and use agile practices for developing the required integration with other corporate systems within the business.

Use agile procurement practices means being willing to rethink the procurement process itself as well as the chosen vendor's ability to support agile practices in their product implementations.

Conclusion

Scrum, outcomes mapping and the Business Services Canvas, as well other practices we introduced allowed us to:

• Realize that the “project” was actually a program of projects not a single project as originally thought. In all there were six initiatives across four major business capability areas
• Guide the business team in defining their Minimally Viable Product Features for the COTS product which saved 97.5% of the original $1M budget
• Identify a define the new services they needed to stand-up within the Learning and Development group to satisfy the four business capability areas
• Identify, design, and develop all of the required Minimally Viable Business Processes.
• Identify the new roles can changes to existing roles that would be needed to support the new and existing services based on the new capability areas ad processes

The procurement itself took less time, cost considerably less than planned (only 2.5% of the budgeted $1M), used a far less complex procurement process, and achieved the right results for the business.

The project was completed within the original overall budgeted cost of $2.5M, within the same expected time-box of 18 months, yet delivered newly identified business processes, services, and additional tools (with the money saved in the procurement), none of which were part of the original project definition and scope.

Have you used Scrum in a procurement? I'd love to hear how it went.