The Game Producer's Quest Log

What is the PRINCE2 methodology? Part 1: Principles

Prince of Persia 2

Prince (of Persia) 2. Close enough?

Have you ever heard of PRINCE2?

While the “prince” part might evoke some fantasy-related imagery or a certain Persian adventurer, PRINCE2 is actually a project management methodology developed in the UK. The name (currently) stands for “Projects in Controlled Environments” and this second edition was originally launched in 1996.

Despite considering myself informed about the space, I hadn’t heard about this methodology until I saw it mentioned in Doug Pennant’s The Pocket Mentor For Game Production (an excellent read!) and was curious about learning more. While I’m the kind of producer that hates sticking rigidly to any methodology, I do love learning about different methodologies so I can pick, choose and adapt them to my project and teams.

The core of PRINCE2 consists in 7 principles, 7 themes, and 7 processes. Going through these 21 ideas in a single post might be too much, so I’ll be breaking it out into 3 posts. Besides a quick overview of each concept, I’ll also give give a quick commentary on what I think of each and how it relates to my experience in games.

Disclaimer: I’m not a certified PRINCE2 practitioner - my main reference was online research and “Managing successful projects with PRINCE2” (2009) but with how much these methodologies are updated some of things I write about may be outdated!

The Seven Principles

Continued Business Justification

Why are you developing this project? Are you recording this somewhere? Are you constantly revising and updating if needed?

This principle aims to capture the importance of having a clear “why” for your project. Without it, it becomes challenging to evaluate the value of the project and you might end up continuing development due to inertia or sunk cost fallacy instead of a strong reason.

In large organizations, a clear business justification also helps revise if the project is aligned or not with the larger organizational strategy, and is not overlapping with other projects in the portfolio. PRINCE2 is open to the justification being changed throughout the project, but for this to happen, you need to make sure you’re revalidating it at regular intervals.

This a principle you can see clearly in AAA — most large studios and publishers have regular processes in place to share and evaluate progress on games, and projects that under-perform or no longer make sense are cancelled. Thinking about this does make me wonder if its a practice that indie developers should practice more often. Many indie projects are born from passion, but as a result you see many stories of indie teams stuck for years on a single project or taking risky financial decisions that might not make sense if were evaluated against a concrete business reason to develop the game.

Learn From Experience

While an intuitive principle, PRINCE2 does a great job of emphasizing how improvement is a result of seeking out lessons, recording and then acting on them throughout a project.

While retrospectives during a project are a common practice across methodologies, I particularly like how PRINCE2 points out that, especially if this a new kind of project for the team, a key task is to spend time at the start looking at similar projects to review what lesson are applicable to your own project. And related to that, at the end of a project PRINCE2 recommends saving and share out your lessons that could be useful to other teams.

Thankfully, people in game development are generally extremely generous about sharing information, and there is a wealth of post-mortems or GDC talks that you can use as a starting point when developing your own game. That said, a challenge is that the game industry is always rapidly changing, and even lessons that made sense 5 years ago can be out of date today.

Defined Role And Responsibilities

Projects cannot succeed unless they have the right people involved, and these people need to know what is expected of them and what to expect of others.

PRINCE2 separates the project management team into three stakeholders with their own responsibilities:

It’s an interesting exercise to attempt to map this to games. It’s intuitive to see a publisher as the business stakeholder and the developers (usually, each team lead) as a supplier stakeholder, but who represents the user? In some organizations, I’ve seen product managers who exist to represent the player and their wishes, but in others that responsibility ultimately falls to someone like a creative director. In some teams, different people own different parts of the project and have the final say on the elements they own. There’s no correct answer, but regardless of the way you slice it it should be clearly defined!

Manage By Stages

This principle refers to the specific way PRINCE2 breaks down a project in discrete phases called management stages. The idea is that at the end of each stage there is a moment to review progress to date, the state of the current and future plans (especially the next stage plan) and as previously mentioned, review if the business justification still makes sense.

While there is some additional formal details related to concepts like “end stage report” and “end stage assessments”, the general idea here is to have a clear plan that is reviewed at certain gates with stakeholders, while leaving the day-to-day management to each team’s specific project managers.

What I found interesting is that PRINCE2 doesn’t explicitly define a sequence of stages, instead suggesting that beyond the initial set-up stage the amount of stages required by a project depends on the complexity and risk of projects. While each game studio has their own way of defining gates and milestone approvals, I do find it interesting how games have a certain degree of standardization with stages like pre/post production, production, vertical slice, horizontal slice, alpha, beta being used amongst almost universally across games even if not formally or if people use different names for them.

Manage By Exception

As brought up in the previous principle, PRINCE2 tries to leave the day-to-day details to the team and their project manager, while only requiring the complete stakeholder team for stage revisions. But what happens when something “exceptional” that wasn’t in the plan happens?

PRINCE2 recommends agreeing on tolerances for these six aspects: cost, time, quality, scope, benefits and risk. For example, if the agreed upon tolerance for time is +3 weeks, then there is nothing to worry about if a milestone is delayed by a couple of weeks — but if the delay is over a month, then the team will have to escalate the issue to the stakeholder team.

It’s honestly something I’ve been thinking a lot about now that I’m working in a larger organization and have discovered how noisy it can be with so many different projects going on with very different teams and priorities. As my boss wisely puts it: how can make sure we're only providing clear signal to stakeholder and not noise?

Focus on Products

This a meta principle that demonstrates good self-awareness from the methodology: a good project is a result on focusing what the project needs to produce, not the process behind the work. The idea is ensure that the work that is being done is actively providing value towards the final user in someway, and that the project is actively seeking out and mitigating risks that may cause user dissatisfaction in the final result.

You can see this idea expressed multiple ways, but this is why I generally talk about being a “player oriented producer”. Players are the final user of any game, but it’s easy to get in the weeds of implementation and technical details and forget how your day-to-day choices are impacting the experience of the player.

Tailor to Suit the Project

Another self-aware meta principle: PRINCE2 promotes itself as a “universal” project management methodology, but the only reason it is truly universal to different types of projects and teams is that it can be tailored to suit the needs of each project.

While PRINCE2’s specific recommendations on what tailoring it should look like are out of scope for this post, I do like some of the points it makes like:

Especially as I talked about at the start of the blog, I prefer not sticking too close to any methodology and instead mixing and matching, so I appreciate a methodology pointing out that you should only use what makes sense for your case.

And that’s all for this week! I’ll be back next week talking about the 7 themes. Any principle that resonated with you in particular? Please let me know!

{{ end }}