Chapter 15. Working with a Publisher

As a member of the Nintendo Ultra-64¹ Dream Team in the mid-nineties, Angel Studios was exposed to a very collaborative publishing model. Nintendo and Angel discussed a game idea, and we were asked to “find the fun” with it. Nintendo funded the project for three months and then visited to see the results. Occasionally, the legendary Shigeru Miyamoto—creator of Mario, Donkey Kong, Legend of Zelda, Nintendogs, and many other hit games—visited as well!

¹ This was the code name for the Nintendo 64.

Nintendo had no interest in any documents we’d prepared; they only wanted to see the game. If the game was making progress and demonstrating fun, Nintendo funded another three months and left us with the instructions to “find more fun.” If not, the game was abandoned, and another idea was discussed.

This iterative approach, which gauges progress based on the game alone, is very agile, but few publishers pursue development in such an agile way. In fact, there’s a polarization of views about agile approaches such as Scrum within the publishing community. Some have mandated that all their first-party developers use it, while others have banned it. Those that use Scrum have found challenges in establishing the best level of collaboration.

Establishing an agile relationship between publishers and developers is challenging. Publishers don’t simply hand out money to developers who offer nothing more than a promise to try to “find the fun.” There usually has to be a more formal arrangement. Outside of our industry, there are plenty of examples of agile contracts between stakeholders and developers that work and could form the model for the game industry.

This chapter examines the problems with the existing publisher/developer relationship, the challenges with establishing a more agile model, and a range of solutions to becoming more agile.

The Challenges

When I was working in the defense industry, documentation was king. For every week of actual development (writing code, testing, and so on), I spent two weeks writing documentation. Everyone’s cubicle had an overhead shelf filled with binders that demonstrated the amount of documentation each of us had written for their current project. Our performance was measured primarily by the amount of documentation we generated.

The last defense industry project I was on was to design an avionics architecture for a new fighter jet. It represented hundreds of millions of dollars of work that our company was desperate to secure.

My job was to compile hundreds of various design documents into a single document to deliver to the Air Force within a few months. After a couple of weeks it became apparent to me that I could not create a comprehensive, organized, and readable document from all of these separate documents. I approached the project manager with my concern. “Oh, don’t worry about that,” he told me. “The Air Force just weighs these documents; they don’t actually read them!”

I was shocked at this revelation. I finished compiling the master document with an eye toward maximizing the weight. When completed, the printed version weighed 20 pounds and filled one of those boxes that copier paper comes in. It was truly massive. The document was delivered, and I was given a pat on the back for a “job well done.” Shortly after, I resigned.

One of the main reasons that game development has become less iterative is the increasing requirement for detailed, up-front plans from publishers. This has resulted from the rising cost of project failures. Publishers desire more certainty from developers and want to be sure they are “thinking things through” before creating code and assets. Publisher-side producers are encouraged to demand a detailed plan and schedule, tied to a contract, because it places much of the responsibility for project uncertainty in the hands of the developer.

Developers are encouraged to create these documents and schedules because the false sense of security they provide gives them time to explore the game, fund their studio, and (ideally) ensure that the publisher’s long-term financial commitment is established.

Although design documents have not reached the size of those on major government weapons systems, most publishers and developers are realizing that there is no correlation between the size of the design documents and the success of a game. The illusion of certainty and the ulterior motives that drive these bad practices have to end. The business model won’t support it for much longer.

Focus Comes Too Late

Most games demonstrate significant increases in gameplay value after alpha, when integration, debugging, optimization, and polishing begin in earnest. This is often a stressful time between the publisher and the developer because the publisher finally has a potentially shippable game to provide feedback on, but the definition of alpha usually means that all features are implemented and so it is too late to consider many of the suggestions.

The pressure to add these last-minute changes is often too much. Teams succumb to adding late features because they know the game needs them, and they don’t want to ship a bad game after all the effort put into it. Unfortunately, the ship dates are not changed to reflect this added work, or if they are changed, it involves a performance penalty for the studio or damage to their relationship with the publisher.

Milestone Payments and Collaboration

Publishers usually hold the upper hand in a development agreement. Contracts often allow them to terminate a project at their convenience. Given this leverage, they can usually dictate new features, which result in “feature creep.”

Milestone payment delays and threats of termination are blunt tools. The pressure they create results in milestone builds that lack fun and also lack consistency with and adherence to a vision. They might satisfy a milestone deliverable checklist, but they don’t move the game toward market success as much as they should.

Contracts negotiated between a publisher and developer usually cover the full development cycle of the game from concept to gold master. Given this liability, publishers prefer to have some guarantees of performance. These typically take the form of milestone schedules linked to payments. Milestones usually occur every three months and have specific testable conditions in them such as the following:

• Three playable levels

• The AI characters navigate environments and attack the player.

• Players can join other players for online gameplay.

These seem like reasonable milestone deliverables, but they highlight a few problems:

• Quality cannot be defined in a contract: Development studios are highly dependent on milestone payments, so if the choice comes down to providing two great levels of gameplay or three mediocre levels, as defined by a milestone the developer may choose the latter simply to be paid. There is no way to contractually define a quality bar unless the developer allows the publisher to subjectively judge the quality of deliverables, which they would be negligent to allow.

• Collaboration is discouraged: In the event that a publisher or developer identifies a change to the game that alters future milestone deliverables, it’s usually difficult to introduce such a change into the contract, especially if it impacts the budget or ship date. As a result, game-improving changes are inhibited at many levels.

• Problems are hidden, and trust is destroyed: Developers try to load as much of the development fees from a publisher into early milestones as possible and define the deliverables in a way that avoids exposing problems until late in the project (see the “Examples of Milestone Definitions That Hide Problems” sidebar), when the cost of cancellation is too high.

• Developers don’t want to expose problems to the publisher early because they think they will overreact and cancel a project: Publishers think that developers won’t openly share the bad news, so they end up assuming the worst. These attitudes destroy trust.

Limited Iteration

Many publishers see the need to iterate planning and development. One common practice used is to allow “rolling milestone” definitions. These enable the detailed definition of a milestone to be fleshed out during the preceding one. Although this enables details to emerge, it doesn’t permit changes to major deliverable dates or much flexibility within the milestone being worked on. Like an Oreo cookie, it sandwiches the flexible part between two inflexible lumps.

First-Party Problems

The issues of contracts and payments largely disappear when a studio—acquired by a publisher—becomes a first-party developer. This seems like a relief to a studio that has struggled to survive, but it raises different challenges.

When a publisher owns a studio, the publisher has more freedom to control it. For example, if a project is late, they might transfer developers from another project over to help, which rarely does (see the discussion of “Brook’s Law” later in this chapter). They might decide that they don’t trust some of the design decisions being made and dictate them remotely, which destroys morale.

Some studios with a track record of success erect barriers with their parent publisher to avoid these problems, going so far—in one case—as to bar them from entering the premises!

It doesn’t help to keep the publisher entirely in the dark because they have a role to play in the success of a game. For example, this success depends not only on the quality of the game but also on the publisher’s responsibility in marketing it. A talented marketing group can help the developers fine-tune the game to deliver what the market wants.

Portfolios Drive Dates

Market forces often compel publishers to promise ship dates and even projected sales figures for a game. The demands of large retail chains, licensing deadlines, long-term portfolio plans, and the desire to please shareholders pressure publishers to commit to very uncertain and optimistic product flow and ironclad ship dates.

This compels a publisher to ask the improbable of their developers, even after many failures demonstrate the futility of this. It’s not that publishers are unaware of the development realities. They simply can’t resist the pressure from retailers and shareholders.

Perhaps as the market changes and as new distribution channels appear, this problem may be alleviated, but it won’t happen soon. One solution is to increase the level of collaboration between the publisher and the developer to make them partners in the goals of the game. This requires a higher level of trust that has to be slowly built to overcome long-established fears.

Building Trust, Allaying Fear

The common root of all these problems is a lack of trust and collaboration between a developer and publisher. Trust takes a long time to build. Building it through iteration, transparency, and collaboration are agile principles.

The first step is to deliver value regularly. When a publisher receives sprint builds with significant incremental improvements to the game, it builds confidence and trust.

The second step is welcoming change from the publisher. Observations from publishers contain valuable feedback about the marketable value of the game. When this feedback is reflected in the game within the next few sprints, it builds trust. Publishers and developers become true collaborators, rather than rivals trying to manipulate one another.

These steps lead to greater trust in the developer’s ability and decision making. It enables honest discussions of project goals whenever scope, schedule, and cost start to conflict as they invariably do on most projects. By having these discussions earlier, when there are more options for addressing problems, the relationship and product benefit.

First, the fears that publishers have of releasing the “agile genie” must be overcome.

The Fears

Publishers have a great deal of fear about agile. Some of these fears are as follows:

• “We’d have no idea where the project is headed. They could iterate forever!”

• “If the scope is flexible, developers won’t work very hard. We’ll get half the game for our money!”

Developers have fears about an agile relationship with a publisher as well:

• “The publishers will micromanage the product backlog, and we’ll have no creative control”

• “Allowing publishers to always change the scope will lead to a death march!”

These fears aren’t groundless. A misunderstanding of agile or Scrum practices and principles make it possible for any of these problems to be realized.

Understanding Agile

Teams slowly absorb the principles of agile development as they iterate, deliver working builds that demonstrate value, and receive stakeholder and customer feedback. Publishers are not faced with the daily lessons of agile and can’t absorb these principles as quickly. As a result, they may not understand the importance of Scrum practices and their role as a stakeholder, which leads to the following dysfunctions:

• Not playing sprint builds

• Not attending reviews or planning sessions

• Ignoring the product backlog

• Demanding detailed schedules and documents up front and ignoring the need to revisit them based on actual progress

• Making urgent requests in the middle of a sprint

These are typical actions of publishers who are accustomed to traditional projects that hide uncertainty and don’t demonstrate real value until post-production. Agile developers need to reinforce the principles and benefits of agile development with their publishers. One method is to establish a publisher-side Scrum advocate or even a publisher-side product owner.

Publisher-Side Product Owners

A product owner is usually a member of the project development team. Video game product owners need to provide frequent and subjective feedback. Does the control of the player feel right? Is a mechanic fun enough? This feedback requires daily engagement with the team. They are the single voice for all the customers and stakeholders of the game.

Unfortunately, many stakeholders reside with a publisher who is based thousands of miles away. This challenges the product owner’s capacity to create a shared vision with them. One solution is to delegate a portion of the product ownership role by creating a publisher-side product owner. This person represents the publisher-side stakeholders to the developer. Figure 15.1 shows the arrangement between both product owners.

Figure 15.1. The product owner roles

The publisher-side product owner communicates with the developer-side product owner as frequently as necessary.

The publisher-side product owner has the following responsibilities:

• Review each sprint build

• Participate in as many sprint review and planning sessions as possible

• Attend the release planning and review meetings

• For first-party developers, ensure that the developer-side product owner is tracking ROI and general project cost dependencies

• Represent the developer-side product owner to publisher-side stakeholders such as executives, marketing, and sales groups

• Ensure that all the publisher-side stakeholders are aware of the current status of development

The two product owners should communicate about every aspect of the game and clearly define the limits of ownership. For example, the publisher-side product owner might own the release goals (epic-level stories) while the developer-side product owner owns the release plan (the stories that fit within the release). This is different for every studio, publisher, and game. For example, some externally licensed games require strong publisher-side product ownership, while intellectual property being developed at the studio must have stronger developer-side product ownership.

Third-party (independent) developers usually maintain more ownership since they have sole responsibility for maintaining their own financial stability.

Together, the two product owners manage the product backlog. This includes discussing the addition, removal, and prioritization of features. The publisher-side product owner must understand that new features are always welcome on the product backlog, but the product backlog itself is not a promise of what will ship with the game. They need to understand what velocity means and how to use it to avoid feature creep and allow collaboration to exist between the publisher and developer.

Meeting Project Challenges Early

Scrum’s empirical measure of development velocity and the transparency of the product backlog enable honest and continual discussions of scope and schedule. By developing a potentially shippable set of prioritized features every sprint, the team and publisher have the following controls over the project:

• Control of the release date: If the velocity of the features being introduced is different from predicted, the release date can be earlier or later than planned.

• Control of the scope: Scope is the easiest factor to manipulate as long as value emerges during development, rather than emerging all at once after alpha, which is often the case.

• Control of the budget: The product owner continually measures ROI based on value, velocity, and cost. This gives greater visibility into whether the budget being spent on the project is generating sufficient return in value seen.

Most publishers are used to waiting until after alpha for the state and quality of the game to emerge, which is usually too late to apply these controls without expensive consequences. Thus, they are not accustomed to having them available. Agile projects give more stakeholders more visibility and control.

As Chapter 6, “Agile Planning,” described, these controls are similar to those applied during a cross-country drive. An experienced driver won’t rely on a map, or plan, as the only source of information about the trip. They fine-tune the plan based on the reality emerging, such as miles driven per day or—if there is enough time—side trips taken to add value to the trip.

Managing the Production Plan

Chapter 7, “Video Game Project Planning,” described how production debt is impacted by decisions made in pre-production and how the estimation of this debt is continually refined.

Production plans are critically important to publishers and developers. They represent major cost and resource obligations. The date that teams start production is a signal that the gameplay is more certain and that they are in the home stretch. Unfortunately, the desire to reach the state of production often overshadows the reality of whether the game and team are truly prepared to enter it. Often the date, or the need, to transition production resources takes precedence over whether the game is ready to enter production.

Developers and publishers need to clearly establish the goals a game must meet before it enters production. Metrics need to be established in pre-production that demonstrate the production plan is still viable. These metrics, such as the number of people-days to produce each level, continually measure the cost of completing assets in pre-production as they approach production quality. Without them, production schedules remain highly speculative and optimistic.

Production forecasts and metrics should be part of every release deliverable. Given these forecasts and metrics, the publisher and developer plan coming releases to ensure that production dates are met or to update planning to match reality.

Allaying the Fears

Given the tools described earlier, developers and publishers begin to allay the fears that were identified at the start of this section.

We have no idea where the project is in development. Developers can iterate forever!

Agile methods require close participation between the stakeholders and the developers on a regular basis. Without a shared vision, a game easily strays off course and becomes something the publisher did not want.

With development projects that cost $20 million becoming common, publishers must have the games prove their value along the way, regardless of the methodology used. Scrum creates a framework for close collaboration and iteration that allows this.

If the scope is flexible, developers won’t work very hard. We’ll get half the game for our money!

Publishers should be impressed with the velocity of features introduced by Scrum developers. If not, the project should be canceled. Agile contracts give both parties an opportunity to identify when a game idea is bad or a team is not a good match for a project. Neither party should wait two years or spend $20 million to discover that all the hard work won’t provide a sufficient return on the investment.

The publishers will micromanage the product backlog, and we’ll have little creative control.

Allowing publishers to change the scope will lead to a death march!

A first-party developer without a product owner owning the vision is in greatest danger of this happening. They need to establish the roles on both sides in terms of product ownership. The practices of Scrum reinforce this every sprint.

Agile Contracts

Outside the game development industry there are many examples of agile contracts that have evolved over time. Examples include such products as tax preparation software or airline reservation websites that slowly expand their features as business evolves and changes.

This model enables clients and developers to work with a series of contracts. Rather than committing to years of promised effort involving large sums of money, the smaller contracts each cover an incremental released version of the product, which provide much more certainty and far less risk. Although developers might prefer the security of a long-term contract, the reality is that the “termination for convenience” clause in most contracts allows a project to be canceled at any time, for any reason.

Most games don’t have regular incremental versions. Many games have one “big-bang” release followed by a small number of patches. There is greater risk in funding these large projects, which leads to detailed, ironclad contracts.

Since agile game development provides a more incremental delivery of value, it gives publishers and studios the potential to build relationships where progress is measured on a regular basis to determine whether the project is worth pursuing further, much as Nintendo and Miyamoto did with Angel Studios.

The benefits of this approach are significant. Not all ideas result in great games. Some teams are not well matched to a game they are tasked to develop. It’s better to abandon those efforts early than to spend years following a bad path.

While frightening to consider at first, it is actually a measure of success for projects to “fail early” rather than to “fail late.” Failing early reduces the possibility of harming the relationship between a publisher and developer. On the other hand, spending $10 million for a game that never sees the shelf creates a lot of bad feelings and destroys careers. Besides, no one wants to spend years of their career working away on a mediocre game.

There is precedence for this type of contract in the game development industry. As more developers become agile, more publishers will find the benefit in pursuing agile contracts over traditional ones.

In the meantime, publishers and developers continue to explore more agile practices with traditional development agreements such as iterating against a plan or using the kill-gate model.

Iterating Against a Plan

Huge design documents and schedules are like a woolen security blanket in the rain; they give comfort for only a short amount of time. Despite up-front planning’s poor track record, publishers and project managers demand it because the only alternative they see—no planning at all—leads to chaos and ruin. They’re not wrong.

When faced with this, the challenge for agile developers is to gradually introduce agile planning practices and to find the cracks in the big bang process that always exist—such as rolling milestone definitions—and exploit them for the benefit of the project.

What does an agile team do when a publisher demands all-embracing design documents and schedules? The first thing is to determine how much flexibility exists within the publisher’s process. It’s rare to find a publisher that does not allow some form of rolling milestones described earlier. If these are allowed, such milestones are managed the same as releases. When the publisher requests an upcoming milestone definition, hold a release planning meeting for it, and invite a representative from the publisher who can make decisions.

Over time, a developer builds trust by allowing some change from the publisher. Care must be taken to not give them a blank check for changes. If a fixed scope list exists, rather than a backlog, each change must be accompanied by the deferral of other work from it.

Most long-term deliverables are tied to the minimum required feature set. As described in Chapter 7, the greatest threat to schedules and resources is an excessive amount of advance speculation about the details for these features. They paint teams into death-march corners.

If—in the worst case—no flexibility or trust exists and the developer cannot refuse the work, what can be done? Although the team benefits from some practices such as sprints and daily scrum meetings, they will be limited in how they may react to the emerging game. They should attempt to insert meetings in the schedule that require stakeholders to review progress and make decisions about the course of the project. Another useful tool is to enumerate all known and potential risks and identify how they will be addressed (see the “Experience” sidebar). Transparency is still encouraged; hiding problems only creates debt that the team pays back with a death march.

Fixed Ship Dates

A common impression about agile is that it does not allow games that use it to ship on a fixed schedule. The impression is based on the idea that agile teams don’t plan but simply iterate with a very short horizon—they just don’t know when the project will end!

Although most games have a ship date, many of these are considered “firm” rather than “fixed.” Firm ship dates are established by publishers to fit portfolio or budget projections. A firm ship date will drive the project, but if it desperately needs another month or so of work to achieve far better results, it won’t be a disaster to slip the date. Fixed ship dates, on the other hand, are critical for the success of some games. Examples of games with fixed ship dates are those that must ship simultaneously with a movie release or games like Madden Football that must be on shelves by the start of each NFL season. The penalty in lost sales for missing these dates is major.

How is a project with a fixed ship date managed differently from one that is not? Mainly, it is the way risk is handled. Risk is uncertainty about what a team is creating and how it is going to build it. For example, if we want to dedicate 20% of our project budget to creating a cooperative online death-match mode with AI opponents for our game, a few of the uncertainties might be the following:

• Will the AI work online?

• Is 20% of the budget enough to create a fun and complete experience?

• Will problems in other areas delay work or take people away?

The list can go on. Any one of these can threaten the project’s schedule and result in the feature being dropped after almost 20% of the project’s budget has been spent on it.

So, how is risk handled? Developers often try to plan and schedule their way out of risk by creating exceedingly detailed plans that attempt to identify the solution to every foreseeable problem. Unfortunately, since the danger lies in what a team does not know, it’s certain that the tasks required to overcome risk will not be identified up front. The best way to handle risk is to focus on answering the unknown, in other words, creating knowledge.

Creating knowledge and value is important for any project, regardless of the ship date. For projects with fixed ship dates, the prioritization of work to reduce risk is a bit higher. For example, if a movie-based shooter game with a fixed ship date has to decide between shipping six months after the movie’s release or dropping online gameplay, they will be more likely to drop online. A game that is not based on such a license, which instead has a firm ship date, is more likely to be delayed to ensure the feature is included.

So, let’s return to the original question: Does agile aid or impede a project’s ability to achieve a fixed ship date? Executed properly, an agile project has significant advantages over other methods. Two core principles are behind this advantage:

• Prioritizing to create knowledge and reduce risk: Focus on delivering high value and addressing risk early. Fixed ship dates only enable a project’s staff or the scope to vary. Increasing the number of developers on a troubled project usually doesn’t help. Brook’s Law² says that “adding manpower to a late software project makes it later.” The law also applies to game development. The best option is varying the scope, or feature set, of the project. Identifying the best features that fit within the schedule is critical to the success of a game with a fixed ship date.

² http://en.wikipedia.org/wiki/Brooks%27s_law

• Not postponing debt: Frequent integration, immediate defect correction, and maintaining target performance (for example, keeping the game potentially shippable) will prevent late surprises that require rework and delay. When projects with fixed ship dates postpone critical work to post-production, they often meet with disastrous results.

Two tools for applying these principles are the product backlog and the definition of done. Stories that address schedule risk must often be prioritized over others on a project with a fixed ship date. An example of this is a spike to mock up a full level. This would create early knowledge about the level dimensions to better refine the production schedule and risk. Doing this constrains some of the options for emergent gameplay, but it might be necessary to know this information sooner than later.

Elevating the definition of done (see Chapter 5, “User Stories”) enables risk to be addressed earlier. For example, if a game must ship on all platforms, a product owner might require stories to run on all the platforms earlier in the project than they normally would. Although this additional definition of done may slow teams down, especially if the platform technology isn’t fully mature, it accelerates improvements and creates more knowledge about the risks of those platforms earlier.

As described in Chapter 7, agile methods don’t attempt to plan away uncertainty with large documents, but they also don’t ignore uncertainty. They simply tailor the practices to the different level of uncertainty over time. Planning for short-term goals, such as sprint goals, is done at a high level of detail. Planning for medium-range goals, such as release plans, is less detailed but receives continual refinement. Long-range planning for things such as ship dates, production scheduling, and so on, is also continually refined and influences short-term planning. For example, an agile plan won’t say “Production will start on September 14” a year in advance. It will refine a range of times over the course of pre-production. The reason is that not only will we gain knowledge about production in pre-production, but the debt itself will change. By acknowledging uncertainty and working to refine it, agile planning will increasingly match the reality that is emerging rather than drifting further away from the big document written at the start of a project.

Too many times fixed ship dates result in little innovation or a poor game that must be shipped before it has been properly polished. Games released along with the release of movies have long had a reputation for low quality. This doesn’t need to be the case. Eliminating the waste of dropping features at the 11th hour after months of working on them is a good place to start.

Sometimes a fixed ship date is impossible to achieve. A risk-based approach for developing completed features will not work miracles, but it will expose the bad news sooner than later.

Agile Pre-Production

Publishers aren’t deaf to the agile message. They understand that fun cannot be defined in a document. They’ve seen detailed plans and schedules fail projects again and again. However, most publishers exist as publicly traded companies that must be able to forecast budgets and ship dates for their games. As a compromise to this reality, publishers are more readily engaging developers to be more agile in pre-production alone. This involves small teams taking longer to iteratively explore potential features, creating knowledge about production costs, and defining the quality and fun of the game. Since production is more expensive and amenable to predictive schedules, this is a reasonable compromise.

The Stage-Gate Model

With a “big-bang” release model, a contract that covers the entire development cycle is a rather large gamble, especially for an original idea. For these games, publishers may require decision points, called green lights, often at the juncture of two stages to decide whether to continue funding the game. Two of the most common green-light junctures are the following:

• Concept green light: The publisher decides whether to let a game enter the pre-production stage after reviewing project concepts, an initial plan, and a prototype.

• Production green light: The publisher decides whether to let a game enter the production stage after reviewing the gameplay, the production-representative assets, and the resource plan and schedule for production.

Publishers fund a number of game ideas and use green lights to funnel them down to a select a few of the best. This is called a stage-gate model. It gives a larger number of innovative ideas a chance to be proven.

Figure 15.2 shows a stage-gate being used to winnow four games down to the one that demonstrates the best value.

Figure 15.2. A stage-gate in action

The stage-gate model creates a clear advantage for an agile developer. It aligns the principles of agile with the goals of the model: to judge the game itself rather than the plan for it.

The stage-gate model can also establish the boundary between a longer pre-production stage that is largely exploratory and the production stage that is far more predictable.

Summary

Although publishers may not consider themselves agile and may even recoil in fear at the term, they have been trying to find ways to be more agile for more than a decade. Iterative practices have been creeping into the way business is done between them and developers. By continuing to build an agile vocabulary and trust through applying agile principles, this trend will continue and allow game development and publishing to remain a viable and even lucrative business model.

Additional Reading

Cook, D. Rockets, cars and gardens: Visualizing waterfall, agile and stage gate. http://lostgarden.com/2007/02/rockets-cars-and-gardens-visualizing.html.

Cooper, R. 2001. Winning at New Products: Accelerating the Process from Idea to Launch, Third Edition. Cambridge, MA: Basic Books.