Slashdot Mirror
How Mission Creep Killed a Gaming Studio
Nerval's Lobster writes: Over at Kotaku, there's an interesting story about the reported demise of Darkside Game Studios, a game-development firm that thought it finally had a shot at the big time only to collapse once its project requirements spun out of control. Darkside got a chance to show off its own stuff with a proposed remake of Phantom Dust, an action-strategy game that became something of a cult favorite. Microsoft, which offered Darkside the budget to make the game, had a very specific list of requirements for the actual gameplay. The problem, as Kotaku describes, is those requirements shifted after the project was well underway. Darkside needed more developers, artists, and other skilled tech pros to finish the game with its expanded requirements, but (anonymous sources claimed) Microsoft refused to offer up more money to actually hire the necessary people. As a result, the game's development imploded, reportedly followed by the studio. What's the lesson in all this? It's one of the oldest in the book: Escalating and unanticipated requirements, especially without added budget to meet those requirements, can have devastating effects on both a project and the larger software company.
So the real story is that bad contracts killed a gaming studio?
What idiots signed a contract allowing Microsoft to unilaterally change requirements mid-project with no increase in budget?
Sounds like it truly is one of "the oldest ones in the book": Working with Microsoft is a bad idea.
Haven't we heard of multiple companies being screwed in partnerships with them over the years (long before Nokia)?
Agreed. I've been writing software for 32 years, and "We've completely changed your requirements, but that shouldn't affect your schedule or your budget any!" happens all the time. The point is, you have to push back. Tell them exactly what every change is going to cost (padded heavily). Unless they agree to add time and money to the project, then just deliver the originally agreed to project. Don't let people make unilateral changes in the contract after it is signed, unless you actually like working on money-losing projects!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
The point is, you have to push back.
We love to make fun of the useless "suits". But that's a situation where you need good executive management and good lawyers. They need to negotiate good contracts up front, and then make sure the contracts are abided by.
Escalating and unanticipated requirements, especially without added budget to meet those requirements, can have devastating effects on both a project and the larger software company.
Not to mention the company's workers, who are likely to be burnt in the process before getting lay off
And it's also a situation in which you can get completely and utterly fucked by the people in suits who work in sales.
Many of us have seen what happens when that oily salesguy you'd like to to kick sells something which is complete fiction, and that it is now someone else's problem. His check clears, he gets a new car and a vacation, and everyone else is stuck building a fucking unicorn.
Sometimes, in small companies or with overly greedy salespeople they can sell the farm for a couple of magic beans.
And then no amount of effort is going to make it possible to keep up with an unrealistic client with a gold-plated sales contract which doesn't impose penalties for them failing to stick with a coherent design.
Sometimes, it is the suits who get you into this kind of trouble, and then they double down until there's nothing left.
Lost at C:>. Found at C.
I work as a mechanical engineer, in the building industry (HVAC) and while this is also quite normal, the word that gets thrown around is variation, obviously to the contract.
Reading the article, particularly between the lines, it appears that the problem wasn't really with the studio; they were trying to get more money out of MS, but MS just decided to kill the project rather than have a cost blowout. While mission creep did kill the game, the studio didn't plan any contingency or mitigation for a cancellation (or more likely it was just sack everyone).
Or, that the specs meant something very different to the developers than it did to the client. And the client then had to adjust the specification to get the developers to do the work _they actually agreed to do in the first place_. I've been encountering this especially with outsourced projects lately, where "QA the system" means "QA the whole system" to most systems or management personnel, but to the 3rd party QA team it means "test just the new feature". Then when the new feature reaks or hinders another longstanding features, _which should have been reported by QA_, the developers are faced at the last minute with a mad resdesign task that affects _both_ systems and is not stable, to boot. But it passes the very limited test specified to pass that specific bug report, so it is accepted and goes into production.
It's been a difficult few weeks trying to clean up after several messes like that. It pays the bills to do this work, but it's very frustrating to have to clean up _after_ you waned developers and QA of the risks they were taking with the "test only the new feature" approach.
Many of us have seen what happens when that oily salesguy you'd like to to kick sells something which is complete fiction, and that it is now someone else's problem. His check clears, he gets a new car and a vacation, and everyone else is stuck building a fucking unicorn.
Scott Adams summed it up nicely.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
Dilbert cartoons are spot-on about a third of the time.
The rest are understatements.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."