Reply To: Development Management

#24943
Unknown,Unknown
Participant

(re: Development Management) Wow — a great question. I do think that one of the major reasons that Sierra did so well was that we managed development better than our competitors.
That said…
We did a terrible job. Most projects finished late and over budget. We had a bit of an excuse, in that there were lots of factors that could radically impact a project in development. For instance:
A competitor comes out with something comparable (I never wanted to be “second to market” in a product category) This could result in radical redesign If it just isn’t fun. This happened a lot. The game would be playable, but just “wasn’t fun” – this always meant LOTS of additional work Someone had a cool idea for a new feature – that we all agreed would make the product sell a LOT better
Generally though, our problem was that our staff, like me, were all perfectionists. Everyone was always wanting to do things over and over until “it was just right”. This meant redoing a particular animation dozens of times. Rewriting a routine over and over until it ran in the fewest number of milliseconds possible.
Our industry was different than most. A competitor of ours, Blizzard, always refused to establish a budget or ship date (or, so goes the rumor). They would agonize over the smallest details, and throw away major chunks of code – over and over again, for years. As crazy as this sounds, I loved them for this. When they shipped a product, it was awesome. The problem was: how do you do this in a public company? Shareholders demand ship dates and revenue projections. On the other hand, perfection takes time. I always had trouble balancing these two goals.
None of this may be relevant to your question. One good thing we had at Sierra was an amazing staff. We were in the fortunate position that the industries best talent wanted to work for us. Generally, we never shipped a product late due to incompetence. We shipped late because of wanting to ship a perfect product.
That can be different than the problems one might see at a “normal” company. Sometimes, in the normal IT world, there really are project managers who don’t know what they are doing – and, who can’t manage people. It happens all the time. My best advice here is to look at someones track record before hiring them. If someone ships a product over budget, late, and buggy – they will ship their next product exactly the same way. Most projects (that fail), fail before they start, through bad staffing. I can’t say this strong enough. If you hire leaders who shipped their previous products late (or, quite often not at all) – you have my word that they will almost certainly do it again Avoid hiring people who always seem to fail, but have really good excuses. I don’t like excuses. Great people get things done under adverse circumstances. People who claim to be good, but who have constantly failed because “the dog ate their homework” are best left to competitors.
-Ken W