How to get out of a Project Nightmare! -Using the PRINCE2 Principles-

So you are a project manager and your project has been falling in pieces and going completely off target. Or, alternatively, you are a new project manager and you have been asked to jump on a sinking project to help put it back on track.

What would you do? A good place to start is looking at the “7 PRINCE2 Principles”.

Why? Well, these principles can be seen as a good list of critical success factors for projects . This means not fulfilling all of them could increase significantly the probability of failure and no-one likes a failed project.

The seven PRINCE2 principles are:

  1. Projects must have “continued business justification”
  2. Projects must “learn from experience”
  3. Projects must have “defined roles and responsibilities”
  4. Projects must be “managed by stages”
  5. Projects must be “managed by exception”
  6. Projects must be “focused on products”
  7. Projects must be “tailored to suit the project environment”.

Let’s discuss the principles here below.

Projects must have “continued business justification”

Your project might be dragging on, with close to zero interest in its progress, for one simple reason:

The business idea behind the project might just not make sense anymore if it did make sense from the very beginning!

A few questions to ask should be:

  • Does the project have a business case?
  • Was the business case released and approved at the beginning of the project?
  • If yes, has it been continuously maintained and reviewed during the execution of the project?

If the answer is NO to one or more of the questions above, you should stop and escalate this fact and ask why there is no valid updated business case and start working on it.

Let’s say, that if your project started without some sort of business justification, there can be a chance that the project is just not worth doing. Even if a business case did exist at the beginning of the project, its assumptions and conditions could have changed. Consequently, an update and review would be required to see if the project is still viable and desirable.

Now..I know what you’re thinking: who creates business cases nowadays for their projects? Maybe 20-30% of the companies? This figure may be optimistic.
The fact is you need a justification document for your project because this is a key project driver. If your project is a simple one, you could do good use of an excel table with a brief reason description, a reference to the business options, benefits, a ROI calculation, time and cost estimations and major risks.

For a better and practical idea on how to make this simple, see:

Projects must “learn from experience”

Every project should “learn” from past experiences. Lessons to be learned include both negative lessons AND the positive ones.

This principle helps you escaping the nightmare your current project is facing by supporting the root cause identification, and it does that by asking the following questions:

  • Is there a lessons learned register or database for this project?
  • And for other projects in the organization?

If the answer is NO to one or more of the questions, you should ask to start a lesson learn workshop for your project and, if possible, take into account similar projects in the organization portfolio.

Looking at the lessons learned in your project and similar projects is a great way to solve your current issues and avoid repeating similar ones in the future. The goal of these discussions should be to seek and capture the lessons, the causes, and the actions put in place. A good percentage of the issues projects face are caused by systematic root causes which have impacted or are impacting also similar projects your colleagues are managing.

Projects must have “defined roles and responsibilities”

Every project should have all the roles and responsibilities clearly defined.

This seems quite straight-forward but, oddly enough, it’s a very common cause of project mismanagement and quite typical in organizations with a low maturity in project management.

The project roles and responsibilities are often confused with the resource functional roles and responsibilities. So, of course, each person will have a clear role in their company but that doesn’t say everything (or nothing at all) on what they are accountable for in a project.

So, the first thing is to aim at having a clear project organization at all levels (at direction, management and delivery).

Direction level questions:

  • Who is the ‘executive (or sponsor)’ for the project?
  • Who are the ‘senior users’ for this project?
  • Who are the ‘senior suppliers’ for this project?
  • Who signs off on the products as they created?

The roles and responsibilities above form the “project board” or project steering committee.

Not having these people on board will make It almost impossible to sustain a robust “governance” and direction for your project. (Remember: no direction, no delivery!).
Management level questions:

The next project organization level is the “management level”. This is where the project management acts.

  • Is the project manager clearly identified and officially recognized?
  • Is project support required for managing properly the project?
  • Is the change authority well identified and clear?

The project manager responsibility should be clearly identified and recognized by everyone. Low maturity organizations could have an ambiguous project management role with an unclear responsibility.

Delivery level questions:

Now let’s look at the organization of the delivering level: where the execution and delivery of the specialist products are done.

  • Are all the skills required, to deliver the project, clear and acknowledged by the team?
  • Do you have a resources with the right skill at the required time?
  • Have the resources ‘accepted’ the responsibility and are they fully aware of what is expected by them?

In order to deliver the agreed products, the specialist skills required need to be identified. Then real people need to be assigned to those skills.
One of the biggest challenge lots of companies’ face are having limited resources shared between a significant number of different projects.
Project priority decisions could be required at project portfolio level and, in case, the project plan will need to be updated accordingly and in alignment with resources availability.

Finally, resources should “accept” their project role and responsibility. This won’t reduce risk of losing them for personal or professional career reasons but at least it will enhance the opportunity of high performance while they are on board.

What would happen if you based all your plans with the assumption to have a key resource, and two weeks after he/she resigns? It wouldn’t be a good plan, wouldn’t it?

Projects must be “managed by stages”

Another potential reason why your project could be in bad shape is because of a lack of key high-level decision making when needed.
Why should a project be divided by stages and managed one stage at a time?

Simply because a project is made of uncertainties and you just can’t predict everything from the very beginning. Another reason is that strategic decisions need to be made and it might be impossible to make them at the beginning due to the lack of information available.

These stages are called “management stages” and they are used as a mean for “control” by the project board. They are basically smaller chunks of a bigger project with decision points for the project board at the end of each stage.

Key questions:

  • What are the key decisions you need from the project board and when are they required in the project?
  • How confident are the project board and project manager at proceeding?
  • How far ahead is it sensible to plan? What is your planning horizon?

The board might want to have more frequent formal stage review moments for a highly innovative or a complex project. Some companies might have a standard and formal stage-gate review process as well. In case of an extremely innovative research or development project, it would be hard (and not so productive) to plan too much ahead, meaning that your horizon for planning is not that far.

Shorter the planning horizon, more stages there will be in a project.

Projects must be “managed by exception”

Projects should have a clear and proper delegation structure which allows each level and role to work with a sound accountability avoiding two typical mismanagement behaviours: micro-managing and lack-of-management.

Both behaviours can cause: team frustration, lack of performance, poor accountability and poor ‘team buy-in’.

So how do we solve this?

The 5th PRINCE2 management by exception gives a structured system for delegation and escalation.

We do that by defining tolerance levels on the project objectives (time, cost, quality, scope..etc) which define authority thresholds for the three levels of the project management team (direction, management and delivery).

So each level, when there is an issue or risk which exceeds the agreed tolerance, will escalate to the level above. On the other side, within the agreed tolerances, the related lower levels will have all the empowerment to work on an activity. This supports the empowerment of your team.

Let’s take a look at the related questions you should get the answers to.

  • Is there a clear escalation and delegation structure in place?
  • Is the team aware of their level of authority?

Ensuring this principle is put in place will help you build a high performing team, where everyone is used at full potential.

Projects must be “focused on products”

Another potential problem your project might be facing is: not having a clear end goal.

In other words, you could be working towards a plan which is not going towards the right direction.

This happens more often than you can think and, particularly, when the overall project management is not focused on the products meant to be delivered in the first place!
This point is strictly related to the planning theme. Planning should be “product-based” or “deliverable-based”. This means, basically, concentrating on the products delivery/realization and not on the activities.

What happens when we concentrate on “activities” and not on products? Well, we can become less focused on the end objectives and it becomes harder to control progress of our project.

  • Here are the related questions you should get the answers to for this topic.
  • Have all the required products/deliverables been identified for the ongoing stage?
  • Does the detail stage plan include all the products to be delivered?
  • Have all the required products been identified for the project?
  • Have all the quality information and acceptance criteria been clarified for the product and the project?

We should keep in mind that the reason the project started in the first place is to create the final product or products. Activities and work are only the mean to get there. Being focused on products allows us to identify more efficient ways to reach our goal and, of course, ensures we keep a good track on our project status.

Imagine what would happen when a product is not clearly understood by your stakeholders, and ambiguously described. This could make your project stakeholders have different ideas on the product and different expectations on the quality required.

Projects must be “tailored to suit the project environment”

One last thing to look at is: if we are applying project management properly, considering the context and project.

Project management methodologies and best practices, being PRINCE2 or others, are important but they need to be adapted to the particular project environment. You just can’t apply it by the book.

Let’s think of typical cases of bad tailoring:

  • Complex project with insufficient management control and documentation.
  • Simple project with excessive management control and documentation.

Both examples can increase significantly the probability of failure and should be addressed.

Unfortunately, tailoring project management is not easy at all and experience is required.

Here are the questions you should get the answers to.

  • Is the effort required to manage the project too high compared to the value it brings?
  • Is the level of management control and documentation lacking in terms of information and data compared to the complexity of the project?
  • Is the project management language used understood by everyone or would other terms be more familiar to the project team?
  • Are other projects in the same organization being managed differently?

Remember that the goal is to keep the project management at the right level of detail which provides the proper level of control without exaggerating in bureaucracy.


Putting together all the points analysed above could be a powerful start to identify some key gaps in how your projects are managed and delivered. Once these gaps have been addressed you can look for ways to solve them (perhaps implementing and tailoring proper project management behaviours, mindsets, processes, themes and techniques).

Note that the PRINCE2 principles are not the only points to analyse in order to improve your project management, but they represent a great starting point.

There are also project healthchecks and project management maturity models which could be very useful as well. More on those in another article.

This article was based on the PRINCE2 Principles. PRINCE2 (Projects In Controlled Environments) is a project management methodology and best practice owned by Axelos Global Best Practices.

I hope you enjoyed this article.


Ciro Sbarra
Project management consultant and trainer

No comments yet.

Leave a Reply