Whether you’re developing software or painting a house, a project always seems to have two questions attached to it: How long will it take? How much will it cost? Those are necessary questions that determine the viability of the result. A project that takes too long may yield a less useful result. A project that costs more than the benefits it generates doesn’t make economic sense. I’ve heard these two questions a lot during my career.
In project management, the saying is: “Fast, cheap or good: Pick two.” The implication is that if all you’re worried about is time to delivery and direct cost, you’re going to end up with a poor outcome. But, as noted, a good product that isn’t delivered soon enough or at the right price, may not achieve the desired outcome. It’s a balancing act, to be sure.
Unfortunately for project managers everywhere, these two questions—How long and how much?—are questions which are asked at the very beginning of a project, when there are a lot of unknowns, both the known unknowns and the unknown unknowns. Obviously, if you’ve painted a lot of houses and you’re asked to paint another, the unknowns are relatively few. You know what unknowns you’ve encountered in the past (dry rot, wasps, hard-to-reach locations), and can account for these “known unknowns” with a little pre-planning. There are still unknown unknowns that can bite you, for which you add some contingency expense (again, based on your past experience of meeting unplanned expenses).
Generally, it’s best to hire someone who has done the job you want done (or something close to it) many times before, if you want an accurate estimate before committing to the project. It’s one way to reduce project risk (another is to limit the scope of the project).
But one of the problems with software development—and game development in particular—is that it frequently involves doing something that has never been done before. To be successful, a new game has to deliver a new or noticeably improved experience to the user. If we want to create a successful game, the best we can hope for is to hire people who have developed a lot of (successful) games. In addition, you have to rely on those developers when they tell you how long it will take. In the case of software, how long something takes is usually the main component of cost: paying the people who develop the software.
Mobile games (like the ones I help make at KIXEYE) are a huge business. In August, the top-grossing game for iPhones and iPads in the U.S. (Fortnite) was generating approximately 1.8 million dollars a day. Conservatively, that’s on the order of half a billion dollars a year from a single game! And it doesn’t count Android device revenues or revenues outside the US. It’s pretty astounding.
But a game won’t be successful if it isn’t fun. Unlike painting a house, success isn’t simply a matter of technical skill or the right choice of colors. There are thousands of good-looking, technically-competent games which don’t make any money at all. Lack of fun is the biggest risk in game development.
Until you determine whether your game is fun, you really can’t start asking the questions of “How long?” and “How much?” Which means you have to build (as quickly and cheaply as possible) some of the game to see what works. This means truly understanding what the core offering of your game will be. Is it building things? Is it combat? Player interaction? Leveling up for rewards?
The same applies to developing anything new. Call it a feasibility study, but it’s all about understanding the biggest risk to your core offering. If lack of fun is the biggest risk, you must address that at the outset. If it’s system throughput, you need to develop enough of the system to test that early on. If you don’t, you risk some very nasty surprises (after you’ve spent even more time and money). Decide how much time or money you’re willing to manage the risk of a failed project. That’s your first decision.
And what if you can’t make it fun, or get adequate throughput, or manage whatever the risk happens to be for your project? It’s disappointing, but be thankful that you found out in the quickest and cheapest way possible. Be thankful you didn’t disappoint your users with a bad product.
Let me leave you with my favorite saying about product development: Your users won’t remember if you shipped late, but they will never forget if you shipped crap. Remember that the next time you’re faced with the choice of fast, cheap or good.
