|
3. Estimate Costs
Now we will estimate our project's costs.
Using the previously calculated values for the number of new users per month (75,000) and the retention rate assumption (60 percent), we calculate that 45,000 users are converted from new to active users each month.
Assume that our marketing department estimates user acquisition costs (UAC) of 60 cents per user. Using these, we can then determine our acquisition costs over the expected lifetime of the project.
We'll also estimate our development costs, using our best salary estimates broken down by discipline, combined with the expected work-months for each discipline to give us total salaries paid. We'll then combine this with estimates of operational overhead and additional market research costs to estimate total product development costs.
Finally, we add these total operating costs to our total user acquisition costs to determine total project costs.
4. Develop a reverse income statement
Now that we know our required profits and operating margin hurdles and the estimates for our actual costs and revenues, we can compare them directly.
The reverse income statement acts as an essential "sanity check" in planning. The "cost cushion / deficit" and "profit cushion / deficit" entries in the table below directly compare our DDP estimates to our initial hurdles. If either of these is zero, it means there's a serious problem and we should either attempt to adjust our plan to fix the problem or abandon the project entirely.
Plugging in the previously calculated numbers, we get the following:
As you can see from the table above, our total costs of $2.46 million are well within our allowable costs. However, our expected profits of $1.329 million are just barely above our minimum profit hurdle of $1.3 million. This indicates that the project in its current state is only marginally acceptable, and we should see if there's any way to adjust the plan to improve our profit cushion. We will also need to be cautious moving forward to ensure that the project's outlook remains above our profitability hurdle as we learn more and narrow our assumptions.
In this case, we've satisfied both hurdles, so we can move on to the next step.
|
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.