It’s kind of strange, but everytime I’ve been through the development cycle of any game I always here someone complain that “we should have planned better”. Or perhaps we should have “designed better”. They are tough accusations to defend against. After all, what can’t be done better? But those comments always seemed to me to be off the mark, missing something important about the development process. In a similar vein defensive comments like, “It’s hard to schedule innovation.” also seemed to miss the point.
So what is it with project management, process, and project planning?
This morning I had a soup to nuts project management experience with my six year old son that put some stuff in a clear light.
First, let me explain the difference I see between development and production. Production is something you’ve done before… many times. “Flipping” burgers, assembling cars, are tasks that I largely view as production tasks. Things that are well understood, processes that have been tried and proven many times, and optimizations (along with cost reductions) are a key focus of creative thinking and engineering effort.
Key questions asked for mature productions are:
- “Can I do it faster?”
- “Can I do it cheaper?”
- “Can I improve quality?”
- and “Can I improve consistency?”
Development is also concerned with these questions, but typically these questions get relegated to the back burner. One single burning question typically dominates the development project. Namely:
“How Am I going to do this?… at all.”
Development is of course almost never completely new, but it often attacks problems, or projects that the team has little or no direct experience solving. It leverages the teams strengths, builds upon what they know, but almost always involves fundamental changes in process, production, or understanding.
Put another way, Mature Productions are applications of “what is known.” Development, in my exerience is most often about “learning how”.
So, let me give a specific example and see if this helps.
My son wanted a skate board ramp. Have I ever built a skate board ramp before? Nope. Not one. But I’ve built lots of stuff. I have tools. I’m pretty sure I know how to use them. But I dont have a tried and true process for building skate ramps.
So I took the opportunity to teach my son about project management. I told him, here’s the steps to managing any project.
First, we start by knowing what we want. – Skate Board Ramp.
Then, I told him, here are the steps to managing any project.
- Design it.
- Plan it.
- Build it.
- Test it.
- Clean up afterward.
There were two important things, I said that were missing from my short list, between 3 & 4. LEARN, and ADAPT. To me they are integral parts of steps 3 & 4.
So, step 1 – design it, was done using Google Sketchup.
I sat down and quickly “sketched” out a ramp using the materials I knew we had on hand. I’d had some experience with this in the recent past and really liked Sketchup as a design tool. It made it super easy to figure out what angle I needed to cut the support legs (10 degrees), so there was little or no guessing when it came time to cut the wood.
I talked to my son once I’d finished the first draft of the design and in that process two more things popped up.
- Always check with the customer during the design phase. Once they get an idea of what you are trying to do, requirements almost always change as THEY learn more about what they want. Basically, you should test your design.
- Present information to your customer in a way that makes sense to THEM.
As you can see from my image, the ramp is show upside down so it shows what I (the developer) cared about most – the underside of the ramp and the structure I had to build. It wasn’t easy for my son however to see how he could jump off the skinny little posts. So I re-rendered the drawing with the dimensions removed and the ramp placed right side up. He was much happier. He also wanted it taller – 9 inches high instead of 6. So I quickly made those changes, printed the drawing and we were ready for the next part. The plan.
Together we wrote out the plan. It looked something like:
- Put on our safety gear (goggles and gloves)
- Gather our materials. (get the wood)
- Measure the cuts.
- Cut the wood.
- Assemble the ramp.
- Test the ramp.
- Fix anything that needs fixing.
- Clean up.
With that plan in front of us, we set about making our ramp. Now one thing conspicuously absent was the lack of time information. I didn’t really know how long it would take us to do all of this, but I suspected it would be about an hour project. An hour should be plenty of time. Of course it wasn’t, but we’ll see why in a minute.
Stuff changes:
We put on our safety gear with no problem, then quickly moved to step 2. Gathering the materials. Right away the design started to change. First of all, once I started handling the materials I realized that using 2×4′s for the legs might not be as stable as I wanted. I had a pile of 4×4′s which I decided to use instead. So almost out of the gate the design was changing. And this is extremely common in development.
Designs must adapted to the resources available.
I personally have never seen a development project that had EVERY resource it ideally needed available to it. There is always some constraint, or new information that comes along to cause change. Our ramp was no different.
Secondly, when I designed the ramp, I used the information I had available (namely dimensions), but the actual wood available varied somewhat from my initial estimates. This brought up another thing I’ve seen in projects.
Designs adapt to integrate new information.
In construction there’s a term called, “as built” and it refers to the way the contractor ACTUALLY BUILT the design. Not the way the architects drew it. In the HBO series project Greenlight, I remember after the end of principle shooting, someone saying, “Okay, now lets find out what movie we’re going to make.” Their point was just this, the movie they intended to make when they filmed, and the movie they ultimately ended up making were not necessarily the same. The realities of filming, caused changes that could not necessarily be undone later. Once the filming was done, the director (and editors) had to make the best possible movie out of the materials that had at hand. Regardless of what they wanted to do originally, they would adapt the design to the resources available.
Our little project was demonstrating these adaptions.
After measuring and cutting the wood, we started to put the thing together. Again more assumptions were tested, more changes were made and more problems ensued and were quickly solved. For example, the screws that were supposed to hold the wood in place were too short. We needed longer ones – but not so long that they would go through the 2×4′s. We scrounged up a suitable substitute.
Tuning
After assembling the ramp, we tested it slightly by walking on it and realized that there was too much flexing of the plywood. It needed just a wee bit more support. All in all the design was great, but we were all worried the wood would crack after a few jumps. So back in we went – to add 10 degree angle blocks in front of the 2×4 supports to keep the front of the ramp from flexing. In game development we often call this “tuning” making small changes to the design to improve it’s performance and the users’ all around satisfaction.
In programming, there are “optimizations”. The thing runs, but not fast enough, or with too many system resources, or just not well enough. So we “optimize”. Make small (but significant) changes that improve the overall quality of the project. That is the heart of development.
Development is about iteration – making small changes to improve the quality of the project.
We also noticed that even with our thick legs, they wobbled too much. They needed braces. Angle braces (left over from another project) were quickly called into service and the screws that were too short before worked out perfectly in their new application. It is very important to note here that we did not scrap the whole thing and start over when we ran into problems. The plans changed as we adapted to our resources, and learned new stuff, and the changes were relatively small. Development seems to be about progressively circling in on your goal. Development is not taking wild stab after wild stab.
Final Review
After we finished, we cleaned up, put our tools and materials away, then played with the ramp. It was fun. Then we put the ramp way. Later, we made one last change. Putting the ramp way, revealed that it was HEAVY. Watching my 6 year old son struggle to put his new toy away, I realized he needed some help. Finding a set of left over casters, we attached them to the side of the ramp so all he had to do was wheel it in and out of the garage.
The final ramp, looked as follows:
A few things I did learn during the project.
A few things I did learn during the project.
A few things I did learn during the project.
A few things I did learn during the project.
- With no time estimates, it was easy to lose track of time. The project actually took an hour and 45 minutes. But fortunately time wasn’t the critical factor. That is not always the case.
- While my son was involved and feels that the project was “his”, without a detailed task list to keep him engaged, he would often wander away. The same thing happens with adults. Without a clear list of actions to keep team members engaged to work toward a goal, they will at best do nothing of value, and worst, do things that are counter productive.
- Finally and most importantly, building a skate ramp with your son is a blast.
My point in all of this, is that not on the second time, but probably the third I would start to build ramps pretty much the same way. I would work out the kinks, and the mystery of “how” I would build the ramp would receed. The questions at the beginning of my essay would move to the fore front of my thinking and I would start to have a “mature production”.
So after all of this, I think the key to managing a successful development is not to whine about better planning or design, but to ask, “how can we learn faster?” Because that more than anything seems to be the central theme of development.
- Scott
Comments are closed.