top of page

Risk Management Book - an excerpt and call for volunteers

  • Writer: Liam Wickham
    Liam Wickham
  • Apr 19
  • 5 min read

I have been very quiet for a while - after the Udemy course on Risk Management did so well, I was approached by a publisher to create a book on the subject. Full of enthusiasm, I thought it would be fairly straightforward to convert the course content and transcripts into a book form - in fact, it presented me with the opportunity to greatly improve the layout of information and expand on topics, as well as respond to feedback from those who had taken the course.


For this blog post, I am going to share a sample from the opening chapter and ask if there are any volunteers out there who would like to be added to a small elite list of reviewers - I will send chapters for review and seek feedback in the quest for perfection! If you are interested, hit Reply and send me a message "Interested". Thanks.


Risk Management Book - excerpt - work in progress


Understanding the Three Levels of Risk

Risk in game development exists at multiple levels, each with its own unique challenges and impact on projects. Understanding these levels helps teams and leaders anticipate, mitigate, and manage risks effectively. The three primary levels of risk are Portfolio, Program, and Project risks. Each of these levels determines the type of risks being discussed and the nature of the conversations that need to happen to address them. Regardless of your personal position, role and interests, it is important to understand how the levels interrelate and influence each other, if you are to make use of them effectively.


Portfolio-Level Risks

Portfolio risks exist at the highest level of the organization. These are structural risks that impact multiple initiatives, games, the business strategy, and the overall sustainability of a studio or publisher.


  • Broad Exposure & Interrelated Risks: Risks at this level do not exist in isolation. If one decision is made, it could ripple across multiple products, teams, or business units. A funding decision for one game may impact resource allocation for another.

  • Risk Balancing Across the Business: Portfolio-level decisions often involve managing risk exposure across multiple initiatives to ensure sustainability.

  • Strategic Decision-Making: A strong business model and corporate strategy determine how risks are handled at this level. These could be decisions about acquisitions, new projects, or whether to cancel a game in development.

  • Multiple Games & Initiatives: Managing risks at this level includes overseeing multiple studios, balancing priorities between live-service games, new IPs, and ongoing development.

  • Governance & Compliance Risks: This includes EDI (Equality, Diversity, and Inclusion), corporate audits, external funding negotiations, and legal compliance across different global markets.

A key example of portfolio-level risk is deciding whether to shut down an entire game project. It might not just be about that one title - other teams, technologies, or business dependencies may be affected. For instance, if a studio is working on multiple projects and one gets cut, it can trigger layoffs, resource reallocations, and damaged reputation.


Program-Level Risks

Program risks focus on a single game or large initiative, encompassing multiple teams or departments that contribute to a unified goal. These risks sit between high-level corporate strategy and ground-level execution, often involving people in roles such as executive producers, production directors, creative directors, development directors and lead producers.

  • Game or Department-Level Focus: These risks impact entire game franchises, large internal teams, or multi-studio collaborations.

  • Operational Risks & Bottlenecks: Unlike portfolio risks, these are more immediate risks, such as key technology dependencies, milestone delays, or cross-team conflicts.

  • Alignment with Strategic Goals: This level ensures that game development aligns with corporate expectations while remaining realistic within its constraints.

  • Budget, Scope, and Timeline Management: Key discussions here involve which features are essential for launch, which can be delayed for post-launch updates, and which should be cut altogether. One of the biggest risks that often occurs here is a lack of understand of the budget that would then enable economic decision-making.

  • Workflow & Process Risks: Teams at this level also focus on improving production pipelines. A game may fail not because it lacks creative vision, but because its processes were broken - team workflows, inefficient toolchains, or ineffective coordination between departments are all very common and a common source of discontent.

An example of a program-level risk is the misalignment of different departments. What if an art department is creating assets that do not match the game engine’s requirements? What if animation teams and Enemy AI programmers aren’t working together efficiently? These bottlenecks can derail entire milestones.


Project-Level Risks

Project risks exist at the team or feature level, where day-to-day execution and dependencies play a significant role. This is the level where most developers, artists, and designers operate, dealing with tangible, day-to-day challenges.

  • Feature or Team-Specific Risks: These risks directly impact a feature team, product team, or outsourcing project.

  • Highly Influenced by Ground-Level Operations: A project’s success depends on how well different teams interact. Are back-end teams available to support multiplayer infrastructure? Is the data team too overloaded to provide analytics? Is the animation team waiting for input from design and art before it can commence work, causing a chain of events leading to costly delays?

  • Resource & Dependency Issues: Effective project risk management ensures that necessary tools, people, and assets are in place to support development without causing delays. Often though, efforts to reduce dependencies fail, or tracking and visualising of them falters. A smooth development path can then become strewn with unexpected blockers.

  • Last-Minute Feature Cuts or Changes: Teams at this level frequently face scope changes based on high-level decisions. Imagine working on a major feature for six months, only to hear that it is been cut due to budget constraints.

A significant risk at this level is being blocked by other teams. For example, an engineering team working on multiplayer features might be completely dependent on a backend team that is already stretched too thin. If that backend team fails to deliver on time, the entire multiplayer experience could be compromised. Information sharing can multiply the impact, where apparently small and subtle changes at the design end were not communicated to engineers, resulting in being faced with rework or worse. This is why risk management at project level is just as critical as at the portfolio and program levels.

The Reality of Risk Across All Levels

Many studios operate in a single-game environment, where everything hinges on the success of that one project. If the game flops, the studio could shut down. This creates a single point of failure, which is a huge risk. The challenge is that many traditional risk management approaches come from industries with multiple revenue streams and diversified portfolios - not an industry where everything depends on one hit game.


Risk discussions are often misaligned between levels. At the portfolio level, leadership may be focused on strategic goals like "How do we ensure funding sustainability?" Meanwhile, at the project level, developers are struggling with more immediate concerns like "Why is this feature just not working but we’ve run out of time..?" The gap between those perspectives can lead to poor communication, bad decisions, and missed risks.


...


That's it for this article. Remember, this is part of my opening chapter and so it is necessarily brief and punchy, as each point is expanded throughout the book.


I hope you will like it!




Comments


bottom of page