A Consultant's View

Prairie Trail Software, Inc. ............................................................. March 2010

Project Failure

Projects often fail. They either never finish or wind up over budget and way late. Often, there are specific issues that are blamed for the project failure. In a Business Week article, Joseph Grenny points out that it is rare that the true cause of the failure are those specific issues. Instead, it is how we react to those issues that cause the project to fail.

One of the most common blames for project failure is a schedule that was too optimistic. Many times a project is given a deadline that has very little to do with reality. Often, the project was funded when the champion "won" a type of "liar's poker" about what the project would cost and how long it would take. Yet, that is not the cause of the failure. It is how everyone reacted to that deadline when they realized that it wasn't going to be met that is the true cause of failure.

One of the most common situations in development projects is the lack of good communication about the project status. Team leaders engage in a kind of "chicken" trying to hide how their part of the project is not following schedule. They lie about their team status hoping that some other team will take the heat for missing schedule and allow them the time to get their part working. The result is that these problems will surface at the worst time.

The common process of "liar's poker" to get the project and then, "project chicken" leads to attempts to install systems that are years behind schedule and are a mess.

Let's be honest about software development. Most development projects are a compromise between features and time to develop. Often, the effort to meet the deadline means that features get shortchanged, parts do not get tested properly, and user requirements get ignored. These actions can happen openly or they can happen surreptitiously. When management allow such choices to happen in secret, the project is far more likely to fail. Here is where "management by walking around" and quietly talking to the developers about what they are working on helps. Often, management can "take the pulse" of a project by noticing what kind of problems the developers are working on.

The standard "waterfall" method of project management assumes that we can know enough to properly manage the project from the beginning. Those projects are truly rare. Most projects are started before we know most of what needs to be done. The challenge is not to meet an impossible deadline, but to push back with ways that both satisfy the customer's needs and deal with the deadline in an open and honest manner.

Computer programs, like many other complex systems, need to meet a minimum level of operation in order to be successful. Having open and honest project management lead to systems that might not have all the features, but are far more likely to meet the customer's needs and actually work.

Prairie Trail Software provides the back end to the web with eCommerce, databases, web services, and provides the software for merchant service providers. Give us a call at 1-800-618-4199.