Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Waterfall Game Development Done Right
View All     RSS
May 12, 2021
arrowPress Releases
May 12, 2021
Games Press
View All     RSS

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 Page 1 of 3 Next

Agile, Agile, Agile. It's hard to disagree with a project management process named "Agile". It's like disagreeing with something named the "Patriot Act" or answering "No" to a department store checkout attendant that asks if you would like to save 20 percent on today's purchase. It's clear: Agile is cool, and every Scrum master certificate mill will agree with that statement.

But what happens when an Agile paradigm isn't appropriate?

"How is that possible?" says the guy with the skinny jeans and the PBR.

There are two scenarios where we think a more "waterfally" approach is appropriate (We'll explain the "more" part later... because no one could ever be purely waterfall if you think the name implies a rigid schedule).

The first is when a project is innately low-risk, and the second is when your stakeholder doesn't wholeheartedly buy into the Agile process. Examples of the second include Kickstarter and the majority of contract work.

For the first case, I think you can throw out any game development scenario where you are striving to achieve fun that isn't a full clone of something that is already proven to be fun. Fun is just too damn squishy, and in my experience, you don't know something is fun until you play it and say, "Hey, that's fun!"

Creating fun is a risky proposition. Vertical slices -- a technique where you make some small percentage of the game at near final quality -- and rapid prototypes help pave the way for a more structured project.

The second case is the focus on the remainder of this article. GarageGames is a service company and in the majority of the cases we see, the formula for customer's desire on an initial consultation is usually something similar the following:

I want X by the date of Y. How much will you charge me?

Problem Statement:

A customer wants a firm fixed price (FFP) quote for a game-related software development project. How does a company arrive at a price and date that is fair for the procuring and commissioned company?

To simplify the problem statement, what the customer wants to know is: What, How, When, and How Much is required. Additionally, you will need to determine Who from your firm will do the work. Those elements, solved together are a FFP contract, schedule, and Statement of Work (SOW). Here are the steps we use to build them:

  1. Determine initial scope -- Focus on the What.
  2. Determine if the project is suitable for FFP contracting -- Initial analysis of How.
  3. Build a rough order magnitude estimate -- Second analysis of How, first analysis of When and How Much.
  4. Determine scope of the Statement of Work -- Final analysis of What.
  5. Determine & deliver final quote -- Final analysis of How, When, and How Much and Who.

Determine Initial Scope

This usually occurs through one or more conversations with business development, technical, and project management. If a GarageGames employee can do all three it can often be covered in one conversation. The most important goal is to be output and goal focused. Don't get too caught up in implementation. Right now you are more interested in the what than the how or when. For us, this process of determining initial scope starts with a conversation about the customer's high-level goals.

Often times, the customer doesn't know what they want aside from their high-level goals; sometimes, you need to help them understand their goals (a bit of a red flag sometimes). It's understandable that they might not know; if they really understood the solution to their high-level goals then they wouldn't be coming to you now would they? Work with the customer to define and document the high-level goals. By understanding them, you are in a better position to either develop their plan or validate any existing plans.

Knowing how much can be helpful at this stage. Customers typically don't want to tell you their budget at this point because they are worried that you won't give them an honest quote --you have an asymmetric knowledge advantage that makes them uncomfortable. A customer's budget holds intrinsic clues about what can be accomplished and not knowing that number will make the process much harder to scope and define the project.

GarageGames asks customers to try and identify a budget range for the purposes of accelerating the quote process. We assure them transparency in our quote that addresses their fear and we've found that sharing more detail with the customer gives them a better experience. Transparency puts both parties on the same side of the table tackling a problem instead of negotiating against each other as foes. Working together to bring down cost is something we enjoy doing. We believe that if we save customer money they are more likely to spend that money on us in the future. Both sides win.

If they aren't willing or allowed to share a budget range with you hope isn't lost -- it's just more work to triangulate the cost from the bottom up.

Determine if the project is suitable for FFP contracting

At this stage, we are going to analyze the project by doing an initial analysis of how we will implement the project to meet the customer's high-level goals.

It's time to start thinking about risk. All projects, especially software projects will have some risk. How confident are you about your team's ability to accomplish this project? What is the variance of success and failure? At GarageGames we measure risk using a confidence scale of 1 to 10.

With an eye towards risk management, we do our initial analysis of how we will implement the solution. To do this, we work with technical leads to formulate an approach.

We decompose the output above from high-level outputs into smaller features. This process is known by many as a Work Breakdown Structure (WBS). At GarageGames, we tend to get to a more detailed decomposition than many. It takes more work, but it protects us from taking a job we can't complete by exposing more known issues.

For each of the features, we have the leads describe the expected implementations. How will you develop this feature? How confident are you that this approach will work? Document the confidence and determine a gut feeling about your confidence in the implementation of the entire project. A task estimate may look like this:

Implement Frustum Culling   Estimate: 20 hours   Confidence: 7

One of the biggest mistakes made by companies is saying "yes" to a job they can't perform. If your gut feeling is that you aren't very confident in your ability to accomplish the work, please do yourself a favor and either 1) walk away or 2) insist on a time and materials contract where you are paid hourly for the work as you accomplish. Saying yes to a FFP job you aren't confident in will likely hurt your business as bad as your prospective client. Just say no!

If you are having challenges decomposing the steps or the cumulative confidence numbers are low, this might be a bad job for your company.

GarageGames Confidence Scale

Below is the scale GarageGames uses as a standard for confidence numbers:

  1. No clue -- don't make decisions on this. We need to talk more.
  2. Hardly a clue -- don't make decisions on this. We need to talk more.
  3. Someone else has done this and I read about it; job not well defined -- don't make decisions on this. We need to talk more.
  4. Someone else has done this and I think I understand this; job might not be well-defined -- don't make decisions on this. We need to talk more.
  5. Done something similar to this before and this relates to that work -- this estimate has a variance of +/- 50 percent of estimate.
  6. I think I understand this fairly well and I understand the goal.
  7. The average case for programming when the requirements are understood.
  8. A confident case for programming; average case for a lot of art work.
  9. I've done this before and it's very similar.
  10. I'm probably not working on software... or... no matter what; I'm only going to work on this for a period of time (i.e. 1 week of QA).

Article Start Page 1 of 3 Next

Related Jobs

Ringtail Interactive
Ringtail Interactive — Stockholm, Sweden

Technical Artist
505 Games
505 Games — Calabasas, California, United States

Senior Product Marketing Manager: Free-to-Play
Sony PlayStation
Sony PlayStation — San Diego, California, United States

Technical Artist
Sony PlayStation
Sony PlayStation — San Diego, California, United States

Senior VFX Artist

Loading Comments

loader image