How Postmortems Prevent Projects from Hell The saddest thing about a traditional postmortem is that we make people sit down in a room after it's too late to change the project's results and think about all of the things they might have done if they had just sat down earlier to think them through. It's really just cruel. (May 2001 DevX)

Stabilizing Your Risk Executives intimidated by technical mumbo jumbo don't ask tough questions about deadlines, deliverables and costs. Technical staffs don't factor in the costs of long-term training, maintenance and support. Result: When the true costs are added up, as many as 80% of technology projects actually cost more money than they return. (May 2001 ComputerWorld)

Playing Project Telephone We can’t do this proposed project. CANNOT. It will involve a major design change, and no one in our team knows the design of this legacy system. And, above that, nobody in our company knows the language in which this application has been written. So, even if somebody wants to work on it, they can’t. (Apr. 2001 Enterprise Systems Journal)

Hedgehogs, Harry Truman, And IT Complexity Why did some prisoners survive the horrors of a Viet Cong prison while others didn't? First was an unshakable belief that they would indeed survive and someday be freed. The second factor was that the prisoners looked at their circumstances with brutal objectivity. The bottom line: figure out what's required right now and forget the Pollyanna attitude. (Apr. 2001 InformationWeek)

Keep Your Project On Track As a software developer or project manager, you're probably more than aware of the problems that plague your organization. The problem list typically starts with overwhelming commitments and deadlines. (Apr. 2001 Software Development)

When Bad Things Happen to Good Ideas Knowledge management revolves around the concept that one of the most valuable corporate assets is the experience and expertise floating around inside employees' heads. The problem is, in many cases KM devolved into a purely technical process, resulting in expensive software implementations sitting unused by oblivious, fearful or resentful employees. (Apr. 2001 Darwin)

New Spins on Spin-offs In the 1980s and early '90s, leading-edge companies believed they could spin off all or part of their IT organizations. Most of these failed. One reason is that companies don't realize it costs 10 times as much to commercialize a product as it does to develop it for internal use alone. (Apr. 2001 CFO)

Building An IT Team What makes up the ideal IT team? An icebreaker, a Sherlock, a straw boss, a guru and a sherpa. (Apr. 2001 ComputerWorld)

Mental Model Meltdown When I was a working programmer, I always had a healthy attitude toward management and my end users. I considered them to be frightfully stupid or in league with the forces of Darkness and Evil - probably both. (Mar. 2001 Intelligent Enterprise)

When the Going Gets Tough, the Tough Get… Gentle? I asked how long the project was estimated to take. They said eighteen months. By this time, I already knew the project was in its fifth year. This all sounded rather strange to me. So I gently asked if they would explain how project estimates were developed... (Jan. 2001 StickyMinds)

Creating the Project Plan . Though everyone has a favorite theory as to why software failures occur, my experience and work has taught me that more projects are doomed by poor cost and schedule estimates than by technical, political or team problems. It's no surprise, therefore, that so few companies and individuals understand that software estimating is not just an art, but a science that can be learned. (Jan. 2001 Software Development)

Bugs! While vendors shoulder most of the blame for today's shoddy apps, some industry watchers argue that a slice of the blame pie belongs to the all-too-quiet CIOs. But a handful of CIOs are bucking the trend. They're making sure they get better software by hopping in on vendors' test and development cycles and holding out cash until they fix their apps. (Jan. 2001 CIO)

Decide How to Decide Software projects require a decision leader—someone to "make the call." But the decision-making difficulties that plagued the Challenger and often software projects, reveal leadership alone is not the solution. The culprit is not a flawed leader but rather a flawed decision-making process. (Jan. 2001 Software Development)

Join the Revolution What aspect do violent revolutions and making changes to development processes share? Other than possible loss of life in large numbers (OK, there is a really small possibility of that, except maybe when changing development processes), both succeed when they have the support of the people. (Nov. 2000 Software Development)

Behind the Glass Curtain The effort to tie back-end systems with Web front ends is a cultural struggle, not just a technological one. A frontend proponent is baffled by the fact that an IT consulting company is projecting a cost of $500,000 for a site that integrates with backend systems. After all, the proponent just sponsored the development of a gorgeous Web site with highly complex visual effects. A college intern built the site for less than $40,000. (Nov. 2000 IntelligentEnterprise)

Software failure can lead to financial catastrophe Software failure is a terrifying possibility that should scare the bejeezus out of any company looking to stay in business. Considering all the money and time that goes into these projects, it seems peculiar that the application failure rate is so high. But developers and managers consistently make several mistakes that help explain this phenomenon. (Oct. 2000 Infoworld)

Open Source Meets Big Iron Dozens of studies during the last 20 years have shown that good working practices improve programmer productivity more than new languages, WYSIWYG interfaces, CASE tools, and other silver bullets. Despite this, most programmers still start coding without a design, then go on to short-change testing and set wildly unrealistic delivery schedules. (Dr. Dobb's Journal Jun. 2000)

Human Error Corporate IT staffs and business-line executives alike get so immersed in big integration projects that they forget not everyone in the company understands the project as well as they do. Instead of focusing on "screens and data," CIOs and system designers need to be more sensitive to why end users should want to use new applications. (CIO May 2000)

Self-managing teams Researchers have found that a manager's attitude about teams is even more important than the first line supervisor's. If an organization wants teams that it can rely on to solve problems and whose members like working together, give teams as much autonomy as possible over work flow and resources, and remove barriers to productivity, such as lack of equipment, materials, space and staff. (Training Zone Apr. 2000)

To Team or not to Team? The '90s was the decade of the team: team-bonding, team empowerment, hot groups, team bonus plans, team schmeam. But how effective are teams really? Are teams overrated, overused? (CIO Mar. 2000)

Check Your Ego At The Door Good manners aren't the first thing you look for in a software developer. But being a productive developer does require a certain sense of etiquette. Burnishing your particular piece so beautifully that it puts a drag on system performance is not only wasteful, it's rude. (TechWeb Mar. 2000)

Another Trip to Hell The timing for a project blowup could not have been worse. In the summer of 1999, Hershey Foods suffered a glitch in a $112 million new enterprise system. Third-quarter revenues were down $151 million from 1998. And what happened to Hershey can happen to any company. (CIO Feb. 2000)

The Best Influences on Software Engineering discusses the state of software engineering as we enter the 21st century. What has been the effect of code reviews, incremental development and prototyping? How have different programming languages changed the way we develop software? (Steve McConnell, IEEE Software Feb. 2000)

Turning CHAOS into SUCCESS Project management is gaining traction in IT organizations, and the results are encouraging. Failure rates and costs are down, and project success rates are up. (Software Magazine Jan. 2000)