I have been doing some work recently applying Agile techniques on a business process reengineering project. This has led to some thoughts on what I am calling the “Solution Gap”.
I see the Solution Gap as the gap between the intended value of a system and the solution that is supposed to deliver that value.
The Solution Gap is particularly significant when the intended value is people-oriented. IT systems are a good example of this. An IT system might be intended to make people’s work more efficient, or it might be intended to engage with people more effectively. People however do not react in consistent, obvious, or predictable ways.
It is often said that IT projects are different from other types of project, and the Solution Gap is one of the significant ways they are different. The concept has wider application than just IT projects though. Business processes are another example of systems with intended value which is people-dependent. Services (commerical and public) are another example. Even marketing initiatives and creative projects can be viewed in this way.
The Solution Gap is one form of uncertainty. One approach to removing uncertainty is to perfrom extra analysis. The other approach is to incorporate validation and feedback into the overall process. In the case of closing the Solution Gap additional analyis is to be recommended, but it is important that this does not then preclude the option for validation and feedback. Ultimately you cannot know whether the solution will deliver the intended value until the solution is put into operation.
There is therefore a point where analysis stops being cost beneficial. More specifically, this applies to analysis which is based on zero feedback. It makes most sense if such analysis is an ongoing activity rather than a purely up-front activity, incorporating increasing amounts of actual feedback as the project progresses.
One common trap that projects fall into is to assume that the analysis and design effort put into identifying the solution has resulted in the ‘correct’ solution, ie the Solution Gap is deemed not to exist. This thinking is enshrined in governance approaches that view implementation as purely a cost center - the solution is known and the cost now needs to be managed down, or at least to target. This is a generic form of delegation where only the solution is delegated. The obvious implication of this approach is that the risk associated with the Solution Gap is owned entirely upstream (eg by people required to ’sign off’ the solution), but more importantly the opportunity to optimise across both solution and value has been lost.
The Agile approach has some built in resolutions for the Solution Gap. Firstly, they inherently build in validation and feedback mechanisms. Secondly they promote collectively working towards clearly defined goals and continuous optimisation (eg prioritisation) against those goals.
There are however areas relating to the Solution Gap where the de-facto Agile processes are not prescriptive, and it is left to the vision and experience of the team to get it right.
For example, the focus of prioritisation is on deliverying business value. This approach might be effective in closing the Solution Gap, but might not. An alternative approach which I have used effectively is to focus (initially) on validating that the solution will deliver the intended value with minimum investment, with the likelihood that this will also generate real business value.
A precursor to this is that the intended value needs to be clearly identified and communicated in the early stages of the project. Note that this is different from identifying objectives and goals. Objectives can be expressed as easily in terms of solution as they can in terms of value, and my experience is that it is more effective to focus the conversation on value directly.