A quick dive into applying Bayes Theorem to Production and Project Management for games.
Foreword
For even the most mildly seasoned producer, it's no secret that every project and every team are different. With that said, I want to make it clear that the following article is a conceptual discussion of how Bayes Theorem could be applied to project management.
WTF is Bayes Theorem?
Thomas Bayes was an English statistician, philosopher, and minister in the early 1700's. He found himself fascinated with being able to make a guess at something and then measure the accuracy of that guess. This should already sound familiar to producers and project managers. What Bayes came up with is a surprisingly (at least for the author) simple formula that can grow dependent on the number of factors someone wants to consider. The formula is as follows:
where A and B are 'events' and P(B) ≠ 0.
P(A) and P(B) are the probabilities of observing A and B without regard to each other.
P(A | B), a conditional probability, is the probability of observing event A given that B is true.
P(B | A) is the probability of observing event B given that A is true.
The common example given is let's say you might be sick with a rare disease, and you have a test run that might prove you have the disease. The four possible outcomes are: you have the disease and it isn't proven, you have the disease and it is proven, you don't have the disease and it isn't proven, and you don't have the disease and it is (falsely) proven. Each has a probability of occurring, but their sum total is 100%.
How does this apply to managing a game project?
Scope/feature creep is practically inevitable in any project. Some studios have better practices about managing it. All producers should have a hand in determining the impact of that scope change on various milestones and deadlines. This is where Bayes Theorem can help. Imagine your game might have major change based on various discussions from on high or a changing landscape due to some industry innovation. That's your event A, and how likely it is to occur is P(A). Now you talk to the team and figure out how much additional work this would be. That's your event B, not the chat but the work itself. You can then look at how likely it is to adversely impact your scheduled release date or P(B). From there you can get an idea how the possibility of this significant change may impact your schedule.
I know there's a lot of guessing and postulating with this. Where it becomes more useful is when you add in more variables that have 'known' probabilities (this is where you thank your UXR/HFE team for getting this info).
Closing Remarks
Bayes Theorem is by no means a catch-all solution that will make you infinitely wiser. This is a tool that might help you argue on behalf of your team. If you've done a good job tracking the project, its health, and its status, then this formula can inform discussions about added scope.
For context, my team uses Jira and Confluence to record the project as we go. I use a python script to pull data from Jira into Excel where I can use complex formulas to glean more insight about the projects in our studio. I've only just started using Bayes Theorem to decipher scope change impacts on projects. I'm sure I have more to learn and understand about Bayesian Statistics. As always, I welcome open discussion and if you have found this useful or can offer some improvements, please comment below.
Read more about:
BlogsYou May Also Like
