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.

Does your website provide value?

I am working with a not for profit organization that needs to replace the software that they are using. The software was developed for this international organization many years ago and now is supported by one person on a database that has not been upgraded for many years.

As part of the assessment, the organization wants to put together a budget, so that they understand their costs before they start to spend money. As a result, they don't want to do a detailed evaluation of the software at this time, they just want to project the costs.

The approach that we have taken is to estimate the costs with as little effort as possible and as little interaction with the supplier as possible. This has meant using the website information whenever we can and only ask very specific questions which can be answered simply. This won't be a perfect projection (too many projects undertake a detailed analysis, thereby expensive) before creating a budget.

This is the first time, I have done this and it has given me a new understanding of what a website should provide. In the past, I have been frustrated by websites that lure you in with a promise of information, then require you to sign up, so that they can market to you (As an aside, most of them ask for this, but never follow up). This slows the process down and if you are not ready to talk to a salesman, gets you to look elsewhere for answers.

In this investigation, I found the following types of websites:

1. Some that provided very little information other than being a sales brochure, asking you to contact them for anything that would really tell you about functionality. Most, however, would give you technical specs.
2. Some provided a lot of functionality information, but very little in terms of education about what you need to prepare for.
3. Some that provided functionality, technical and educational information, but required you to sign up to get much of it.
4. One that provided all of the above with no request for signup. It provided a lot of information about what not for profits need to look for, why they should manage it and options for getting it. This went way beyond their software. It was a pleasure reading it and it helped us put together a better proposal.

I worked with a business coach a few years ago, who told me that I should be providing educational information, so that people could understand how I could help them. I now understand what I need to do with my website to increase the value that I provide.