3 Steps to Agile Procurement - less time, less complexity, less cost

Larry Cooper

 

 

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 Agile to do it. The glove was thrown down!

 

That being said, when I got there I was handed a 246-page RFP that another similar organization had issued for a similar procurement. That did not look very agile 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 we were doing it.

 

I ran them through an exercise to understand and more clearly articulate why they were needing to do the procurement form a business perspective rather than from a technology one. I introduced outcomes mapping as the approach. This led to the identification of:

 

  • Four major new business process areas that had to be designed, developed and implemented

  • The fact that the intended COTS product was one of only five different tools that were needed and was only one of two in the business process area where it was to be used

  • Role re-evaluations that identified skills gaps as well as missing roles within their organization

 

2. Figuring out what the product 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, and then to rank each one according to a scale of business importance (Very High, High, Medium, Low, Very Low). This took about 8 weeks or 4 Sprints.

 

(We used a Business Service Canvas (a derivative of the Business Model Canvas we created for this step)

 

We then did pair-wise comparisons for the statements in each priority level within each capability area

 

E.g Lets say Capability area 1 had 4 statements ranked at Very High. I 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 chose one over the other, they would both stay at Very High. We would continue for all statements for all priorities for all capability areas.

 

Once all of the statements were prioritized, I asked them to consider the Low and Very Low and whether they wanted us to include them in the RFP seeing as they had already said they were not all that important to them (based on the assigned priorities). After some discussion they decided to remove them from the RFP. This allowed us to end up with an 8-page RFP document with some pre-populated spreadsheets with the capability statements by capability area and room for the vendors to fill in their actual responses (no bound or printed responses by vendors were permitted)

 

 

3. Run the Procurement

 

We then issued the RFP, evaluated the responses, ran a boardroom demo, and selected our winner.

 

Vendor responses to the RFP were evaluated much faster than would have been the case with a traditional RFP process - 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 procurement. Implementation took an additional six months and

 

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 – this was about one million in savings over the originally planned expenditures for the software product.

 

(Scrum was also used along with other practices to:

 

  •  Guide the team defining the Minimally Viable Product Features for the  Product that saved 97.5% of the original $1M budget

  • Identify, design, and develop all the required Minimally Viable Business Processes. None of these processes had been part of the original project scope - they were uncovered through the Outcomes Mapping and the Canvas work)

 

 

The result?

 

The procurement itself took less time, cost considerably less than planned (0nly 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 budgeted cost, within the same expected time-frame, and delivered business processes and additional tools that were not part of the original project definition.

 

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

 

Agile procurement means being willing to rethink the procurement process itself as well as the vendor's ability to support agile practices.

 

（文章来自 LinkedIn）

 

 

欢迎关注及分享，更多文章请识别以下二维码关注“SCMC珂涛”或“SCMsmart"