Benefits Realization Management
The one exception we mentioned in the previous section is Chapter 7, Benefits Realization Management. We found this of particular interest because to us this is a relatively new discipline that to date has received little attention, or gained little traction, in North America. This chapter is introduced with the graphic shown in Figure 4 and as its Introduction states: "A benefit is the measurable improvement resulting from an outcome."[14]
An interesting subtlety in the Managing Successful Programs Guide, is how it differentiates between Outcomes and Outputs. An Outcome is:
"The result of change, normally affecting real-world behavior and/or circumstances; the manifestation of part or all of the new state conceived in a program's Blueprint."[15]
In other words, it is the result of a program.
Since a project is defined as:
"A temporary organization that is created for the purpose of delivering one or more business outputs according to a specified Business Case"[16]
And an Output is defined as:
"The tangible or intangible product [or deliverable] resulting from a planned activity."[17]
It follows that outputs, deliverables or products, whether tangible or intangible, are all the results of projects.
To clarify then, in the view of MSP, programs are designed to generate benefits for the organization, while projects produce the products that are the enablers of those benefits. This makes a lot of sense in the overall scheme of things.
Figure 4: Benefits are anticipated when a change is conceived[18]
In fact, the Guide sheds light on the relatively uncharted post-project waters by illustrating the linear chain from project outputs to the achievement of strategic objectives by the example shown in Figure 5.
Figure 5: Example of the chain from project output to strategic objective[19]
However, the reality is not that simple because programs that deliver change inevitably cause side effects. These side effects may be perceived as benefits to some and dis-benefits to others, but either way should give rise to further opportunities even if only as intermediate benefits. This complexity is displayed in Figure 6.
Figure 6: Path to benefit realization and strategic objectives[20]
While the relationships shown may be easy to follow conceptually, they are not nearly so easy to establish in practice. The solution is to carry out a "Benefits Mapping" exercise. The MSP Guide describes Benefits Mapping as follows:
"A Benefits Map is developed to show how the benefits relate to each other and the projects (which deliver the outputs that allow the realization of benefits). A Benefits Map covers the entire set of benefits and becomes a major planning document for programs. The Benefits Map is so important because benefits (and dis-benefits) do not typically happen in isolation."[21]
The Guide also provides the following tip:
"Ideally, the Benefits Map would be created working from right to left, from strategic objectives, through end benefits and intermediate benefits. It should then define the enablers (project outputs) and business changes required. Where the enablers are given, for example in an emergent program, the Benefits Map can be created from both ends and join in the middle."[22]
As an example, Figure 7 shows a sports-complex legacy Benefits Map.
Figure 7: Benefits Map: Example of a sports-complex legacy[23]
Obviously, there is more to this chapter than we have reported here, all of which is highly instructive.
14. Ibid, p61
15. Ibid, Glossary, p247
16. Ibid.
17. Ibid.
18. Ibid, p61
19. Ibid, Figure 7.3, p63
20. Ibid, Figure 7.2, p63
21. Ibid, p68
22. Ibid, p69
23. Ibid.
|
What We Liked
