Slashdot Mirror
Anatomy of a Runaway Project
JCWDenton recommends a piece by Bruce Webster revealing some insights into a failed multi-million-dollar IT project. "The following document is the actual text — carefully redacted — of a memo I wrote some time back after performing an IT project review; names and identifying concepts have been changed to preserve confidentiality (and protect the guilty). The project in question was a major IT re-engineering effort for a mission-critical system; at the time I did this review, the project had been going on for several years and had cost millions of dollars; it would eventually be canceled and the work products abandoned. The memo itself provides an interesting glimpse into just how a major IT project can go so far off the tracks that nothing useful is ever delivered."
Depending on where the bottlenecks are, Java could do reasonably well. (And I say this as a professional kernel developer that works mostly in C, assembly, and shell scripting.)
The bulk of most apps is not a hot path and therefore the language is not as important. Even in the hot paths, algorithms often count more than the language. Once a suitable algorithm is determined, performance-critical things are often best written in other languanges (and if it's really critical, in assembly).
In short, a lack of senior staff means a lack of attention, coaching and oversight. If you have too many juniors, your project is going to take a lot longer to correct "newbie" mistakes, and these mistakes are caught later after they're made as well. Either allow for this extra time, or end up with crappy code.
Sadly, the idea has taken hold with upper management that IT is simply a commodity, and as a result most IT shops have become piss-poor at identifying and nurturing talent. They expect junior developer to become "mediors" automatically after a few years, where in practice they have picked up a ton of bad habits on which they've never been corrected. And I expect the shortage to increase in the future... more and more professional IT staff are starting to look for ways out.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
From large companies to small, it's the single biggest problem they all have. Decisions makers don't want to hear the truth, no matter how loudly they protest otherwise. Anyone with intellectual honesty that doesn't have a previously won huge level of trust from a decision-maker is almost invariably thought to be lying. They all want to have their cake and eat it too, and they will throw money at anyone that tells them they can. Even after getting burned by the consequences of their decisions, less than half (in my experience) bother to try and learn from the failure. Most of them blame the honest person (if they did nothing and as a result failure happened) or latch on to the next person willing and able to lie even more convincingly than the last guy.
It is unfortunately common to knee-jerk a development problem by adding more management.
A project manager who doesn't actually have the skills it takes to make a project successful will be as bad or worse than no project manager at all. Hiring/retaining more of them will just multiply the problem.
It is very difficult to interview for and find good project managers. The talent pool is just teeming with people who are not skilled developers, and would to love to have a job that is, essentially, just telling other developers to do their jobs. There is tremendous incentive for people who are not competent to be a project manager (or much of anything else, for that matter) to fight tooth and nail for PM jobs. When you hire such a person, your project usually fails, or if it does succeed it is despite, and not because of, the best efforts of your project manager.
Another problem: the best project manager in the world won't get you results if you disempower him or her. I have seen it happen often that the executives see a project slipping and shift into micromanagement mode. At that point, the project manager just becomes a mouthpiece, and the company has robbed itself of the value of their paid talent. If you can't trust your project manager to tell you when a goal cannot be achieved, or when more time must be allocated to some task that doesn't have obvious functional benefits, or that a deadline must be extended, then you have either hired a lemon or you are involving yourself too much in his job. In either case, your project will suffer because of it.
Ok, I will stop ranting now. The bottom line is...more management doesn't solve problems. The right amount of *competent* and *properly empowered* management does.
It all comes down to the fact that somehow the common business sense that people have in every other area seems to go out the window while they are thinking about IT.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
I read this with interest as I have been involved in large scale IT development projects for various corporations for the better part of 15 years. This memo makes it appear as if the problems in the project were execution related: bad management, poor quality control, bad architecture, performance problems, etc.
In my experience, it is actually not that common for an experienced team to fail largely on execution problems. Rather, as I like to say (call it Renn's Law if you'd like): "Most failed corporate software projects failed before the kickoff meeting". Usually the signs of failure were there all along, before the project even officially got started.
Here are some of the key things I've seen lead to problems, most of which are not directly related to the core development (design, build, and test) of the project:
- Lack of an identified executive sponsor
- Failure to identify a limited subset of people who are empowered and responsible for articulating the business requirements of the system
- Lack of clarity as to the actual goals to be achieved or the underlying problem to be solved.
- No shared vision of what a successful outcome would look like among the various stakeholders
- Project positioned as an IT-centric solution to a business-centric problem without a corresponding business strategy, process, and change management plan in place.
- Insufficient resources (time, money, people) allocated to the project
- Lack of qualified staff in key roles (data architect, functional lead, etc)
- Poor governance and scope control