Projects Fail
Projects often fail. They either never get done 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. The development of computer systems is notorious for not meeting deadlines. 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. Such a deadline was set without full knowledge of what needed to be done. 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. Often, the result is that these problems will only surface when it is time to install the system.
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 of parts that work and parts that don't.
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. In contrast to that, the Agile project management methods such as SCRUM assume that we have limited knowledge of what needs to be done. In such methods, a project is split up into blocks that can be properly managed in small amounts of time.
The challenge is not to meet that impossible deadline, but to push back with ways that both satisfy the 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 needs and work.