Using the Lean Canvas for an IT solution proof of concept

I was assisting a client with sourcing some new IT solutions. For one particular IT need, the client had shortlisted a potential solution with a trusted vendor but they needed to explore the potential solution further to understand its capabilities in more detail. They were unclear as to whether they should directly source with this vendor or go to the wider market (with a Request for Proposal (RFP)) to address this particular need. Further to this, it was unclear how long this project would run for so it was important to understand the time and effort that may be involved without consuming too many resources. 

The client was seeking to employ a specific approach for this potential solution, where a “fail fast” lean Proof of Concept (PoC) would be conducted to rapidly test whether the potential solution was fit for purpose without spending unnecessary time and effort required to conduct a RFP.

To start, we confirmed the following principles to guide the PoC:

• Do not develop detailed requirements but rather hypotheses where we believe the solution’s features will be valuable for the client and its customers.
• Leverage Lean and Deming’s PDCA cycle which emphasises the use of the scientific method (hypothesis testing & observational learning) and the efficiency of ‘small batches’, doing things in incrementally on a success basis.

By adopting this approach, our anticipated benefits included:

• More efficient use of resources by avoiding expensive detailed planning to manage risk. Instead the PoC team would use rapid feedback from the experiments to help gauge the solution's effectiveness and inform estimation of future experiments.
• The client managed uncertainty of the proposed solution by iteratively running a series of experiments where the PoC team learns and adapt.

Leveraging industry better practice based on Lean Start-up and Deming’s PDCA model (see Figure 1 below), we designed an iterative approach for the PoC, focusing on learning from rapid feedback in small experiments (use cases) to reduce the uncertainty risk. At regular intervals we would check the progress of our experiments. If the experiments showed success, we would continue to persevere with the PoC. If too many experiments failed with the potential solution, we would pivot and start a RFP process.

Figure 1: Mapping Lean Start-up and the Deming Cycle to formulate PoC approach

This table details the various steps in this approach:

Step	Description
Plan PoC	Form PoC squad. Develop a simplified solution canvas (based on Lean Canvas) that captures and communicates the key operating assumptions & problem/solution criteria of the new solution.
Design experiments	Design (MVP) experiments (in the form of use case stories) to maximize learning from the potential capabilities of the proposed solution with minimum effort. Include a value rating, clear scope for each experiment and initial estimate of time and effort for each experiment.
Execute next experiment	Execute and test the next experiment leveraging existing agile scrum practices. Study test results, document the product/modules used, their version number, level of customisation & effort required to implement, effort consumed in the experiment and key observations. Update the solution canvas as required.
Persevere or Pivot	Based on the results of the experiment, decide to Persevere with the PoC and next (MVP) experiment or Pivot to a new RFP process.
Persevere	Continue with the current PoC process using sprint retrospectives to enhance the process. Provide customer showcases on progress. Revisit the solution canvas, update estimates of remaining experiments (if required) and select next set of experiments.
Pivot	If the results of the experiments invalidate the solution hypothesis, document and showcase findings to customers. Pivot to a new RFP process.

Once the PoC squad was formed, we collaborated on the development of the solution canvas (based on the Lean Canvas). I facilitated the workshop starting with an initial (blank) solution canvas (see Figure 2) and we derived our position on each segment starting from number 1 to 9. 

Step

Description

Plan PoC

Form PoC squad. Develop a simplified solution canvas (based on Lean Canvas) that captures and communicates the key operating assumptions & problem/solution criteria of the new solution.

Design experiments

Design (MVP) experiments (in the form of use case stories) to maximize learning from the potential capabilities of the proposed solution with minimum effort. Include a value rating, clear scope for each experiment and initial estimate of time and effort for each experiment.

Execute next experiment

Execute and test the next experiment leveraging existing agile scrum practices. Study test results, document the product/modules used, their version number, level of customisation & effort required to implement, effort consumed in the experiment and key observations. Update the solution canvas as required.

Persevere or Pivot

Based on the results of the experiment, decide to Persevere with the PoC and next (MVP) experiment or Pivot to a new RFP process.

Persevere

Continue with the current PoC process using sprint retrospectives to enhance the process. Provide customer showcases on progress. Revisit the solution canvas, update estimates of remaining experiments (if required) and select next set of experiments.

Pivot

If the results of the experiments invalidate the solution hypothesis, document and showcase findings to customers. Pivot to a new RFP process.

Figure 2: Initial Solution Canvas

The solution canvas provided a simple way to centralise the team’s focus on the PoC and help articulate the who, what, where and why without a significant investment in time or money. The discussion helped to clarify the scope and the various assumptions that the team held. The final result was converted onto a wall mounted whiteboard that allowed the team to update the solution canvas contents as the PoC was executed and refined. I could not re-produce the final output in this blog post as the canvas contained confidential and identifiable information on the client. I can outline that segments 5 (Channels) and 9 (Unfair Advantage) were found to be redundant for the purposes of the PoC and therefore removed from the PoC's solution canvas.

For executing the PoC experiments, the team employed a standard agile scrum approach with ceremonies such as sprint planning, daily stand-ups, fortnightly showcases, and team retrospectives. The outputs from team retrospectives were used to update the solution canvas and update the estimates of the remaining experiments as required. This, in turn, helped to tune the PoC's approach and inform the next sprint planning meeting. 

From this experience I hope you can see how the Lean Canvas is an effective, lightweight and dynamic instrument to help provide guidance and central focus for the team on their endeavors.

Suggested reading on Lean Canvas:

Maurya, M. (2011). Why Lean Canvas vs Business Model Canvas? Retrieved November 20, 2016 from https://leanstack.com/why-lean-canvas (@ashmaurya)

Humble, J., Molesky , J. & O'Reilly, B. (2015). Lean Enterprise: How High Performance Organizations Innovate at Scale. O'Reilly Media. ISBN 978-1449368425