In part I, we discussed how inadequate attention to problem statement identification could be one of the major causes for the failure of many innovation projects in healthcare. We also discussed the advantages of using design thinking approaches to problem identification, the "D" of the D.A.R.T. model. In this post, we will discuss the "A', which stands for Assess.
While the design stage focused on "divergence" through widening the problem statement, brain-storming to generate multiple points of view (POVs), framing â reframing, etc., the assess stage focuses on "convergence". The assess stage is when we start to trim the multiple POVs, and possible multiple solution partners to one POV, and one solution partner. These are also areas where organizations tend to falter.
Convergence of the multiple POVs generated from the design stage involves finding connections between the different POVs and scoping it clearly so that the problem statement is well defined. However, all too frequently, organizations are in a hurry to get to the implementation stage, and do not spend enough time in clearly defining the POV. The same is true for identifying solution partners: this activity is either defaulted to preferred partners since the effort of setting up contracts with new partners is too cumbersome or is outsourced to an "aggregator" type organization that identifies potential solution partners through key word searches. Both of these approaches lead to engaging with non-optimal solution providers, while there potentially exist other players with deep and relevant expertise who are missed.
Assessing the Baseline
Another important activity that should be performed during the "assess" stage is assessing the baseline. Most people would readily agree that this is critical but is routinely missed because of the impatience to jump into solutioning. In many cases, a baseline assessment is done, but at a qualitative level. While this is also helpful since it provides a good understanding of the processes, it is important to also have quantitative metrics. These same metrics will then also be assessed at the end of the project implementation, to have an objective assessment of whether the innovation project actually met its goals.
As part of the baseline assessment, it is also useful to do a comparison with industry benchmarks, if available. This would help guide the process of setting appropriate goals for the innovation project and ensure that a lot of effort is not spent on making small improvements that still do not match industry benchmarks.
In one of our previous experiences, a team had come to us requesting that we help to make one of their current process more efficient by using "AI". They felt that the current process was too manually intensive, which would of course be helped by use of NLP or ML. One of our first steps was to try and quantify the effort required at baseline, and the gain that the new process they wanted to implement would fetch them. It was a bit of struggle to get the quantitative data required to make this assessment, however, when we were done with this step, this is what we found: The new process would result in a saving of roughly 1.5 FTE, but in order to implement the new process, they would actually end up spending close to 3 FTEs in the first year. The team felt that this gain was not worth the effort, and we ended up going back to Step 1, Design, to see if we could address a more wider problem which would provide better return on the investment.
The Assess part of the model includes a few steps: Converging on an appropriate POV, identifying an appropriate solution, identifying the right vendor to implement the solution, assessing the baseline both qualitatively and quantitatively, comparing to industry benchmarks if available, and finally, also setting the right goals to be achieved at the end of a successful implementation. In many cases, we find that this is not a sequential exercise, and one might need to go back and forth between Design and Assess before we get it right. However, this is the planning stage of the project, and it is critical that we spend the time to do this well. In the next part, we will look at some of the common pitfalls in the implementation stage.