Gamasutra: The Art & Business of Making Gamesspacer
Waterfall Game Development Done Right
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Waterfall Game Development Done Right

November 21, 2012 Article Start Previous Page 3 of 3

Build the Statement of Work (SOW)

To some extent, you've probably developed the majority of the content for the Statement of Work. The process of decomposing implementations, estimates, and calculating risk has probably generated a decent amount of documentation between you, the developers, and the customer. It's time to organize that documentation into a draft Statement of Work. A good statement of work will define assumptions, clarify features, define milestones (and ideally the tests of completion). Of course, the customer will have details that are important to them as well. If scope changes during this process, make sure you go back and update the ROM estimate.

One particular tip that I think is really helpful, if you haven't done so already, it to define as many functional inputs and output specifications as possible. To us, that usually means GUI wireframes, APIs, and network protocols; today you may also want to define gestures, voice, etc. You can't define application implementations until you can understand and describe the inputs and outputs of the application.

It's also important to agree on quality. If possible, find work samples that reflect the quality bar you expect to achieve. Setting expectations is paramount and setting quality expectations is one of the more difficult tasks to accomplish since quality is not nearly as quantitative as other more technical specifications.

Determine Final Quote & Final Statement of Work

You are almost there. The last step will generate the final version of documentation required to perform a waterfall project correctly. You've answered what (SOW) and how much (ROM Estimate) but you still haven't modeled all of the complexity to answer when. And in order to do that, you need to have your final answer of the last "W" which is who.

For the final answer, we use Microsoft Project. Many people cringe when I mention Microsoft Project, but once you learn how to use it correctly for software projects, it's quite useful. The key is to add the "work" column (Right click on the header and select "Insert Column") and enter your estimates there. Don't enter work under the duration column; it will drive you crazy if you start using more than one resource to complete a task.

Finally, if you find yourself using dependencies to keep things from going crazy you have done something wrong. Dependences should only be used to represent a real work dependency -- not as a tool to force project into submission. If you want a task to begin or end sooner, use priority. If you want a set of work, like a milestone, to begin after another set of work, like the next milestone, then use dependencies at the milestone level. Add resources and use leveling liberally. If you aren't hitting "level resources" a lot, you've done something wrong and Project will be more difficult to use than it should. The strong majority of people that dislike Project probably aren't using it correctly.

With everything in project, you now have a reasonably accurate set of dates to share with your customer. By filling out the resource section, you also have a clear understanding of who will do the work.

Start the SOW with the customer's high-level goals. If you project no longer meets those goals... something went wrong along the way.


You have finally answered What, How, When, Who, and How Much. You've accounted for risk, which is the area most project managers fail to consider when building estimates. Those elements are everything you need to perform a FFP contract. Moving forward, if you prefer to run your team in an agile format, you can take your tasks in project and move them into the Agile project management system of your choice. At GarageGames, we use Jira and GreenHopper. I prefer to use Microsoft Project as my backlog and enter tasks during sprint building time while others at GarageGames like to enter the tasks from project directly into Jira.

Now to the final point: In the beginning of the document I mentioned that I thought it wasn't possible to make something truly waterfall. And what I meant was that all software projects require some flexibility. You may need to make changes on the fly. Discuss with your customer if there is wiggle room in dates or features in cases where things are slipping. It's not realistic to thing that nothing will change, so be sure to leave some room for... well...agility.

Article Start Previous Page 3 of 3

Related Jobs

Digital Extremes
Digital Extremes — London, Ontario, Canada

Sound Designer
Disruptor Beam, Inc.
Disruptor Beam, Inc. — Framingham, Massachusetts, United States

Lead 3D Artist
Red 5 Studios
Red 5 Studios — Orange County, California, United States

Graphics Programmer
Red 5 Studios
Red 5 Studios — Orange County, California, United States

Gameplay Programmer


Eric Preisz
profile image
I don't think I would advocate getting paid per day (perhaps there is some confusing text in the article). We build estimates on the granularity of a day. Payments tend to be on delivery/acceptance of milestones.

Clinton Keith
profile image
I fundamentally agree with the Eric on the gist of this: why employ purely iterative and incremental development approaches when there is little uncertainty.

However, a problem common with comparing agile and waterfall is the labeling. Few, if any, studios are purely "agile" or "waterfall". They are more mindsets that encompass a wide variety of practices and approaches to development. Labels are convenient for helping make an argument, often with cute little straw-man statements to help reinforce preconceived notions.

In reality, its more of a scale from pure iterative, inspect and adapt practices to assembly-line approaches that need little inspection. Studios have *always* been somewhere in the middle of this scale. Individual practices are employed based on uncertainty. To make the argument that "waterfall works" fails here. Sure, *some* waterfall practices work when we know more up front. You might say that you don't need any agile practices, but that's like saying you'll never need to inspect what your making and how your making it...not a state that any game developer has been in for very long, in my experience.

Anyways, I love the confidence scale. I'd love to try doing this on a project with some leads using planning poker! Thanks for writing this Eric.

Eric Preisz
profile image
"However, a problem common with comparing agile and waterfall is the labeling. Few, if any, studios are purely "agile" or "waterfall". They are more mindsets that encompass a wide variety of practices and approaches to development."

Well said.

However, I do think that the popularity of Agile methods has somehow colored developers and diminished the discipline and acceptance of prior planning when possible. The pendulum has swung too far in the belief that all development require a reactive only project management process.

Clinton Keith
profile image
Agreed Eric. I call those projects "Incremental and iterative death marches" ;)

Chris Toepker
profile image
Eric, the confidence scale is a thing of beauty, putting into words things I think every day. Thanks for that!

As for Waterfall, what I think is interesting is how we (as the 'new industry'?) seem to want to invent new words all the time. I've found working in manufacturing the approach is just called "project management." Not as sexy a name perhaps, but when done fully and professionally its about about as waterfally as you can get, covering the scoping and quoting and resourcing and etc. questions quite well.

And when an "agile" approach is needed, a design phase is added. In other words, you don't commit all the resources until you really know what you want to make...whether it is some fun (in our case) or stylish (every bit as squishy, no?!) or ergonomic or what-have-you. Don't know what I mean? Check out:, especially:

James Hofmann
profile image
I think the essential difference between manufacturing and software is that hardware's physical constraints and lead times produce a lot of known-quantity requirements and deadlines that aren't negotiable, while software allows everything to be negotiated, so experienced and well-managed practitioners can preserve "any" amount of desired flexibility into the end of the project, at the cost of weighing down development of individual features.

Tom Kofoed
profile image
Dont blame Water Fall or Agile/Scrum
Blame the the person who use a method incorrectly or to religiously (Rigid).....

Eric Preisz
profile image
@Chris - Originally, I used a 1-10 scale of "risk" instead of "confidence". I found over time, it was easier to get people to give more consistent results using the later. Collecting confidence is all about managing and quantifying risk. An estimate without a risk assessment is missing a lot of valuable detail.

Jeff Murray
profile image
Great article! Nice to see an alternative view on this subject, for a change.

Speaking from my experience, I've worked with both Agile and Waterfall with games programming teams between 4 and 13 programmers. Although we saw better engineered products with Agile, we ended up with better (more fun) games when we used a more Waterfall-based approach. Was that the methodology, the team or the game design? It's hard to say- these are organic products at the end of the day! Given the choice, I'd try to aim somewhere between the two and see if it is possible to balance them out.

We did risk assessment in a similar 1-10 scale, but found that without a strong PM on the project, they were difficult for clients to understand / deal with. Clients would still ignore them, turn tail later in the project and go ahead regardless!

Christopher Lambert
profile image
Over 18 years software development experience here, my feeling regarding process is quite simple - there is NO process until you understand the company, the project, the people and technology at play. Agility is about selling books for the most part, as is Waterfall. In my opinion you should be examining the situation and developing a strategy on a case by case basis and using aspects of all processes as a tool chest from which you piece together something to suit the needs of a given project/company/team/technology.

In my case, I find Boehm Spiral Model to still be the 'best general fit' after all these years and frankly see no advantage of waterfall or agile over this approach 'in the general case'.

Svein-Gunnar Johansen
profile image
I would argue the following: If there is a place for waterfall, it is in building the first iteration of your project: The "walking skeleton". And only if this can be built with high levels of confidence.

Robert Riedl
profile image
A third scenario to use 'waterfall' would be when you've created something very similar. In this case, you can use your actual time from the previous project to set up your schedule.

Speaking of actuals, I'm curious how accurate your risk modifiers were. Sometimes estimates can be too conservative and adding even more padding can unnecessarily increase your project cost estimate.

Richard Ranft
profile image
Having actually worked for Eric I'd like to say that as long as everyone is honest in their assessments of their tasks this seemed to me to be fairly close on the average. As always, we have to remember we're "estimating" and probably won't have a number that lands within minutes of the actual task duration.

Nickolas Anderson
profile image
This was a good read and very insightful. Thank you, Eric. The commentary surrounding it has been poignant as well.

In my opinion it is best to be pragmatic about methodology and to not become wedded to a single approach.

@Eric: The Confidence Measurement is fantastic! I'm going to have to try that.

@Christopher: The Spiral Model is an interesting visualization of the development process. I hadn't encountered it before. Thanks for sharing that.

Brian Dreyer
profile image
I’d defer to the “Agile Manifesto” or the 12 Agile Principles:

1. Does what we’re doing at this moment support the early and continuous delivery of valuable software?
2. Does our process welcome change and take advantage of change?
3. Does our process lead to and support the delivery of working software?
4. Are the developers and the product owner (stake holders) working together daily? Are customer and business stakeholders working closely with the project team?
5. Does our environment give the development team the support it needs to get the job done?
6. Are we communicating face-to-face more than through phone call and email?
7. Are we measuring progress by the amount of working software produced?
8. Can we maintain this pace indefinitely?
9. Do we support technical excellence and good design that allows for future changes?
10. Are we maximizing the amount of work not done- namely, doing as little as necessary to fulfill the goal of the project?
11. Is this development team self-organizing and self-managing? Does it have the freedom to succeed?
12. Are we reflecting at regular intervals and adjusting our behavior accordingly?

The big issue with Waterfall is change – the team/people, features, tech, etc., true Agile deals with this better, quicker, cheaper and allows you to kill what needs to be killed faster.

Agile, in my humble opinion will never work without a dedicated ScrumMaster and that’s not (always) a traditional Producer/PM – especially when there's Jr. people on the team.

Eric Preisz
profile image
@Brian - I don't see anything in the Agile Manifesto that we don't apply to our practices. Although, from my experience, I've seen #9 overrule #10 more often than it should...but that's another article.

Dan the gaming Guy
profile image
I like having a macro waterfall schedule that breaks project features / efforts up into buckets (this ensures your project is not a run away train of endless itteration), within each of those time buckets use an agile and fast itteration process to accomplish desired outcome of each part.

Also ensure to schedule a very healthy polish (around 25-35%) phase at the end of the project to:
1) Reduce risk of over scoping your product by having a shorter production phase
2) Create some buffer if youre budget is reduced, your asked to bring your dates in or if something else goes wrong with staffing/hiring/planning, etc
3) If you avoid the above scenarios, you should be able to create a highly polished product

"If you can make every aspect of your product good, your result will be great".