Hell on Earth, and How to Get There Quickly

Okay, imagine this: Company X has just hired you as a producer. The head of studio hands you a complete, detailed design document and says that the project is expected to go into production in two months. The lead designer and lead programmer, highly qualified and easygoing people you know well, are already working on a prototype full-time and it looks like you have something special on your hands. You spend your two months carefully planning the project, the company approves the resource allocation plan you submit, and by the time the rest of the team is ready to rock and roll, you’re well on your way to a blockbuster.

If that’s the situation you find yourself in, you’re luckier than me, and there are numerous how-to books and articles that can tell you how to proceed. (Heck, you might even be able to apply some of those nifty concepts they showered you with at graduate business school. Never happened to me, but it might happen to you.)

Now, if you don’t mind, we’ll stop fantasizing, and talk about something a lot more likely. Let’s say you are hired to replace some poor schmuck who was recently disintegrated into subatomic particles by an irate CFO because his project (now yours) was going absolutely nowhere. The team tried to get by without a producer for a month or three while the company recuperated your predecessor’s severance package, so by now nobody (least of all the client) knows exactly what has been done or how well. Half the team has quit the company in disgust, and the rest is thoroughly demoralized.

Back when I was young and innocent, I was thrust into a similar situation.  I thought I was prepared. Now that I am a grizzled veteran pushing 30, I know better. The project I took over, a rather simple Macromedia Director-based multi-platform trivia game with a database of 16,000 questions, had already slipped its ship date by the time I got involved, and the hidden issues I soon uncovered were staggering. If I had known then what I know now, we probably could have finished the game 2 months earlier and with a lot less damage to our personal relationships. When appropriate, I will refer to this game in the text, but please bear in mind that this article is an aggregate of situations I encountered in a variety of contexts; no one project could ever have this many problems (I hope).

Earn the Team’s Trust

Let’s face it: when you take over as producer on a project that is already underway, you start out completely powerless. If your staff liked your predecessor, they resent you for "stealing" his or her job. If they didn’t, they assume you are no better until proven otherwise. Either way, productivity will be infinitesimal until you establish some sort of positive relationship with them. Time is of the essence here: if you don’t make inroads within two days, you are probably never going to, so get busy. In my case, I wanted to let the trauma of the situation (my predecessor had been fired while pregnant) recede before getting too involved; big mistake.

How do you earn the trust of a team in trouble? First, talk to them, one at a time, for however long it takes to identify the problems (real or perceived) which dragged the project to the brink of disaster. They know more about the situation (and each other) than you do. Make each staff member feel safe about talking to you, explain that whatever is being said will stay in the room, and that you are there to make the situation better for everyone, not to find a culprit. Make small talk for a while if a person needs time to loosen up. It’s a fact of life that if you demonstrate a willingness to listen, people will quickly open up to you. You may learn that:

• A junior programmer has been left without supervision when his mentor left the company. He feels cheated, because he did not receive the help he needed from more experienced colleagues and got a poor performance review as a result.

• Some people have been field-promoted because the departed had to be replaced in a hurry, and salaries have not increased with responsibilities.

• One of the guys can’t work overtime any more, because his spouse has threatened to leave him if he does not spend more time at home. Others have to pick up the extra workload and he feels resented.

These are all very difficult situations where no one is to blame. And remember that when dealing with people, appearances are as important as reality: if your lead programmer thinks that the artists hate him, you have a problem whether the artists actually do or do not hate the lead programmer.

Once you know what is wrong in the team dynamics, you will be in a much better position to find answers. Sometimes, all that is needed is a shuffling of responsibilities; it is human nature to be easily motivated doing stuff you like. Other times, you might need to trade an employee or two with another project to bring in fresh minds and resolve personality conflicts, or to negotiate on a shy team member’s behalf with a project lead or management. Whatever the solution you pick, you win, because you have shown to your team that you are willing to work hard to make their lives more enjoyable.

Restore Morale

Now that the team is ready to believe in you, it is time to make them believe in each other again. By now, your people are probably sick of the project, of its problems, and of each other. When bug reports pile in, rumors of cutbacks fly all over the studio, and the project becomes a laughingstock in the press (yes, it happens), hidden conflicts surface in a hurry. By the time you come in, some people may have left the company and open warfare may have broken out within the remains of your team.

There is little you can do in the worst cases, except get rid of a bona fide rotten apple or separate (physically and organizationally) good people who just can’t get along. However, most of the time, surprisingly little effort is required to get people to believe in each other. Find out who likes to talk to the gaming media, and who just wants to be left alone to do their work in peace. Find out who likes what kind of beer, and buy a round on Friday. Take them to a ball game, go shoot pool, have a pool-side barbecue at your place, anything to get them out of the office and give them a chance to enjoy each other’s company. Set aside at least 4 hours, because the first 2 will be spent breaking the ice, and the real bonding will only occur later. Here is the ideal scenario: leave at noon on a workday (this "small victory" accelerates the bonding), do something active in the afternoon, and talk over beer and sodas until 8-9 PM. You can repair months of damage in one day.

Assume Nothing

Now, get ready to settle down and perform a thorough review of everything related to the project: design documents, code, artwork, everything. It’s quite possible to let shoddy work creep into a project (consciously or not) when you don’t feel involved or believe that it might be canceled, so review all assets carefully.

Make it clear that you are not doing this to point fingers, but to resume the project with a clean slate. Explain that you must have a clear picture of the real state of the project before you can prepare a sensible plan for the future and restore confidence between the team and the client.

In my project, I failed to do this, because my team was already sick of the game and the senior staff who had written the most intricate code wasn’t with the company anymore. We assumed that since we had not met any serious problems, everything would be fine. Heh. It turned out that the "thematic search" through the question database ran fine on PC but required over 20 minutes on Macintosh once the 16,000 questions were integrated. I found out to my ever-lasting horror that the Mac version of the third-party tool we were using was written in Hypercard, and therefore totally unsuited to a project of this size. By then, it was too late to look for an alternative, and this major feature had to be scrapped. Imagine how happy that made the programmer who had spent several weekends making it work in the first place. Not to mention the client.

Earn the Client’s Trust

By the time you come in, the client, whether a publisher or your own company’s upper management, has been burned by the project’s past failures. However, they haven’t completely given up; otherwise, they would have canceled the project instead of bringing you in.

How do you regain their confidence?

• Be honest. Make realistic estimates of what has been done, what must be re-worked, what you can finish and what should be dropped from the project. Do not try to hide any of the project’s problems; on the other hand, do not pad your estimates excessively to make yourself look good. The client may not like everything you have to tell him, but better face the bad news now than to end up with another slip later. It may be the case that the project is in trouble (and the client ticked off) because unrealistic estimates haven’t been met in the past.

• Communicate. Talk to the customer daily, and don’t wait for them to make the phone call, either. If you come off as a forthcoming, straight shooter, the client will give you the benefit of the doubt and you may get more freedom than you think.

• Be firm. Do not try to wing it with a skeleton crew in half the time you really need, it won’t work. Refuse demands for excessive overtime to "make up for past mistakes". Explain the situation clearly and truthfully, and if the client doesn’t want to understand, get out, you can’t save this project. One of the reasons why my game took so long to finish was that both of my programmers had to spend 50-75% of their time on another project, which had been scheduled to begin once mine was finished but had not been pushed back or re-staffed once trouble began. In the end, both clients wanted our heads on a picket fence.

• Small victories. Make the first few milestones of your new project plan simple ones, which can be met in at most a few days. (In case a CEO is reading: "Fix all the reported bugs" is not a good choice for a first milestone.) Once you have hit 3-4 of those (which shouldn’t take more than 2 weeks), both your team and your client will believe that the project is back on track, and pressure will drop faster than the Atlanta Falcons.

And If They Say No?

Run. If the client insists on cutting your best estimates in half and reserves the right to add a feature or two at any time, you simply can’t win. No matter how hard and how well you work, you will never be able to meet their unrealistic expectations, you will get blamed for it, and the project will leave you drained, bitter and quite possibly unemployed. Save yourself the aggravation: leave now. It may shake them back into reality.

Conclusion

Successfully saving a project from the brink of disaster can be an extremely rewarding experience. Other producers will whisper your name in awe and sacrifice many goats on your sacred altar. Companies will be shoveling money at you for the rest of your life. Oh yeah, and you’ll feel pretty good about yourself, too.

However, before signing on, make sure that you are prepared, and that there is something to save to begin with. Be honest in your job interview: ask for a couple of weeks to evaluate the situation before committing to the job on a permanent basis. Then, give it your all. If you succeed, you’ll have a heck of a story to tell.

Bio