Stages of DDP
For the sake of this article, I will separate DDP into seven steps that match the seven parts of the attached DDP spreadsheet. This is slightly different from most presentations of discovery-driven planning, but the overall process is broadly similar.
- Specify required profitability. This step asks you to determine the baseline profits and operating margins you would require in order for the project to be acceptable, both in terms of operating income and operating margin. This step forces you to state your minimum requirements up front so that you can have an unbiased hurdle for the project to pass at each stage. In addition to stating our required profits, using the required ROI tells you how much you can spend on product development and marketing.
- Estimate revenues. In this step, you build a reasonable model of your project's revenue stream over the lifetime of the project using the best known data, whether based on data from previous projects, industry sources, research, or any combination thereof.
- Estimate costs. Here, we list all the activities that will be required to complete and maintain the product. As in step 2, we use our best unbiased estimates of the cost for each activity based on the best data we can find.
- Develop a reverse income statement. The "reverse income statement" compares the estimated costs and revenues against the required profitability hurdles to see if they measure up.
At step 4, we compare the expected costs and revenues of our project developed in steps 2 and 3 against the required profitability from step 1. If the project's costs or potential profits don't satisfy our hurdles, we stop here, and attempt to re-plan. There is no point proceeding to steps 6-7 if we can't find a way to adjust our plan to meet our profitability hurdles.
If the project does measure up, we move on to sensitivity analysis and checkpointing:
- Isolate key variables and assumptions. In this step, we list all of the assumptions from steps 2 and 3 in a single table, and we attempt to define reasonable upper and lower boundaries for each of these variables.
- Perform a sensitivity analysis on your assumptions. We now use the ranges determined in step 5 to run a simulation of our model in order to determine the sensitivity of our assumptions -- that is, which assumptions have the greatest effect on our costs or revenues. This step requires a predictive modeling tool such as Oracle Crystal Ball or a reasonable alternative.
- Develop a list of Checkpoints. In the final stage, we develop a list of Checkpoints at which we will test and refine our assumptions. We attempt to prioritize development so that each Checkpoint tests as many of the most sensitive assumptions as possible at the lowest possible cost. Each Checkpoint gives us an opportunity to test several of our assumptions, further restrict the range of our assumptions, and re-plan as necessary. As our project evolves, we should revisit our assumptions at each Checkpoint and re-plan if necessary. This provides a means to cancel or refactor our projects as early as possible, and to gradually increase the scope of our investment as the ranges of assumptions are reduced at each successive checkpoint.
Note that Checkpoints are not the same thing as production milestones. The Checkpoints should serve as our overall production goals and drive the definition and scheduling of our narrower production milestones. Checkpoints define your plan to learn.
|
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.