I really didn't expect such a strong reaction. We had originally written the design document to include six cities. We had cut that down to three as we discovered how difficult it was to create full cities for the PS2. During the first phone call, they accepted the cut calmly, I later learned that the final cut from three cities to two had come one week after a large marketing blitz which told the world that Midnight Club would have three cities. Had I called them a couple of weeks earlier, it would have been a much different call. Of course, had we put two cities in the original design document, we would have been heroes by shipping on time and budget AND with the original scope. As it was we shipped on schedule and budget with one third of the scope we had "promised".
The uncertainty of how accurately we can plan decreases with how far we plan ahead. We often get into trouble by relying on our plans too much and ignoring reality. We base complex and highly interdependent schedules on a plan we assume is comprehensive; a plan that anticipates every potential risk. We then discover that reality doesn’t follow our plan and the amount of work we need to spend is far greater than our budget allowed for.
One reaction to this problem is to ask “why plan at all?”. Indeed, many projects have launched with little planning. A project without a plan or schedule can be appealing at first glance, but there are problems this raises. Maintaining a vision becomes a problem, especially with larger teams. Strong leadership can help overcome this, but that leadership will often become a bottleneck. Developers of sequels to smash hit games will often announce that the game “will be done when it’s done”. Unfortunately even this formula doesn't always insure that the success of the sequel will match that of its predecessor.
There are often schedules outside the team that need to be coordinated with key project deliveries. Publishers often have marketing budgets that drive the rate at which projects can be released. Portfolios of games are balanced around key selling seasons or movie co-release dates. Few developers have the luxury or of ignoring these pressures.
The reality is that most hit games released have missed their original ship date, budget and scope. Detailed planning, bloated budgets, staffing and crunch inflicted on the developers haven’t proven to be a cure.
So what value does planning have? It isn’t so much about creating an accurate schedule, cost and feature set for a project up front. It’s an ongoing quest to refine those values over time through iteration. It's used by the team and customers to balance schedule, cost and features. Any planning method has to acknowledge the uncertainty of these three elements of a project up front and focus on refining the plan continuously by doing the following:
- Reducing risk - You can’t plan away uncertainty. A plan should acknowledge risk first and foremost. Addressing risk requires visibility and transparency.
- Creating knowledge - A “Big Design Up Front” (BDUF) usually fails because we don’t know enough to make the decisions that we make up front. A planning process has to build on what we learn through iteration.
- Communicating information - A good planning method has to communicate changing information properly. BDUFs fail at this because teams and customers don’t reread the document for changes. Frequent effective meetings between the team and stakeholders to update the plan are essential. Instead of spending months planning up front a good planning method spreads the planning time across the project.
- Supporting better decision making - Too often bad games are released because the decision to cancel it came too late in the schedule. Publishers simply hope to recoup some of its budget through selling the game to a hundred thousand unsuspecting players. A proper planning process would allow better decisions to be made earlier which would steer the game to profitability or cancellation before too much money is spent.
- Reflecting realistic progress - We would prefer to know early in the project whether our plan is realistic or not. Say we have to ship our game 12 months from now and our current feature set requires 18 months based on our current progress. Knowing this information can help us pick and choose a smaller set of the most valuable features or decide that we have to slip the release date. Conversely if we realize we are going to miss the ship date 3-6 months before we are scheduled to slip, we may not have the same range of choices: We might be in the middle of production on a fixed set of mechanics. A good planning process should have a feedback mechanism built in to reflect reality. It should build trust between the publisher and team.
The goal of agile planning provides all these areas of support. If you want to find out more, buy this book.
At the very least, you can avoid a phone call like the one I had!