Top 10 Software Selection Mistakes

Top 10 software selection mistakes

Michael Burns. CA Magazine. Toronto: Dec 2007. Vol. 140, Iss. 10; pg. 14, 1 pgs
Abstract (Summary)

For many companies, replacing a system is like going to the dentist: necessary, but potentially painful. Often, you can stave off the need for replacement with preventive action such as upgrades. But if the system is no longer supported, or if there has been a change in the business that renders it inadequate, you have no choice but to go to market. And when you do, it's easy to make big mistakes. Here are the biggest ones: 1. requirements not defined properly, 2. scope not defined, 3. lack of buy-in, 4. involving the wrong people, 5. featuring myopia, 6. disregarding smaller vendors, 7. not improving business process, 8. no script, 9. lack of risk management, and 10. lack of project management.
» Jump to indexing (document details)
Full Text
(687 words)
Copyright CANADIAN INSTITUTE OF CHARTERED ACCOUNTANTS Dec 2007

[Headnote]
USING TECHNOLOGY TO IMPROVE THE WAY YOU DO BUSINESS

For many companies, replacing a system is like going to the dentist: necessary, but potentially painful. Often, you can stave off the need for replacement with preventive action such as upgrades. But if the system is no longer supported, or if there has been a change in the business that renders it inadequate, you have no choice but to go to market. And when you do, it's easy to make big mistakes. Here are the biggest ones.

1. Requirements not defined properly: you will run into nasty surprises if your requirements are not defined clearly. Prioritizing is key; otherwise, you could end up with more than you bargained for in terms of cost and complexity. You should ask vendors to tell you how well their system meets each requirement. Vendors will not usually mislead you if your requirements have been defined without ambiguity. They realize your decision will be based primarily on trust and they will lose your trust if they don't tell the truth.

2. Scope not defined: scope has a nasty habit of creeping or growing unless you define it early and stay focused. It is fine to change the scope but only after the impact has been understood and approved.

3. Lack of buy-in: if the people who are going to use the system are not motivated to make it a success, you're headed for trouble. You need to get employees involved from the beginning. Not only will you do a better job in defining requirements, but also in gaining buy-in. You need to make sure senior management agrees to the methodology used, the time frame and the budget. One very effective tool is to have senior management define measurements of success prior to the selection, then show these measurements were achieved.

4. Involving the wrong people: without highly motivated and knowledgeable people, your project will go nowhere. At least one champion should be assigned to act as a dedicated resource during implementation. You will also need subject-matter experts who can represent the business processes in scope. They may need to allocate 25% of their time during the implementation.

5. Feature myopia: many companies spend too much time assessing the features of the system and not enough on the implementers. The implementers need industry knowledge, project management skills and product expertise. Finding the right implementer can be a challenge, partly because there is no good source for finding the right one. As well, the people assigned by the software developer to divvy out the leads may be recommending a particular company for reasons that have more to do with politics than with the right fit.

6. Disregarding smaller vendors: there are very good companies that support specific industries. These companies are small but not necessarily risky. They don't need lots of new sales to be profitable.

7. Not improving business process: implementing a new system is the best opportunity you will ever have to improve your business processes. All the problems with the existing system are in fact opportunities for improvement. So make sure that you are aware of the problems and that the new system will help resolve them.

8. No script: vendors will naturally want to show their strengths during their demonstrations. You should provide them with a script that documents your business processes, problems to resolve, scenarios and requirements, and that includes sample forms and reports (see the November issue or visit www.camagazine.com/gap).

9. Lack of risk management: don't avoid the naysayers. Seek them out and ask what could go wrong and what should be done about it. You should also consider getting some outside help to reduce risk.

10. Lack of project management: most people learn project management through the school of hard knocks. Yet there is plenty of help out there. For example, check out the Project Management Institute (http://www.pmi.org) for methodology. In subsequent articles, we will discuss project management concepts and tools.
[Author Affiliation]
Michael Burns, MBA, CA, is president of 180 Systems (www.180systems.com), which provides independent consulting services, including business process review, system selection and IT audit. Contact 416-485-2200; moc.smetsys081|snrubm#moc.smetsys081|snrubm

Indexing (document details)
Subjects: Workflow software, Work methods improvement
Classification Codes 9172 Canada, 5240 Software & systems
Locations: Canada
Author(s): Michael Burns
Author Affiliation: Michael Burns, MBA, CA, is president of 180 Systems (www.180systems.com), which provides independent consulting services, including business process review, system selection and IT audit. Contact 416-485-2200; moc.smetsys081|snrubm#moc.smetsys081|snrubm
Document types: Commentary
Section: Work in process
Publication title: CA Magazine. Toronto: Dec 2007. Vol. 140, Iss. 10; pg. 14, 1 pgs
Source type: Periodical
ISSN: 03176878
ProQuest document ID: 1404584341
Text Word Count 687
Document URL: http://proquest.umi.com.ezproxy.apollolibrary.com/pqdlink?did=1404584341&sid=6&Fmt=3&clientId=13118&RQT=309&VName=PQD

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License