Software Procrastination

Procrastination is something we all fall into, at least from time to time. Why do we procrastinate? Does it matter?

A recent experience with a client provided me with answers to these questions.

The client was a small organization that had acquired software from a related organization many years ago. They didn't have a lot of sophisticated needs, so they stayed with it. Over time the related organization replaced the software, but still had one person on staff with the experience to support it.

Problems developed on a regular basis. Some of them were described as quirks that required a person who had experienced all of the quirks to prevent them. Support was expensive. They had to fly someone in from the US to fix problems.

They knew that they needed to replace the software, but had no one on staff with experience and didn't know what they needed to do. They researched alternatives, but that only served to confuse them. They continued to defer.

Finally, a few months ago, they had a major problem. While one of their staff was on vacation, they encountered one of the quirks. It caused a major problem that required 3 months worth of cleanup at year end to recover.

That created the incentive to take action. In one planning session, we were able to develop a high level plan, provide a basis for justifying replacement, and give them some level of comfort about moving forward.

That raised a few questions for me:

• Why do we procrastinate? Is it because we don't know what to do next?
• How much time are we wasting when we procrastinate? We think about it often, but unless we are taking action, the thinking is wasted and stressful.
• Why does reseach not help? If we know nothing about a specific area, do we actually waste time by doing research?
• Why are we afraid to ask for help from a specialist? Is it because we need to feel in control and are afraid of it costing too much money? Perhaps spending a little with a specialist who helps us plan, without requiring a long term commitment from us would provide value.
• Are the specialists the problem? Do they expect a long term commitment and are they not willing to help put us in control?

All I know is that a lot of time (and time is money) is wasted in procrastination. I, for one, will have to look at my own procrastination differently in future.

6 Myths about buying software

Buying software for a business can be a real problem for small businesses. Many small businesses put off buying until they feel "comfortable" with the decision. They look around at alternatives and "evaluate" them based on what they learn about features and the successes achieved by others. They decide to look for the supplier who has sold the most and go with them. They may also go with the salesman that they feel most comfortable with.

All of these can present problems and increase costs for the business. If your company is losing money, or could save money by installing the software, any delay costs you money. The problem is that many myths exist about buying software.

Myth #1 Software that is successful in one business will be successful in another.

The success of a software product in one company is based on many factors. Some have to do with technical implementation issues. Much bigger issues:

• Is built to solve the problem that you have?
• Are your people ready for the change?
• Does your consultant really understand your business?

Myth #2 The best consultant to hire is the one that knows the software.

The statement says it all. The consultant knows the software, but does he understand YOUR business? Every business is unique. Yes, for the most part, business processes are the same. Yet I have found every one is also unique in certain ways. You may have certain things that you do that make you special. The software consultant may not understand the value.

Myth #3 Education provided by the software company is the best way to get trained.

The software company can train you on how to use their product. Unfortunately much if this training is often given through a "fire hose". Too much is given and not remembered. What is seldom understood, is that new software often brings a new business process. Your people need to understand how their jobs will be impacted. Not all of the functionality of the software is necessary for your business, especially at first. You would gain far more productivity by training on the business process changes, then on the functions in the software that will be utilized in the early stages.

Myth #4 Comparing features is the best way to evaluate software.

Every software product has many more features than any business requires. Many are not required by your business. Many may look neat but not be practical.

What's more important are the problems that you are now facing, what changes in the business process will be required and how the software will help to solve them.

Myth #5 Consultants cost too much. I can do it myself.

Consultants do cost money, but they can show you shortcuts and save you time and money.

The IT field is very broad and there are many specialties. No single person can understand it all, and even if they do a reasonable job of working through it, it will take more time, you will make more mistakes and not get as food a result. The reason people specialize is that they have the experience, have learned from their mistakes and can do a better job.

Myth #6 The cost of the software needs to be justified.

There are two problems with this myth.

The first is that there are many costs associated with installing software. The cost can be 4-5 times the price of the software. You also need to consider software supplier consulting costs, training, hardware, implementation and conversion and initial loss of productivity.

The second is that even if you justify the total costs, you will underestimate the value that the software can bring. The right software can make a significnt improvement in your business process, that far exceeds the cost of the software and associated costs. But you have to plan for it.

Software is an organizational change project

No business can survive without computerization today. Yet the success rate for software projects is highly variable. Some businesses are successful at gaining a return on investment. Many are not.

Why is the success rate variable? In many cases, the same software product is installed in similar businesses, why is one successful and another is not.

The reason is the same as the reason that organizational change projects have a high failure rate. When you change the software that runs your business, you are creating an organizational change and you have to manage it in a similar manner. It is not just a technology change and the reason for failure is not often technology or lack of technical skills.

What makes it an organizational change?

1) Your business operation is made up of business processes (quote, order entry, accounts payable, accounts receivable, inventory, etc.).

2) What is business software? It is the automation of a business process (the process has been programmed to operate in a certain way). There are certain expectations in these processes, and many options available for tailoring the software to your business.

3) In order to implement the software successfully, you must understand your existing business processes in detail and choose the functionality of the software that best fits your needs. Many failures are due to the lack of understanding of this impact.

4) It is unlikely that there is a perfect match between what you are doing today and what the software allows you to do. At very least the software is automating functions that you were doing manually before. This means that people's jobs will be changing. Sometimes this requires organizational changes. If people don't understand the reasons for this change, they will resist it. The resistance will be directly proportional to the amount of flexibility that people have in their current jobs. Many software projects fail for this reason!

5) The software company is experienced in their software and provides training on its features and functions. However, it seldom relates exactly to how you do business. You receive fire hose training on the functions, but not on the changes in the business process. They search around for the features that will let them do what they used to do before. Sometimes they can no longer do what they did before in the way they used to do it. Although projects seldom fail for this reason, productivity goes down for a long time while people learn how to do the job using the new software.

When you make all of these changes, you change your business processes, you change people's jobs and sometimes you even end up changing the organization. If people don't understand why all of this is necessary, you will encounter problems.

Check in to see what the solution is.

Adding more elements to the people, process, technology diagram

In a new post on Value Delivery Management, Jed Simms has expanded the triangle of People, Process, Technology and added 4 new elements: Strategy, structure, information and culture as key elements for a software project to deliver business value.

While I have advocated most of these elements in my past posts, Jed has put it into one diagram.

To see his post, click here.