Increasing software project failure rate

Software project continue to have an increasing failure rate according to a Standish report. Standish regularly reports on the success of software projects. This year shows a decrease in success.

While more and more emphasis is placed on project management for the failure, I believe that the real reason is a lack of business value definition. In too many cases, projects get initiated with a good and valid business reason, but the "solution" is seen to be the installation of software. Software is a tool which can help a business improve, but it is not a solution by itself.

More effort needs to be placed at the front end to determine the real goal. The real goal might be to increase sales, reduce costs, improve cash flow, improve quality of service. By using a software product the business may be able to capture and analyze data more quickly and easily, deliver goods more quickly, etc., but the software will not do that. It can help, but if your business process is ignored, you may end up creating more problems, more quickly. That doesn't help reach the business goal.

Start by clearly identifying the business goal, then show how the goal will be achieved. When you see what steps are required, you can identify where software can help. After you have decided how the software can help, don't turn the project over to IT for implementation. Keep focused on the goal, which should deliver business results, earlier rather than later.

If there is something in the project that doesn't produce business results, you will learn that earlier and be able to adjust the deliverables of the project to ensure success.

Key issues in CRM software failures

I attended a town hall meeting today on IT failures specifically targeting CRM. The key items mentioned about the failures all related to not It and non-software issues. Some of the key items that I took away included:

• Software comes with the vendors version of best practices. This may not be your company's view of best practices. Converting to their best practice could hurt your results.
• For CRM in particular, attempting to get information on what your best salespeople do is a problem. If you ask them what they do, so that you can copy it, then watch them, you will find that they don't practice what they say. This is true of other professions, but it may not have the same impact. Most of what people do is done subconsciously. That's why what they say and what they do is different.
• Many IT projects fail because they try to do too many things for too many people. This increases complexity and increases opportunity for failure.
• Because of the defined complexity, the application becomes difficult to navigate and decreases productivity and sales. It's better to make it simple.
• There is too much emphasis on training vs. education. Training tells you how to do it. Education helps you understand why you should do it and how that will help to improve performance. There was another question related to how much training should be provided vs. making the software intuitive. Would anybody play games if they required you to attend a full day training session?

Those were my key takeaways. You can check for more on Twitter at #ITfail.

Top Ten List for CIOs

The Chief Information Officer title has been around for some time now. The title is often used to describe the person who heads the Information Technology function for a business. While this is normally true, I believe that this title should be restricted to leaders who recognize the value that Information technology should be providing for a business.

Too many CIOs are still "managing the business" That is, they are responsible for all of the technical staff and hardware and manage the day-to-day operations of the IT business. While this is a necessary function, it doesn't add value.

The Society for Information Management (SIM) have completed a study of CIOs and came back with the following list of priorities:

1. Business productivity and cost reduction.
2. IT and Business alignment.
3. Business agility and speed to market.
4. Process re engineering.
5. IT Cost reduction.
6. IT reliability and efficiency.
7. IT Strategic planning.
8. IT innovations.
9. Security and privacy.
10. CIO Leadership role.

The focus here is clearly on the business and not on IT as the driver. This says one of two things: Either the CIOs polled are taking action or at least the message is getting through.

In the past, too much of the focus has been on Reliability and efficiency (#6) or on Security (#9). While these are important, they are what the IT operation needs to deliver. The CIO needs to be focused on the business.

See Top Ten Presentation.

A view of a failing software project

I have just read an article about a CRM project that is doomed to failure. The basis for the problem is that, buyers often utilize the customizing features available in many software packages to change the functionality before they understand what the software does and how it works. Utilizing the software out of the box is what the writer recommends.

While this may not be possible for all software buyers, it raises an excellent point. Software is developed to automate a process. If you start to change the functioning of the software without understanding the basic operations of the process, you are doomed to failure.

The answer may not always be, use it out of the box without changes. However, understanding the underlying process is critical. A better approach would be to document your existing business process and compare it to the process provided by the software. This does two things:

• It provides you with a basis for evaluating the software and identifies opportunities for improvement of the existing process and what you can get from the software.
• It will also tell you whether there is a conflict.

Now you know exactly what you need the software to do and whether any enhancements are required. If there are no critical missing requirements, I would agree: Use it out of the box without customizing.

You will get results earlier, and if customizing is required, you will get a bump up when the system has stabilized and your staff are up to speed.

The original article can be found http://bit.ly/47lzRv

What's the difference between an estimate and a quote?

I've been working with a small organization that has to replace it's software.

They have no idea where to start, so they came to me. They want to understand what it might cost them. Before the Board of Directors will approve any expenditure, they want to know the full cost.

In talking to a number of software developers and software suppliers, I found them initially reluctant to discuss potential costs. In their experience, the clients seldom have any idea what it takes to develop and install software. If the supplier quotes too high a price, the client will go elsewhere. If they quote too low a price in order to keep their interest, they get burned when the client comes back.

The problem is that the business needs a starting point. They need to know if it might cost $1 or $100,000. They want it for the lowest possible price. That is a ball park estimate. However, since they have no idea what is required to develop and install software, and the software supplier has no idea what's functions are required, they can't give a quote. No matter what they say or do, the client will see the estimate as a quote.

We have a standoff. The supplier ask for a budget, but the client is trying to create one.

The reality is that we need a third party, who understands that software is an automated process, and in order for the supplier to be able to give a quote, he must understand much more about the business. By acting on behalf of the client, he can get to understand the scope of the business need, without getting any value from the price of the software.

In this case, I have been able to get three estimates from different suppliers, despite their reluctance. They knew that I understood the difference, and they are not providing the estimate to the client. I am. Now I have to make sure that the client understands that this estimate will help them decide how to move forward. As we define the process and identify the requirements, we will be able to get a reasonable quote from the supplier.

What's the business value?

We can't run our businesses without the use of technology today. New technology related projects get started every day. Yet studies that have of project success continue to show a poor success rate.

Most of the emphasis within IT, whether by internal groups or by IT suppliers focus on what the IT group or supplier delivers and not on business value. Yet business value is the priority for the business.

In this week's post at value delvery management, Jed Simms talks about the business case and the fact that it is two things: a contract and a strategy. Between them, maybe we get the value we should always be getting.

See Jed's article.

Is buying software an emotional experience?

I've spent time in software development as well as implementing software for a variety of business functions. One of the things that I always found strange was that most technical people that I worked with, had their favourite software product. Trying to implement new software was always a struggle. One person wanted to use his favourite product, and another wanted a different product. It had nothing to do with requirements, it had to do with experience. People wanted to use what they were comfortable with.

I've seen this many times, and I also understand it. When I believe that I can get the job done using one software product, I have no interest in trying another. As a past software developer and as a business person who has repurposed many software products, I also know that most software today is flexible enugh to do many jobs, if you can define what you want, you can probably do it.

When there is no current software product, and something new must be purchased, I have a logical approach that I take. First define the goal. The define the process that will reach that goal. Then identify whether a software product will help the process to meet that goal. I know this works and have used it many times.

Recently, I have seen business owners look for solutions by assessing website information on various software products (not a problem, it is one of the steps). Then they get comfortable with a software product, without having defined their goal or understood whether the software will help them. Since I am someone who likes a structured approach, I understand why they feel more comfortable (they have spent some time learning about it).

What confuses me is that the level of comfort becomes a decision point. They think the only way to learn more and get results is to buy it. And often nothing can change their minds.

The opposite side is also true. When someone has a bad experience with a software product, there is often nothing that you can do to show them how they can get all or most of what they need from their current software. The decision has been made, even though the costs of installing new software may be 5-10 times of keeping the one that they already have.

Maybe, I'm wrong. Maybe buying software is an emotional experience.