Exploring the Business Side of Making Games

Author: by Dianna Davies

It may be difficult for managers to accept global development ideas that come from the trenches, just as development people don't necessarily deal in the dollars and sense of the business side, but without constant evaluation of our industry practices we may find ourselves challenged to compete with the large publishing giants and increasingly competitive third party developers. The fact somebody is an entry-level programmer or a texture artist doesn't mean that they are not aware of what is going on around them, or feel the effect of being in the grips of a poor development process. The expression of these effects tends to manifest itself in emotional and sometimes defensive communication. If your team is expressing concern over a particular course of action, the first instinct we have as human beings is to feel defensive. After all, if things are not working perfectly who gets blamed?

What does this have to do with improving the development process? Analyzing your own motives in response to a challenging question can be very revealing. Ask yourself this first and foremost: "What is best for the project?" Remember that we are in the business of making games. Stress makes remembering that point difficult if not impossible. We are creatures of habit and when the chips are down, we revert to reactive behaviors. Naturally, this is not an overnight process, and along the way, those of us assigned the responsibility and honor of leadership make many mistakes. However, if we take steps to minimize the stress placed upon a team's performance through intelligent structure and goal setting, the business of game development can really be a pleasure.

Obstacles to Good Project Planning and Management

It's doubtful that anyone who has worked in software development has not experienced a slipped deadline or milestone. This problem is not unique to the software entertainment industry. Andersen Consulting, now known as Accenture, highlights reports that focus on the highest risk business practices within any software industry. According to a publication promoted by Accenture called, The Attention Economy - Understanding the New Currency of Business , the single most critical problem that software companies face is not resource shortages or lazy employees; it is attention deficiency in the management of software development. Our own little ADD problem can only be attributed to a lack of clear goal setting within the ranks of managers that trickles down to the teams. When a lack of goal setting causes the project to slip, the blame falls mainly on the team leaders, and rather than examining the flaws of the global project planning process, it is common practice in our industry to terminate first, ask questions later.

Objectivity is a tough nut to crack when you've been accustomed to the luxury of becoming emotionally tied to your product. It is, however, critical to master objectivity as a tool to properly analyze your product. Why? Because the current trends we indulge in, as an industry, may soon die. Money, as it always does, becomes the determining factor in just how long a company can survive making the same old mistakes. Successful companies seem to recognize the importance of impartial analysis to get to the root of their problems.

One unpredictable wrench in the cogs can come from an unrealistic, overly enthusiastic client, generating feature creep fever. The producer must clearly emphasize, before production begins, that any deliverable agreements will be at risk with the incorporation of added features.

Business Models Used by Non-Game Industry Companies

Most software projects do not use a disciplined approach. This results in optimistic estimates, lack of planning for revisions when we know this is a guaranteed dynamic, feature creep (public enemy number one), ballooning risks, and non-uniform project progress reporting.

I started to read up on a project generated by the Software Engineering Institute, through Carnegie Mellon, called the Capability Maturity Model*. This interest did not spring up out of the blue; I recently began working with a highly experienced software project manager and it was the sensible perspective this person offered that prompted me to attempt to look at management from a non-game industry perspective. Our industry is led by highly intelligent and creative people and, more often than not, undisciplined managers elevated to their roles through the demonstration of exceptional abilities relating to software development, not project management. The Capability Maturity Model (CMM) is comprised of several reports, including the Capability Maturity Model for Software and the People Capability Maturity Model . These models are in use by some of the most successful software companies in the world, including Motorola, IBM, Hewlett Packard, Boeing, and Lockheed Martin.

The CMM categorizes a company's performance into five levels of progression or maturity that describes the stage of development of a company's project management . The majority of companies are at Level One, or the "Initial" maturity level. This is the infancy of a company, and the software process is chaotic, undefined, and dependent upon the individual effort of the development team members. A company can remain in this state for no more than six years before this modus operandi becomes critical. It is at this point that most companies shut down. The report describes Level One behavior as having an unstable structure, not organized for the support of software development. "During a crisis, projects typically abandon planned procedures and revert to coding and testing. Success depends entirely on having an exceptional manager and a seasoned and effective software team…the software process capability of Level One organizations is unpredictable because the software process is constantly changed or modified as the work progresses."

In order to reach beyond this frustrating state of affairs (getting to Level Two in CMM terms) where a company can reach a level of predictability and ensure success on some kind of a consistent basis, it is important to describe some goals. Stabilizing a company's software development process is not an overnight solution. It takes time to plan well and even more time to plan right. Basic processes should be established and tracked in order to determine which is the most successful. Set some goals not only for the creative development process including game design, programming, art, sound and quality assurance, but also for the business development process.

The Intricate Web of Project Planning

The absence of solid project planning originates from a typical scenario in our industry: assembling the team before the plans are made. Project planning is like a web, and each department represents a strand. If one strand is weakened, the whole web is compromised. Project planning may be considered the foundation for the whole web. If your team manager has not planned for design time up front, chances are the project will face excessive revisions, missed deadlines, and re-design. As most developers are aware, this often 0means starting over.

It may seem obvious that time for a proper design effort should be given up front. Sometimes, however, a business goal is in conflict with an ideal planning phase. Not every company has a mother lode of cash to keep the company going through the full development cycle. As a manager responsible for scheduling, I've been at the mercy of the demo/development monster. In one case I was given a project completion date that required very aggressive scheduling, with no allowances for a change in direction or multiple demos. The directive often given to me by the president of the company was often in direct conflict with his immediate need to secure financing to keep the team going. Unfortunately, the team was assembled to move forward on the project plan as it was at the time, and design suffered because of the unmoving deadlines and demand for investment demos.

Our priority changed from developing a project by a specified date to creating the perfect demo that would attract investors. Ultimately, a new design effort had to be established before the rest of the team could continue producing assets for the actual game. The time spent waiting on a new design proved useful to the development team, since the team had never been properly prepared for the vision of the project. The lesson I learned was that I should not be so eager to enforce an aggressive schedule without being sure that the whole team understood the design of the game first.

Interdependencies in Project Planning

What are the needs of each department? How long will it take them to perform their tasks? Who is depending on them? What is the backup plan if you fail? The responsible project manager will make sure they have as much information as possible to help prepare for the unexpected. I love hearing about failed projects and the egomaniacal leader who did not heed the advice of the developers, or didn't even bother to ask any questions throughout the entire project! Most companies do not require good guesswork as one of the qualities in a manager. Organization, teamwork, reporting and tracking are all skills desired by companies in their leader candidates. Game development is not a one-man show.

A big eye-opener for me was coming to the realization that all of my planning and scheduling may have worked great for our art team, but that had little bearing for an undisciplined programming team. The interdependencies in a software development process can mean life or death for a project. There is an immediate opportunity for failure if one team is buying into the need for process, while the other half operates without consideration of consequence.

You cannot predict how long it will take you to do something if you have never paid attention to how long it takes you to do that something. Bless the hearts of programmers who respond to the request from the producer for an estimate of how long task A will take them by saying something like: "It won't take me any time at all, I can code that in a few hours…" However, the other half of the sentence should be: "…but I would need to test it in our game environment to really know the stability of the code." The programmer, in response, is considering only the time it takes to code the task. How long does it take to test the code with realistic representations of game engine assets? How proven is your game engine? How early in development is your test tool? How much time will you need to revise the code and re-test? These types of questions can just as easily be directed to any part of the development team that is not reporting regularly. Isolated development estimates are all well and good, but to realistically predict a deliverable product, the lead or producer needs to consider all aspects of development.

It is not easy to coordinate the tasks between departments. That is why establishing the goals of a project before development begins are so critical. How on earth can you expect to prepare for a voyage if you haven't decided on a destination? It can lead to some sticky situations if you don't know the climate or culture of a place before your arrival. We have all heard stories about day hikers who take off for a short hike, get lost in the process, and spend a life-threatening evening or more waiting to be rescued. Sometimes they make it, sometimes they don't. In game development, I doubt that a group of investors, or a publisher is going to have confidence in a developer that did not plan well and ended up costing them millions as a result.

Tools of the Trade

Sometimes, making mistakes is the most necessary step in project management because it gives a manager the opportunity to evaluate the flaws in both the established process and in their own way of conducting business. I was involved in a situation on a team where I realized I was investing way too much time on the success or failure of implementing structures and developing processes. It was downright unhealthy for me as a manager and as a human being. I resolved to remove as much of my ego and emotion from the situation as I could without losing my concern for the welfare of the team. I came up with a tool that really helped me out of a no-win situation.

Part of our failure to meet our goals was a result of the senior managers lacking tangible proof as to the impact of feature creep in terms of loss of development time. To be fair, I added items that were overlooked in our original specifications, and human resource problems we had encountered. I did not develop this until after we missed our first milestone. I was motivated to do so because I knew that some bad habits, which had plagued the company, stemmed from the lead programmer thinking he had the freedom to impose his ideas and will upon the team without consequence. After I developed this tool, which was a sort of managerial milestone post-mortem, it became clear that 80% of our failure was due to the actions of this individual. It was not presented in such a way as to blame this individual specifically, but instead as an unbiased analysis of our milestone problems, compiled with input from every team member.

I categorized the key issues into three descriptions: resource issue, feature creep, and missed in specs. I reported the specific problem, identified the team members it impacted, and then gave an actual number of days it impacted the schedule. Interestingly, our two month schedule slip was all accounted for once the report was completed. I followed the reporting process with a problem and solution section to help us focus on some easily remediable contributors to our problems.

Maybe we need to develop a standard checklist of project priorities before we go crashing into the development cycle? Why is it that, it is only after we are halfway through the project, before a lacking tool causes enough problems to get the attention of the producer? Probably because the team did not get the opportunity contemplate their needs and prioritize them. We developers often leave the worrying and coordination entirely up to our leaders because we think they have all the answers. No way. People are put into leadership roles for many reasons usually because they demonstrated leadership qualities. What exactly are leadership qualities? Some qualities include focus, knowledge of the product, organization, team player, and self-motivation. The term oracle does not ever enter the category. Sometimes our attitudes as developers are the main cause of the problem. If you think that something is being overlooked, speak up! It certainly is not in your power to make anyone listen to your advice or use it, but you can feel assured that at least any failure that does occur, had nothing to do with your reluctance to contribute to the planning and tracking of a project.

Here are the items I would put on my project-planning checklist:

Creating Team Unity and Personal Satisfaction

Development teams are only as good as the teamwork. Nobody single-handedly makes a game. I'm sure there are egomaniacs out there that like to think that they are the reason a game sold well, but the fact is that the best games had a great team dynamic. The egomaniac is too busy blowing their own horn to really contribute to the serious body of work. The team members who like to work together to solve a problem, usually do.

It is important to make team members feel valued and let them know that they have a voice in the decision-making process. When you are able to rally the team together in the name of solving problems and taking pride in getting something to work that was hard won, then the team members enjoy the process more.

Equally important is the development of personal goals during the project. When an individual is worried about what the boss thinks and there is a change in attitude, that person has probably lost faith in both them and in the system. I remember working for EA and being given achievements and objectives as part of my review process. I did not really understand the significance of that process, especially when my yearly review came up and the A's and O's were revisited. I had an immature attitude about my own shortcomings and felt very defensive when I perceived a failure on my part trying to reach an objective. Perhaps my failure had to do with the fact that there was no real mentorship accompanying those objectives. It was left entirely up to the individuals to track their own progress.

Recognize that guidance is going to be an important part of helping individuals as well as the team meeting their goals. You certainly would not establish a goal for a project and then sit back in your chair and wait for it to be met. The same should be true in our dealings with team members and review structures. I ask my team members to communicate to me any problems I may be causing as well as any problems anyone else may be causing; not necessarily to place blame, but to establish some guidance for the individual in order improve their performance. Some people need more guidance than others. Offer a positive perspective on a personal challenge.

The typical response is to reprimand or fire Programmer A; perhaps a better approach would be to sit Programmer A down and ask them if they need more direction, or if their goals are clear to them. Sometimes, a gentle reminder that being proactive is part of their job is all someone needs. Talk through problems! Air your grievances until you come to an understanding. Everybody appreciates a chance to correct a performance flaw!

The easiest time I ever had leading a team was when everybody was given their own part of development. It was easier to get a grip on problems in development and made everyone feel that they were important to the success of the project. Communication was better and people were more compelled to be proactive. It was important to establish roles at the beginning of the process and ensure that people were clear about their role as well. Weekly status meetings kept us all informed and on-track. I never directly told the team what to do, I merely helped them come to an agreement on a course of action, advised the pitfalls and pros when I could, and tracked the progress of the team according to the schedule. The schedule was never written in stone. We all worked in the same room together without walls or offices. To summarize this point in form, the successful formula for us was:

______________________________________________________

The Rational Planning of (Software) Projects; Mark C. Paulk. Published in the Proceedings of the First World Congress for Software Quality, San Francisco, CA, 20-22 June 1995, Section 4.

The Attention Economy - Understanding the New Currency of Business; Thomas H. Davenport and John C. Beck

Capability Maturity Model for Software, Version 1.1; Mark C. Paulk, Bill Curtis, Mary Beth Chrissis and Charles V. Weber. Published CMU/SEI, 1993.

People Capability Maturity Model; Bill Curtis, William E. Hefley and Sally Miller. Published CMU/SEI, 1995.

*Special permission to reproduce portions of Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-024 1996, and People Capability Maturity Model (SM), CMU/SEI-95-MM-02, by Carnegie Mellon University, is granted by the Software Engineering Institute.

CMM, Capability Maturity Model, and Capability Maturity Modeling, are registered in the U.S. Patent and Trademark Office.

______________________________________________________