Frameworks are great… until they're, you know, not. They're a great starting point, but I've found, the reality of things doesn't quite fit in the box the framework provides. Take RACI for example…
Don't get me wrong, I understand the point and purpose of RACI. I think, conceptually, it's a great idea and is applicable across a wide variety of project types.
That said, I struggled with it for quite a while though, and it took me a while to figure out the actual reason… Like a lot of things, it gets messy with game dev and creative ops. So, I took some time to try to figure out _why_ it was messy, and why I found it difficult to line things up with an ostensibly simple framework.
The Mismatch
I realized it's because in my world, the Accountability element is often split between the director and the producer. Generally, the director is accountable that the work is good, and the producer is accountable that it's delivered on time.
I've found it doesn't usually divide that cleanly. Good directors and good producers have some reach and impact in the other domain. Good directors have some sense of the cost, risk, and time of what they ask for, and good producers have the sense and taste to help ensure the work is hitting the quality bar. I think this crossover is incredibly useful when done well, but it does make things more complicated.
After banging my head against it for… a while. I finally figured out that what helps is having the duo build a shared definition of done for the work that accounts for both the quality bar and target AND deliverable timing and requirements. And that is built collaboratively with each other and the team.
The Complication
Nowadays, that is still applicable, but it's often only part of the solve. When we add co-dev partners to the equation, it adds (surprise) yet another layer of complexity. Because this same split is mirrored within the co-dev partner, meaning all those challenges of shared, but split, accountability are multiplied.
I've seen folks try to solve this with raw brute force documentation. I've found that it typically starts okay but goes to cra… er, goes downhill… fast. The documentation gets out of date as decisions are made, actions are taken, and the project moves forward. It can work, of course, but only if the documentation is treated as a "living thing" that is updated (and refocused) regularly so that it at least resembles reality.
Communication Is The Key
Documentation is one approach, but fundamentally, communication (in whatever form it needs) is what's critical.
Regardless, whatever process you use, the key is to make sure everyone on the team - including co-dev and outsource partners - are aware of what "good", "delivered", and "done" look like, and they stay updated as those change.
Which is admittedly harder than it sounds.
Author note: I’ve spent my career leading and supporting cross-discipline creative teams, primarily in game development, with a focus on production clarity, alignment, and communication. I built DriftWarden for creative leaders who need to turn ambiguous direction into execution plans their teams can actually use. You can connect with me on LinkedIn.