What is the PRINCE2 methodology? Part 2: Themes

14 Oct, 2026

Prince of Persia 2. Yeah, I’ll continue using images of this game.

Welcome to my second post on the PRINCE2 project management methodology!

In my last entry I talked about PRINCE2’s seven principles, which represent the guiding concepts you have to follow keep true to what a "PRINCE2 project" is. This week I’ll be talking about the seven themes, which represent different questions related to project management that you must continually ask yourself during the development of a PRINCE2 project.

While the methodology does define specific artifacts for each theme and the associated roles/responsibilities, I will focus on the general ideas and leave it as an exercise for the reader to find the best way to adapt these ideas to their project.

The Seven Themes

Business Case

This theme is about answering the why.

While we already talked in the last post about the “continued business justification” principle, the focus there was on making sure you had the business case and continually checked or revised it. The theme looks to answer how to build the business case and defines the parameters your case should include. First of all, you need clarity on your project:

• Output: What is the concrete artifact that will be delivered by the end of the project?
• Outcome: What results do we expect as a consequence of completing the project?
• Benefits: How will the outcome positively change the organization?

Admittedly, for most games this is generally pretty straightforward: you want to make a game that people enjoy and sells well.

But I think it’s also a good framework to ask more nuanced questions about how this particular project can fit in your larger organizational strategy — if you’re making a horror game, are you aiming to position yourself in the market as a horror game developer? Maybe you’re not confident about the multiplayer game the team is developing but it doesn’t matter because the goal is for the programmers to learn the technology? etc.

One you have clarity on your project, you can use it to define the business justification, which is divided into three points:

• Desirable: If we evaluate the balance between costs, benefits and risks, does the project still seem like a good idea?
• Viable: Do we have the resources to deliver this project?
• Achievable: Are we confident that the output will actually result in the outcomes and benefits we’re hoping for?

The “achievable” bit here is definitely the load bearing one and where many projects trip up because it’s so hard to answer. For example, in games it’s easy to see the graveyard of live service titles that believed they would be able to achieve a fraction of the success of Fortnite or other similar titles.

Organization

This theme is about answering the who.

PRINCE2 divides stakeholders into 3 groups with different responsibilities:

• Business: Represents the organization and makes sure the business case is followed.
• Users: Represents the audience of the final outcome of the project.
• Suppliers: Represents those who are building the project.

There’s admittedly too much detail here so I’ll gloss over it (I’d need an entire post to describe the responsibilities of each of the 8 roles...), but I did want to mention one of the interesting ideas I read about.

Although PRINCE2 defines 8 roles, in some case a single person can assume multiple roles. That said, there are certain roles that shouldn’t be combined to avoid any conflict of interest (e.g. if someone represents both the business and the users, they may compromise what’s best for the organization by prioritizing what would be good for the user).

This one made me think a lot about how indie teams are shaped — as they are small, most team members will have multiple roles, and many times that division tends to happen naturally depending on each team member’s interests and affinities. But is that really the best way to handle it? One of healthy dynamics we had in my studio Smarto Club was that production and creative direction were separate people, and that created a natural back-and-forth between doing what was best for the project and what was realistic for the team and budget.

Quality

This theme is about answering the what.

PRINCE2 approaches this question with techniques common to many software project management methodologies: “quality” is defined as a list of requirements that the project must meet, with acceptance and quality criteria for each. The idea is that these requirements must be defined early on, and everyone on the team should be in agreement when building this list to avoid conflicts later down the line about what constitutes a successful result. This list is not a static artifact and can be changed as the project evolves, but it must exist somewhere everyone can see it.

The other important element in this theme is answering how we approach quality management. Who is tracking whether the requirements are being met? Who approves if a milestone delivery of project has met the acceptance and quality criteria? And who is making sure that quality is maintained for all requirements across the entire project development timeline? As mentioned in the previous theme, these responsibilities do not necessarily have to belong to different people, but you must be careful to avoid conflicts of interest.

Admittedly this is a extremely difficult topic in games - if agreeing on a list of requirements was all we needed to ensure we were making an amazingly fun project, making hit games would be easy! That said, it’s still true that if we spend time early on agreeing about our expectations for features and the quality we expect them to hit, then we’ll be better positioned to adapt and evolve as the project grows.

Plans

This theme is about answering the how, when and cost.

Plans are at the essence of any project management methodology, and PRINCE2 is no exception. Without a plan, we have no baseline with which to compare if we’re on-track to deliver or not. Without a plan all we have is improvisation.

I appreciate that PRINCE2 is clear about how it doesn’t make sense to develop an extremely detailed plan for the entire project from the start, and instead approaches planning as a process where you develop a general project plan and only create a detailed “stage” plan for the work until the next key milestone in the project plan. I talk about a similar idea in one of my previous posts!

Plans are also an excellent place for PRINCE2’s principles to be applied:

• Are you including time in your plan to reflect and learn from any mistake or unexpected situation during the development of the project? (Learn From Experience)
• Beyond the process, what are the concrete results you expect in this stage at the project level? (Focus on Products)
• How complex is your project? How many stages will you require to ensure proper stakeholder alignment and approval? (Tailor to Suit The Project)

This theme is a particularly good example, but the key to PRINCE2 is to always consider the principles as they answer each theme.

Risk

This theme is about answering the what if.

Uncertainty is a constant in any kind of project. We can’t pretend that all our plans and process will eliminate it, so PRINCE2 proposes having a clear approach to risk management that allows us to mitigate negative consequences from undesirable scenarios.

PRINCE2 suggest that a good risk management framework has the following elements:

• Identification and assessment: What are potential risk scenarios we should be prepared for? How likely are these scenarios? A common tool for assessment is calculating a “risk exposure” score based on it’s probability of happening against the impact of it happening.
• Plan: How will we react to the risk if it does happen? Is it worth proactively doing our best effort to mitigate it? Or is the the probability or impact low enough that it is enough to have a contingency plan in the case it does happen?
• Risk Log: All this thought process should be tracked somewhere and constantly revised - old risks may become irrelevant or change based on our understanding of the project, and new ones will appear as we advance.

The risk log is key as it relates to the Learn From Experience principle. In the case a risk does happen the team should track what happened and if the plan was actually useful, as this will be extremely useful information for teams later on.

Change

This theme is about answering how we react to the unexpected and the impact of changes.

As it is commonly said, no plan completely survives its first encounter with reality. So how do we adapt? PRINCE2 use the term issue to refer to any unexpected event that requires or causes a change in the plan, and requires these events to be tracked to be sure we’re clearly identifying their origin and implications.

Based on our understanding of the issue, we are able to suggest changes that we can evaluate based on the advantage gained against the impact of implementation. These three variables allow us to evaluate the best path forward. An issue with minor implications might be worth ignoring if all possible changes provide low advantages for a possibly negative impact. If the issue cannot be ignored, we’ll usually go for the option that provides the best ratio of high advantages versus low impact.

I think helping guide the team through change is one of the most important roles of a producer on a game. Iteration is such an important part of game development that change is constantly happening, but a good producer is ensuring that team is always conscious of the impact of change and that all relevant parties have their say - a change might make a lot of sense to the game design team, but it may not be a good choice if it’ll double the workload of the art team.

Progress

This theme is about answering multiple questions: Where are we now? Where are we going? And should we continue?

It’s natural for projects to change and evolve during development, and this is a good thing! But that also means we have to be especially careful that we’re constantly revising our progress against our original plans and intentions - I’ve seen teams get carried away by optimism which blinds them to being behind their original schedule or not having a clear way forward after changes they’ve made to the project.

As with the plan theme, the progress theme is deeply related to the “manage by stages” principle. PRINCE2 makes it clear that you need a mechanism with which to regularly track the actual progress of the project against your plans, and to track how your plans are evolving as you better understand what you’re building.

Having this information is key when we’re evaluating our business justification at each stage, as a project that made sense originally might not be justified anymore if we realize that our progress is much slower than what we originally estimated, or if we’ve realized that the work to get to the required level of quality is higher than the work we are willing to invest in.

In games, you will see this kind of evaluation highly tied to the elusive “fun” I have eluded to earlier. In many cases, projects will be cancelled if stakeholders are not confident about the game being fun enough whether that comes from playtests, mock reviews, or simply internal developer opinion.

And that’s it on themes. Next post I’ll be closing this series with the last big category in PRINCE2, the 7 processes that unify all these ideas. Until then!

{{ end }}