Most Software Projects plan to fail

The success rate for software projects in most businesses are set up in a way that makes them easy to fail. They fail to achieve the original exectations of the business. The reasons are fairly simple. They are set up as technology based projects to achieve a technical objective, that of installing the software. Yes, there are other activities, but they typically lack a business focus.

The approach is as follows:

1. The business has a goal. Let's say it is to increase sales through the implementation of CRM software (Customer Relationship Management). CRM software allows you to understand your relationship with a customer better, and HOPEFULLY, to increase sales as a result. The business has certain expectations of what will be delivered (business outcomes), but they are not clearly defined.
2. CRM software is purchased to implement this function. A project plan is produced to provide the function. The project defines the project outcomes to be delivered. This includes the software, perhaps additional hardware, training, perhaps data conversion.
3. The project delivers the project outcomes (assuming it is very successful).
4. The business is left to make the busines outcomes happen using the software that has been delivered.
5. Has the project been successful? Is the business happy? Success rates of 20-30% have been identified on software projects. Business expectations are not met.

In order to have a success project, business expectations have to be met. In order to do that, we must define business outcomes, not project outcomes. Typical IT project outcomes are a subset of business outcomes. The plan needs to change.

1. The business has a goal. The business defines the business outcomes that must be ahieved in order for the project to be successful.
2. A project plan is developed to meet the business outcomes, including not only the items above, but also including changes in business process, change of roles/responsibilities, etc.
3. The project delivers on its activities, which produces the desired business outcomes. If not, adjustments are made until it does.
4. We don't have two teams, we have one. The business result is a common measure for both.

One of the most common problems in many IT projects is that business people get tired of all of the technical activities and abdicate their responsibilities to the IT team. Taking the second approach, reduces the risk of this happenning, because the business outcomes are key elements of the project.