Saturday, November 01, 2003

Telirati Newsletter #8

This is another that has stood the test of time. Now that I am involved in mobile game development, rereading this newsletter put into focus many of the project management tactical issues and product strategies I now must use to succeed.

Newsletter #8: You will make mistakes

You will make mistakes. So will your competitors. On average, their engineers are not smarter than your engineers. On average, their code has just as many bugs as your code. On average, their projects are as late as your projects. If you have respect for your competitors, you will soon realize they are not significantly better than you are, and you can't count on them being that much worse. So how do you beat your competitors?

You beat your competitors by managing better. In this newsletter I will discuss, specifically, managing your product development better. Managing your product development better will not change your schedules, bug-counts, or the make up of your engineering staff enough to beat your competitors, but it will prevent you from defeating yourself. Then you just have to keep that up long enough for your competitors to defeat themselves. So you don't actually beat your competitors, you just make sure you're there, in good position, when they blow it, so that you end up so far ahead they can't catch up to you.

You might think you can do this by avoiding mistakes. Not so. You will make mistakes.

Make your schedules so that they are not doomed to fail. And then, when they do fail, learn from them. How do you make a software project schedule? You make it simple. Schedules that have lots of parallelism and few major milestones that tie parallel efforts together are doomed to fail. Take a look at each of those milestones. If you have not met an early milestone, count on this: there is no such thing as making up the time. Push your whole schedule back by as much time as you missed that first milestone, and do not factor in partially completed tasks on the other side of that milestone.

Don't shoot your own officers. When a project slips, is it the impulse of your senior management to replace the project leader? Start a new, parallel project? Cover their asses? Flail around without diagnosing why a project got into trouble? If so, go find a new job. You are doomed. You might as well work for the IRS. If your company is incapable of learning, and reacting to problems in a way that extracts knowledge, it can't produce software. If it ever did, it was an accident unlikely to be repeated. A cleverer man than I called Apple, while Apple was still fat and happy, "the Cultural Revolution run by men in suits." What he meant was that Apple was run by a bunch of managers who were disconnected from the idea of making great products, who, indeed, were quite cynical about the whole "insanely great" thing now that Steve Jobs was gone. These stuffed shirts would cycle Apple's money through a lot of big, expensive, safe, and mediocre development projects. They avoided mistakes (they still made a bunch). They avoided risk (and still made mistakes). And, in avoiding risk, they avoided any possibility of Apple breaking out of its niche. And then, when things went badly wrong anyway, they purged each other like a Party Central Committee after a bad harvest. If you punish risk-taking, if you fail to learn from errors, these are the results you will get.

Communicate clearly. A specification running hundreds of pages, showing stultifying screen by screen depictions of a desired result is not clear communication. Typically, managers with a poor grasp of implementation technology generate specifications of that nature, and their only result is to alienate the design engineers into a stupor. Instead, make sure every engineer has a clear picture in his mind what the result will be, and what guidelines will be followed to achieve that result. Take one aspect of the project and have a visualization session that encourages the implementers to describe the ideal result in detail so that the engineers know how the specs should be visualized. Keep the specs short and sweet.

There is no substitute for strong leadership. Every product needs one person responsible for the result. The difference between your typical GM dullmobile and a BMW is that some individual cares what the BMW looks like. While there are no absolutes, and every product with any economic impact is invariably produced in a structured corporate setting, it is clear enough from the results when an individual has triumphed in expressing his will in a product, compared with the mediocrity produced by committee. This may sound like a rather poetic take on management. Ignore it at your own cost, however. Software is a thing that costs nothing to make, and can cost anything to buy. So if BMW can charge twice as much as GM for the same lump of steel fashioned into a car, just think what the difference could mean when what you sell is bits on a disk.

Pick a few clear themes and repeat the message often. Every major product should have one or two key goals. It should be clear that these goals are to be met at all costs, and that every other goal is secondary. This is the way to keep things on schedule. This is the way to make sure the key design elements receive the most implementation attention. This is the way to make sure that, if you hit rough water, every oarsman in the boat knows which way to pull. You won't have time to fix the clarity of communication about priorities in the middle of a crisis.

Count on losing a few. The way to attack a market segment is to find a set of approaches to that segment and prioritize them according to factors of development risk and likely reward, and when you think the market windows open and close for each opportunity. Then, count on the fact that you might not have a hit on your first try. Know, beforehand, then what your second, and third, try should be.

Compare and contrast results: Microsoft's Internet Explorer 3 is competitive, and version 4 is perhaps dominant. Windows, on the fourth try, dominates. Most of their competitors have quit already by the second round. Microsoft's approach bears all the hallmarks of: 1. Managing projects carefully. 2. Responding to delays intelligently. 3. Learning from errors. 4. Keeping at it long enough that, on the one hand, the things that have been learned can be applied, and on the other hand, the dim-bulb cover-your-ass managers at the competitors firms have long since failed. Simple enough. Why isn't everyone doing it?

Copyright 1997 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.