Sample Project
To illustrate discovery-driven planning, we'll build an example of a freemium mobile game to be released on iOS and Android. We assume that this game is published by a major mobile publisher and is able to use that publisher's network to drive a significant number of new installs every month. We will drive revenues entirely through in-app purchases.
The numbers used in these examples are guesses and are not intended to be accurate representations of what these values would be for any other project.
Similarly, the choice of a freemium model is only for the sake of this example. You could just as easily use DDP for a paid-up-front revenue model, a subscription-based model, an ad-driven model, or any other.
Let's go through the seven steps one by one and show how you would build the DDP for this project. All of these steps are available in the separate "DDP Template for Games" spreadsheet.
1. Specify required profitability
We need to state our required operating income and operating margin up front. Assume that our executive team tells us that the company expects a minimum of $1.3 million in profits and a 20% operating margin from this project. This implies that we'll need to make at least $6.5 million in revenues and no more than $5.2 million in total costs. These are our initial hurdles for the project.
Here and in the attached spreadsheet, we will use numbers in blue to represent requirements. Numbers in grey cells represent calculations based on previously stated requirements or assumptions. Numbers in light orange cells represent assumptions.
2. Estimate Revenues
In this step, we'll estimate our most likely revenues. Assume that our marketing department estimates 75,000 new users per month with a simultaneous launch across multiple platforms and a major marketing effort assisted by our publisher's cross-game promotional network (again, these numbers are not to be taken literally).
They also believe that we will retain 60 percent of new and existing users each month and lose the remaining 40 percent. We assume the game will have an effective lifetime of 3 years.
Based on this, we project average Monthly Active Users (MAU) over the project's lifetime -- this is calculated in a separate page on our spreadsheet ("MAU"). Our marketing department also estimates that 15 percent of monthly active users will be active users on any given day.
Also note that we list a number with each assumption in the third column. This is a unique identifier for each assumption that we will use to refer to it later, during the sensitivity analysis stage.
|
Printer-Friendly Version
I'm sure it could be an article in itself, but could you speak to the issues of bridging the gaps between discovery-driven planning and development methodologies over the SDLC? I understand the connection between driving your development cycles with input from the discovery-driven checkpoints, but it seems to me that this is more geared toward agile methodologies than more front-loaded design schemes. Are there any key factors to integrating DDP with specific design methods that we should be aware of?
DDP is really a very broad project planning and business planning framework that can be used for almost *any* kind of planning, regardless the scale or even what industry it's in.
It's much more of a high-level, big-picture, ten-thousand-foot-view type of planning framework, and you would generally use other software development and planning methodologies inside of the DDP plan you create.
You're right that DDP does lend itself more toward agile methodologies. Non-agile methologies like waterfall tend to assume correctness from the outset (from http://en.wikipedia.org/wiki/Systems_development_life-cycle : "Sequential or big-design-up-front (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results").
And we all know that that certainty doesn't really exist in software, much less in game development, where you combine all the unpredictability of software development with the added unpredictability of creatively-rooted projects.
DDP, on the other hand, is basically taking the opposite approach. It says to the planning team: "Start by admitting how much you don't know and how much you can't predict. Then identify all of those parameters as best you can, figure out the boundaries on the uncertainty associated with each one, and use the DDP system to figure out which uncertainties represent real risks and sort them by risk. Then you can gradually corral those risks over time as you go from one Checkpoint to the next and gradually reduce uncertainty by converting your assumptions into knowledge."
The uncertainty can arise either because we're missing some amount of a priori knowledge (say, we might not know a certain parameter in advance, even though the parameter has a definite value -- for example, we might not yet have done the marketing research to figure out cost of acquiring a user on mobile, even though it is a definite dollar figure that many companies know precisely).
Or it could be because it's something that will happen in the future and there's inherent uncertainty involved (say, we hire 10 programmers and expect them to be done in 2 years, but we don't know if they'll actually get it done, if our design changes will push their schedule to 3 years, if our lead coder will have a heart attack, etc, etc).
In either case, DDP can help you get a handle on where the biggest risks are really hiding and help you build a plan to identify them, quantify them, and manage them.
I've always been pretty agnostic about it, but I definitely think Scrum has its limitations.
There's really nothing inherently wrong with it as a day-to-day planning methodology, but it seems really incomplete to me. Scrum tends to be totally focused on the short term, and there's very little focus on long-term planning.
And that just doesn't work.
Even if you don't have a fixed schedule or feature set, or you're building your game under a huge cloud of uncertainty for whatever reason, you HAVE to do long-term planning at least at some level.
I've worked on a few projects that used Scrum and/or ScrumWorks software at some level, but were actually totally ineffective teams because they ended up chasing their tails rebuilding their own games more or less from scratch every six months.
So an artist would come in one morning and say, "Hey, guys, I just had this amazing new creative idea! We gotta do this!" And the team would immediately throw out the last six months' worth of work to focus on this awesome new idea ... which would then be thrown out itself six months later in favor of something else.
Their planning was only looking at the here and now, and no one was looking at the big picture or holding the team accountable for it.
That really drove home for me that for all its benefits, Scrum by itself is no guarantee that all that task tracking necessarily translates into any actual progress toward a goal.
So, bottom line, I think that combining Scrum with DDP could be a good approach, if you were to use DDP for the overall, long-term planning aspect, and then use Scrum (or some good adaptation of Scrum, or another good agile methodology) for the short-term, day-to-day and milestone-to-milestone planning.