Why software projects fail

The failure rate of software projects in business is far too high. Many reasons are given, including lack of technical skills, bad project management, lack of management support, etc.

In my experience, a poor choice of software and bad hardware choices are seldom the problem. The problem lies more in the lack of understanding of what software is to start with.

Think of software as the representation of a physical plant. This "plant" was developed to produce a set of products. Because it is a plant, it has to have a built in business process to deliver the product consistently. Each software product has a built in process to deliver. Two different software products sold in the same marketplace can have different underlying business processes.

You business comes in with a business process as well. If you don't understand your business process, and have it clearly defined, then when you install the software, you may be in conflict. The features are unimportant. The business process is critical. Match your business process to that of the software, and you have a much better chance of success. In addition, once you have identified how to use the software to deliver the functions of your business process, you have reduced the learning. You don't have to know everything in the software, you only have to understand how to do what you need.

Sometimes the process defined in the software may be different from your business process. This may cause you difficulty. There are two choices here. Change the software or change your business process. If not, you will always have difficulty.

I recently assessed a situation for a company that had purchased software and gave up on its implementation, because it was too complex. They could not see how to get value from it. In my assessment, I identified that the software was a match for their business, but they had not chosen the right functions. By using different components of the software, their needs were met.

The key here is not only to understand the business process, but also to clearly define the goals of the project. The goal is not to implement the software, but to achieve a business objective. After defining the objective, identify specifically how the software will meet that goal. You can't do that without showing how your process is affected by the software.