Should software installation be profitable?

When an organization installs software, they do so for many reasons. They want something that they currently can't get from their existing business software. In large businesses, they assume that a lot of investment is required in order to gain the advantage that they are looking for. In small businesses, they want to minimize the investment, yet want to gain the advantage as quickly as possible.

Which approach is better? While many small business projects are underfunded, many large businesses overfund their projects and are willing to wait too long for results. This is the primary reason why business units often abdicate their responsibilities to the IT project team. They get tired of waiting for results, and there are too many technical discussions that have nothing to do with improving the business.

Every project to make significant changes to a business can be improved if there is a focus on the bottom line. They should have an interest in making the project profitable for the business as soon as possible. There are at least two benefits of this approach. The first is that less money will be spent before money starts coming back in. This means that the business will be more willing to spend time and effort on the project. Second, because there has been a return on investment already, business people will look to get results and won't get fed up waiting. Because business people are more involved, there will be pressure to drive more results.

I think that the half life of a project is about 3 months. There are too many distractions in running a business to keep someone's attention focused on something that doesn't produce visible results.

So, you should plan to deliver some results from your project within three months. You can incrementally add to the project as it makes progress.

Whether in a small or large business a lack of short term results leads to a lack of interest.

Is a technology upgrade necessary or adding value to your business?

Many small businesses face a challenge when dealing with todays technology. Most of the hardware and software far exceeds our capacity to use their features and functions. Yet in order to maintain support from the software supplier, we have to upgrade to a new version.

This might be ok, except for the fact that there is so much extra capacity in the hardware that the software developers do two things:

• They get sloppy with their development or add new features, because the new hardware can support it.
• They include these new components in the basic package, forcing you to run out of capacity on your desktop or server.

The end result is that you have to upgrade your hardware and software, just to maintain your status quo. The alternative is to lose support from the supplier.

Many small businesses do just that. They can't see the value of the upgrades and don't see support as a major concern. They get very little anyway.

The the big one happens. They have to upgrade because the software will no longer do the job. This causes a major disruption. The changes are so large that it is just like buying a new software product.

Most small businesses resist the upgrades because they can't see the value. They are given no alternative.

Developing changes in the industry are addressing this issue, but many small businesses are reluctant to take it on, because the model is different.

In the past, you bought your hardware and software. You owned it. You didn't have to pay for usage. The new model is usage based. You pay of usage of software. This payment never ends. The advantage is that you don't have to worry about hardware and software upgrades. No large capital expenditures. The supplier is responsible for keeping the hardware and software up-to-date. This is called Software as a Services (SaaS).

A small business should look at this in the same way they look at a building. You rent space. The advantage is that you get a cheap entry point. When you need extra space, you rent more. If you need less, you can release the space. When major changes in building codes come up, you let the landlord pay for it.

This is a good solution for small business. Most small businesses cannot afford the skills and time required to maintain all of the hardware and software. Hardware and software upgrades add no value to their business.

You do more than outsource the maintenance of the technology, you have outsourced the responsibility for it as well.

Todays tools allow you to do this for software and servers and also desktops.

an example.

Is your new software providing new value?

Many software suppliers claim to have the better answer, but is it just more of the same? When a business implements new software, they encounter reductions in productivity caused by the lack of familiarity with the software, the learning curve, the increased stress due to the change.

A business needs to get value from this type of change. In a blog on ZDNet, the writer sates that software companies cannot continue to focus on new whiz bang features, but must contribute real business value, something that is shown on the bottom line.

I agree. But how does a small business assess that business value from all of the statements that are made by the software suppliers? How do they know what contributes to business value?

The first stage is to understand the real business need. Every business runs on its business processes. If value is to be contributed, the business process must improve. Improvements can come in terms of cost reduction (less to deliver existing returns), productivity (more work for the same cost), quality (less returns or more sales), cash flow, etc.

The first question is: "Can your existing software be used to deliver that value?". If it can, then use it! That delivers increased value for a flat software cost and no loss of productivity. That value alone may be enough to stay with the current software. If your current software can't do it all, but can do some, then you must evaluate the additional value possible against the cost of not only the new software, but also the loss of productivity.

To check out that writer's perspective, click here.

Most Software Projects plan to fail

The success rate for software projects in most businesses are set up in a way that makes them easy to fail. They fail to achieve the original exectations of the business. The reasons are fairly simple. They are set up as technology based projects to achieve a technical objective, that of installing the software. Yes, there are other activities, but they typically lack a business focus.

The approach is as follows:

1. The business has a goal. Let's say it is to increase sales through the implementation of CRM software (Customer Relationship Management). CRM software allows you to understand your relationship with a customer better, and HOPEFULLY, to increase sales as a result. The business has certain expectations of what will be delivered (business outcomes), but they are not clearly defined.
2. CRM software is purchased to implement this function. A project plan is produced to provide the function. The project defines the project outcomes to be delivered. This includes the software, perhaps additional hardware, training, perhaps data conversion.
3. The project delivers the project outcomes (assuming it is very successful).
4. The business is left to make the busines outcomes happen using the software that has been delivered.
5. Has the project been successful? Is the business happy? Success rates of 20-30% have been identified on software projects. Business expectations are not met.

In order to have a success project, business expectations have to be met. In order to do that, we must define business outcomes, not project outcomes. Typical IT project outcomes are a subset of business outcomes. The plan needs to change.

1. The business has a goal. The business defines the business outcomes that must be ahieved in order for the project to be successful.
2. A project plan is developed to meet the business outcomes, including not only the items above, but also including changes in business process, change of roles/responsibilities, etc.
3. The project delivers on its activities, which produces the desired business outcomes. If not, adjustments are made until it does.
4. We don't have two teams, we have one. The business result is a common measure for both.

One of the most common problems in many IT projects is that business people get tired of all of the technical activities and abdicate their responsibilities to the IT team. Taking the second approach, reduces the risk of this happenning, because the business outcomes are key elements of the project.

Getting Business Value from Software Training

Learning to use new software can have a big impact on software productivity. Your goal in getting new software is to make your employees more productive. That may not always be obvious, because you may be using the software so that you don't need as many staff, but you still are getting more productivity. You get more work done with fewer people.

Most organizations don't think of that when they buy new software. Training is considered to be a necessary expenditure, but not critical to success of the project.

On the contrary, it may be the most critical element. If you are looking for a productivity boost of 25%, but actually get a reduction during imple,mentation and for 6 months after, you are losing a lot of the benefit that you expected, even if you gain that 25% later on.

Part of that may be due to resistance to change, peak workload issues, and new staff, but I believe that most of it is due to poor training methodology.

Most software training follows the firehose approach. It's like drinking from a firehose! You get a crash course on the software features and functions, but very little context. By context, I mean the standard WIIFM (what in it for me?). Unless I understand how I will use a function, I am not likely to remember much about it. Many trainers may try to put context around it, by showing how it would be used, but that context may not apply to your organization.

When you buy new software, you typically are buying a new way of doing business (you don't want to do it the old way or you wouldn't have bought it!). This new way is a change in your business process. If the context that the trainer is providing is based on the new process and your people don't understand it, the context will be meaningless.

The solution is to start with the business process, understand how the software will help to improve the business process, then to provide training with this new context in mind. You employees will have less confusion, you will get less resistance to the change and your employees will become productive much more quickly.

Why not Experiment with Software during a Recession?

Most of the software that we use in business today far exceeds our normal business usage. Even with normal office products such as Microsoft Word, most of us use very few of the features. Even though I have been comfortable with computers for many years, and always work with multiple products at the same time, I use very few of the functions. I only expand my use when I have a problem and need to do something that I have never done before. Even then, I often use the products and features that I am comfortable with.

This works just fine if I only have to do something once. It isn't worth the time and effort to learn new products and features, when I can do the job faster with the tools that I currently have.

Most businesses are using much more complicated software these days Enterprise Resource Planning (ERP) software coordinates data from many different parts of the business. These products are designed for many different businesses and provide functionality to support them all. Any single business probably uses a very little percentage of these products. Luckily, many of them are modular, so that you don't have to buy all of the components. However, the complexity still exists.

Implementing an extensive software product is a very painful operation. Everybody has to be retrained and becomes uncomfortable because they no longer can do their jobs easily until they learn the new software. As they become comfortable and learn how to get the job done, they typically stop learning about the functions of the software, even though there may be much easier ways of doing the job if they knew more about the software.

The reason they stop learning is that they are getting the job done. They don't need the extra features and don't have time to learn them because of business volumes. They may also not know how to start looking for additional features. Most software suppliers have a standard training package, that doesn't allow for investigation and/or experimentation.

During a recession, volumes are lower and employees may have time to learn, but don't know how to go about doing it. Where do they start?

I worked with one software company that was receptive to the idea of developing specialized training. I set out to see how we could get much more effective use of the software. I asked them to show us how we could get much better use as well as where they would not recommend it use. It worked very well. Our organization became much stronger for a number of reasons:

• It wasn't their first exposure to the software. They had all used it for over a year.
• They had a lot of questions, that they had been too busy to ask.
• We addressed the business problems and looked at how the software could be used to improve things.

This worked because the supplier was receptive. I have worked with other suppliers that weren't as receptive. Mostly this was because the trainers didn't know the software well enough. This may be one of the criteria. Judging the capabilities of your trainers may be one of the most difficult things.

IT projects without a goal

I see a lot of IT projects that are undertaken without a clear goal and this gets reflected in the failures. A good example is the recent cancellation of an SAP implementation by Select Comfort hotels.

During periods of slow sales or recession, a company should be focused on improving productivity or reducing costs. Implementation of new software should be based on increased sales, improved productivity or reduced costs. In this case, Select Comfort is cancelling an SAP implementation to save money. This is contrary to what they should be doing, if the original purpose was valid.

As described in the referenced BLOG entry and original announcement, the SAP implementation didn't seem to have a business goal. There were no identified problems with the original ORACLE system and no defined need for the conversion.

If Select Comfort had a measurable goal, they wouldn't have cancelled it during a slow period. They would have intensified their efforts.