There are sites on the internet (like FindAccountingSoftware) that collect information from people looking for new software and feed it to people that provide software.
If you looked through the list of “projects,” you’d see a lot of them that want General Ledger, Accounts Payable, Accounts Receivable, Payroll, Inventory, Order Entry, Purchase Orders, Manufacturing, Service, and CRM. They want complete training and support. And the budget is $5000 for 5 users.
Or they’re looking for a new real estate management system with a budget of $2500 for the entire project.
Or a new inventory system for $500.
And these projects sit and sit and sit. No consultant or software provider volunteers to contact them. Why? Because it’s not possible to provide for their needs for the price they have set.
I’ve talked to the FindAccountingSoftware people about this. “We try to get them to set a realistic budget, but some are just convinced that they can get something for nothing.”
Several years ago, I got a call (for the second time) from a local business. The first time around, his budget had been $10,000. He was looking for hardware and software and implementation and data conversion. Ultimately he bought a system for twice this from a company that (from the looks of it) my have sold 25 copies of the software.
He got a deal.
Problem was, the software didn’t work. Inventory was wrong. You could run the same report twice and get different answers with the same questions. I know what you’re thinking…you must have put in the wrong dates or something the second time…nope…been around long enough to look for that. The same report gave different results.
So we did a needs analysis (see #2). Good step.
Then we talked about budget. This time, the business fellow figured he could go as high as $20,000 for 13 users.
“Sorry, I can’t help you,” I told him.
“We’ll find something,” said he.
“You did last time!” I reminded him.
Realistically, there are three basic ranges of software. Low, Middle, Tier 1. Some people put in another one, but I’ll stick with the three: S, M, L.
Tier 1 (L) packages are going to cost in the range of $500,000 to a heck of a lot more than that for businesses the size that need them. And the implementation will probably cost at least twice that.
(Ok, the Tier 1 vendors can point to some exceptions on the low end, deals where the software cost $100,000 or $150,000, and where the implementation was $50,000. But for the average business, you wouldn’t be looking in this range of software if you didn’t need about 50 or so users on the low side, and that’s going to cost you).
Figure $5,000 per user in this range, at least. And twice that to four times that for implementation.
Next I’ll take the low end (L). That’s where QuickBooks lives. And Peachtree. Figure about $700 on the high side per user. And the software’s so simple that you probably won’t need much help figuring the software out. You may need some help with the accounting concepts, though. That’s where an accountant or CPA comes in.
And now for where most people live. Usually around 5-10 users, companies figure out that QuickBooks or Peachtree or custom software or Excel or ACCESS aren’t working any more. They start looking for software for their businesses. And they have two basic choices: off-the-shelf, general market software (what I call the “Top 10 Mid-Market Packages.” Even though at any given time there may be 8 or 25 of these packages, I still call them the top 10) and vertical software.
And since discussing the differences will take a while, and this entry’s long already, I’ll stop here with the note that these packages are going to run in the range of $3000 (basic model Chevrolet) to $10,000 (limo) per user. The difference is the features you need and how many users you need. The fewer features, the less the investment. The more users, the less the investment per user.
And–lest you start thinking this–you can’t often just “give up features” to lower the cost per user. Most businesses that need inventory or a web store find that the cost per user is rising and they can’t find much of a way to push it down.
More later.

Hopefully, if you’re looking for new software, you started with a thorough needs analysis. Not just what was wrong with your existing software, but what your total needs were.
I used to teach consultants how to do consulting. One of my points was, “Have a checklist.” I had an illustration of this point. I had one of the class members choose a card from a deck of 30 index cards. On the card was an animal, vegetable, or mineral (you remember the old game of 20 questions, right?). The idea was for the class to ask one yes or no question at a time (with the question, “Is it an animal, vegetable, or mineral?” specifically allowed), and to figure out the answer.
After about 3 questions, the game degenerates to trying to guess the thing. “Is it a zebra?” “A willow tree?” “A rock?”
The 20 questions are soon up, and the game ends.
Then we played the game again. This time I gave the class a decision tree. It had about 8 or 10 questions on it. Each question said, “If the answer to this question is Yes, go to question x. If the answer is No, go to question Y.”
It never failed that they would get the right answer, usually with about 4 or 5 questions.
“But that’s not fair,” they would complain. “You knew the answers when you made up the question.”
Right. And what kind of consultant would I be if I didn’t have a pretty good idea of what the range of answers was for solving a given business problem? Sure, I’ll run up against problems that can’t be solved with my questions (just like you could find a card that wasn’t included in my 8 or 10 questions), but at least I’ll know when the answer is outside what I’m used to…and I can respond accordingly.
So…the point is…you need a checklist, a list of questions, something to start with in order to do a needs analysis. My list of questions is about 30 pages long. I don’t ask all of them for every needs analysis…some companies don’t need inventory or job cost or service. But my questions cover the field on which I play, and I add to them on a regular basis to account for new management techniques, or new players in the game.
Rule #2: Start with a needs analysis based on a plan of attack, which most of the time will be an outline or a list of questions.
Document the answers. The result will guide the rest of the process of implementation.

I visited with a client that was thinking about buying new software last week. They had a pretty good idea of what they wanted, and I was there to ask more questions to make sure I understood all the detailed needs.
In selecting new software, it’s important to define all the needs. Businesses tend to focus only on the things that are immediate problems. That is, on the statements that begin, “It won’t do…” or “We need to be able to…” It’s important to gather this information, of course, but there are also a large number of things that fall in the category of statements that begin “We like the way we’re…” For more on this, check out the post on The Gladys Principle.
Anyway…
As we were leaving, the client introduced us to the “IT guy” who started with the statement, “I have a few questions I’ll need answered.”
“For example?” I asked sweetly.
“What database does it run on? Is it web ennabled? What administrative rights are required on the server? Blah. Blah. Blah.” In other words: Cost doesn’t matter. What the software does doesn’t matter. All that matters are the technical parts.
Reminded me of the guy that wanted software written in a language he knew. Also wanted the source code so he could modify it. He found some. Last time I heard from him, he had sued the software vendor to get his $75K back.
Doing it this way is like the carpenter that only had a hammer, so every problem looked like a nail!
Rule #1: Don’t worry about the technical stuff until after you’ve found the software that does what your business needs it to do.
The technical stuff should only matter when you’re comparing products that you know have the features you want and are trying to make a decision between them.
I’ll learn new technical stuff every time if you give me the business features I need.

Jeff Kugler makes a great point in the article below. He says you shouln’t modify ERP software. I agree. Since you can read the article for free after you register, I won’t repeat the entire argument. Since you have to register, I’ll repeat the key points.
Here is the key thread of the argument:

• ERP software is developed according to best practice standards derived from groups like APICS (manufacturing trade group), and large businesses
• Other features are added because businesses request them, and are selected based on the number of businesses that request them
• You spend less money implementing if you don’t modify
• You implement faster if you don’t modify
• Therefore, never modify

Problem: Jeff isn’t living in the real world where businesses (and people) are resistant to change. He doesn’t account for the ERP systems that would never be implemented AT ALL if they were not modified because the users would reject them.
Problem: Jeff is about two years late. We’ve been telling clients this in our kick-off meeting for at least that long. Some clients listen. Some do not.
Problem: Sometimes modifying software is a competitive advantage. It increases efficiency, productivity, and throughput.
Solution: Minimize the changes in implementing ERP. Delay as many as possible until you’ve used the software the way it is designed to work for at least 3 months. After that, you’ll be in a better position to decide what you need to modify.
My $0.02.
Impartial Enterprise Software Evaluation, Comparison, Selection Research and Tools for IT Executives. ERP, CRM, SCM, PLM, BI, BPM, HR, Financial, Open Source, Outsourcing. etc.