One of the most interesting and fascinating themes in Prince2 project management approach is, for what I am concerned, the business case one.
I find extremely interesting the constant focus on the project's business case and the continued assessment of the project justification, viability, and sustainability.
Also, I have been so impressed by the distinction between Output, Outcome, and Benefit.
Figure 1. |
Output Each specialist product that the project has to deliver, be it tangible or intangible. Outputs are commonly delivered after the project’s closure and sometimes even during the project’s life.
Outcome Results of the changes derived from the use of the project's specialist outputs by the users. Outcomes typically start to be achieved after the handover of the project's specialist products to users.
Benefit Measurable improvement resulting from an Outcome. If the outcome is perceived as a disadvantage, we are dealing with what is called a dis-benefit. Benefits generally start to be achieved after the Outcomes and (should) continue to be achieved for a time span planned in advance. Prince2 states the establishment of a specific plan that describes the methods and times to verify the achievement of the expected benefits.
In Figure 2 we can see a quantitative representation of the relationship between these three ideas. Obviously, the exact Outcomes/Benefits realization times heavily depend on the project’s characteristics and peculiarity.
Figure 2. |
The Buymybooks Limited is a small company that sells books via the internet. Orders are collected by means of their internet site but after the initial collecting phase, orders are printed and processed manually. Also, Buymybooks Limited does not have a software to manage its books warehouse.
Their sell and delivery processes are highly inefficient, resulting in delivery errors, high costs, high customers turnover, and progressive reduction in the market share.
To face this situation, the board of director has decided to introduce a management software system to manage the sale and delivery processes.
Output of the project will be an integrated software management system (orders and warehouse management).
Outcome of the project will be an improvement of Buymybooks Limited sell and delivery processes efficiency.
Benefits of the project will be delivery errors reduction, smaller costs, higher profits and greater customers' fidelity.
So we can agree that there is need to pay a great deal of attention not only to the execution phase of a project but also to the design, support and closure phases. Furthermore, it is of utmost importance check the actual realization of benefits after the project closure. This action should be performed by program or corporate management as prescribed in the project’s documentation.
As a consequence, I would advise to
1) Have a series of compatible and well-crafted benefits
This seems obvious, but it can be sometimes tricky. I have covered the topic in one old post. It has been conceived for project objectives, but it is well suited for project benefits too.
2) Do not just focus on the outputs delivery
Sometimes, is easy to focus just on output delivery and lose contact with project’s outcomes and benefits. It could happen if outputs are the only substantial point of contacts between the project and the team members (that sometimes ignore the big picture), or between the project and the external stakeholders.
Also, it is not uncommon to rely just on outputs delivery to measure project’s completion or success.
3) Choose the best possible approach to maximize benefits
Since a significant part of the project’s value will be realized after project’s closure, take care, during project planning, in choosing the best possible project approach to maximize the expected benefits and not just the outputs production.
In the same way, while drafting the business case, do not take into account just the specialist products realization and delivery costs. Keep an eye also on handover, maintenance and operational costs.
Manage and execute the project thinking also to the desired outcomes and benefits, trying to increase the probability of success and to maximize their impact on business as usual.
4) Close a project if it has been proved to be no more justified, viable and sustainable
A project is a mean to reach an objective and not an objective in itself. Stop investing in a project if it is not longer worth it, is not a failure. Honor to the project manager who conscientiously proposes an early closure of its project, out of respect for the corporate vision.
Keep on throwing money out of the window. That surely is a failure.
To keep track of some of this aspects, I suggest the use of two very simple tools.
benefits/benefits matrix (Useful for points 1 and 4)
The first one is a matrix on which all project benefits are listed in columns and rows, sorted by descending importance, from left to right and from top to bottom. Each benefit's importance is recorded near the benefit's code. You can find an example of the benefits/benefits matrix in Figure 3.
At the intersection of each row and column of the matrix, there is a symbol that explains the benefit's relationships.
Figure 3. |
The “+” sign represents a high degree of correlation between two benefits' viability. This bond leads to risky situations because there is a high probability to realize both the benefits (opportunity) or to miss them both (threat).
The “-” sign accounts for a low consistency between two benefits. This bond leads to risky situations because the realization of one of the two benefit could jeopardize the achievability of the other one.
In the example depicted in Figure 3, the achievability of benefits B2 and B3 is correlated. Benefits B1 and B4 are not consistent, but the real problem is that benefits B2 and B4 are not consistent too and, as a consequence, also benefit B3 is jeopardized. So benefit B4 jeopardizes benefits B2 and B3, that are the most significant benefits of our project.
In the example depicted in Figure 3, the achievability of benefits B2 and B3 is correlated. Benefits B1 and B4 are not consistent, but the real problem is that benefits B2 and B4 are not consistent too and, as a consequence, also benefit B3 is jeopardized. So benefit B4 jeopardizes benefits B2 and B3, that are the most significant benefits of our project.
Especially if one or both the benefits are assessed as paramount, strong “+” or “-” relationships have to be dealt with the greatest attention by the project manager.
if too much “+” and/or “-” relationships appear in the benefits/benefits matrix, it could be wiser TO conduct an additional analysis of the project's expected benefits and to reassess the project’s riskiness.
If two benefits do not have specific relationships, the intersection between their columns and lines is left empty. Obviously, the matrix is symmetric by construction and the slashes on the main diagonal are inserted just for the sake of clarity.
Other symbols could be added to account for different relationships, even if I advise to keep things as simple as possible.
Even in this very simple form, this tool could help in identifying dangerous (-) or risky situations (+), and contribute to the definition of the project's objectives.
products/benefits matrix (Useful for points 2 and 3)
The second tool I want to present is a matrix on which all project products (outputs) are listed in rows and all project benefits are listed in columns. Benefits are sorted by descending importance from left to right. Each benefit’s importance is recorded near the benefit's code. You can find an example of the products/benefits matrix in Figure 4.
Figure 4. |
Each intersection between a row (product) and a column (benefit) contains project's outcome's codes, and represents through which outcome a single product helps to achieve a benefit. The color code states the degree of importance of the product to the expected benefit's realization (e.g., red could mean high, orange average, and yellow low).
We can see, reading the matrix by columns, which product helps to achieve a benefit, and to which degree each product is necessary to this end.
In this way, we can maintain a constant focus not only on project’s outputs but also on project’s benefits, through project’s outcomes.
If we are forced to drop out a product, we can immediately see which benefits are at stake, their importance for the project and how much they are at risk. It is a simple way to depict the effect of a project scope modification on the project benefits.
In the same way, if we decide to sacrifice a benefit, we can immediately evaluate if there should also be a project’s scope modification.
If you feel like to read some suggestion on how to assign importance values to project benefits, please refer to this post. It has been conceived to suggest how to assign qualitative values of impact and probability to project risks, but I think that the content is perfectly adaptable to the current problem.
Quest' opera รจ distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.