Does the RfP Process need a MAJOR Upgrade - Episode 3: RfP 3.0 'Request for Participation'
Looking back in the history of the RfI/RfP process we see, that it’s source was developed in another time at the end of the 19th century. Of course the new channels like phone, email, web, etc. allowed new possibilities and increased efficiency. However the core of the process stayed nearly the same. Do we may be need a major upgrade after almost 120 years?
Lets have a look at the RfP 3.0, the request for participation and how this improves competitive advantage of buyers and suppliers.
Looking back in the history of the RfI/RfP process we see, that it’s source was developed in another time at the end of the 19th century. Of course the new channels like phone, email, web, etc. allowed new possibilities and increased efficiency. However the core of the process stayed nearly the same. Do we may be need a major upgrade after almost 120 years?
Lets have a look at the RfP 3.0, the request for participation and how this improves competitive advantage of buyers and suppliers.
<< Previous blog post: Does the RfP Process need a major Upgrade? - Episode 2: The Facts
Please note: This blog posts is focusing just on the RfP process. We are aware of the fact that modern procurement is much more than this. We hope you enjoy another perspective!
“Lean-agile procurement reduces and distributes risk through incremental and value-added funding for improved business outcomes.”
In previous blog post we’ve learned, that the RfP 2.0 doesn’t work with complex tenders . What we all assumed is underlined with facts. We can’t predict, nor estimate the unknown and so we can’t specify the scope without creating waste. We would need so much time for investigation, that we already could start probing iteratively. Furthermore, we’ve learned to focus to the end user/customer needs, constantly validate those and look for a future-proof partner instead of a predefined solution. If we don’t reinvent RfP 2.0 fundamentally we might loose more and more potential partners interest and with that we’ll also loose opportunity for unexpected innovations and so a potential competitive advantage.
All this leads us to the conclusion, that we need a major upgrade of the RfP, the RfP 3.0!-An upgrade, that fosters collaboration and innovation. We call it „Request for Participation“. But how does it look like?
The thing with trust
The fundament of a partnership is trust and transparency. Have you noticed?-We’ve said partnership instead of relationship, that’s the first fine but big change with RfP3.0. In an ideal world we would just choose a partner and start probing iteratively. Unfortunately, our current culture and believes are not yet there. So we need something in between. The funny thing with trust is, it works in both ways. This often gets forgotten. In other words we need to establish trust and reduce risks for both sides (buyer and partner) at the same time. Therefor we can create sophisticated agile contracts, that describe and handle collaboration, scope, timing, budget, quality, warranty, etc. Personally, I don’t believe in that way and I’m more with Marco Zoppi.
“If the customer is starting to quote from the contract the cooperation has just found it’s end”
Sure, we have to manage the basics in a contract, no doubt. But I’m a strong believer in the good idea of men (theory Y, source 1) and we should not punish the majority, because of some few bad theory X cases from the past. By the way, Niels Pflägin said: "There are NO X-er by default, the system / organisation makes them behave like X-er".
Source: Douglas McGregor, Theory X/Y
Instead we should find lean and agile cooperation models and -contracts, that are fair and foster trust by e.g.
- risk share
- bonus / money for nothing, if we achieve the goal/s earlier
- work / fund just stages, with the option of an early exit at any time
- partnering / open books / joint venture
- etc.
So that the partnership stays adaptive instead of fixed. In my opinion, that’s true agile contracting!-But that’s another story.
Paradigm changes
Currently agile is the only approach we know, to deal with complexity. Its built in approach of build <> measure <> learn brings us iteratively towards the right solution. For the RfP 3.0 this means, that in complex tenders for innovation, business services, ICT, etc. it makes no sense any more to think off solutions (features / functions) or wants in advance. Instead we need to focus on the customer needs and with whom we could solve them best. All this is a creative development, that we only could achieve in a participative approach. The potential partner and all stakeholders from both sides (business, executives, lawyer, buyer, customer / user, developer, etc) need to be involved at once. YES, that means we do this all together in ONE room. This allows both sides to align with the customer needs, but also check if the partner is future proof, if we have a culture-/technical match (soft-/hard skills), etc. Only with this participative, creative development we will create real innovation and get first validations with the stakeholders available. Further advantage of this approach is speed (Time-to-Market). If we get all stakeholders in one room we can immediately decide and achieve results in DAYS instead of Months. We see this from other examples, like e.g. Design Thinking, Hackathons, etc. where time-to-market was improved with such a participative approach dramatically.
Acceptance of uncertainty
But how can we cope with this uncertainty of an „unknown“ solution (scope gets variable)?-Well, there are other disciplines out there, that face a similar challenge. If we think about business development they’ve used to write big business plans and switched over to the business model canvas (a structured page that describes a business model, source 2) and lean startup (an agile approach for early validation of the hypotheses with the customer, source 3).
The general advantages of a canvas are:
- it’s just one page and we have to focus to what really matters
- it’s a good overview / summary, that makes the essence transparent
- it makes things comparable
- it keeps us aware, that everything is connected and influences each other
- it’s a tool, that fosters collaboration and we could use every day to update our validations with customers /users
Source: Lean Procurement Canvas, Version 1.22 by Mirko Kleiner
What if we use the business model canvas for ideation and overtake the concept for procurement with RfP3.0?-We’ve created the lean procurement Canvas, that has basically 3 areas:
1. Focus - Strategic themes / goals (WHY we need this partnership)
2. Customer facing - Customer needs, timing, conditions, etc (WHAT we’d like to solve with this partnership)
3. Partner facing - Capabilities, USPs, etc. (HOW we’d might solve the customer needs)
After ideation with the business model canvas it’s very easy to overtake the strategy (WHY) and the customer needs (WHAT) and add the timing (WHEN), the people (WHO) and the conditions (WHERIN) within hours. With this we have the basic informations to start a participative event with one, or multiple potential partners. On this joint event we workout, whatever is valuable for us to decide starting an adaptive partnership. We could work out together more concrete customer needs and appropriate solutions, an agile roadmap of the next stage, etc. Basically we complete together the procurement canvas and decide.
“The lean Procurement Canvas is an agile Contract”
Start early, validate often
What counts for a business model and in more details for the customer needs counts also for a partnership. Instead of loosing time in non-valuable work we start as early as possible and constantly validate the joint achievements stage by stage and so the partnership. Therefor the lean procurement canvas becomes the tool for management of your adaptive partner ecosystem.
Conclusion
It turned out, that the lean procurement canvas can be used in all areas and industries, that have to overcome complex tenders, adaptive partnerships, etc. We get increased business value with RfP3.0 (increased time to market, reduced and distributed risk, incremental and value-added funding, improved business outcomes, etc). But for us most important, with the participative approach of RfP3.0 we’ve seen returning fun in the faces of all stakeholders!
Want to know more?
If you’ve got infected by the approach RfP 3.0 ‚Request for Participation‘ feel free to share your opinion and/or similar cases with us. More detailed information about the approach, success stories, the community, upcoming workshops and talks, etc. you’ll find under http://www.lean-agile-procurement.com - Stay tuned!
Author
Sources:
- Idea of men (Theorie x/y) by Douglas McGregor
- Business model canvas, by Alexander Osterwalder
- Lean startup, by Eric Ries
- Title image source: pinimg.com
Success Story POCathon@CSS Insurance - A Participative Evaluation in just 3 days
If you're wondering how a big room evaluation day (Step 3 of 4 in lean-agile procurement) could look like read this awesome interview with Konrad and Dominik about their custom implementation at CSS Insurance called "POCathon". CSS is one of the largest health insurers in Switzerland. For there complex evaluation of a software service provider they've invited 4 providers and put them all together in one room for 3 days. At the end of these 3 days they were able to decide with whom of the service provider they will continue agile delivery at the next day!
If you're wondering how a big room evaluation day (Step 3 + 4 in lean-agile procurement) could look like read this awesome interview with Konrad and Dominik about their custom implementation at CSS Insurance called "POCathon". CSS is one of the largest health insurers in Switzerland. For there complex evaluation of a software provider they've invited 2 providers and put them all together in one room for 3 days. At the end of these 3 days they were able to decide with whom of the service provider they will continue agile delivery at the next day!
“The POCathon fits perfectly into lean-agile Procurement and we will use both in combination again.”
Who are you guys and what is your job with CSS insurance?
Konrad Durrer: I have been working in IT for 35 years and was always looking forward to learn new things. After writing stock market applications on large systems, I entered the first ETH course of studies in Computer Science. I then worked in industry and for the governance before joining CSS Insurance. I'm now an architect and technology consultant. In leisure time, I run marathons and enjoy life. Konrad was responsible for the evaluation and is co-initiator of the approach POCathon.
Dominik Liebmann: I'm an API management and integration consultant at ipt AG. My focus is on simplifying business processes. Since my first company at the age of 16, I've been working with IT-supported business processes and worked for many companies (SAP, IBM, Bison Schweiz AG) in Germany and abroad (Russia, China). I personally spend my time either at the local stove or go for mountainbike races. Dominik supported CSS as an external consultant and is co-initiator of the approach POCathon.
You are the initiators of pocathon, what is it exactly?
Konrad & Dominik: The "POCathon" is a combination of the words Proof-of-Concept (POC) and Hackathon and is intended to combine the advantages of both approaches. With a POC you want to test the cooperation with a new partner and its services and / or products. With a Hackathon it is very quickly possible to achieve many learnings by simply putting the right people together and try things out by implementing them. The POCathon starts, when the customer needs and possible providers are already known. It allows to evaluate them jointly in a participative process with an ultimate decision. We see the application area of POCathon independent of the industry and the topic, as long as this has a certain complexity.
Image: (c) 2013 by Sebastiaan ter Burg (Amsterdam Hackathon)
This sounds very extraordinary, even disruptive. How did you get it?
Konrad: Classical POCs are intransparent, partially unfair and and it is not easy to differentiate between product, service and partner. Also, the lead time is incredibly high (weeks & months) and thus the investment massive. We were looking for a faster, more lean way of a competitive evaluation and got inspired by lean-agile procurement (LAP).
Dominik: In LAP, we particularly liked the participative idea, so the people, who are also concerned about it, are placed in the center and get empowered to decide for themselves. This has the advantage that not only the product, but also the partner (soft / hard skills), their way of thinking and working, as well as the cooperation and the ability to deliver can be tested. If the stakeholders are able to participate in this short period of time, they also get a deeper insight. Of course the speed, or time-to-market, was also very exciting to us. Beside that I totally agree with Konrad, that classic evaluations and POCs are partially unfair. Especially as these are done sequentially and it's in our nature that we remember the last provider the best and the 1st the worst.
What made you decide to run a POCathon just for this project?
Konrad: On the one hand there was the pressure of time and the complexity of the business needs. On the other hand the project offered itself, it had clear bounding conditions, the procedure was in our decision-making competencies and the evaluated products were roughly comparable. We therefore looked for further criterias and also wanted to involve the users directly in the decision. Furthermore the details for the POC were already well prepared through the preliminary work.
Dominik: Due to the technical background of the project, all stakeholders were from IT and were tangible for us. The fact that we wanted to involve them in the evaluation became mainly beneficial. Likewise, the providers were open to the procedure too.
“What used to take WEEKS & MONTHS now only takes DAYS!”
How did the pocathon work in practice, can you explain a little bit?
Konrad: First of all the product vision (why) and the business needs (what) of the POCathon were presented to all 2 invited providers. This set the frame, so that the 2 vendors could start implementing their solution (HOW) self-organized, by taking one business need after the other from the prioritized backlog. It was the idea that we have 2 implementations in parallel similar to a competition between the 2 providers.
Dominik: Therefore we basically had an iteration each day. In the morning we made a planning and at the end of each day the results were presented in a review session to the real users. They assessed the technical integration/solution and gave direct feedback to the vendors. We facilitated the process throughout the day and answered questions instantly. In doing so, we also experienced surprises such as when a vendor was apparently behind the schedule but then catch up and delivered in time until the next demo. In addition to that, the users got to know the products and the providers personally in the day-to-day collaboration and this also formed interpersonal preferences. An important aspect of our approach, where usually is not enough time for.
What do you recommend any followers?
Konrad: We had made the preparation of the requirements and / or the preselection in a classic approach. Today, based on the huge success of the POCathon, we would work this phase in a participative process too using the lean procurement canvas and lean-agile procurement. This would allow us to faster classify the offered solution and its intermediate results faster.
Dominik: The POCathon was an experiment. Accordingly, we could still improve a lot, for example the top management could be invited too, end users should constantly participate during the POCathon (they were just for the demo present), the lean Procurement Canvas incl. an agile roadmap could be developed together with the providers, etc. Furthermore, you shouldn't under-estimated scaling effects the more providers get invited.
Where are you today in the project and did you achieve what you hoped with the pocathon?
Konrad: The selected product is in productive use. The users were very motivated by the participative process. You just can not underestimate this. All-in it was a big success for us from the buyer perspective!
Dominik: From the approach point of view we over-achieved our biggest expectations. We could speed up time-to-market, participation of end users and made finally a decision.
How was the feedback from the organization or the suppliers?
Konrad: From both sides very positive, which has surprised us. Due to the daily reviews in the evening, a high identification of the end user with the product could be achieved. We believe this is because they have become part of the evaluation process from the start. We do not recognize the usual discussion that product B would have been better.
By the way, all the providers were paid for their expenses (3 days). This was important to us, since they all delivered business value during the POCathon, one provider contributed already to our current solution and through the others we got important new ideas, learnings and feedbacks. Usually, the winner is willing to provide a special rabat of the amount we invested.
Dominik: I think such an approach is in the interests of all parties. From the point of view of the buyer, all stakeholders as well as the project team members themselves are involved into the decision. From the point of view of the providers this approach gave them the chance to present themself in a completely different quality, with a much less investment of time and ressources. In total, the end user benefits as well, since he gets business value delivered faster, more effective, the procurement process gives room for innovation and becomes less expensive.
Surprisingly the providers even liked the competitive approach being in the same room with their competitors :-)
How does it go on, will you use lean-agile procurement or the POCathon for further evaluations?
Konrad: We see a mutual value both. LAP can be made with a larger number of providers do workout the WHY/WHAT and a POCathon covers the solution (HOW). The POCathon complements LAP perfectly and we will use this in combination again.
Dominik: Amazing was retrospectively what we have been achieved in only 3 days. Imagine if the preparation work and preselection could become similarly effective by the combination with LAP. This will in our opinion disrupting procurement: What used to take WEEKS & MONTHS now only takes DAYS!
Thanks for the interview and FOR SHARING OF THIS AWESOME STORY!
Source: CSS Insurance AG, Switzerland 2017