How Business Automation Projects Fail, Part 1
12 March 2009
I’m starting a short series in How Business Automation Projects Fail. This is part 1, where I’ll cover the case of an apparently simple project to install a common software package. In part 2 I write about a much more complex and expensive project.
Business Processes
Businesses run by following well defined processes. Let’s look at a wholesale distribution business as an example. Here’s a grossly simplified version of the core processes at the heart of the business:
- An order comes in.
- The accounting department vets the payment, issues an invoice when necessary, records the transaction, and passes the order to fulfillment department.
- The fulfillment department picks, packs, and ships the merchandise, records the shipping transaction, and adjusts inventory quantities.
- The buying department reviews the revised inventory records and places replenishment orders when necessary.
Process Automation
In many cases, business processes can be made more efficient by letting computers do portions of them. Say you’re a small wholesaler with an overall selling process similar to what I’ve described. You know you want to automate many parts of the process. You’d like the computer to do the accounting, keep track of the inventory, alert you when customers haven’t paid and when inventory quantities are low.
So maybe you go to your accountant and ask for advice. The accountant says “Buy QuickBooks. I’ll help you set it up,” because that’s what the accountant is familiar with. So you do.
A month later you have the software installed and mostly configured, and you start to try running sample transactions through the system. You quickly discover that there’s a big problem. QuickBooks lacks the ability to manage multiple warehouse locations (this is a hypothetical example) and you need that badly. The entire automated system is useless to you without that feature.
Failed Project Postmortem
How did this happen? Your accountant recommended a capable and familiar software package without taking the time to define your requirements completely and to compare those with the software’s capabilities. The accountant was never trained in that discipline, and neither were you.
What’s the net result? You’ve lost a month of work setting up the software, and you have to start over from square one. You still have to find or commission the right software and get it set up.
Does this little story sound far-fetched? It’s not. It happens to small and medium businesses every day. This is exactly how software projects fail, how business automation projects fail – by failing to define the requirements formally and to make sure that they will be met by the proposed solution.
In this part I’ve told about one common way that a packaged software acquisition and installation project can fail. Stay tuned for part 2, where I’ll cover a more complex project where the business commissions a custom software solution.
This was a failed attempt by this company but in all actuality it could have ended worse for them. What do they have to do now? Do you suppose that person that was in charge of this endeavor will lose their job? It sounds like a very good lesson to learn if you are a business owner. Your blog was very well written and presented in a professional manner.
Accountants are great at what they do, they are great with numbers. But never ask them what to use as far as software for things like this. Accounts will always go with what they know which would be an accounting software. Software is a serious thing and can be messed up easily, I hope everyone reading your post takes it to heart, never ask computer advice from anyone but a computer person
I found your example of the warehouse and Quick Books software to be rather humorous, now don’t get me wrong this a serious issue but I used to work for a construction company that tried to use this same software to keep track of inventory and other things and they would tweek the system to make it work for them, but then come tax time they found out it didn’t work at all. Bad decision.
Since the dialogue is about assessing software requirements and how not to mess it up, I would like Steve’s assessment on what he thinks about the ordeal that many webmasters are going through because of Joomla’s, redevelopment of their content management system. The change has caused problems for many when they attempt to migrate their databases from version 1.5 to 1.7. Yet another version is due to be released in March 2012. Do you have an opinion on this CMS software?
Ok I am not sure if you are joking or not, but why would a company ask their accountant about software for the computer system? Accounting software like Quick Books Pro is not going to cut it for the everyday business and inventory etc. ask the right people for advice on software and leave the beam counting to the accountant.
I hope that this company learned from their mistake. If the person advising you doesn’t ask you what you are going to need then that person is not the right person to ask. I have a computer guy that is a friend of mine and I asked him for advice once on some software and boy did I get the wrong thing. I learned my lesson that’s for sure.
Your blog was put together very well and I have noticed something about companies and when you ask for advice about software, if you don’t ask the right people they are always going to suggest what is familiar to them whether it is right or not. If you ask for help and they don’t ask you what your requirements are don’t trust their advice
I’ve said it before and I’ll say it again. If you are going to ask for advice make sure that you ask someone in the same line of work as you, they are going to understand what it is you need and be able to help you. This isn’t going to be the case if you ask the janitor about accounting software, get my meaning.
Test Design is a key to making accurate assessments for a company’s software needs. How test specifications and test cases are created inherently determines the success of any software assessment. The problem is that most of the design techniques (if they even bother to create them) are not always properly applied, leading to poor testing. This is more necessary for large scale industrial projects and companies. The detailed categorization of mistakes provides a basis for improvement of the Test Case Design, resulting in better tests. It sounds redundant, but it’s true.
it’s important to conduct a proper risk assessment to ensure company policies and procedures help reduce the risks and potential threats within the workplace. Each company faces different risks based on factors such as industry type. There are certain elements that need to be included in all risk assessments. I have learned from writing a business plan that, like a SWOT analysis, risk assessments encourage techs and executives to think harder about different threats and opportunities for the business.
When you have a software consultant on staff do you think that you need a separate helpdesk guy? I am under the impression that the help desk guy should be able to answer your questions on the software as well so in all essence he would be a software consultant as well. I bring this up because of another blog but I think your answer would be important as well.
There is a discount usability inspection method that’s become the industry standard. The heuristic evaluation specifically involves evaluators examining the interface and judging its compliance with recognized usability principles (the “heuristics”). These evaluation methods are now widely taught and practiced in the New Media sector, where UIs are often designed in a short space of time on a budget that may restrict the amount of money available to provide for other types of interface testing.
Assessing software quality and whether it is applicable to your needs can be considered the elusive target. If you are a software developer, manager, or maintainer, quality is often on your mind. But what do you really mean by software quality? Is your definition adequate? Is the software you produce better or worse than you would like it to be? These are all questions that I am unclear about and what must be answered before deciding to spend money.
In the past, when bank statements contained errors or the telephone network broke down, the general public usually blamed “the computer,” making no distinction between hardware and software. High-profile disasters and the ensuing debates in the press are alerting people to the crucial nature of software quality in their everyday lives. Before long, we can expect increasing public concern about the pervasiveness of software, not only in public services but also in consumer products like automobiles, washing machines, telephones, and electric shavers. More than ever, software consultants need to worry about the quality of software.
That is a good question the Mary asks because it is pertinent in the work place of today’s economy. That is because many small and medium sized businesses are choosing to cut corners by employing smaller staffs in order to save on salary spending. Consequently, more responsibility is falling on employees and in some cases, duties they would normally never fall under their job description have become their responsibility. So a help desk customer service rep may also be the IT admin.
When an IT consultant is assessing software, shouldn’t you be questioning the validity of the objectives? The reality is that most quality initiatives either fail (by drowning in a sea of rhetoric) or cannot demonstrate success because no financial return can be identified. A consultant should question software quality in the same way. experts consider the meaning of software quality, how it is assessed, and whether the steps being taken to improve it are really worthwhile.
While I was studying, I read about an influential paper examining views of quality, the author concluded that “quality is a complex and multifaceted concept” that can be described from five different perspectives. The transcendental view sees quality as something that can be recognized but not defined. The user view sees quality as fitness for purpose. The manufacturing view sees quality as conformance to specification. The product view sees quality as tied to inherent characteristics of the product. The value-based view sees quality as dependent on the amount a customer is willing to pay for it.
As people and companies continue to feel the stressful pinch of a down trodden economy, the quality of customer service and project management efficiency will continue to suffer because businesses are forced to cut corners and avoid spending on the things they think are not absolutely necessary. Unfortunately (for consultants and the businesses themselves), the hiring of a software / IT consultant is widely considered a luxury and so a company won’t spend on one. Little do they realize that the price for making that decision may be the life of the business.
If you get in over your head when you are asked to do something it is better to speak up from the beginning and say you don’t know how, it is that simple, and it will save you embarrassment and the save the company hundreds if not thousands of dollars. This article was just as great as the other one and they both have very good information in them. Thank you for posting these.
Your second post was a much more expensive and much larger scale problem. But this one had it’s place in line as well. Why do you suppose people that don’t really know about this stuff try to make these judgment calls anyway? You don’t have to be a genius to figure out when you are in over your head and ask for help before you completely ruin everything.