Skip to content
Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

The PRINCE2 generalised approach

Does the PRINCE2 generalised approach suit the challenging environment faced by IT projects, particularly in relation to risk management?

Introduction

PRINCE2 is recognised as a leading standard approach to project management, but can it be deployed successfully, especially with regard to risk management, in the challenging environment faced by IT projects?

PRINCE2 is a methodology

PRINCE2 is a methodology and a series of processes and controls; it guides and encourages one towards all the processes and steps recognised as good practice. PRINCE2 itself is not the problem and what it says is very sensible and easy to apply. The difficulty comes from people not understanding the concept of risk and poor application.

PRINCE2 and risk management

If people correctly defined risks in terms of cause, uncertainty and affect the resultant management activities would be much more effective. Risk registers can contain meaningless statement of effects or causes and it's left to the reader to decide what the risk is. 

The PRINCE2 approach to risk should be effective in IT or any other discipline, if it's applied correctly, and takes into account the wider risk management tools and techniques available, which is how it is designed to be used in the first place.

Where risks are shared across organisation and contract boundaries, this is the realm where the skill and experience of the Project Manager needs to come into play, particularly in the fuzzier world of technology projects. It is down to the personal touch and the ability to develop constructive and trusted relationships. Only then can shared risks be adequately and openly managed.

The PRINCE2 method gives some of the most comprehensive treatment of risk for the following reasons:

  • PRINCE2 emphasises tailoring of your project management approach and one of the key factors in tailoring the approach is the "risk profile" of the project, so already at a high level before you even get into the 'meat' of managing the project you are already dealing with risk.
  • The PRINCE2 approach to risk goes beyond the usual focus on risk to the project schedule/cost and seeks to address risk to the "achievement of the business case" that was used as the basis of approving the project and is closely tied to the principle of "continued business justification" which mandates change to the project particulars so that the business case can be met or aborting the project if the business case cannot be met. Additionally any major change that is approved for the project is assessed for its impact on the risk profile of the project and it is this inter-linkage of these factors which I think makes the approach very useful.
  • The PRINCE2 Risk theme defines 4 steps (Identify, Assess, Plan & Implement) and "Communicate" being a step applicable throughout the risk lifecycle which if applied properly would be effective in dealing with project risk.

However, an alternative view is that PRINCE2 does not allocate project risk anywhere in particular - for IT or non IT projects. This does depend on how the 'project' is viewed; client, supplier or project manager and IT projects often confuse these roles! The client can transfer part of a risk but never all of a risk, and some risks are not transferable.

PRINCE2 when it comes to risk management just provides the basic framework to manage it but is not helpful in actually dealing with the challenging environment of IT projects as they are complex and involve several dependencies.

A final thought in this section is at what point does a project go from one where the PRINCE2 risk management approach is enough to a project that requires a full on separate Risk methodology such as PRAM or M_o_R?

A tailored approach is required

As mentioned above, any process should be first tailored by the Project Manager and then administered by support roles to leave the Project Manager to do the "thinking" job. The tailoring exercise is very important and should align to the business needs and the type of project, always bearing in mind a potential QA process adherence audit in the future.

The paper by Bourne/Walker – “The Paradox of Project Control” on the Mosaic website discusses the different kinds of project and captures that different kinds of project require different approaches. This paper does note that construction projects/hard engineering are different from IT/organisation transformational projects; if this is accepted and the real life fact that there is a range of projects between those 'extremes' then no single approach will suit them all unless it is customised to fit.

Culture and awareness of risk

A risk log can never be “all you need”. Yes it is a good logging, assurance and tracking tool but the most important element is an awareness of risk, and a culture of managing risk. Having a ‘risk log’ can be seen as ticking the box of ‘do you have risk management’ but in fact the log is meaningless and management is no more than – have any risks changed this month?

There is a lack of awareness about risk management among senior management and clients that can only be addressed by creating a culture of risk and ensuring stakeholders understand risk in the context of their project.

The approach taken to communicate bad news to stakeholders (not just senior management) is important. It is useful to say up front that you think there's a problem and that you're trying to scope it and quantify the effect. If you subsequently find a way to fix it, go back and say so, you may earn some brownie points. If not, then go back and confirm the problem and. importantly, ask for help. This instantly means that the problem is shared and you're not isolated in trying to manage it. The formal risk review is the means to capture the record of discussions. If it then turns to rats, then everybody shares the pain. With reference to 'integration' across management, if you think about it, you are the integrating factor by the very job you do, which comes back to one of my earlier posts about managing people.

Summary

PRINCE2 is a methodology and a series of processes and controls; it guides and encourages one towards all the processes and steps recognised as good practice. PRINCE2 itself is not the problem and what it says is very sensible and easy to apply. The difficulty comes from people not understanding the concept of risk and poor application.

PRINCE2 does provide an approach to risk management but this must be tailored to the requirements of the organisation and the project. Adopting this approach, there is no reason why using PRINCE2 for IT projects should not be successful.

The experience of the Project Manager is important, recognising the need to be flexible and ensuring the stakeholders have a clear understanding of risk and how risks are communicated and managed.

Edited by Martin Taylor, with contributions from Roger Chankey, Sion Jones, David L, Nicholas Howarth, Dave Atkinson and Edwin Mpofu.

Does the PRINCE2 generalised approach suit the challenging environment faced by IT projects, particularly in relation to risk management? web briefing v1.0 13th September 2012

See the original discussion at: http://www.apm.org.uk/content/does-prince2-generalised-approach-suits-challengingenvironment-faced-it-projects-particular


About the editor
Martin Taylor is the owner and Lead Consultant of change360 and a full member of APM. Martin has over 25 years' experience in programme, project and business change management in private and public sector organisations.

martin@changethreesixty.com

www.changethreesixty.com

07703 029823

Web briefings

Web briefings are the developed from the APM Community, an online community of project professionals. They result from discussions and questions asked within the community, the content is developed from users’ responses and edited by APM.