Keys to success in technology projects

This week Jeff Atwood has a great post in his Coding Horror blog, excerpting from Steve McConnell's 1996 book Rapid Development. He quotes a list of "36 Classic Development Mistakes" that can doom your project. I've had to extricate teams (and I admit it, myself) from many of these over the years. Jeff and Steve are thinking about software development efforts, but any technology project is prone to these mistakes. Avoiding these mistakes are the keys to success. Three biggies I've struggled with are: Heroics. This is probably the most common software mistake of all. A project looks like its going to need four more weeks of work. There are two weeks left to delivery date. Solution? The team works 16 hours days for 15 days. The result? The deadline needs to be slipped after all, a lot midnight code needs to be reworked, everyone is raw and ragged, and developer-user relations are frayed. Programmers are by temperament very prone to heroics, but users can encourage it by reluctance to modify deadlines when necessary. Key to Success: when schedules start to slip, accept reality and make adjustments. Insufficient Risk Management. As the authors of "Waltzing with Bears" note, every worthwhile software project carries significant risk -- or it would already be done. Developers often gloss over risks due to what my wife Doria calls "the hot dog factor" - the assumption that nothing will go wrong because they are real hot dogs. And users hide from risks because they do not want to confront them, plan for them, or call them to their superior's attention. When a problem emerges, it blindsides everyone. Key to Success: you really do need to plan for those unpleasant possibilities. Feature Creep. This one has be written about so often that it is easy to forget about - then you see it happening again. Users and developers put in a lot of hard work together to specify the desired behavior of the some new application. The as release date looms, there are more and more features user's can't live without. It may seem like its just correcting design shortcomings or adding flexibility. But release dates are missed, new bugs are introduced, and unintended consequences of these late change are discovered at the worst possible times. And when features do not seem to cost anything to users, all bets are off - there is no way to consider the return on investment of the development effort. It's easy to blame feature creep entirely on the users. But developers can encourage creep if they do not have clearcut process in place for tracking and accepting user requests. And they're setting themselves up for last minute change requests if they don't check in frequently with users as they work to make sure they are on the same page. The moral: You need a well-defined process, and supporting tools, for tracking and managing your user's requests. image originally uploaded as: http://www.flickr.com/photos/nicohogg/344155950/