subject: Myth About Choosing Software Packages [print this page] Myth about Choosing Software Packages Myth about Choosing Software Packages
A software package is a software designed to solve a specific business problem. The application tool market is now fully mature. There is no major problem left that cannot be solved by using a software package.
Nowadays package can be purchased and implemented easily, the IT community, in particular, has become far too reliant on such tools to solve a business problem. Such reliance often sets expectations of what the tool can achieve to dangerously high levels and the tool eventually becomes a silver bullet. From then onwards, IT managers prepared to change the way it operates in order for it to be compatible with the package.
The reliance on software package by development team eager to overcome new technical challenges can often compromise an otherwise healthy project. As a consequence, many IS projects can fail due to the incorrect and an inappropriate use of software tools. This is especially true of a small IT department.
In such circumstances, the scope for in-house IT development may be small. A software development tool is purchased, in the hope that it can be used or customized to support the business. The selection criteria for the tool, however, are likely to have come from the software development team (who may want to gain experience in a new and exciting product) rather than from a combination of business and IT professionals.
The dangers of using software packages
Whilst IS professionals are sometimes accused of knowing what the solution is to a business problem well before any functional requirements have been indentified, based on their knowledge and familiarity with a specific software package, business users must also accept responsibility and accountability for their actions. As budget holders, business stakeholders under pressure to deliver a new system can often be influenced by the latest software fads and look for quick solutions. Many business managers purchase software packages without a clear understanding of what functionality was needed by the business. In many cases, the choice of software package was in direct contravention of the companys IT strategy, and as the package was installed by a third-party vendor, the IT department refused to support it.
The relative ease of purchasing and implementing such packages combined with the lack of budgetary controls means that many organizations are not only buying too many unnecessary software packages, they are also buying too many of the same software packages. Buying the right software package is a huge risk, but with the application of some common-sense principles and effective requirements management, these risks can be minimized. Before buying a package, we need to understand the business requirements.
Evaluating a software package
All business applications, packages and software suites consist of:
.Features;
.Advantages;
.Benefits.
Features are parts of the system that are rarely used. For instance, how many of the features of Microsoft PowerPoint or Excel are actually used on a regular basis? Probably about 20 per cent. Wacky and insignificant features add nothing to the cost/benefit equation, but delay development time and accrue cost. The moral here is to identify the features which will not be used and leave them out.
Advantages are those parts of the tool that make life easier for us maybe they provide a few helpful routines or automation in particular areas. They are nice-to-have and often cost more than the benefit they deliver. They are better than features, but not by much.
In the business case for any IS project, benefits that are tangible, measurable, and repeatable must be identified. Strategically, it is by the realization of benefits that competitive advantage can be gained and maintained within the organization. In the strive to deliver benefits, IS and business managers must be proactive in their assessment of projects and the software tools they use. Benefits come from the early delivery of business requirements, so aim to go live sooner rather than waiting an inordinate time for the extensive functionality to be implemented. Benefits should be measured against initial investment costs, so focus core functionality on the most important business requirements. Twenty percent of software should provide eighty percent of Business value.
Selecting the right software package
If the outcome of the requirements management phase has indentified functionality which may be a software package, it is important to understand the scope of work that can be achieved by using a software package and equality, what cannot be achieved from it. Do not rush out and buy any software before you have fully understood what it is meant to achieve.
Here is smart piece of advice:
.Dont window shop and opt for the best-looking.
.Do evaluate software packages against your critical functional priorities.
.Dont evaluate too many you will not have the time.
.Dont class all your requirements as must-haves you will end up performing unnecessary customization.
.Give suppliers a hard time in making sure the package meets your requirements sales persons deliberately avoid information about the need of customization.
.Agree your package selection criteria and use it to asses each package uniformly otherwise accurate comparison will not be possible.
.Choose your own reference sites.
.Do not judge the software purely on the in-house demo. Make sure the supplier tailors the demo to meet your needs.
.Do assess the supplier as well as the package. How strong are their finances? Do they understand your business and the sector within which you operate? How good is their technical support?
.Be fair. Do not expect a 100 per cent fit but do ensure that the critical requirements can be met.
.Do negotiate on price, including ongoing support and training costs.
.Do take legal advice before signing the contract.
Critical success factors in Requirement management:
.All stakeholders are involved throughout the requirements management process.
.Always prioritize requirements against the need to satisfy the stated business objectives.
.Do not undertake and key development activates until a requirements specification has been produced and agreed with all the stakeholders.
.Use whatever tools and techniques are necessary to ensure the requirements are understood by both customer and supplier.
.Validate all requirements and assess their impact on the project before approving them.
