[Experienced Sony Computer Entertainment Europe producer David Manuel shares the secrets he's learned from years of seeing developers fail to learn from the mistakes they've made on projects in the past, and offers suggestions on the key learnings to integrate into your production process.]

Last year, in Brisbane, Australia, where I used to live, there were the worst floods for over 30 years. And yet over the last few centuries there have been several such floods that have hit the city.

After each flood, there has been a commission to look at ways to mitigate flooding in the future. And yet most of the recommendations are ignored and building continued on the flood plains. This seems to be true with a lot of events around the world -- whether it's floods, fires, or riots. A commission is set up, recommendations are made, and then we shelve it and forget about it until it happens again.

The same thing happens in video game production, too. We often spend time writing up postmortems -- but are these lessons heeded? It's depressing to see the same old issues, such as feature creep, aggressive crunching, low morale, lack of focus and direction, communication issues within the team or/and between developer and publisher, and poor technology and pipelines crop up again and again.

We, as an industry, often fail to act on what we learn.

Over the last decade, we have heard a lot about agile production methodologies and the need to embrace change, which makes sense. However, even when agile is used, similar sorts of problems arise, and in some cases are exacerbated.

The goal of this article is to discuss ways of minimizing these issues at the start of new projects, primarily by creating solid foundations and planning ahead. In other words, even with unpredictable weather, building a dam and avoiding building on flood plains is far cheaper, and better, than waiting for the next flood to hit.

1. Implement Previous Recommendations

Not all teams write up a postmortem at the end of a project, either due to apathy or because they see no point. However, if we are going to even begin to learn from our mistakes, then all projects, especially the ones which were canned, need to have a postmortem.

It also needs to be a fair process which is diplomatic but at the same time doesn't pull its punches in terms of what went right, what went wrong and what can be improved next time.

Once a postmortem has been written up and agreed by those involved, it needs to be available to all members of the studio -- preferably through the company's intranet, so it can be referenced at any time with ease rather than lost in email or hidden away in archived folders.

When starting a new project, ensure that all relevant recommendations from the postmortem are implemented and checked at regular intervals by the company to avoid these recommendations being forgotten and the same issues constantly recurring.

2. Start Early and Start Small

One of the biggest impacts on finances is managing the peaks and troughs of development team sizes, especially between projects. All too often it appears the next project only really gets going when the current project has ended. Unfortunately, this creates the problem of having too many staff twiddling their thumbs whilst those designing the project are only just beginning to lay down the foundations of the game and its overall vision.

Instead, it would be much better to develop the next game, if possible, well in advance during the current project, with a skeleton crew of staff numbering around 10 percent or so of the eventual team size.

Personally, I would include in that group the following: a full time lead designer to work on the basic vision, research, and game design; a producer to map out the deadlines, the budget, the potential scope, and work closely with the clients on the brief; and a concept artist to visualize initial ideas. Naturally, they would need to regularly liaise with key staff who are due to join the team later -- e.g. the lead programmer and lead artist.

It is also advisable to keep everyone who is earmarked to move onto a new project informed of its progress via presentations, etc. Otherwise, if people are kept in the dark, they may feel resentment or detachment towards the new project. If people are simply slapped onto a project mid-development, they may feel more like a jobbing resource than a valued member of the team.

The idea is that when a number of production staff comes across to work on prototyping, a lot of the foundational work is already in place. Note -- this does not prevent iteration, flexibility or the continuation of creativity at or beyond the concept stage. It is primarily there to initiate what the game and the prototyping should focus on rather than having too many development staff stumbling in the dark looking for ideas without having the luxury of time to research and to simply think. There shouldn't be a massive amount of game development documentation awaiting them at this stage.

3. Put Your Key People in From the Start

The problem with having a lead designer and producer starting early on a new project is that there is a high chance they are also working on another project in mid- or postproduction. To get around this, I would advocate staggering lead designers and producers on projects -- meaning that there would always be an available lead Designer and producer not in full production, even if it's a one project studio. The additional expense would be cost effective, because the rewards are so much greater than the risks.

If we skimp on a resource, particularly one that is needed up front, then the impact can be severe. If you are unsure of someone's ability in a key role at the start, then it will be far more costly to change them later during mid-production, as it is likely their work will be redone.

Make sure you have utmost confidence in those key personnel. If there are any obvious skill shortages, then start the recruitment push with plenty of time to fill the position for when it's needed, or implement a training program.