Here's how the Game Dev PMO will help you...

Would you like to know what separates a world-class, successful game development organization that delivers consistently reliable results with such regularity that it seems effortless ...and a struggling organization that seems to be lurching from fire to fire without ever getting ahead of it?

Would you like to know what separates a leader who controls the team's roadmap, manages their priorities, and executes plans smoothly and efficiently ...and one who is reacting constantly to changes flying out of "left field," barely able to keep their team together and focused?

Would you like to know what separates an organization that attracts the best talent, retains its "A" players, and keeps getting better with each challenging assignment ...and one that has to settle for whatever staff it can find, with little power to attract the top performers who could really make a difference?

 Well, the thing that separates them is pretty straightforward....

In Fact, the Game Dev PMO Story Could Be Your Story...

When I joined EA, I was soon introduced to the Game Development Framework - EA's stage/gate model that all of its AAA titles have used for much of the past 20 years to deliver consistently outstanding results.

The premise behind it is simple (though the premise behind an automobile is simple too, if you gloss over the 10,000 parts that make it up) - but the premise is this:

Every project is divided into 6 themed stages, bounded by gates that are made up of a number of core requirements or deliverables. Everyone on the team - and indeed the entire company - lives and breathes these stages and gates, and works in alignment to ensure every gate is hit and passed with precision.

What struck me most is how effectively the entire company marched to the beat of that drum. For sure, a lot of effort underpinned every project, but from a distance, it sure looked like a well-oiled machine.

For the 4 years that I oversaw the Game Dev delivery for the FIFA franchise, I came to know that process intimately. Like anything, there are pro's and con's, and there is power in adapting the process over time to reflect the world we live in. But make no mistake: FIFA would never have become the multi-billion-dollar franchise it is today without it.

When I left FIFA to join the Frostbite Engine team, one of my first tasks was to build a process that matched the GDF - but that worked on a central team that ran a scaled Agile model rather than a stage/gate model.

Each year for the next several years, we revamped a different aspect of the organizational process until we had developed a set of systems that handled Frostbite's deliverables and in so doing met their game team customers' needs.

Just like the powerful stage/gate model the product teams used, we had built a powerful scaled Agile model fit for a central or service team.

Both these models - which reflect the values and principles of the Game Dev PMO - were far removed from the image of "poor management" I was wary of when I joined EA.

How the Game Dev PMO Model
Delivers So Much Value

You may be eager to understand how a set of operational routines can deliver efficiency gains, quality improvements, and vastly deeper team engagement and retention. Great topics. Let's dig in...

The first thing we'll need to establish is why Game Dev projects are delivered late, overrun budgets, or fail to deliver the quality and engagement they were expected to deliver.

Here are some of the common reasons:

• Poor estimates - results in plans that align poorly with actual development capacity. Underestimating means capacity that isn't fully utilized. Overestimating means commitments that can't be met.
• Scope creep - results in new requirements sneaking into the project, pushing out the original work, and making delivery dates impossible to meet.
• Resources pulled onto other work - results in development capacity available for committed projects diminished, making existing project plans impossible to deliver.
• Dependencies not done in time - results in dependent work unable to continue on time. This means idle developers, or "keep busy work" on non-critical tasks. The impact is late project delivery.
• Requirements change late in project - if managed carefully, this is expensive, but recoverable. If managed poorly, it means late delivery and/or missing deliverables.
• Stakeholders misaligned - this often means someone will be disappointed and/or the project plans need to change in mid-cycle. Either way, wasteful and messy.
• Development team not sufficiently skilled - this typically happens with challenging initiatives where the "A" players on the team are fully booked on higher priority work. The result is poor quality and substantial rework.
• Work not tested properly - results in escaped defects and a lower quality final product. Customers not impressed. If caught before release, may mean late delivery.
• Escaped defects from earlier release distract dev team - results in effective development capacity being reduced, causing late or incomplete project delivery.
• Support demands steal development capacity - this also has the effect of diminished development capacity, though the magnitude of the problem is even larger since support can take many forms.
• Project risks not identified in time - results in the team being blindsided by unexpected events, and having to scramble to recover. The result is usually more work than expected, and late delivery.
• Risks not managed well - this also results in more work than planned, and can mean either late project delivery, or missing deliverables altogether.
• Project fails to meet requirements - this is often the result of failing to validate the features properly earlier in development, and may result in failed deliverables and late project delivery due to mandatory rework.
• User acceptance criteria not met - this is typically the result of failing to involve important stakeholders in progress reviews at key points during development, and results in costly rework and late delivery.
• Easy work crowds out important work - this happens when priorities are unclear or not respected, and results in a less-valuable product delivered on time, or the full-value product delivered later than necessary.
• Roadmap never had a chance of being delivered - this happens when development capacity is substantially lower than the actual work required to deliver the roadmap. Expectations will be missed and reputations damaged.
• Roadmap becomes disconnected from reality on the ground - this happens over time when the feedback loop from the dev team fails to include change propagation to the roadmap. The result is missed expectations.
• Stakeholder expectations not managed - this typically comes about as a result of a poor communication or change control plan, and depending on the stakeholders affected, may result in late rework.
• Requirements change without plan changing - results in the team changing direction with additional costs not reflected in the plan. The plan becomes outdated, and the project runs late, with expectations failing to be met.
• Spending time on initiatives that don't deliver the strategic objectives - results in an end product that may be delivered on time, but fails to provide the required level of value to the business. In other words, waste.
• "Shiny object" features distract from core work that needs to be done - results in time stolen from development capacity, which in turn leads to late delivery or incomplete deliverables.
• Feedback comes too late in the project - results in very-late course adjustment and often substantial amounts of throw-away work. Typically results in late overall delivery, or missed deliverables.
• Maintenance outages disrupt customers - results in poorly-timed service interruptions leading to unhappy customers and poorer numbers than expected.
• KPIs not monitored in a timely manner - results in  underperforming features and slow or no remedial actions, leading to overall failure to perform to expected levels.
• Team structure doesn't easily map to the products we deliver - resulting in cumbersome overhead, poor communication, and lack of algnment on key feature implementation. The end result is poor quality and late delivery.
• Team members lacking technical guidance or product leadership - results in underperforming team members, either through technical inadequacy leading to quality issues, or feature issues leading to rework and late delivery.
• Roles on the team are not clearly understood - leading to missed expectations, individual and team underperformance, and general quality issues on the products they deliver.
• Tasks slip through the cracks - resulting in delays, quality issues, and general confusion. Invariably, this results in project delays as missed tasks prompt late rework.
• The last 5% of the project takes forever to finish - this is usually related to poor understanding of the requirements and consequently poor estimates to deliver "Big-D Done" features.
• Not clear which teams are responsible for delivering which pieces - this  lack of clear accountability often results in nobody taking owernship of certain areas until very late in the project. The result is project delay.
• Ill-defined roles collide - results in lack of clarity over who owns which responsibilities. People step on each others' toes, or assume someone else will deliver, when in fact nobody does. Projects run late.
• Team can't hire quickly enough when need arises - results in development capacity shortfalls, making project plans late or undeliverable.
• Team doesn't have the budget they need - results in insufficient ability to deliver the committed work, which in turn means incomplete deliverables and/or late projects.
• People don't have the equipment they need - results in sharing existing equipment - or doing without - which slows down development, resulting in project delays and overruns.
• Poor hires slow down the team - happens as a result of careless hiring or in some cases desperation. The result is a lower-caliber team, which produces lower-quality products that are delivered late.
• Attrition is depleting team capacity - leading to a general reduction in team productivity, and a resulting high likelihood of late or incomplete project delivery.
• Onboarding costs are a huge drag on the team - this invariably taps some of the more knowledgeable team members who help to ramp up new hires at the cost of their own capacity to deliver. The result is late project work.
• Return On Investment for outsourcing is unclear -  results in inability to get approval to outsource work, which in turn results in insufficient development capacity to deliver projects.
• Attrition affects hiring priority when key people leave - often results in recruiting for less-critical roles ahead of more-critical roles in order to avoid recruitment churn. This leads to reduced effective capacity on the team.
• Teams not performing up to expectations - results in lower quality products, and/or slower delivery time and late projects. Can also lead to loss of key team members.
• Individuals on the team are performing poorly - results in lower overall team performance, and problems with team morale. This in turn leads to a reduction in effective development output.
• Proliferation of management meetings bogging down key leaders - results in skipped meetings or lack of attention due to schedule and cognitive overwhelm
• Team meetings few and far between - results in team feeling disconnected and in the dark about what's going on, which reduces morale and raises the risk of attrition.
• Management attention and support drops - resulting in team feeling overwhelmed and underappreciated. This in turn damages morale and raises the risk of attrition.
• Staff frustrated - resulting in more widespread and intense feelings of burnout, and a loss of pride in the work they are doing. Raises the risk of attrition.

Honestly, this is a bloomin' big list. And, I can say with absolute certainty that I have seen every single one of these happen - often in substantial combinations - at various times over the past 35+ years - and one thing they all have in common when they happen is: it's not pretty. It's expensive, it's messy, and it's embarrassing for the team - and especially for the leaders.

It's no way to run a business.

Fortunately, it doesn't have to be this way.

Let's run some numbers: How Much Would It Be Worth To  Make These Improvements?

It's tricky to make blanket predictions about how worthwhile something could be to a certain organization, because as I've already pointed out, every organization is in a different situation.

But, there are a few useful (and very conservative) ways to approach this question.

Method 1 - Cost Savings

A good Game Dev PMO implementation is going to drive down your development cost. Improvements in planning and execution will lead to greater efficiency, less-rework, and fewer surprises. In this vein, imagine that you were able to make your team just 1% more productive.

In a scenario where you have a team of 100 developers and creators making $150k annual salary (and yes, I know your fully-loaded costs are likely much higher - but as I said, I'm being conservative), your annual payroll spend is $15 million. 

A 1% improvement represents a savings of $150,000 per year. That's savings that can either be put back into the corporate coffers, or deployed into other productive projects.

But remember, that's with just a 1% improvement. Your objectives will be a lot higher than that. A better way to think about it is: for every 1% improvement in productivity, you save $150,000. So a savings of 10% represents $1.5M in benefit.

Now, you might be thinking - wait a second. I only have a team of 10, not a team of 100. Okay, fair enough. Of course, the percentages scale up and down, so the same proportional benefit applies. But smaller teams have the advantage of simpler communication and coordination, and thus it's actually easier to make larger-impact improvements. So, it's more likely your benefits will skew higher.
 

Method 2 - Retention Savings

A good Game Dev PMO implementation is going to bring order and sanity to what can sometimes be a frantic development environment. This will enable better planning, more focused development time, and better quality games that your customers will love.

This comes with another benefit: your "A" players will love it too. 

They crave a smoothly-running professional environment where they can exercise their craft without constant fire-fighting and course-changes. This makes them happy to work for you, proud of what they produce, and more likely to refer their "A" player friends to come work here too.

As of this writing, the average turnover in tech companies is 13.2% (article), but rises as high as 21.7% for software engineers. Being conservative, let's work with an assumed turnover rate of 15% on the above-mentioned scenario of 100 developers and creators.

• Lost productivity during 2 months' recruitment = 15 x 2 months / 12 months x $150k = $375k 
• Lost 25% productivity for 3 months from 1 team member onboarding each new hire = 15 x 3/12 x 25% x $150k = $140k
• Lost 50% productivity for 3 months from each new hire ramping up = 15 x 3/12 x 50% x $150k = $281k

Total cost of 15% attrition and backfill is $796,000 per year on this team of 100. If you reduced your attrition rate by just 3 percentage points, from 15% to 12%, you would save $159,200 per year in lost productivity. With your organization running as smoothly and professionally as you want it to, you could likely reduce it quite a bit further. (Cutting attrition by 7 percentage points would represent $464k per year in savings.)
 

Method 3 - Revenue Rise

This is a restatement of Method 1, but instead of banking the cost savings, it focuses on the potential revenue upside that comes about from redeploying saved productivity either into new opportunities, or improvements to existing products that drive increased sales.

If you could generate in sales 10x the development cost to produce your game, then every 1% increase in productivity - whether deployed into improved features that drives more sales, or wholly new games - in our scenario of 100 developers and creators at $150k salary... that means an extra $1.5M in sales per year.

It's hard to measure the true potential of new product or business opportunities. Often, the potential upside far exceeds the cost to produce such that any formula would be utterly irrelevant. The inspiring story of how the Battle Royale game mode came out of a tiny tag-team of engineers over a number of weeks, and went on to generate billions of dollars for the Fortnite franchise is just such a case. There's a certain amount of good fortune involved in any success story, but without carving out the capacity to explore it, it never would have happened.

Frequently Asked Questions About The Game Dev PMO

Is This a Software System?

The Game Dev PMO is an integrated set of processes for managing various aspects of your Game Dev organization, however it is not specifically software. As part of a consulting implementation, we may partner together to develop spreadsheets, templates, and other tools that are bespoke for your organization. We may also work together to connect these tools to your already-existing software systems for streamlined flows of information.

Will We Implement All 9 Areas?

That's up to you. Most often, we start with an Assessment that looks at what you're already doing well, and where you're most likely to experience the largest benefit from Game Dev PMO processes. We then suggest focusing on those areas first. We suggest tackling each area as an independent engagement so you start to gain immediate ROI. This also gives you the flexibility to pause or skip implementation in areas where you have little need for improvement.

How long will it take to see results?

Some benefits start to accrue immediately - like having a more orderly cadence of operational meetings and activities. Other benefits require a more substantial implementation - such as standing up a lightweight stage/gate or scaled Agile model, or rolling out an Initiative Management or Green Light process. In these cases, there is a definition stage, an optional pilot project, and an organization-wide roll-out. The timeline will depend on the nature of the implementation and the size of the organization.

How does an Engagement work?

An engagement typically starts with a free Zoom call to see if there's a good fit. From there, we often suggest an Assessment (discussed below) after which we begin a consulting engagement. We partner with an individual on your team, who owns the responsibility for implementing and operating your Game Dev PMO on an ongoing basis. Together, we define the processes, tools, templates, and documents you will need, and together we prepare and execute a roll-out plan.

How does an Assessment work?

An Assessment usually takes the form of a series of group and individual meetings, and reviews of existing tools and processes. Often this is done over Zoom, but can also be done in person. We then write up the results of the assessment, along with a series of recommendations about how best to proceed, and in what order. We then meet with you to discuss the results, and decide together how to proceed with the implementation.

Do you offer ongoing operational advisory?

Once an implementation is finished, it moves into the operational stage. Many people find it useful - especially for the first few months after roll-out - to meet on a regular basis to discuss how the operation is going, bring up questions and challenges, and discuss how best to approach them. We have a limited number of advisory slots available on a month-by-month basis. This is certainly something we can discuss as part of our engagement.