The 5 Ws of Software Project Success

Computers are a necessary component of every business today, yet the success rate for software projects in business is not very high. Most companies get some value from implementing software, yet they get far less than they should, and far less than if they looked at software as an investment rather than as a cost of doing business.

If you look at it as a cost, you look at whether you can afford it. If you look at it as an investment, you look at whether you will get a 20, 50 or 100% return. Very few businesses ever achieve returns that measure 20% let alone more than that.

We have all heard the questions that every reporter must answer in any article. They are: Why, what, where, who and when. It turns out that these questions are the same ones that generate results for software projects. The reason that software projects fail to achieve big returns is that there is not a clear answer to these questions.

Let's look at each of these in turn.

Why buy or install the software?
While this seems like a simple question, there are many potential answers to the question. This is often described as the goal or objective of the “project”. The software can be used to satisfy many different goals, and often the people involved interpret different goals from the original.
Take Customer Relationship Management (CRM) software, for example. The assumed goal for some may be to increase sales, but CRM software can do many things:

• It has a contact manager.
• It has the capability to track every interaction with your customers.
• It has the ability to track the status of activity with a customer.

Saying that you want to implement CRM software encounters this type of conflict.

A recent client's objective was to understand the status of activity with customers. The reason was that he was having high turnover with salesmen, and when they left, he had no idea whether there was any sales in the works. By tracking the status, he could quickly assign someone to work on these customers to finish the sale. Most people that I talk to would not have assumed that this was his objective.

You must clearly define why you want to install the software to everybody involved.

What must happen to get the software to deliver the results needed?

Most software projects focus on software implementation, but this need has nothing to do with the software or training on the software. This has to do with how people do their jobs. If we use the example above, every salesperson needs to track all of their activity with clients if you are to be successful. This can be a lot of work.

What is the incentive for the salesperson? If there is no incentive, why would they do it? If they do it, how do you know whether the information that they capture is of value for your objective? Many projects attempt to capture all of the data, assuming that it will be of value later. This results in too much data that is of little value.

Define how you will track whether it is doing what you want it to do. Do it on a small scale to ensure that you can use the data that is being captured. Work with the data that provides the most value first.

Who, Where and When will the information be captured?
These are the questions that deliver the results. If people are in the office and working on their computers, it is easy to capture the information that you are looking for. Rather than write it down, people can type it. However, if they are in the field and don't have access to a computer, and don't have any other need to capture the information, it will be much more difficult. This is where most software projects go wrong. They try to capture too much information, but force people to do it on their own time and don't offer any benefit to the person doing it.

This is a case of less can be more. If you ask for too much, you will get garbage or not get it at all. If you ask for less, the most critical information, you are more likely to get it. If you also show the value that you get early, it is likely to be better information.

This completes the circle:

• Everybody knows why you are doing it.
• Everybody knows what must happen in order to meet the goal.
• The people who must do it, know where they have to do it and when.

CRM - 3 roads to disaster

CRM (Customer Relationship Management) seems to get an increasing number of articles about failure. It offers so much opportunity for a business, yet has a high failure rate.

The attached article by Rick Cook in Inside CRM is another in the list. In it Rick identifies 3 areas where businesses have made mistakes with a CRM project:

• Concentrating on technology rather than people.
• Not having everyone on board.
• Not putting the customer first.

I've mentioned these before, but it keeps happenning. The last is the most interesting. When we use the words "Customer Relationship Management", how can we think of anything but putting the customer first. If we want to improve the relationship, the customer must be first.

The second must be important if we are to accept the third. If our people are not on board, the customer will never be first.

If we accept those two, then we should not be concentrating on technology. It is the least important and only becomes important because the job is left to the technology people. Technology is only a small part of the solution. It may be a big one from a non-technician's point of view, but forget that. The people, the change in process, the relationship is what's important.

In order to achieve success, it is the only thing that is important.

Future state with a software project

When a business owner decides to take on a software project, they want to create an improvement in their business. With a owner managed business, this is more important that with a public business, because the money is coming out of the owner's pocket.

If this is so important, then why do many business owners get frustrated with the results achieved.

Many projects taken on to improve a business start off with a dream of improved results, but they are often just a dream. You look at what others have achieved, and HOPE to do the same. You don't know how they did it, but they used this software and got results.

The reasons are very simple, but not necessary very easy. As Albert Einstein said: "Life is simple, but not easy". The same is true of software projects. In order to get the results that you need, you need to understand HOW you will get those results. Your business is working a certain way today. How will the software change the way you get results? How will that benefit yoyr business? How will you know that you are succeeding?

If you can't answer these questions, you will be disappointed.

You understand your business. You don't need to understand the software. But you do need to understand how the software will help you. And you do have to play a major role in the decisions that are made during implementation of the software, because these can be critical.

Dream about what you want the future to be like. That's great. Then take a detailed look at what you have to do to make it that way.



http://www.valuedeliverymanagement.com/blog/index.php/2009/01/20/critical-insights-1/

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.

SOA - Another Technical Solution with the same issues

IT organizations and specialists come up with new buzz words and three letter acronyms all the time. One of the current ones is SOA - Service Oriented Architecture. At this time, it isn't of interest to small businesses, but the issues raised follow the same pattern that can be found in all IT related projects.

A recent article talks about ten mistakes that are made with SOA projects:

1. Failure to explain SOA's business value.
2. Underestimating the impact of organizational change.
3. Lack of strong Executive sponsorship.
4. Attempting to do SOA on the cheap.
5. No SOA skills on staff.
6. Poor project management.
7. Viewing SOA as a project instead of an architecture.
8. Underestimating the complexity of SOA.
9. Failure to implement and adhere to SOA Governance.
10. Letting the vendor drive the Architecture.

These issues are true for SOA, but they are also true for any IT project. SOA is new to most IT organizations. In the same way, new business software is new to a small business. Change the acronym to anything else, and you will have the same issues. In the past 30 years, significant effort has been expended by IT organizations to solve the overall problems. The failure rate is still very high. Even worse than absolute failure is that those organizations that feel that they have succeeded, do not get as much value from the implementation as they could.

As the article explains, the biggest issues relate to people and process. This is true of all technical projects. If these issues are not addressed, your chance of failure is high.

The full article can be found at: http://www.cio.com.au/article/253821/10_mistakes_cause_soa_fail?pp=6

More on CRM software installations

Another article on CRM (Customer Relationship Management software) talks about problems with SaaS (Software as a Service). This term can be found all over the IT press and is being hyped as the solution to all your technology problems. SaaS is simply a service where your supplier hosts the software that manages some aspect of your business (This BLOG is an example. I don't install or maintain the software. It's provided to me and I use it).

The primary point of the article is that SaaS doesn't eliminate the need to plan for implementing new software for CRM (or any other business function). The installation, management and support of software is only one small aspect of any software that will run your business functions. The time and effort needs to be put on your business processes and how implementation of the software will improve your ability to deliver the business outcomes that you are looking for.

The key elements of getting results that you want are:
1) Have a business goal.
2) Walk through your business process and identify how technology can improve your ability to deliver.
3) Don't forget the people. Everybody listens to their own version of WII-FM (What's in it for me). If your people don't see the benefits, they will fight it.

The cost of software is only one small part of the project. Lost productivity (as your people learn), conversion, training, consulting support are others. In an article on my website, I outline the costs of buying software.

Click here if you want to see the original article on SaaS and CRM.

The search for perfection in software projects

When installing software to run your business, there is good news and bad news. The good news is that most software today is very flexible and offers a lot of options. The bad news is that the software is flexible and offers a lot of options.

These options offer the opportunity to collect a lot of data that may be useful for your business. This data can be the source of failure of your project.

In speaking to a colleague today, I was reminded of all of the projects that I have been associated with and many others that I have encountered after they failed to achieve their objectives. In many of these, the planning process is the source of the problem. Each project is considered to be a major event. Since it is such a major event, the planners want to "get it right", and they assume that they won't get a chance to do it again. So they attempt to collect all of the data that they can, and anything that might be useful in the future. Anyone associated with making software work is familiar with the term GIGO (Garbage In, Garbage Out). If the quality of the data is poor, then the system just won't do what you want it to do. This results in failure of the project, or failure to achieve the return on investment.

The problem with any data collection system (that's what the software is), is that when you collect new data, you are changing the way people do their jobs. The more that you change it, the more difficult that it is to do the job. People may not be receptive to that change. When the job is made more difficult by requiring that new data be collected, people become more reluctant to do the extra work, until they see value from that effort.

The more data that you try to collect, the longer the planning process takes, the more effort it takes to get the job done, the longer it takes to implement and the longer it will take to get a return on investment. This stretches people's patience and reduces their interest in doing the extra effort.

Many projects, such as CRM (Customer Relationship Management) suffer from this disease. The planners see all sorts of opportunity in collecting data about customers, the interaction with customers. They attempt to get salespeople to collect this information. The salespeople see no return on investment of their time, and they don't collect quality data. The result is a failure of the project on at least some level.

The solution is to narrow your focus. Define the business outcomes that you want, identify the data that is required to deliver those outcomes and implement those features as quickly as possible. Measure whether those outcomes are being achieved and show your salespeople the results. Remember that they will be looking at it from the WIIFM perspective (What's in it for me).

Once you have achieved your desired outcomes, look for the next step and the next desired outcome. Many project planners look at a project from a one time perspective, rather than an iterative perspective. They want to capture all of the data the first time, and that dooms their project to failure.

More on software project failures

It's terrible to harp on this issue, but it is such a big issue. Software projects fail to deliver on return on investment. I had to raise this issue again because of another article that talked about it. The article is written from an IT point of view.

IT organizations in large businesses are a focal point for a lot of the work that gets done in a business. 70-90% of IT expenses are typically spent to keep the "lights on". This term is used by most people in IT for keeping the business running. Most businesses are lucky if they spend 30% on new projects. Even when they do, much of the staff's attention is placed on multi-tasking to keep the lights on.

When they do work on new business initiatives, they are focused on the mechanics of the projects: gathering requirements, implementing technology, managing the activities, trying to manage scope creep. Most IT organizations do a pretty good job of managing all of these activities. They are also focused on improving their abilities to get the job done. Project management, requirements gathering, managing scope have all improved over the last ten years, yet this has had little impact on the results.

The issue is not managing projects, it is not managing the steering committees and getting everybody to do a better job. It is a matter of focus!

Most IT projects take on a life of their own and lose sight of the original goals while they focus on the technical issues of the project. The goal may start out to improve productivity of staff in delivering service. A decision is made to implement new software to achieve that goal. From then on, the implementation takes over. The original goal is assumed to be met by the delivery of the original software. However, most projects take longer than expected. During that time, the business needs change; the business managers learn more about their business because of the project and change the requirements because they see a better way. All of the focus is on the development and implementation of the software, that is, to have a "successful project".

The result is that the "project" might be successful (i.e. it was implemented on time, within budget, meeting specifications), but the patient died (the business didn't get the results it needed).

While this article and other studies are focused on large organizations, the problem is the same with small ones. The projects aren't as large, the costs aren't as high, the failures aren't normally as detrimental, however they are still failures. Money is wasted and most small business cannot afford this waste.

We need to focus on the business value! What are we trying to make happen? How will the software help to make it happen? If changes are required because the business changes, then let's make sure the original goals (if still valid), will still be achieved.

The original article can be found here.

The 5 factors for a successful software project

In my experience, software projects in small business are successful for a few good reasons, none of which has to do with the software itself. It has to do with the approach of the manager or owner of the business.

The 5 factors are:

• Attitude
• Consistency
• Persistence
• Support
• Advice

I've discussed your technology attitude in a number of posts, and this is a critical factor. If you go in with an attitude that you aren't comfortable, you are aiming at failure.

Consistency is the second most important. For those people who have had negative experiences with computers, you may find this hard to believe, but computers are very consistent. They will do the same thing every time and will expect you to do the same. People are much more flexible and can adapt when things change. They don't recognize that St. and Street are the same and a lot of problems are caused by inconsistency of data. The same is true if you change the way you do something.

Persistence is the third key element. I have never seen a software project that goes perfectly and that is often due to our lack of consistency. No matter how frustrating it seems, you have to push on through and solve those problems that you will encounter during implementation. Most of them have simple solutions. The good news is that because of consistency, once they are solved (really solved), they don't return.

Support is a critical element. If you have no experience with installing software to upgrade your business, get someone to help you. An experienced consultant can help you overcome those simple problems that I mentioned. You will save a lot of time and effort and be able to continue to make progress towards your goal. Get somebody who will work with you throughout your implementation, not just react to your problems when you encounter them.

Even better, get some advice before you start. This will allow you to plan more effectively and prevent many of the problems that you are likely to encounter. If you do choose to get advice, look for a supplier who will work with you throughout the project. This means that they will learn more about your business and be in a better position to support you when you need it.

Notice that none of these factors involve either the software or your technical skills.

A long time ago, a mentor told me that there are three factors for success: focus, will and capability; capability is the least important. If you maintain focus and have the will to continue, you will develop the skills or capabilities that you need.

Getting started on a software project

I have a problem with starting software projects. I have been working with software for my whole career, and typically when I start working with a company, I understand the situation and what needs to be done.

While it is obvious to me, it is seldom obvious to my clients and their staff. They called me for help because they were not able to achieve the goals that they set out for themselves. I am ready to get going and can see the steps that need to be taken, but I can't go there.

Over time, I have learned that I can only go as fast as my clients are capable. In the early stages, it seems quite slow and little visible progress is seen. This can be frustrating for managers of projects as they are anxious to get going. However, this is a difficult time for people to go off in a rush. They are working in unfamiliar territory, with changes to their business processes, new technology and tools and typically a new list of issues every day. This is not normal operations.

Many consultants will offer a "solution" to this problem. They will bring in a group of outsiders who will make the project happen. There is a flurry of activity and everybody is happy. Then the project grinds to a halt. Often this is because roadblock and roadblock has been put in the way. This is usually after a lot of money and time has been spent. The reality hits that the staff has to know what is going on. It can't work without them.

While the early stages of a project can be frustrating for those that know what needs to happpen next, it is a time of learning, and sometimes learning can be slow. people learn what they need to know. Once learning has started and everybody understands where things are going, they start to look for opportunities to use the software and they understand how it can help them.

This occurred in a recent project that I worked on with a client. The first month was frustratingly slow. We focused on the business process and looked for ways that the software could help improve the process. We uncovered many process issues that would prevent successful implementation. In the second month, things were still slow. Volume of work prevented catching up with the backlog, but now we were no longer building a backlog. We were keeping up with day to day requirements. More process problems were identified and resolved. By the end of the third month, the staff had taken ownership of the software and could see how it was helping them. The backlog was eliminated and the software was functioning as desired.

Although progress was slow in the early stages and required ongoing support and coaching, the learning process was happening. The slow start was worth it.

In starting any new project, leave time for learning. Start slow. It will pay for itself later on. I have seen too many failures where companies bring in a ast of thousands to make early progress. The only thing that they succeed in doing is increasing the costs.

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.