Tuesday, June 23, 2009

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.

Monday, June 15, 2009

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.

Monday, June 8, 2009

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.

Thursday, June 4, 2009

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.

Tuesday, May 26, 2009

Does your software provide the information that you need to run your business?

I read a study a few months ago that identified two key issues about managers in a business:
  • 15% or more of a manager's time is spent looking for information.
  • 42% make decisions based on bad information, once per week.
Since the role of a manager is to make decisions, and decisions are made based on the information that is available, this means that managers are extremely unproductive (wasting 40% of their time) and ineffective if they make decisions on bad information.

What's the reason for this?

Most of our information today comes from computer systems. They are capable of producing data at a much higher rate than any manager can absorb. What is the problem?

Most software that is installed in a business is installed to handle normal transaction workload, because this is the obvious area. The more transactions that can be handled by the fewest staff creates a more productive environment.

However, hidden in all of these transactions is the data about your business. Unless you can extract this data, it isn't being used to manage your business.

In many assignments that I have taken on, I look for data about the business. By analysing that data, I can find out a lot about the business. It may take a lot of analysis and structuring before I can understand the value. In most cases, what I come up with is not known by the business owners and managers. They have assumptions about what is happenning that conflicts with the data. They don't know, because they don't get this information normally.

Computer systems are a great source of data, but it is useless unless the data can be turned into something useful that can be used to make decisions.

Monday, May 25, 2009

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.

Thursday, May 14, 2009

Are You Suffering from Software Withdrawal Syndrome?

You know what that is. Your company has just installed new software to run the business. The discussion put you to sleep. When you wake up:
  • You have to relearn how to do your job
  • Everybody is talking a new language
  • your job is harder to do
  • Your job takes longer to do
  • You get irritated more easily
  • Your customers no longer have any patience

For some reason, people who work with computers are immune from this disease.

The impact of this disease on the business can be substantial.

  • productivity goes down
  • Costs go up
  • Sometimes quality of service can be a problem
  • You can lose sales.

During a time like this, who can afford it?

The reason for the disease and the assciated impact is that three things have been ignored during the project:

  • People - how are they going to be impacted and how can this impact be prevented?
  • Process - your business process will be change by the software. How can this impact be prevented?
  • Business Results - how do you keep your finger on the goal, the reason why you bought the software during the ensuing chaos?

Can you afford to lose the benefit that you were looking for? What are you doing to ensure that your business is not negatively impacted?

This disease can be prevented. Even after you have it, there are steps that you can take to reduce the impact and recover faster.