I was recently asked this by a very intelligent and insightful individual. My expanded answer follows.
The short answer is that I differentiate between the solution and the engagement in several different ways. The solution, and the analysis performed beforehand that helps to decide whether to even pursue a solution, is where the value is generated. The engagement describes the management environment in which the solution is generated. So, if I’m talking about the management environment, I’m not likely to be talking about the solution in its own detail.
It’s amazing how long you can think about a thing and still have so many unstated assumptions in play. It is clear in my mind that the framework I’ve developed is intended to guide work in any engagement with customers and problems, enhance situational awareness within such engagements, and so on. I often speak and write about the kinds of work that are done within each phase of an engagement, but I had not done so in the conversation where this question was posed to me, so some important context was missing. I’ve also had the feeling that, if people have failed to understand what I’ve been trying to communicate with all this, they may think it is just another form of content-free consultant-y blather. My antipathy towards fluffy consultantspeak is as strong as anyone’s, so let us definitely understand the missing context.
I recently discussed the factors that can drive potential solutions. Many of those factors consider how value is evaluated and generated before and outside of any particular engagement. If those factors are not expected to drive value, through the application of prior experience, a priori reasoning, or other entrepreneurial judgement, then why would anyone even begin an engagement?
It is certainly true that projects fail for various reasons, but projects quite often succeed, too, so let’s look at how that happens.
When I did business process reengineering using FileNet document imaging systems, it was pretty well understood that properly designed and implemented systems could generate substantial cost savings. So although engagements meant to analyze, automate, and reconfigure customer operations were known to provide (a really good chance of generating) benefits going in — for certain document-heavy classes of business processes — the engagements themselves still needed to worked through all the phases in detail to figure out where and how they would be realized for each customer’s specific process, and to figure out the exact value of the benefit.
The specific benefits of solutions like the foregoing may be readily calculated, but it may be far more difficult to assign specific monetary values generated in other situations, for example by the creation and employment of nuclear power plant training simulators. Their use is likely to lead to more efficient and effective operations on an ongoing basis, though those savings would be difficult to identify and quantify. The biggest reason they are used, however, is to prevent catastrophic failures that result in the loss of entire plants and extended losses in the surrounding regions. Economic analysts can (and do) put prices on those things, but the goal is largely to forestall the unthinkable.
Other types of benefits may not be strictly monetary, but may instead provide psychic or quality-of-life benefits. This is probably more likely to be true for consumer products than for capital goods or process improvements. It is also true that the producer of these kinds of products must provide them at a price consumers are willing to pay, because the customers will perform their own, subjective, cost-benefit analysis, whether they do so explicitly or not.
Business analysts, project managers, executives, and individuals in every other role can contribute to analyses of whether projects and product development efforts should be undertaken. However, it’s important to be able to do the necessary costing and accounting that enables determinations of which efforts are worthwhile and which aren’t.
We can also state that doing project and product work more efficiently always drives value. This not only enables a team to deliver outputs at lower cost, and probably higher quality, but those savings may make the difference between whether customers accept those outputs or not.
The initial phase, whether we call it the intended use, problem statement, or something else, is mostly about defining the goals of the engagement and setting up the management mechanisms in preparation for doing the work. I assume that this step is only undertaken if the effort has already been judged to be beneficial.
Value is generated in the conceptual model phase differently based on when it occurs. If it is carried out at or near the beginning to determine the As-Is state for a process improvement, then generating the most thorough and accurate picture of the current state will lead to the best results in later phases. This work includes learning everything possible about extant assumptions and risks. If the conceptual model work is conducted as part of the design phase, when there is no current state and the goal is to build something entirely new, then thorough and accurate information is still important, it just happens in a different way.
The requirements phase is where the envisaged solution is fitted to the specific needs of the customer, and where the needs of the solution and applicable regulations and standards are folded in. The more accurately and completely the needs can be identified, the more value the solution will be able to provide.
Value can be added in the design phase through elements that embody robustness, modularity, efficiency, novelty, and effectiveness in many ways. Elements can involve improved materials, effective rearrangements, the leveraging of new scientific discoveries, updated machines and components, and more.
Improving the efficiency and effectiveness of activities of the implementation phase adds value by consuming less time and resources. The resource savings can be realized both while carrying out the actual work or during the operation of the delivered solution. Alternatively, value may be enhanced by building in ways to generate more outputs with similar inputs. One possible example of this is efficient computer calculations that produce more granular, accurate, and frequent outputs. Another example is improved machining methods that produce tighter tolerances, that result in tighter seals and reduced friction and wear, that would allow an engine to produce more power and less pollution over a longer period of time while requiring less maintenance. It should also be understood that effective deployment is an integral part of the implementation phase.
It occurs to me that the line between requirements, design, and implementation can be rather blurry. Harkening back to the last example, I would ask whether the improved ability to machine surfaces is an element of design or implementation. I’d love to hear your thoughts on this distinction.
Activities in the test (and acceptance) phase add value in at least two ways. One is simply by reducing the time and effort taken to conduct (all necessary) testing. Theoretically this applies to all forms of iterative review and incorporation of feedback embedded in every previous phase, as well. The other value-add comes from ensuring testing is thorough so that the chance of passing deficiencies on to customers is reduced to the greatest degree possible.
Finally, just as evaluation and selection activities before engagements can add value, ongoing review and consideration can add value after the initial engagement ends. This involves thinking in terms of the extended life cycle of a solution, and continually looking to improve the solution and the means of delivering it.
In conclusion, while most of the explicit value is generated by the specific analyses and decisions made before a solution effort is undertaken, during the actual work of generating a solution, and ongoing review and improvement of the solution, the environment in which the work is performed and the framework used to guide it should not be overlooked. The solution and the engagement, which again are often referred to as the product and the process, may be thought of as a pair of scissors. You need both halves working together to get the best results.