What the reporting suggested
Scope had grown, creative direction appeared to have drifted, and the demo did not represent the game that had been described. The conventional read was to pull back.
The framework · Studio Assessment
Can this team deliver?
A strong pitch, a polished milestone and an experienced leadership team are all good signs. None of them shows how the production underneath is actually running. That’s nobody’s fault: it’s hard to see a production clearly from inside it, and harder from a milestone review.
A Studio Assessment is an independent read on whether the team, the plan, the leadership structure and the production reality support the game being made.
What an assessment answers
- Can this team deliver the game?
- What is putting delivery at risk?
- Are those problems temporary, structural or fixable?
- What should change, and what is healthy and should be left alone?
When a review is most useful
The most useful assessments happen while there is still a meaningful decision to make.
Selecting a partner
Several external studios are in consideration, and leadership needs to understand which team is actually structured to deliver.
Before signing
A funding or partnership decision is close, and an experienced development read belongs alongside the legal and financial diligence.
At greenlight
The pitch is compelling. The question is whether the team, scope, plan and production assumptions support it.
When a project slips
Milestones are moving or costs are rising, and the picture from outside is incomplete. Often the team sees the problem too, and needs help making the case.
Acquisition diligence
The team is most of what’s being acquired, so how it actually operates matters as much as the financials.
On a regular cadence
A standing rhythm across the portfolio, so the first look is never a crisis.
Five patterns that put delivery at risk
After 30 years shipping games, I’ve seen the same structural problems surface again and again in productions that struggle. They’re hard to see in a milestone review and much clearer once you spend time with the team and see how the work actually gets done. Every pattern is judged against the stage of the project: a prototype isn’t judged like a beta.
1
Creative and production misalignment
When the game, the plan, and the available resources stop lining up
Warning signs
- Creative and technical leadership are working toward different definitions of success.
- Product decisions continue without enough evidence of player value.
- The team struggles to make decisive cuts when scope exceeds budget or timeline.
What this puts at risk
Scope continues to grow while the production plan stays largely unchanged. From the outside, the project can appear on track until the remaining work no longer fits the time and resources available.
What healthy looks like
Creative and production leads describe the same game and the same constraints. When scope exceeds the plan, something gets cut, on purpose and early.
2
Technical and product misalignment
When the technology stops serving the game
Warning signs
- Significant engineering effort is going into systems without a clear gameplay or production benefit.
- Technical decisions remain fixed after product assumptions change.
- Technical priorities and the evolving game vision are no longer aligned.
What this puts at risk
The team can make substantial technical progress without making equivalent progress toward a shippable game. Problems often become visible only when systems need to scale into full production.
What healthy looks like
Engineering work traces to something the player will feel or the production needs, and technical plans change when the game does.
3
Decision and ownership gaps
When unclear decisions quietly become schedule problems
Warning signs
- Decision-making authority is unclear: who actually has final say?
- Features move forward without clear ownership of budget, staffing, or schedule impact.
- Important decisions travel informally rather than through accountable channels.
What this puts at risk
Decisions take longer, teams work against different assumptions, and small delays accumulate into schedule pressure without a single obvious cause.
What healthy looks like
Anyone on the team can name who makes which call, and decisions arrive with their cost in budget, people and schedule attached.
4
Team capability gaps
When the team you have no longer matches the game you're building
Warning signs
- Key roles don't have the experience required for the current phase or scale of production.
- Familiarity and trust sometimes outweigh demonstrated capability when critical roles are filled.
- Known performance or capability gaps remain unresolved because addressing them would be disruptive.
What this puts at risk
Problems that could have been addressed early become increasingly expensive to correct as production advances and the organization becomes more dependent on the existing structure.
What healthy looks like
Key roles are held by people who have done the job at this phase and scale, or who have real support while they grow into it. Gaps get named and addressed, not worked around.
5
Evidence and adaptability gaps
When the plan isn't changing as quickly as the evidence
Warning signs
- Playtest results, user research, or production data aren't materially changing decisions.
- Established creative assumptions are difficult to revisit when new evidence challenges them.
- Major scope decisions are made without fully reconciling ambition with available resources.
What this puts at risk
The team can continue executing effectively against assumptions that are no longer supported by player evidence, production reality, or the market.
What healthy looks like
Playtests and production data visibly change the plan. The team can point to the last thing it believed, learned was wrong, and changed.
These patterns don’t automatically mean a studio can’t deliver. The question is which are present, how serious they are, whether the team recognizes them, and whether they can be corrected before they materially affect the project.
You can’t assess a team from a status deck.
The useful information is usually spread across the build, production data, milestone history, leadership conversations, and the people doing the work. I spend enough time with the team to understand how the project actually operates, not just how it reports.
I come in as another developer, not an auditor.
I’ve dealt with the same milestone pressure, scope problems, creative disagreements, technical constraints, and production tradeoffs. That tends to produce a different conversation.
My job isn’t to catch people doing something wrong. It’s to understand what’s actually happening, what’s working, what isn’t, and whether the problems can be fixed.
Findings go to the team before they go to leadership, and nothing is a surprise.
What the team gets out of it
A review isn’t something done to a studio. Done well, it’s one of the more useful things that can happen to a team mid-production.
- Problems the team already senses get said out loud. Most teams know where they’re weak. A review gives those concerns a route to leadership that doesn’t depend on anyone sticking their neck out.
- What’s healthy gets protected. Every report names what is working and shouldn’t be disrupted.
- Strong teams earn more room. Evidence that a team is self-aware and correcting course is the best argument there is for trust, time and budget.
How a review runs
Start with the decision
Agree what leadership needs to decide, then review the build, plan, milestone history, budget, team structure and available evidence.
Spend time with the production
Talk with leadership and the team, sit in on the work, and understand how the project actually operates day to day.
Share findings with the team first
The team hears what was found, and has the chance to correct or add to it, before leadership does.
Write the recommendation
Proceed, proceed with conditions, or pass. Where something should change, say what. The owner of the decision makes the call.
A typical assessment takes one to four weeks.
The output is a recommendation leadership can act on.
The assessment should give leadership enough evidence to decide what happens next. The decision stays with the people who own it.
- Executive recommendation
- Areas that are healthy and should not be disrupted
- Material execution risks
- Evidence supporting each finding
- Leadership and organizational observations
- Production and scope assessment
- Corrective actions where appropriate
- Conditions that should be met before further investment
Proceed. Proceed with conditions. Pass.
Case example, anonymized
What this looks like in practice
An investor funding a large-scale, high-ambition project had to decide whether to continue funding after a milestone demo that did not match the pitch.
What the assessment found
The problems were real but not structural. The demo had been deliberately de-risked from the core game to accelerate technology work and recruiting. Leadership already knew where the project was weak and had contingency plans under way, and production discipline was strong.
- Recommendation
- Proceed.
- Result
- Funding continued, with review checkpoints agreed at three and nine months.
The other half of the read
Studio Assessment asks whether the team can deliver. It doesn’t ask whether the game is worth delivering. Title Review covers that question.
If you’re building an independent review function, or wondering whether you should, I’d welcome the conversation. colin@cmackie.com