What is the PRINCE2 methodology? Part 3: Processes
Prince of Persia 2
Welcome to the final post on the PRINCE2 project methodology!
In the previous posts, I’ve covered the seven principles (high level why/beliefs that guide a PRINCE2 project) and the seven themes (questions you should constantly be asking during the project), and we’ve finally reached the final pillar, the seven processes.
You can think of processes as the practical application of the previous ideas to guide a project from start to finish, and they map much more directly to specific stages or periods of a project. While in previous posts I’ve generally attempted to keep my explanations general and broadly applicable, this post will be much more in the weeds of the way PRINCE2 structures a project.
Also, a quick shout out to the PRINCE2 wiki — I only found it now during my research for this final post and some of its pages are still WIP, but it’s a super clean and useful resource!
The 7 Processes
Starting up a project
Before investing any significant time or resources into a project, you must decide if it’s worthwhile to even explore the project! This is the start up process.
PRINCE2 proposes the following questions to answer for the start up process that should all be captured in a project brief document:
- What is the project? What would the overall stage by stage plan look like?
- Does this project have a clear business case?
- How are going to approach the project? Do we have any similar past projects we can learn from?
- Who can we call upon to do the initial work on the project?
The idea isn’t to have an exhaustive response for each of these questions as they will be refined later, but perform a general sanity check to see if the project makes sense with all these points put together.
In games, this would happen before pre-production and I’ve usually just seen it called “research.” During this process a team should be able to identify the concept of the game, a general idea of scope in terms of team size and development time, and research if the investment makes sense compared to the potential returns of this type of project. Depending on how novel some of the concepts or mechanics are, it might make sense to make quick prototypes or concept art.
Many indie teams run into the issue where they jump into pre-production without having done enough research first, and end up facing issues either when looking for funding or when planning the rest of development, but these issues could have been discovered at the start if they had spent more time thinking about full project cycle.
Initiating a project
While the previous process is about questioning whether the project is worth doing given your resources, the initiation process is about laying a strong foundation to ensure the project is actually successful. The way PRINCE2 proposes to achieve this is by creating initial documentation around the project plan, stakeholders roles, quality/risk approach and business case that can ensure alignment before actual work on the project begins.
This is where the 7 themes I talked about in my previous post should be explicitly answered:
- Business Case: Why are we making this?
- Organization: Who is making this?
- Quality: What are we making?
- Plans: How are we doing it? When does it need to be done? How much will it cost?
- Risk: What if something goes wrong?
- Change: How do we manage the unexpected and the impact of changes?
- Progress: How will we measure if we are on track to meet our goals?
My first instinct is to say this process is what maps to what traditionally is referred to pre-production in games, but on closer thought, the focus is pretty different. Many times pre-production is thought of as the stage where the game is prototyped to validate stuff like fun and the pipeline (such as in Mark Cerny’s classic talk), but that inherently means a more iterative and less structured approach, while this PRINCE2 is about explicitly defining the process.
To be fair, it’s still something that you will have to do in a game development project, but I’d argue that it lives in the boundary between pre-production and production.
Controlling a stage
This is the process that refers to the day-to-day work of managing a project, and is the bread and butter of what you expect producers or project managers to traditionally do: assigning work to the development team, reviewing progress, and escalating when needed.
While not a particularly glamorous process, this is where the documentation created in the previous stage is put to practice. PRINCE2 isn’t particularly prescriptive of the rituals you use to manage this work, so I don’t have too much to comment on here — find what works best for your process and team!
Directing a project
This process is specifically about how to enable the key stakeholders to have the information they need to make key decisions over the direction of the project, while trusting the project manager or producer to handle the day-to-day management.
PRINCE2 breaks out the responsibilities of direction into five main activities:
- Authorizing Initiation: This refers to the transition from the start-up/research stage (should we make this project?) to the initiation stage.
- Authorizing the Project: Once the initiation is complete, the stakeholders will review the project plan and decide whether it makes sense or not to enter full development.
- Authorizing a Stage: For each stage a project has, stakeholders have to approve the work done and decide and whether the project can continue.
- Authorizing Closure: At the end of a project, stakeholders will formally authorize the closure if all deliverables have been met.
- Ad-hoc direction or exceptions: As brought up in previous posts, PRINCE2 recommends setting certain tolerance levels for variations on time/budget/quality etc., and only escalating to stakeholders if the project is breaking out of those thresholds.
As you can see, the direction process is mostly about reviewing the work done at the end of each stage and approving the next package of work.
And I feel like this is pretty intuitive to games! We are very used to working in terms of milestones that can either pass or fail, and most of the time there is a certain degree of distance between the day-to-day to work and the stakeholders who ultimately decide whether the delivered milestone is approved. While it’s an extremely structured process in most AAA settings, you will also encounter milestone approvals in indie if you’re working with a publisher. And if you’re not… having a regular evaluation process that you can think of as “one way doors” will still help you create a healthy development timeline.
Managing a stage boundary
While the previous process is about the responsibility of key stakeholders to take ownership and make decisions at the end of each stage, the management process is about ensuring that the correct documentation is generated so that stakeholders have the information they need to make an appropriate decision on whether the project should continue or not.
There four key objectives that must be met to achieve this goal are:
- Confirm all the deliverables for this stage have been delivered, and that they meet the previously agreed upon requirements/acceptance criteria.
- Revise the project documentation so that it’s up to date and include what’s necessary for the next stage. This includes updating documents like the overall project plan and risk register, creating a detailed stage plan for the upcoming stage, and reviewing current progress against the estimated progress.
- Confirm whether business case still makes sense or if it requires any kind of update or modification to account for project changes.
- Review any lessons you learned during this stage to identify if you need to change your approach for future stages, while also writing them down in a lesson log.
Once the project manager has prepared this documentation, the stage is ready to be presented to stakeholders.
And as you may be guessing, this can be a lot of work! It’s important to get this documentation right, but it can also harm developer momentum if too much time is spent creating these documents without any clear direction on where the feedback will land.
I’ve worked on projects with publishers where we’ve definitely had the issue that, for the sake of timeline, we kept on working while hoping for the best after delivering a milestone. But, when the publisher feedback did arrive, there was always feedback that required us to go back and do rework that could have been avoided if we had gotten the feedback earlier.
Managing product delivery
We’ve talked a lot about processes that are about interfacing the project manager with stakeholders, but only talked briefly about the development team in the “Controlling a stage” process. As you might guess, the “managing product delivery” is about how the project manager interfaces with the development team!
PRINCE2 uses the term “work package” to refer to a deliverable that has clear requirements, and there must be a clear understanding around the effort, time and cost to produce this deliverable. Project managers should have a clear grasp of who they’re assigning work packages to, and that there will be a clear mechanism to report the progress of the package. While in a smaller team this can happen directly between a project manager and the developers, in a larger team PRINCE2 recommends having a team manager that serves as an interface to the team.
They key here is to make sure this process is not a unilateral decision imposed by the project manager, and instead it’s a conversation between the project manager and development team. As I’ve brought up before, PRINCE2 is extremely open to the idea of variation within tolerance range, and this opens the door for the development team to push back or propose alternatives on requirements, costs or time.
Having clear requirements or definitions of done is key here to make sure everyone is aligned in not only the initial discussion, but also when evaluating the work that is delivered and confirming whether the work is approved or not.
Closing a project
Unsurprisingly, the final process is about properly closing a project! This process covers both a natural, planned closure when all the necessary work is done and the product is approved, in addition to a premature closure if stakeholders decided a project should be cancelled.
In either situation, PRINCE2 recommends building a end of project report that covers the real results of the project against the project plan and business case. It is also key here to track and account for any lessons learnt, and any specific recommendations the project manager has for either further action on the project or any similar projects. This documentation has to be approved by key stakeholders before the project can be considered closed.
Admittedly, I bet there’s newer documentation on how PRINCE2 handles this, but the first thing that came to mind when reading about this is how many times nowadays the “release” is never the end, whether it be patches, new updates, etc. and the cadence of these updates is usually very much tied to the ad-hoc need to fix issues/success of the game rather than something completely pre-planned.
I do highly appreciate the need for proper closing documentation though, and glad PRINCE2 requires stakeholders to approve this to actually close a project.
And that’s all folks! This series took quite a while longer than I thought as each post required investigation and was longer than usual (which is why I had trouble maintaining the weekly cadence…).
While it’s not like I’m going to start applying PRINCE2 to my next project or am on my way to become a certified PRINCE2 practitioner, I believe having more tools in your toolbox makes you a better producer, and I feel like I got a lot of new tools for my box! And I hope you did, too.
I’ll be back next week (for real!) with a return to more casual, short write ups. Until then!
{{ end }}