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?

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.

Is your IT service delivering what the business needs?

A CIO Magazine article "What it takes to succeedNow as a CIO" described the difference between results described by the CIO (Chief Information Officer) and the CEO of organizations. Much of this relates to the definition of expectations. Many CIOs are still buried in managing Information Technology and still not focused enough on business outcomes.

Some statistics in this study:

• 70% of 506 CIOs rated IT as "considered an integral business partner by the rest of the company", while 46% of the business respondents rated IT as fair or poor.
• When asked about the impact of IT, "only 15 percent of you chose managing customer relationships and 11 percent said acquiring and retaining customers", yet these were critical to the business.

The real story is in this quote "There's an outcome that we need. How do we get it? Not, 'We need a new system. Please put it in." If your business discussion is not being held this way, then your business will lose. Whether you have a CIO or an IT Manager, or no IT department at all, this is the type of discussion that needs to take place.

You can see the full article here.

Information Technology is like a one legged stool

Every business today uses computers. It's hard to run a business without one. Even if you have a very simple business, you need to communicate with your clients and your suppliers and they force you into this world. Most businesses look at computers to improve the waay they do business. They look to productivity improvements, or functions that cannot be done without them.

Most of the technology that we buy is underutilized. The price of hardware has dropped so much that is is cheaper to put in too much hardware than to provide smaller alternatives. Software is the same. It is cheaper to distribute a single piece of software than to try and maintain multiple copies. So we have much more than we need.

There are two problems with this excess capacity. First, the software and hardware is more complex and harder to maintain. Each of us pays for this complexity. We may think we are getting value for money, but unless we can use it, the complexity adds up to more costs. In a large business, this may be manageable. In many small businesses, this can add up to slowdowns, extra downtime, extra support costs, productivity loss.

The second problem is that the complexity makes the software more difficult to learn and implement. I see many small organizations that fail to achieve the benefits from the software they bought. Part of this is caused by the fact that there are too many features. Part of it is caused by the expectation that the software is bought as a "silver bullet". Install the software and it's magic. Things will be better. It doesn't happen. It takes a lot of effort to get value from new software. Some parts may be easy. Getting real value is not.

I see Information Technology as a three legged stool. I will ignore the hardware at this point, because it doesn't provide value. It simply allows you to use the software. I will also ignore tools like Microsoft Office for the moment.

Leg #1 is the business software. It can be as simply as Quickbooks or as complex as SAP. Business software comes with built in business process assumed. It expects you to work in a certain way. If you do, then you get the best return. It helps you to do the job. If you don't, then it can make your life difficult, whether by forcing you to do things multiple times or by getting bad information because of the quality of data entered. If you look at your business process before you try to implement, you will be more successful.

That leads us to leg#2, the business process. The business process is how something moves through your organization, say from order to cash (your real goal is to get paid for the product or service that you deliver). If you understand all of the steps in this process, and understand how the software will help you to make that process more effective, then you will get significantly more value from the software. In many cases, even when an organization has looked at its business process, they encounter problems. The reason is that when you change business processes, you affect people. It's often been said that people resist change. That is true. People don't want to change if they don't see the value! Why should we? We are comfortable with what we do, we are more efficient when we know what we are doing, and we know how to prevent errors. Give me a new process that I don't understand, I will be less productive and I am more likely to produce errors. Why should I change? OK, some people like change for the sake of change, but we can only take so much. If you wake up one morning in a new house, have to drive a new car and go to a new job, how comfortable are you?

This leads us to the third leg: People. If you don't consider people, you will be less successful. I have seen many software projects that redesigned and implemented processes without involving the staff that did the job. The designs were based on senior staff or management input, and the process was automated to do what they wanted. The problem was that the process was not based on current reality. It was based on old experience (Senior staff and management don't do the day to day job), or on ideas of how things should work. The staff tried to work with it, but had to create all kinds of workarounds to get the job done. This reduced productivity, created frustrations with the staff and made them resent the change. Is there any doubt as to why people resist change? By involving staff in the goals of the change, in the redesign of the process and in how the software can provide tools to improve the process, you end up with a more effective process and less resistance to change.

So there you have it. A stool with three legs: Software, process and people. All three are critical for success.

There are two other elements that you will see on a stool and these are important as well.

• The first is the goal. The goal is to have a place to sit. The seat describes the goal of the project. This goal is a business goal, not a technical one. See yesterday's post for examples of the business goal. It's important that the goal be well understood and repeated regularly. Try sitting on a stool without a seat, if you don't understand. I have seen many stools without a proper seat.
• The second is support. Ever seen a stool without supports between the legs? Doesn't last for long does it? As with the stool, you need support between the legs (Software to people and process, process to people).

The most important thing is Focus. In real estate, they say there are three things that are important: Location, location, location. In IT projects, it's: Focus, focus, focus.

What is Business Value from Information Technology?

I've made a number of posts to this BLOG talking about getting business value from Information Technology. In discussions with different people, I have found many different interpretations. I've often commented on the fact that many IT projects have failed to deliver business value, and often get lost in "successful technology implementations". In these cases, the operation was a success, but the patient died.

In order to clarify, I want to describe business value in terms that might be better understood. Business Value can be measured by:

• Cash Flow
• Sales
• Cost of Sales
• Cost of Administration

It's that simple. There are many aspects of each of these, but if you have enough cash to manage your business, you have adequate sales, and your costs are in line so that you can make a profit, you are OK.

When you take on a technology project, you are trying to drive improvement in one of those elements. If not, why are you doing it? You may be doing something to reduce waste, improve quality, reduce inventory, improve productivity, but the real goal is to improve one of these four items. If your expenditure in technology or other services doesn't return value here, then it is a failure.

An assignment with a client recently, outlined the following problem:

• The company had installed software a year ago yet was not using it effectively.
• They took too long to issue invoices - weeks, sometimes months.
• They had opportunities to grow the business, but were restricted due to cash flow.

The focus of our actions was on improved cash flow. Within three months, we were able to get the software operational, tracking business from order to cash, and significantly improving cash flow. With improved cash flow, the business can now invest in equipment that will provide growth in sales.

The world is not static. The business was constantly changing while this activity took place. Traditional methods of measuring benefits would not have been possible. What was obvious, is that the order to cash cycle was improved, allowing the business to invest in growth. The improved cash flow was measurable.

Who is responsible for IT project results?

Many of the business owners and managers that I talk to are frustrated with the results that they get from IT projects. They take too long, they cost too much, they don't do what the business owner or manager want to do. Even with those who are relatively satisfied with the results aren't getting what they should be. I see many businesses who are satisfied with the results when so much more is available..

Why does this happen?

The reason is that there are three conflicting goals in any project. They are conflicting because even though everybody believes that they are all important, they compete for resources, for attention, for focus. The three are:

• Implementation of the software and processes to get the improvements that your business is looking for.
• Achieving the business goals for which the software and hardware was purchased.
• Running the day-to-day business.

The first goal gets all of the attention. Usually a project manager is assigned, and she knows that she must get the software installed in order to have a successful project. If the project manager is your software supplier, his goal is to get paid. What is a successful project? At best, the software delivers the functionality that was requested, at the cost that was estimated, in the time that was planned. Why did I say at best? Because if that is the criteria for success why was the business doing it? A lot of consultants have studied IT project success. In these studies, although there have been improvements over the past ten years, aprroximately 30% succeed, 40% have limited success, and 40% are outright failures. Even with those successful projects, they achieve less than they could have. The project manager typically owns this goal and tries to keep everybody focused.

The third goal, running the business, has to get attention. It is what brings in the money. It pays for the purchase of the software, which is supposed to improve business performance. The first goal competes with the third goal, because they both need resources (people, time and money). Few businesses have periods of downtime that allow them to reallocate resources to projects during slow times. Most of the time, both peak at the same time. In addition, implementing new software and learning new ways of doing things reduces productivity. So you have peak resource needs for the project, peak resource needs for running the business and low productivity. This problem exists in large companies that can afford to throw extra people at the project. It really hurts the small business. The business unit manager is responsible for this goal and tries to keep everybody focused on it.

The second goal is the biggest challenge. the reason all of this started is that the business owner wanted to improve performance. The software was purchased for this purpose. The assumption that was made, was that if the software was acquired, the business would be better off. The question that was missed is "how will the business improvements be achieved?". This may seem to be obvious, but it seldom is. Because nothing was specified as to how it would be achieved, the implementation of the software becomes the only goal. People lose touch with why it is being done. Since the business owner is not involved in the day-to-day activities, and seldom wants to get involved in the detailed activities of the project, there is a big gap.

This gap is the source of the problems. There is a focus on the delivery of the software. There is a focus on delivery of service to the customer. There is no focus on the business benefits.

The solution must come from the leadership team. The owner and senior managers must set the goal (to improve sales, reduce costs, improve service, etc.). They must ensure that everybody understands how the software will help to improve performance. They must maintain this focus throughout the project, because everybody will forget. If they do that, two things will happen:

• The software will deliver the business results.
• They will be surprised by the extent of the improvements.

An IT project is a business change project

I just read an article by Jed Simms identifying that every project is a change project and should be managed as such.

What does this mean? Many of the business owners that I talk to are not interested in technology and don't want to have to deal with it. They aren't comfortable with it, despite the fact that it surrounds us. The reason is that much of the technology is hard to deal with. Software is developed by software programmers for software programmers. It isn't developed for normal people. So it's not hard to understand why business people don't want to have to deal with it.

The problem lies with the fact that when we change technology, we are changing the business. Our business processes are affected, therefore our daily work is affected. Our business lives are changed (or why did we do it?). We were looking for improvements, we were looking for change. When we change business software or even the underlying technology (like Vista), we are changing our daily activities. We do much of our daily work without thinking about it. When our subconscious takes over, we get much more efficient. However, when faced with change in our daily work, we have to start thinking about it. We have to learn these new ways of doing things. This slows us down tremendously. We become less productive.

In many cases, the change can feel overwhelming. There is so much to learn and we still have our normal work to do. What do we spend our time on? How do we prioritize? Since we can't get our work done in the normal time, we start to get stressed. We often revert to the way we used to do it, or find some other shortcut. These shortcuts are not always useful from the perspective of the new technology or software. This causes numerous problems.

As a business owner, you don't need to focus on this technology. You need to focus on the change in your business. How will your business be changed? What is the most important thing for your staff to learn about this new software? How do you get them to be productive more quickly?

This is what a change project is all about. This is why every business owner needs to be aware of the business impact. This is why any IT project needs to be dealt with as a business change project.

Should you care about SR&ED?

SR&ED (Scientific Research & Experimental Development) is a tax credit program provided by the Canadian Government to help companies improve their competitive position. In a recent discussion with a SR&ED consultant, I found that many of the activities that a company undertakes may qualify for a tax credit. This can help a company to justify their expenditures on advancement.

Information Technology is a necessity for any company to survive today. Since technology is constantly changing, keeping up with technology and increasing the return on investment is also a necessity. This is more than a technologists view, but one of a company improving or maintaining its competitive position.

Most people probably think of SR&ED in terms of research and development projects, but the Income Tax Act defines it more broadly. There is a structured approach to the requirements and sometimes it can be difficult to go back and justify expenditures as SR&ED eligible.

There are three criteria for eligibility:

1. The project must be undertaken in a systematic manner, following a scientific method and be carried out by qualified personnel.
2. The business must face a technological uncertainty with regards to the project.
3. The business conducting the project must seek to advance its technology, even if the advancement may be only incremental.

When I take on an assignment, the company that I work with has normally failed to successfully implement software to upgrade their business performance, which was their goal. On the face of it, they possibly have qualified for criteria 2 &3 above. They obviously faced technological uncertainty, because they failed. They were attempting to advance their technology as they were implementing new software to upgrade business performance. The only criteria that they may not have met is the first one. Was the project undertaken in a systematic manner, following a scientific method and carried out by qualified personnel?

In my experience, these projects did not follow criteria 1. They didn't get qualified personnel to help them because they didn't want to spend the money. They often fail to get the value or business outcomes that they sought because they didn't have the skills. The SR&ED program may be an opportunity to provide a win-win. Since expenses on an a project that follows a systematic method are eligible, the business may hire skilled consultants to help them and get some of those costs back in a tax credit, their success and profitability are improved.

Can a business afford not to invest in getting help to improve their business performance? This is only a preliminary view of the potential for a business to gain twice from SR&ED. As I learn more about the opportunity, I'll provide an update.

The 5 factors for a successful software project

In my experience, software projects in small business are successful for a few good reasons, none of which has to do with the software itself. It has to do with the approach of the manager or owner of the business.

The 5 factors are:

• Attitude
• Consistency
• Persistence
• Support
• Advice

I've discussed your technology attitude in a number of posts, and this is a critical factor. If you go in with an attitude that you aren't comfortable, you are aiming at failure.

Consistency is the second most important. For those people who have had negative experiences with computers, you may find this hard to believe, but computers are very consistent. They will do the same thing every time and will expect you to do the same. People are much more flexible and can adapt when things change. They don't recognize that St. and Street are the same and a lot of problems are caused by inconsistency of data. The same is true if you change the way you do something.

Persistence is the third key element. I have never seen a software project that goes perfectly and that is often due to our lack of consistency. No matter how frustrating it seems, you have to push on through and solve those problems that you will encounter during implementation. Most of them have simple solutions. The good news is that because of consistency, once they are solved (really solved), they don't return.

Support is a critical element. If you have no experience with installing software to upgrade your business, get someone to help you. An experienced consultant can help you overcome those simple problems that I mentioned. You will save a lot of time and effort and be able to continue to make progress towards your goal. Get somebody who will work with you throughout your implementation, not just react to your problems when you encounter them.

Even better, get some advice before you start. This will allow you to plan more effectively and prevent many of the problems that you are likely to encounter. If you do choose to get advice, look for a supplier who will work with you throughout the project. This means that they will learn more about your business and be in a better position to support you when you need it.

Notice that none of these factors involve either the software or your technical skills.

A long time ago, a mentor told me that there are three factors for success: focus, will and capability; capability is the least important. If you maintain focus and have the will to continue, you will develop the skills or capabilities that you need.

IT Project failure

Over the years, many studies have been done, looking at the success rates for IT projects. All of the traditional issues are always raised, and they often are categorized as some of the following, as it was on this Blog "12 early warning signs of IT failure". The list includes:

1. Lack of top management support
2. Weak project manager
3. No stakeholder involvement and/or participation
4. Weak commitment of project team
5. Team members lack requisite knowledge and/or skills
6. Subject matter experts are over-scheduled
7. Lack of documented requirements and/or success criteria
8. No change control process (change management)
9. Ineffective schedule planning and/or management
10. Communication breakdown among stakeholders
11. Resources assigned to a higher priority project
12. No business case for the project

While these may all be valid, there is one underlying issue that is not mentioned. One of the first things that I was taught in problem solving ( a basic introduction to any computer course is "root cause analysis"). Root cause analysis says that you shouldn't look at the first level of causes to understand why something is happenning, but look a few levels down to the underlying causes of these causes. This is also a standard quality management practice.

When we look at some of the above-mentioned causes, we find:

• Lack of top management support
• No stakeholder involvement and/or participation
• Weak commitment of project team
• Subject matter experts are over-scheduled
• Lack of documented requirements and/or success criteria
• Communication breakdown among stakeholders
• Resources assigned to a higher priority project
• No business case for the project

All of these related to the fact that this was not something of value to the business. If top management and the business units don't want it, these things will happen. So why do projects get started, and why is time and money spent on them?

Projects get started for good business reasons, but quickly get into "project mode". They cease being a business need and become an IT project. The project team starts talking about implementing software instead of upgrading business performance. Time stretches out as we build a sophisticated system to provide all options that might be requested at some time in the future (it never comes). Let's get back to basics and focus on the business outcomes that the business needs. By focusing on those business outcomes, that should deliver benefits to the business, we will not only have more successful projects, they will deliver the value and keep the interest of top management and the stakeholders.

The first priority for IT

Most businesses look to technology to solve a business problem. After all, why buy software if it doesn't do that?

But if the infrastructure (IT highways, bridges, etc.) are not stable and capable of supporting the new functions, failure is often the result. This shows up as increased costs, poor response time, delayed projects, etc.

When you build a new building, you have to ensure that the foundation will support the structure that you are building. A shed needs less of a foundation than a house; a house needs less that a tower.

Your business software has the same kinds of needs. Unfortunately, many software suppliers or even outsourcing IT suppliers won't tell you this. They may be afraid to lose the contract if the cost is too high. They may not understand the needs of the software. Most software suppliers tell you the minimum that is needed to run their software. That doesn't mean that it will run well. This minimum doesn't consider your other needs. It is an isolated view.

These are some of the reasons why costs escalate. The needs were there, but nobody looked at it, or they didn't understand it, or they were afraid to mention it until it was obvious it was necessary. This happens with internal staff as well as external suppliers.

Most small businesses look at the cost side of the equation and don't want to spend more than they have to. This is understandable. It is also a mistake.

Check out my article on "The cost of Buying Business software".

Alligators and software

What do alligators and software have in common?

It comes from one of my favourite sayings "When you're up to your neck in alligators, it's hard to remember that you are there to drain the swamp".

Most projects to install new software in a business start with a fanfare, and an expectation that this new software will solve all your business problems and be the holy grail for your business. I've raised this issue before and said that software will not do this by itself. There are many prerequisites to successful software projects. My blog on business value being a key one.

Even when you have established your goals, identified the business value, identified how the software will support your business process to deliver this value, you have a problem..... reality.
Reality rears its ugly head on a regular basis. You need to respond to your customers. You need to make more sales calls. You need to build, deliver or do whatever it takes to bring in revenue today. That software can wait until tomorrow. As we all know, tomorrow never comes. There is only today. The today issues are the alligators that will prevent you from being successful.

Years ago, I attended a management course that talked about the three requirements for success: focus, will and capability. Contrary to common thinking, capability is the least important. Focus is the most important. If you FOCUS on it, and have the WILL to continue no matter what happens, you will succeed. If you don't have the capability, but have the will, you will develop the capability.

I have followed that strategy for myself and have overcome many problems.

In many cases, you are distracted by day to day events. Can you get back to focus on delivery? Do you need help? A good coach can help you to maintain focus and help you to define solutions to the inevitable problems. You are the one who must have the will to continue. If it is really imporatnt to you, you can buy the capability that you don't have.

So just remember. If you take on a software project, remember the ALLIGATORS. And remember that your job is to drain the swamp.

Business Value - the Silver Bullet

A detailed study of project success performed in Australia provided another perspective on the failure rate of projects (this went beyond IT projects). A very small percentage of project succeeded in delivering business goals. They failed, not because of poor project management, nor technical difficulty, but because they never defined the business value that was to be delivered.

The projects got initiated with a fuzzy definition of what was to be delivered. It was assumed that by completing the implementation that business benefits would be delivered, but nobody was focused on this. They were focused on the implementation. However, implementation of software delivers a small portion of the benefits, and unless the full business value is identified, success will never be achieved.

I have seen many projects initiated with an attempt to provide "justification". This justification always seemed to focus on identifiable financial benefits, and not on the business value generated. For example, improved productivity was only measured if staffing could be reduced. In addition, this lack of identification of business value leaves a lot of benefit on the table.

I recently completed a project where one of the business goals was to be able to invoice within three days of completion of a job. Within three months, we had achieved that objective and that benefit alone paid for not only my contract fees, but for the original purchase and install of all of the hardware and software. The previous project had been to install the software. While implementation of the software had been completed, the business never saw the value until we focused clearly on these goals.

Why is it that so few projects focus on business value? In my experience, most software projects take on a life of their own, once they are initiated. Many compromises later, the project is completed and there is no way to measure its success. We can measure it one way; the business people are always disappointed. Their expectations (not written down) were not met. A focus on business value would eliminate that problem.

Is Planning necessary?

I had a discussion with a client recently who said that her approach to doing things had changed significantly since we started working together.

She is a very action oriented person and typically starts off in a rush in order to accomplish her objective. She now starts by planning what she wants to do before starting any action. She has recognized how it saves time in the long run.

I recently found a statement describing how 1 hour of planning saves 3 hours of execution.

In starting any project, everybody is looking for action, and planning does not look like action. Managers want immediate results. Unfortunately, this focus on immediate results often causes more problems. Unnecessary work gets done, the wrong function is delivered.

I always look to the business goal that we are trying to achieve and what we need to do to achieve it. In looking at a project this way, questions get asked and the answers change the definition of the problems. People are separated by a common language. What you say and mean may be different from what I understand. If I don't attempt to outline a plan for what you are asking for, I really don't understand what is involved. If I start acting on it, it may look like I'm on the right track, but I could be way off base. By developing a plan, I get a better understanding of what you are asking for and when I communicate this to you, you can tell if I'm delivering what you want.

If business people are separated by a common language, what do you think will happen with technology people? They have a language all their own and their focus is very different. What they hear you say is very seldom what you mean. Without the outline of a plan, you will not get what you think you are asking for.

Getting started on a software project

I have a problem with starting software projects. I have been working with software for my whole career, and typically when I start working with a company, I understand the situation and what needs to be done.

While it is obvious to me, it is seldom obvious to my clients and their staff. They called me for help because they were not able to achieve the goals that they set out for themselves. I am ready to get going and can see the steps that need to be taken, but I can't go there.

Over time, I have learned that I can only go as fast as my clients are capable. In the early stages, it seems quite slow and little visible progress is seen. This can be frustrating for managers of projects as they are anxious to get going. However, this is a difficult time for people to go off in a rush. They are working in unfamiliar territory, with changes to their business processes, new technology and tools and typically a new list of issues every day. This is not normal operations.

Many consultants will offer a "solution" to this problem. They will bring in a group of outsiders who will make the project happen. There is a flurry of activity and everybody is happy. Then the project grinds to a halt. Often this is because roadblock and roadblock has been put in the way. This is usually after a lot of money and time has been spent. The reality hits that the staff has to know what is going on. It can't work without them.

While the early stages of a project can be frustrating for those that know what needs to happpen next, it is a time of learning, and sometimes learning can be slow. people learn what they need to know. Once learning has started and everybody understands where things are going, they start to look for opportunities to use the software and they understand how it can help them.

This occurred in a recent project that I worked on with a client. The first month was frustratingly slow. We focused on the business process and looked for ways that the software could help improve the process. We uncovered many process issues that would prevent successful implementation. In the second month, things were still slow. Volume of work prevented catching up with the backlog, but now we were no longer building a backlog. We were keeping up with day to day requirements. More process problems were identified and resolved. By the end of the third month, the staff had taken ownership of the software and could see how it was helping them. The backlog was eliminated and the software was functioning as desired.

Although progress was slow in the early stages and required ongoing support and coaching, the learning process was happening. The slow start was worth it.

In starting any new project, leave time for learning. Start slow. It will pay for itself later on. I have seen too many failures where companies bring in a ast of thousands to make early progress. The only thing that they succeed in doing is increasing the costs.

Searching for information

We install software in a business to increase productivity and reduce costs, sometimes to deliver a service that could not be delivered in another way.

Having said that, I am always surprised at the lost productivity that I find in business. One of the areas of wasted effort is searching for information. It doesn't take long to do most jobs. What takes a long time is searching for the information to be able to do the job.

Paper has a disadvantage over computers. It can only be in one place at any time. When information is loaded into a computer database that is shared among many people, it is accessible by everyone. So you can do the job when you are ready, not when the information reaches your desk.

In working with a small company recently, I found that they were often delayed in getting their invoices out. The reason was that jobs were being charged as time and materials and all of the charges had to be in before an invoice could be produced. This often took weeks before all of the payroll and payable forms could be made available. It was a further problem because many of these jobs were verbal agreements and there was no tracking mechanism.

Once we had the tracking mechanism in place, it acted as a trigger and a small change in the paper flow process allowed the information to be immediately available and the invoice could be created on the same day.

While a totally automated process might provide more benefits, a lot of work was required to get there. This provided the benefit (faster invoicing, faster receivables) without major effort.

Electronic tracking of workload (a small effort) produced a big benefit (faster revenue). This is what businesses need to look for. Big, complex, lengthy projects are not necessary to get value. Focus on the value first, then what effort is required to get it.