Small Business can be Beautiful when it comes to IT.

I see many small businesses that are struggling with the use of computers. They often spend the money thinking they are going to get improvements and end up with far less than what they expect. What is the problem here?

Large businesses have many different problems. In a large business, many people have to work together to get the job done. Many of these people hardly even see each other. They make assumptions about what other people are doing and try to do their best, in their own little silo. In many cases, they are operating to different objectives, objectives set by department and end up working at cross purposes. When new software is implemented, the project is often assigned to dedicated people, people who don't do the job on a day to day basis. They develop the new processes, identify what needs to be done and turn it over to the people that have to make it happen. There are huge communication problems and even when the needs are identified, it is difficult to solve.

In small businesses, people work much closer together. They can see each other and should know what everybody is doing. They don't have departments with different objectives. They shouldn't have silos and communication problems........... But they do. I have seen organizations as small as 5 people operating in silos and not knowing what each other is doing and what impact they are having on each other.

So the problem is not unique to large business. It also exists in small.

The good news is, it's easy to solve in small businesses:

• It's easy to set a single obective.
• It's easy to get people in a room and talk about what needs to be done.
• You can undertake major changes in software, business process, organization and do it in a few months.

So what's the problem?

The problem is that when organizations decide to implement new software, they think of it as a technical project to be run by technicians. It isn't.

The reason that you start is that you want to upgrade your business by using technology more effectively. To make it work you need to:

• Have a common business goal that is understood by everybody.
• Understand how you will achieve that goal, by changing your business process, using the tools provided by the software, training your people to work differently, perhaps changing roles and responsibilities.
• Installing the software and converting your data.

Only the last one is technical. The first two are not. Success should not be measured by whether the software was installed, but by what business goals were achieved.

Large businesses can afford to put extra resources towards a large project. Small businesses can't. They also need to demand business results quickly.

Simplicity Increases Software Value

I just read a book about simplicity, and, although it has nothing to do with Information Technology and Business Software, it describes perfectly the problem that most businesses have when it comes to IT.

In some ways, technology is simple. This is the way most people who work with computers every day would probably describe it. In some ways, it is simplistic. Software does whatever you tell it to. It can sift through tremendous amounts of data very quickly, but it has a set routine that it follows.

When it comes to implementing new software, we have two groups of people involved. The ones that know the software and the ones that don't. To the ones that know, it is simple. They are cmfortable with it. They work with it every day.

To the ones that don't, it is confusing and frustrating. It is confusing because there are so many options. Most of them are of no value to you, but until you know that, they are still an option that you have to choose to ignore. Then when you try to do something, it doesn't work the way you think it will and you encounter a problem. This gets you frustrated.

In order to help you overcome your frustration and confusion, many technicians will simply shrug and say you have to learn. Others follow the KISS principle (Keep It Simple Stupid). They try to dumb it down. This misses the point completely. It assume that the people learning are stupid or slow. This is not the issue! The issue is that the software is showing all of its options (read complexity), and the users have not yet developed filters to ignore all of this complexity.

The answer is to help new users learn. You don't do it by firehose training. You help them to develop filters. Instead of KISS, you need MISS (Make It Simple, Stupid). This meets the person doing the training needs to do it in a way that helps the new learners. Give them the information that they need to do the job. As they do the job, they will learn to ignore what is not important (develop filters) and encounter less confusion and frustration. They will also become productive much more quickly. The problem is switched from the learner to the trainer.

How do you help people develop filters, learn only what they need to do the job? You start with the business process. Then look at what parts of the software help doing the process. Some parts are more important than others. Some can be delayed until later. Train only on what's needed. Just in Time.

Four steps to success of software projects - Step 4

The last step of the project is what is normally viewed as the project. The difference here is that the project as defined in many organizations as the imlementation and set up of the software. The project must go much further. No value is delivered by implementing software. The value (new business outcomes and benefits) is delivered by the new business process.

The software is simply a tool that allows you to perform activities more easily, perhaps do some that you couldn't do without it.

I won't emphasize any of the normal implementation activities here, as most software suppliers will provide the details, and most technical staff will know what to do.

What I will emphasize are the things that are normally not done and why that must change.

Recognizing that the software is simply a tool and that the process delivers the value, the approach to training must change. Most software training is like drinking through a fire hose. You get too much information too fast for you to absorb. In addition, most of the information is of little value, especially at implementation time.

When you implement, you are using a new set of tools in an unfamiliar way. therefore your staff will be less productive, uncomfortable and frustrated. This is normal! Your goal, then, is to get them productive as quickly as possible. You can't do that with firehose training! What you can do is tailor the training.

You know how the process has changed. You did it in step 3. You know what part of the software is required to perform the functions that are critical to productivity. You went through that in step 3 and the early part of step 4. So you want to develop a specific set of training to have people understand how to do what they have to do every day.

Hopefully, the software that you have chosen has the capability of doing much more than just those early activities. Once the software is stable, people are more productive and comfortable with their new environment, you can look at the software again with a view of exploiting more of its features.

Exploiting the capabilities is often overlooked in many organizations. The pain of implementation stretches for months and nobody ever goes back to look at what more can be done. This is another area where value is lost. You have bought software that has tremendous capabilities, yet you never go back to gain the value that is waiting. Most software is significantly underutilized.

One of the biggest opportunities is taking advantage of the information that is now available. Most managers spend most of their time looking for information to make effective decisions. This new software should be capturing a lot more information that you had before (otherwise, why did you install it?). This information is a valuable resource.

The four key elements of this phase are: software tool, training, information and expand.

Four steps to success of software projects - Step 3

Once you have your goals and vision and have identified your team, you need to look at your business process.

Your business process is the list of activities that you do to deliver the results that you are looking for. Since you are trying to improve the results that you get, obviously you need to change the activities. The software that you buy will require a change to the activities that you do. Even if the method of recording is the only difference, something will change. In addition to just automating activities, software comes with built in assumptions about how you will go about using it.

The is the big mistake that many organizations make! They assume that all they are doing is using a new tool. The approach to doing these activities will change! You are trying to deliver a different set of results.

Albert Einstein once said: "Insanity is doing the same thing over and over and expecting a different result". The opposite is also true. You can't expect to improve the results that you receive by continuing to do the same activities.

You start by describing the activities that you now do. This is extremely important! Everybody will make assumptions about what is going on, and they will be wrong. The devil is in the details. Once you know what is happenning today, you can look at what you need to do to get the improvements that you are looking for. This lays the foundation for the new flow of activities.

This new set of activities and the flow between activities and people will provide you with a new set of business outcomes and benefits. The process will show you what you must do to deliver the business outcomes. It will also provide you with a specific set of requirements for the software that you will purchase. You have a direct relatiosnhip between the software requirements and the business outcomes.

These four elements: activities, flow, business outcomes and benefits, will provide you with the basis for success.

Four steps to success of software projects - Step 2

Once you have set your goal for a project and have visualized the results, you need to start looking at your project team. In most small businesses, there are not a lot of people available to work on such a project. That's why most small organizations take the lead of the software supplier, and let them run wth most of the project.

In larger organizations, where there are people who can dedicate themselves to the project, they tend to be technical people and the total focus is on the implementation of the software.

This is mistake #2.

The software will not deliver the results that you need! Your people will! They will only do that if they are aware of your goals and your vision, are educated in the tools necessary to deliver your vision and work together to make it happen.

Your project team must consist of the people who will be doing the job after implementation, the technical resources that will implement the software, the people who will provide the education and training. Most of these people will not be dedicated to the project. They will do activities that are required, but they must all understand the goals, the vision and their roles before during and after.

The big mistake that many organizations make is to not involve the people who are currently doing the job, because they are too busy. They are the people who understand what is being done, must understand what has to be done after implementation, and must be involved during the project.

The four key elements of this phase are: Awareness, education, involvement and teamwork.

Four steps to success of software projects - Step 1

When you consider buying, installing or upgrading business software, the starting point is asking the question - why?
It may be that you want to increase sales, increase productivity, decrease costs, improve cash flow, etc. The reason doesn't matter. Most often and organization will jump from this broad goal right to looking for software products, or talking to friends or colleagues about what they used. This is a big mistake! The goal is too loosely defined. Everybody in the organization and your suppliers will have a different view of how to achieve this goal. How you achieve this goal will depend on what you mean by it. And this is different from person to person, company to company.

You need to be able to visualize what this goal means. For example, if you are considering Customer Relationship Management (CRM) software, is it your intent to become more intimate with your customers, understand their needs and wants even when you can't satisfy them, understand every interaction? Or do you just want a contact manager and the ability to track sales in process?
This step is the most important!

Once you have visualized the solution, you need to identify how you will maintain the energy to deliver the results. Most software projects are more of a marathon than a sprint. As much of the activity is technical and of no interest to the business, most business people get tired and ignore the project waiting for something that they can get involved in, in spurts. They are busy running the company and can't focus on the project the way that technical staff do.

During this step, you need to identify deliverables that are to be performed by the business to move it forward. You must identify activities that can be done in spurts that help to move the project along and maintain focus.

As leaders, you must also maintain this focus by looking for results, improvements in te short term and not be satisfied with waiting to the end.

These four elements: Goal, vision, focus and leadership will be critical to the ongoing success.

Four steps to success of software projects

Many business owners are frustrated with the performance of Information Technology in their business. To some, it is the reliability of the hardware and software, to others, it is the language of IT that gets them. They are trying to run their business and unless they are technicaly proficient, they get frustrated.

The real issue, though, is their sense of value and lack of control. They don't feel that they are getting as good a return on their investments and are frustrated that they can't seem to do anything about it.

This doesn't have to be the case. As a business owner, you don't have to be technically skilled, like you don't have to be a mechanic to drive a car.

The problem is that all of the focus is on the car. If you had to know how to repair a car before you could drive, most of us wouldn't drive. If most of us knew how to repair a car before we drove, car manufacturers wouldn't have to put any effort into preventing them from failing.

Unfortunately, computers haven't reached that place yet. Most computer technicians believe that everybody should be knowledgeable about computers, so they don't consider speaking business language.

In order to fix this problem, we have to change our attitudes. As business owners, we need to insist that software developers and companies focus on the business issues and not just on implementation of the software. If we ensure that they do this, we will increase the value that we receive, decrease the frustration and improve our business performance.

Where do we start?

My approach is to change the sequence. Often a business project that will require software, moves straight into the project development phase and all future focus is on the implementation of the software. This is the problem period and is the source of all future problems.

My approach goes through four steps:
1. Purpose
2. People
3. Process
4. Technology
Yes, technology is the last step. It may be the largest. It may be the longest. Many of the benefits can be received before the software is fully implemented. There are big benefits in the first three.

I will outline each of the steps and their benefits in future posts.

Is Resistance to Change a problem for IT projects?

I read about a lot of project failures that are classified as failures due to resistance to change. I was recently speaking to a consultant who was talking about Customer Relationship Management (CRM) projects and the challenges that they face.

All change encounters resistance when there is no benefit shown. If there is no benefit to making a change, then why should I change? After all, I listen to WII-FM (What's In It For Me). All change is difficult. We have to want a change in order to go through the effort to make a change. Just look at people who have lost weight, quit smoking, etc. They had to really want to change. To people who run IT projects, resistance to change is common. However, most of them are deeply involved in the change, see the value or potential value and are comfortable with technology. They can't understand why people don't embrace this new solution.

Often people involved with a project don't see it as a change, or at least don't see the negative side of it. Any change requires a refocus, a relearning, a move from subconscious activity to conscious activity. This is very time consuming. Your productivity goes down. However, business volumes don't (except for a recession, when staff gets cut to compensate). This means you take more time to do your normal job, and therefore will encounter more stress. Who wants that?

Much has been written about organizational change and cultural change and the efforts to get everybody on board. All of these changes are the same and require the same kinds of effort. If people don't understand the goal, don't understand how they can contribute to the goal, they won't support the pain that they have to go through to get there.

When a project fails due to resistance to change, it has still failed. It has failed because of a lack of recognition that people are listening to WII-FM. What's playing on your station?

The last mile of software development

I read a paper recently that talked about the last mile of software development.

The software development process was described with the following components:

• Business requirements are identified.
• The software is developed (seen as most important by developers)
• The software is tested
• The software is implemented.

This last stage was called the last mile of software development.

If we look at it from the business perspective, no value is created until the last mile. Until the software is implemented, the business gets no value (except for software development companies).

Describing it as the last mile may be part of the problem and the fact that many software projects fail to deliver on their promises. The same is often true when a business buys a software product. The only time that value is created is after installation of the software, when improvements in the business are actually received. And even then, it is not the last mile. Your initial implementation will not be as valuable as when your people become comfortable and productive with it.

So implementation is not the last mile. This is where you need to focus.

If your supplier or your staff view the implementation as the last mile, maybe you need to change one or both.

IT Value comes from speaking business language

I was at a seminar recently that was focused on helping new immigrants to integrate into our society. You may ask why this has anything to do with computers.

It is probably the major issue and the reason why many business people get frustrated with IT staff and suppliers. The issue is communication.

Despite the proliferation of computers in our society and in business, the reality is that maybe 20% of people are comfortable with computers. Many of those people are comfortable with the games, but not any more comfortable with business use. When I speak to small business owners, and many staff, they are often frustrated with computers. This is a result of computer speak and lack of focus on the business issue.

Most business owners know they have to use computers and want to, but when they speak to the technicians, all they get is computer talk. They are told all of the great things that computers can do for them, but in terms of the software or hardware, not in terms of their business.

Getting back to the seminar, one of the things that was stated was, "In order to make new immigrants productive and effective in our society, you have to make connections with them, speak to them in their language". This doesn't mean that they don't have to adapt. However, the more stressful that you make the interaction, the slower they will be to adapt to their new environment.

This is also true for people who are uncomfortable with technology. If you force them to speak the new language, and they don't see how it helps them, they grow frustrated and "tune out". The only reason why technicians don't speak their language is often that they don't know the language of business, even though they profess to know it by their selling approach. The sales pitch talks about solving business problems. However, the implementation approach seldom does.

This is the primary reason why IT projects fail. The steps go as follows:

• Define the business goal
• Develop the technical implementation plan.
• Train staff of the functions of the software
• Implement the software
• Have people figure out how to use the software to do their business functions
• Find new ways to address the functions that can't be done by the new software.

If we change our approach, we get:

• Define the business goal
• Describe the business process that will help us achieve the business goal.
• Define how the software will help improve the process to achieve the business goal.
• Define the process and technical implementation plan.
• Train people how to use the software to implement the process improvements
• Implement the software
• Support people in their learning how to improve the process using the software.

In this case, all of the focus is on improving the process to meet the goal. The software is simply the tool that helps, and there should be no confusion as to why you need to learn the software. You also don't waste time on learning parts of the software that don't help improve the process.

Is your project a technical project or a change project?

Many projects fail to achieve the business results that were expected when the business started to plan for them. The basic reason is that the projects are seen as technical projects, that is, delivering a new piece of software that may be necessary to automate a business function.

While that software may be required to deliver the function, it is seldom sufficient. The software assumes that certain things are in place (I know that software can't assume, but the programmers do). In many cases, the software creates the opportunity to build a new business process. That business process would not be possible without the software, but it seldom addresses all of the problems. The changed business process may require changes in roles and responsibilities, new interfaces between people and departments, totally different activities. If those new functions are planned for, then the process falls down. In many cases, new approaches are developed after the implementation. Although this works, it is seldom efficient.

If the process is designed when the software is developed, all changes can be planned for. In many cases changes to the process can be completed before the software is implemented, thereby gaining some of the benefits early.

Don't assume that a technology project is a technology project, to be left to technicians. Make it a complete change project and paln for all of the activities that the technical people probably won't think of.