Crossword of the week

I hope you will enjoy this crossword. Another fun way to increase our PRINCE2 knowledge.

Correctly defining Business Benefits in a PRINCE2 project.

We know the Business Case is owned by the Executive of the project.
The Executive being a ‘busy person’ will most likely ask the Project Manager to ‘write’ the Business Case.

The Project Manager may however not have all the knowledge or access to all the information required to create a full Business Case. But she/he must ensure it is done and ask the right people to give the right level of information to be able to finalise the document in IP3 (Refining the Business Case and Risks).

When you start using PRINCE2, the most difficult part of the Business Case is most likely going to be the identification and definition of Business Benefits of the project.

It helps to confirm what Benefits really are as often they are understood to be solely profits. This is not the case as there can be many more types of benefits beyond the simple profit defined as the result of turnover minus costs.
You can define legal benefits, technology benefits, human benefits, environmental benefits and many more depending on the exact nature of the project.

Some projects may never result in pure financial profits, some will even loose money to the company but they are nevertheless compulsory for the viability of the company.

A good example of this are projects of compliance with new legal or regulatory requirements, a new law or a new european directive.

Another example are data migration projects allowing various legacy systems to function together as one operational entity.
Projects of that nature will most of the time cost organisation money without bringing any direct profit. There are nevertheless essential to the good functionning of the business operation and should clearly be done.

When defining the benefits you’ve identified, ensure you make them as measurable as possible.
Don’t forget the Executive will do a Post Project Review of the project outside of the project once those benefits have become measurable, so we need to know how to analyse them in clear and unambiguous terms.

john higham
the french PRINCE2 expert based in France

TATs and UATs

It is good practice to control the quality of what is produced during a project.
In PRINCE2 this is done in MP2 once the product has been created, manufactured or otherwise assembled.

In other circumstances, these quality checks are often called TAT or Technical Acceptance Test. In reality, PRINCE2 refers to those as product approvals (this can be applied to both management and specialist products).

The method of control for the final product will depend of the environment and will be defined in the Project Quality Plan (IP1) and confirmed for each simple product in the Product Description (in PL2). This Product Description is then added to the Work Package and agreed between the Project Manager and the Team Manager (if there is one) or the Team Member who will do the work (this happens in CS1-MP1).
Once products have been approved, they still need to be accepted by the Project Board.
This happens at the end of each stage during the End Stage Assessment (in DP3) for each product created during the previous stage, and at the end of the project for the final product (in DP5).
These are often referred to as UAT or Users Acceptance Tests.

Which tool for which project.

Often people want to know which tool or software should be used when applying PRINCE2 to a project.
The answer to this question can be quite tricky as there is no unique definite answer.

There are many tools available, from pen and paper to the most sophisticated networkable collaborative application.

This choice is often made by the company’s quality and systems department who has decided once and for all on the tool of choice (mainly because had a good deal or a good price for a large number of licenses and not because it fits the company’s requirements…).

You really need to see the needs for the particular project you are working on more than which tool is available to you.
In fact, if the tool is a hindrance to you, change it as quickly as you can to adopt a more flexible solution. In some cases, management will expect the use of certain tools and you then have to comply to their expectations.

A simple rule though, keep your reporting simple and to the point. Remain flexible and use as many generic tools as you can.
This way you will be able to drive your project and not administer it.

The role of a project manager is to ensure the project is done (on Time, on Cost and on Quality …) not that it is beautifully documented.
If documentation is a requirement, ask for some project support to assist you.

john higham