Enterprises … are very focused on patch Tuesdays; they tend to think of the next release, and the release beyond that, as ways of solving problems. … But for game developers, patching is typically not an option. The release must be complete and almost perfect, because it will be standing on its own in the marketplace …. [I]n the game world, because everyone involved is so tightly focused on a release date and a single goal, the teams are able to be brutally honest with each other. What games can teach enterprise developers, Software Development Times, Feb 2012.

Beware of over-generalizing

When we try to nail down a problem that needs solving or a situation that needs improving, it is important to understand the context of the problem and well as the apparent problem itself. The generalization above that enterprises all focus on weekly patches and that then causes a kind of tunnel vision is a typical kind of over-generalizations I hear.

In one humorous case, I was interviewing for a position as Director of MIS (for a typical enterprise environment that had such things as weekly patches), and the VP interviewing me brought up my career in the military. She said she had worked with a military person before and ex-military are set on doing things only one way. When I then tried to describe the kind of flexibility I’ve shown in various jobs (including the Air Force) she kept “reminding” me that the military is inflexible and she knew that because she had worked with a military person once …. I really wondered why she had asked me to come interview. She overgeneralized based on a single, obviously bad, experience.

In the case from the article above with the weekly patch being potentially a problem, we’ve regularly helped organizations move from habitually late “big bang” waterfall based projects to consistently on-time incremental released projects. In some cases these projects were for technology products that were ultimately released to retailers and hence had to stand alone and could not be easily patched at a later time. We leveraged the advantages of incremental releases with the “motivation” of having to be almost perfect when we finally finished. The periodic, even weekly, release notion is a very powerful project management tool (look at its now popular use in Agile/Scrum). So when I hear that weekly releases somehow engender negative results, because they are weekly, tells me that this is probably not the root cause of the problem we are seeing. We need to dig deeper.

Brutal honesty works well

I love brutal honesty. I do like to remind folks that it is only brutal to those folks who are not use to simply presenting the situation as it is. When I’ve implemented brutal honesty, such as telling a project’s status — warts and all — I’ve typically encountered looks of horror, looks of outrage, and looks of “boy, he’s stupid and won’t be around long.” I’ve also received compliments from customers of “well, it is about time you started telling us the truth” and “thanks, we can now adjust our business case and still make this a success.”  One engineering manager, who was known for always saying whatever anyone wanted to hear (and had been regularly promoted with this approach), ask me with wonder “we can now just report the actual project status?”

As to the notion that by having a hard deadline where one can not tweak the product or project after it is completed engendering brutal honesty — I’ve never seen that. In fact, I’ve found hard “no excuses” deadlines often encouraged low levels of honesty because it was a death sentence to even suggest we won’t make it.

I had a VP explain to me how it worked in one Fortune 50 company. He said all the VPs would always say they were on time, waiting for “the other guy to blink first.” Once the situation got so bad where someone was forced to admit they would not be on time, then everyone else would quickly admit that they had more work to do also (kind of a support group for failure) but the game was to not be the VP who first admitted it.

In all cases where I experienced brutal honesty and it worked and worked well, it usually was first demonstrated by a significant leader who had the courage to do it. Once that was done, and people saw that they survived, then more people would do it. So in those same companies where there was brutal honesty, I suspect it had little to do with hard deadlines, but lots to do with key leaders who practiced brutal honesty and allowed others to do the same.

Also, compare approaches in Hiding The Problem As A Project Management Tool

I love articles that explore and explain why a company or industry does well. These are great to study and learn from.  Just beware of over-generalizations that attempt to explain why those successes exists.  Often the success might not be for the apparent reasons and so if we try to emulate the same successes without a deeper understanding, we may find ourselves unable to attain the same benefits.

See other things games can teach us with Teach Your Daughters War Games!

Are your project plans based upon any over-generalizations that might make achieving success difficult?