Getting it out There

In my relatively short time in the industry I seem to have attracted a few fixer-uppers, reboots, ports and all round oh do you mind just finishing it off jobs. Some of the biggest of these I have been Lead Programmer or Lead Designer on. Through mistakes, and successes I now have a rough battle plan for getting these jobs done that I thought I would share as my first post.

To clarify we are not referring to projects with a stable team and direction that you take over, or are promoted in charge of. We are talking about those deals where a wet deposit of mud is dropped on your desk, and you are told to find the diamond inside.

1. Run Away if you can

First off, run away! No seriously escape is your best option. These jobs are scary, messy and with ten hidden problems for every problem you can see. Unless there is a really really good reason to do this then just leave it, its not worth your time.

Okay you think it may be worth your time? First question has someone signed some paper-work and committed you before a full in-depth review, if so slap or knock out the foolish suit with no brains. Try avoid commitments, and deadlines at first, you need some time to inspect this project with your full team.

2. Investigate & Negotiate

Find the stake holders, and if possible the developers originally involved and follow the path that lead to the current state. Treat all previous work on the project as if it was done by a genius savant who forgets his trousers. The people before you are likely to be intelligent and experienced but assume they make silly mistakes.

Find out the stake-holders goals, and what they want from the project. Whittle it down as much as possible and kill any sacred cows you can. The more you have the option to change and throw out the more options you have.

Ask to get back to them, keep the lines of communication open. The most common cause of a project failure of this kind is a lack of communication or vision. Understand what they want, keep them in the loop because I guarantee you that you only understand half of what they want, and they only understand a tenth.

3. Rip & Roar

Is there a playable build? Get some pizza, drinks and your team together. Play it play it and play it some more. Understand the product, read the documentation, pour through the assests and then rip into them.

Give the team a chance to say what is terrible about the game, what should be burned with fire, and stuff that just doesn’t make sense. Be sure to keep them on track with the stakeholder vision, but don’t stop them from tomatoes at the goals, let them question it.

Write all this down in a public space, such as a whiteboard. It keeps everyone aware of the challenges that need addressing.

4. Analyse

Pick through the design, art and code. Often the design of a derailed project will have conflicts, and missing pieces of data. Get your design team to dig deep into the numbers, and systems.

The code review strategy depends on the size of the team. I suggest strike teams of 3-5 programmers with specialist areas, or general on a small team, to attack all the core systems. Compare it to the documentation, if there is any, but more importantly map it out yourselves. Don’t let them do any commits yet, just map out the maze.

I cannot speak for the art process but generally its been a case of compiling a style bible, and clarifying the style. Hopefully someone else can give more advice here ;)

Highlight areas of risk, and I can guarantee for every one you find you missed three. You should now have replaced your rip apart boards, with risk boards.

5. Rebuild

Talk with the team about time-scales and build a plan to rebuild. Leave yourself time to iterate, and for the un-missed risks. This is pretty much like a normal game process just with a very unstable base.

This is normal project management, and I don’t want to tell everyone how to suck eggs. The only real challenge, which is hopefully address by the previous two steps, that the team buy in is much harder to get on a rework than a fresh concept.

6. Set Expectations

Now is the time to go back to the stakeholders and set expectations. The worst mistake you can make, and one I’ve made, is to try gloss over some risks.

Everyone should know the risks, the costs and what they are likely to get at the end of the project. I guarantee the costs are higher, and the risks are higher. The only reason to do this from a business perspective is to recover investment. Don't be afraid to say it's not worth it and kill it now.

Sometimes though the reason is because someone believes there is a diamond in that piece of mud they dropped on your desk. It’s a great feeling to find that diamond, and worth the work.

Also now would be the correct time to sign the piece of paper. ;-)

Claire

Postscript

Here are some general tips for you all, hope they help.

• Lines of Communication are so important in problem projects, be sure of them.
• Don’t pollute the project with blame, hence the rip it sessions. It gets all that negative air out there then rub it out and replace it with plans.
• It’s tempting to throw out massive blocks of code, but a lot of time can be wasted. Instead I encourage decoupling efforts first so you can isolate problem areas.
• Some core design may need to be reworked, but encourage your designers to isolate risk areas first.
• Don’t be afraid to prototype! Yes I know the project has already started but prototypes give a stable clear vision of a problem and a possible solution.