Output, Outcome and Benefit - Managing today to shape the future

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.

Let’s make a simple example to better clarify this view.

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.

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.

Are your project objectives S.M.A.R.T. enough?

I love acronyms.

I have always considered acronyms as incredibly shrewd and useful tools, for communicating and for remembering complex concepts in a simple and effective way.

In this post i will focus on one acronym that I came across the first time while studying Prince2 and that, as often happens, I then met again several times in the following days, even if slightly modified.

The acronym is S.M.A.R.T. and, related to project objectives, stands for Specific, Measurable, Achievable, Realistic, and Time Bound.

Honestly, I have to say that there seems to be no universal agreement on the words whose initials make up this acronym, as you can see by following this link. However, the version presented here is the one that I find more congenial and useful to my needs.

Specific

How could you hit a target, if you do not know where the target is? Or worst, how could you hit it, if you do not even know what the target looks like? In the same way you cannot achieve a objective if you do not provide (or if you have not been provided with) a clear description of the objective itself.

It seems obvious, I think that everyone would agree with the previous statement...but please keep in mind that defining specific objectives for a project is not an easy task.

To state or analyze a clear and well crafted business case, considering all present and future developments, benefits and advantages, requires both great project insight and business vision. You could need the aid of a business analyst and, possibly, great support from your corporate management.

If you have been provided with project documentation, in the form of a charter or of a project brief, take your time to examine it carefully and request clarifications wherever necessary.

Never get tired to inquiring your project's documents because, you know, the devil is in the details.

I believe that not to specify clearly project objectives is not a smart (and obviously not a S.M.A.R.T.) shortcut but the highway to failure.

Measurable

All the objectives must be measurable. Period. Always. Period.

If you do not have measurable objectives, it will be impossible to determine if you have been successful or not. It will also be impossible to determine the degree to which the project has fulfilled its expectations.

Also as you might rationally decide to terminate or to continue the project, if you do not have precise targets to measure progress? How could you reassess  the business case? This could result in a massive expenditure of money without proper justification. Also, if you haven’t properly quantified your objectives, it is consequently impossible to determine their risk exposition and, as a consequence, it is impossible to determine the project’s risk exposition. No good. Believe me. 

The problem here is to find proper ways to measure objectives.

Even this one can be a daunting task, depending on the particular industry you are in.

It is easy to measure the number of defective pieces of equipment coming out from a production line, or the lifetime of a new electric bulb. It is more difficult when it comes to customer satisfaction, software quality, reputation improvement, products quality improvement...In these cases an indirect measure could do the job.

As an example you could measure the number of contacts of your customer service  and put it in relation with an improvement or a worsening of your products.

The bottom line is: everything can be measured, the problem is to identify suitable measurement units. It is a complex problem but is a problem that can be and must be solved.

Achievable

Some objectives just do not go well together. They seem to live in orthogonal dimensions.

Sometimes it seems that a complete scope, a fast time to market, a low budget and an high quality standards mix well...as oil and water.

So take care in having an achievable and consistent set of objectives. If it is not the case, try to reconcile reality with management's desires and expectations.

Never start a project that has not achievable objectives, pretending that everything is just fine and thinking ahead how to justify the unavoidable failure or below average performance.

Realistic

Everyone would like to be in charge of the next multi-billion dollars, thousands resources, hundred contracts project, with all the whistles and bells. Reality is, many times, different. 

The project manager’s duty is to reconcile budget, time, scope, quality and all the other constraints into a shared and satisfying vision, be he/she in charge of a mega project or working in small businesses. The duties of a project manager toward the sponsor and the stakeholders do not change with budget’s size. Again, he/she must reconcile reality with management desires and expectations and must resist the temptation to artificially raise the bar in order to magnify its own role.

Time Bound

Every project should have a starting date and an ending date. Every objective should be achieved in the defined timeframe. Benefits could be achieved later on but a time span have to be defined as well.

This is an important commitment for a project manager.

So there is no point in defining objectives that cannot be achieved in the project timeframe or in the expected time for benefits realization, once project products are released in the operation environment.

Otherwise, an attitude of this kind could frustrate team members, create distrust in corporate management and alienate stakeholders. 

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Project management resources from Tasmania

Tasmania is an archipelago comprising more than 300 islands situated about 250 Km south of the Australian continent, from which is separated by the Bass Strait. The main island is named Tasmania after Dutch explorer Abel Tasman, who reported its existence on 1642. 

It is a sovereign state and counts nowadays more or less half a million inhabitants.

These are all well known facts but there is something peculiar that maybe not everyone knows.

Tasmanian government on its own created a project management framework named Tasmanian Government Project Management Framework, comprised of the Tasmanian Government Project Management Guidelines and many supporting resources. I have come to know this attending an amazing presentation given by Sean Whitaker at the last Project Management Institute Global Congress in Vancouver.

This framework has been realized to be a guideline for every Tasmanian government agency and it is freely consultable from here, the official Tasmanian government web site.

Resources that can be found are

• Mailing list. It was meant to be a way for sharing project management ideas between Tasmanian government employees. However to facilitate collaborations between public and private sectors subscription is not subjected to any restriction.
• Framework documentation and generic project management tips.
• Templates for generic project management activities related documents. 
• Checklists to assess project characteristics or the degree best practices are being implemented.

All materials is organized in sections

Getting started in project management
This section provides informations and resources on basic project management topics, to help everyone get started in basic project management activities.

Project life
This section provides informations and resources to help managing projects, organized in a kind of project life cycle. We can find here tutorials and templates to organize the project, create Gantt charts, create WBS, report the project status,...

Project management guidelines
This section describes how to manage a project following the Tasmanian government framework, identifing and explaining all the included key processes. This document is realeased under the creativecommons Attribution 3.0 Australia license.

Supporting resources
This section contains resources to help project managers to set up and manage projects like fact sheets, templates toolkits...

Project Management advisory committee
This section contains the meaning and the pourpose of the tasmanian government project management advisort committee (PMAC for short).

Further information

This section mainly contains examples and presentations.

As I said all the material is freely consultable from the internet and I have proposed it in this post as a source of information and for self-learning pourpose. If anyone is interested in downloading part of the material here presented and using it to manage his/her own project, I recommend to ask for permission following one of the many information links provided by the Tasmanian government on its official web site.

These resources could be very useful for someone who is taking his/her first steps in the project management world, as it essentially covers basic project management principles and activities.
Nonetheless I think that even an experienced project manager could get some benefit. 

Who knows where the next good idea or tip will come from ?

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Is life a bad chartered project ?

Once a friend of mine told me "Life is strange. Usually when you have the necessary introspection capability to make a choice, you discover that it is too late. Either you have already taken the wrong decision years ago and the chips are down now, or you have to drastically reduce your expectations and targets. This happens many times and in many ways."
I totally agree.
For example you have to choose which degree apply for when you have little idea of what you would like to do in your life. You become a lawyer and maybe you would have been more happy as a doctor.You will discover it...that's sure...but it will be too late.
Maybe one day you wake up and say out of the blue "Here I am...I want absolutely learn how to play jazz guitar...I will play in a band...I will...". But then you realize that you are 40 years old, with a full time job and 2 kids to play with. You still can learn jazz guitar...but you probably will end up playing "Autumn Leaves" or "Blue Bossa" alone in your basement, late at night, without having any clue on how to play a decent solo.
Doesn't this ring you any bell? Isn't this the same situation you will find yourself stuck into when you are managing a badly chartered project? Isn't this what you get when you realize to have put too little an effort in writing a project charter, either because you couldn't or because just you wouldn't ?

In a badly chartered project you will come at a point where the product you deliver is not what it should have been, when there is no more way to satisfy requirements or hit objectives. You can be sure of this.
Or, if you are lucky enough, you will come at a point where you have to dramatically review objectives and savagely cut scope, time, costs, quality...or all of them.

The result doesn't change...a failure.
Maybe you will succeed in make the sponsors and the clients buy in your deliverables...but they won't be properly satisfied and at the bottom of your heart you will feel that you have failed in some way.
So when you are taking up a project be careful to understand what is in the charter and what it is not and that both things be understood by the sponsor and key stakeholders.
This is a good rule of thumb even you are helping chartering the project.
So what do we hope to find in a solid project charter?
Well...many things...there is no silver bullet in this game...but if I had to write a list I would recommend at least

• A detailed project description, including high level objectives and requirements. Sometimes stating what it doesn't belong to the project is as valuable as writing what it is a part of it.
• Solid and well explained business case. This automatically define your options when it is time for change and/or control. If you know what is at stake you can choose which project constraints optimize at expenses of others. Moreover if the business case expires it is right that the project dies.
• Most important constraints (time, budget, quality, ...). Also these informations help you in revising your options when it comes the time to change. 
• How project objectives contribute to company objectives. This shows the value of your project as perceived by your company and the strength and the effort you will be allowed to profuse in your quest for success.
• High level project risks. 
• High level stakeholders. If you don't know by now who will be most influenced by the outcomes of your project or can influence the results in a massive way you will be rushing headlong toward disaster.
• High level deliverables. If you don't know what you will be asked to deliver how would you possibly deliver it ?
• Project manager authority. What are you in charge of ? You must know what you are entitled to do, which actions, countermeasures and decisions you can take and which you cannot take.
• Time horizon of the project. 

If you cannot states all these informations at least at a very high level...well...it probably means that you don't have the necessary insight  into the project to charter it in an effective way.
If you can't describe it you can't project it and if you can't project it...it simply means that you can't do it.

So take your time and try to analyze every aspect of your project before finalizing the project charter, because it is the foundations over which your project will be build and because once released, you and your team will be committed to it. 

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.