From Quote to Cash

Many small businesses suffer from the quote to cash cycle.  With many small business owners that I talk to, who work IN the business, delivering products and services, there is always a challenge to balance workload.

You work hard to get a sale, then work hard to deliver.  In many cases, these jobs are back to back, with a need to start working on the second, the minute the first is completed.

With a build to suit approach, which is where many small businesses start, a lot of time and effort is spent doing a quote or estimate.  Once the sale is made, all focus goes into delivery.  When the job is finished, you start to work on the next one.  Many times, you are too busy to create the invoice.

Most people might say "generating the invoice is the most important part!".  I always felt that, and was surprised at how many businesses don't do it immediately.  I found, surprisingly that many people are focused on delivering the next job.  They react to business critical items, such as paying their suppliers and their staff (or they can't do new jobs), but are very slow to pay themselves.  They often defer creating the invoice until they "have time".

In analyzing the situation with clients, I found the challenge.  Most of these owners hate paperwork and love doing the work.  They don't work at simplifying the paperwork, because it doesn't come easy to them.  They often create complex processes and tools that makes the job hard to do.  Yet they have done all of the real work, they just haven't made it easy to use.

A common example that I have seen is the generation of quotes or estimates in Excel or Word, the generation of the order form in a different product, purchase orders created manually, then invoicing again using a different tool.  Each of these often requires entry of customer information, product information, prices, etc.  Since there is no link between them, the data is entered multiple times.  In many cases, the same information in the quote is again used in the invoice.  Then the data is entered in the accounting program.  To save time, only the basic accounting entries are entered.

The result is that the business is able to do financial statements at the end of the year (often late), but has no understanding of the profitability of products or customers.

A simplified business process would capture the information once at the beginning, provide the ability to generate order confirmation, purchase orders and invoices simply, as well as save time, give you better information about your business, and get invoices to your customers faster.

Sounds like a winning proposition to me.  Why doesn't everybody do it?

An evolving business

I started my career in Information Technology and went from programming software, to planning data centres and networks.  In managing data centres, I learned that effective operational processes were critical to delivering consistent quality services.
As a consultant for 13 years, I started by improving IT processes in large data centres as The IT Process Doctor, to working with smaller businesses who were not getting value from their IT investments, as The Virtual CIO.
In my previous Blog entries, I blogged about IT.
Recently, I found my true passion, helping small businesses to operate more successfully, by eliminating the complexity in their business, so that they can improve productivity and eliminate many of the frustrations that they encounter in the activities that we all must do to success in business.
The approach to simplifying a business is rooted in simplifying operations through the development of consistent processes that continue to deliver day after day.
Every person who becomes adept at any skill operates on a subconscious basis.  The more you have to think about an activity, the slower you are.  The more you operate at a subconscious level, the more productive you are.  If we simplify activities, people can move more quickly to a subconscious level.
That's why change causes so much disruption.  When you change a set of activities, you have to think about what you are doing, and you slow down.  This can be extremely frustrating when you have to be really productive.
Over the next few weeks, I will be blogging about approaches and ideas to help small businesses improve their performance.

Increasing software project failure rate

Software project continue to have an increasing failure rate according to a Standish report. Standish regularly reports on the success of software projects. This year shows a decrease in success.

While more and more emphasis is placed on project management for the failure, I believe that the real reason is a lack of business value definition. In too many cases, projects get initiated with a good and valid business reason, but the "solution" is seen to be the installation of software. Software is a tool which can help a business improve, but it is not a solution by itself.

More effort needs to be placed at the front end to determine the real goal. The real goal might be to increase sales, reduce costs, improve cash flow, improve quality of service. By using a software product the business may be able to capture and analyze data more quickly and easily, deliver goods more quickly, etc., but the software will not do that. It can help, but if your business process is ignored, you may end up creating more problems, more quickly. That doesn't help reach the business goal.

Start by clearly identifying the business goal, then show how the goal will be achieved. When you see what steps are required, you can identify where software can help. After you have decided how the software can help, don't turn the project over to IT for implementation. Keep focused on the goal, which should deliver business results, earlier rather than later.

If there is something in the project that doesn't produce business results, you will learn that earlier and be able to adjust the deliverables of the project to ensure success.

Key issues in CRM software failures

I attended a town hall meeting today on IT failures specifically targeting CRM. The key items mentioned about the failures all related to not It and non-software issues. Some of the key items that I took away included:

• Software comes with the vendors version of best practices. This may not be your company's view of best practices. Converting to their best practice could hurt your results.
• For CRM in particular, attempting to get information on what your best salespeople do is a problem. If you ask them what they do, so that you can copy it, then watch them, you will find that they don't practice what they say. This is true of other professions, but it may not have the same impact. Most of what people do is done subconsciously. That's why what they say and what they do is different.
• Many IT projects fail because they try to do too many things for too many people. This increases complexity and increases opportunity for failure.
• Because of the defined complexity, the application becomes difficult to navigate and decreases productivity and sales. It's better to make it simple.
• There is too much emphasis on training vs. education. Training tells you how to do it. Education helps you understand why you should do it and how that will help to improve performance. There was another question related to how much training should be provided vs. making the software intuitive. Would anybody play games if they required you to attend a full day training session?

Those were my key takeaways. You can check for more on Twitter at #ITfail.

Top Ten List for CIOs

The Chief Information Officer title has been around for some time now. The title is often used to describe the person who heads the Information Technology function for a business. While this is normally true, I believe that this title should be restricted to leaders who recognize the value that Information technology should be providing for a business.

Too many CIOs are still "managing the business" That is, they are responsible for all of the technical staff and hardware and manage the day-to-day operations of the IT business. While this is a necessary function, it doesn't add value.

The Society for Information Management (SIM) have completed a study of CIOs and came back with the following list of priorities:

1. Business productivity and cost reduction.
2. IT and Business alignment.
3. Business agility and speed to market.
4. Process re engineering.
5. IT Cost reduction.
6. IT reliability and efficiency.
7. IT Strategic planning.
8. IT innovations.
9. Security and privacy.
10. CIO Leadership role.

The focus here is clearly on the business and not on IT as the driver. This says one of two things: Either the CIOs polled are taking action or at least the message is getting through.

In the past, too much of the focus has been on Reliability and efficiency (#6) or on Security (#9). While these are important, they are what the IT operation needs to deliver. The CIO needs to be focused on the business.

See Top Ten Presentation.

A view of a failing software project

I have just read an article about a CRM project that is doomed to failure. The basis for the problem is that, buyers often utilize the customizing features available in many software packages to change the functionality before they understand what the software does and how it works. Utilizing the software out of the box is what the writer recommends.

While this may not be possible for all software buyers, it raises an excellent point. Software is developed to automate a process. If you start to change the functioning of the software without understanding the basic operations of the process, you are doomed to failure.

The answer may not always be, use it out of the box without changes. However, understanding the underlying process is critical. A better approach would be to document your existing business process and compare it to the process provided by the software. This does two things:

• It provides you with a basis for evaluating the software and identifies opportunities for improvement of the existing process and what you can get from the software.
• It will also tell you whether there is a conflict.

Now you know exactly what you need the software to do and whether any enhancements are required. If there are no critical missing requirements, I would agree: Use it out of the box without customizing.

You will get results earlier, and if customizing is required, you will get a bump up when the system has stabilized and your staff are up to speed.

The original article can be found http://bit.ly/47lzRv

What's the difference between an estimate and a quote?

I've been working with a small organization that has to replace it's software.

They have no idea where to start, so they came to me. They want to understand what it might cost them. Before the Board of Directors will approve any expenditure, they want to know the full cost.

In talking to a number of software developers and software suppliers, I found them initially reluctant to discuss potential costs. In their experience, the clients seldom have any idea what it takes to develop and install software. If the supplier quotes too high a price, the client will go elsewhere. If they quote too low a price in order to keep their interest, they get burned when the client comes back.

The problem is that the business needs a starting point. They need to know if it might cost $1 or $100,000. They want it for the lowest possible price. That is a ball park estimate. However, since they have no idea what is required to develop and install software, and the software supplier has no idea what's functions are required, they can't give a quote. No matter what they say or do, the client will see the estimate as a quote.

We have a standoff. The supplier ask for a budget, but the client is trying to create one.

The reality is that we need a third party, who understands that software is an automated process, and in order for the supplier to be able to give a quote, he must understand much more about the business. By acting on behalf of the client, he can get to understand the scope of the business need, without getting any value from the price of the software.

In this case, I have been able to get three estimates from different suppliers, despite their reluctance. They knew that I understood the difference, and they are not providing the estimate to the client. I am. Now I have to make sure that the client understands that this estimate will help them decide how to move forward. As we define the process and identify the requirements, we will be able to get a reasonable quote from the supplier.