bg-img11.jpg

FIRM FOOTING

VIEWS & ANALYSIS FROM OUR EXPERTS

Avoid Costly Mistakes: Four Questions You Must Answer Before Purchasing Large Software Systems

Share:

We’ve all heard stories about organizations spending thousands on software projects that take longer than expected and exceed original budgets. One of the reasons this occurs is that organizations often don’t realize that purchasing a large, commercial off-the-shelf (COTS) system is a significant undertaking. If the needs aren’t sufficiently defined, there can be many roadblocks, including implementation delays, increased cost, scope creep, and ultimately, unsatisfactory results (delayed or unfinished projects and cost over runs).

These applications are complex, and implementation affects both internal and external stakeholders. Procurement often requires participation from different departments, each with unique goals and perspectives. Ignore these perspectives at your own peril. Here are key questions to consider for making the best buying decision:

1. Should we purchase software that similar organizations have purchased?
As vendor consolidation has diminished the number of distinct COTS systems available, this question is increasingly common. Following this approach is similar to deciding to buy the car that your neighbor did, because they seem satisfied. How can you be sure that the systems purchased by similar organizations will meet your needs, particularly if your needs are undetermined? One way to identify your organization’s needs — and to avoid costly mistakes down the road — is to identify requirements during the procurement process.

2. What are the functional and non-functional requirements of the system?
Requirements are details that help describe a software system. There are two types of requirements and you need to understand and review both:

  • Functional requirements. These define specific functions of a system to meet day-to-day needs of an organization or department. They describe the necessary system capabilities that allow users to perform their jobs. For example, “The vendor file must provide a minimum of four (4) remit-to addresses”. Functional requirements may also define the mandated state or federal capabilities required of a system, such as the ability to produce W-2 or 1099 forms.

  • Non-functional requirements. These requirements identify criteria used to judge the operation of a system, rather than specific behaviors. They can be technical requirements that define what database the system must support. For example, “The system must support use of the client preferred database”. They may also describe security capabilities of the system, or ease of use and overall end-user interface.

Document requirements for an efficient process

There may be thousands of requirements for a COTS system. To make the procurement process as efficient as possible, continually define and refine requirements. While this takes time and resources, there are clear benefits:

  • Having requirements defined in an RFP helps vendors match the capabilities of their software systems to your organization’s needs and functional expectations. Without requirements, the software procurement and selection process has little framework, and from a vendor perspective becomes a subjective process — making it hard to get consistent information from all vendors.
  • Requirements help determine specific tasks and activities to address during the implementation process. While many applications can’t meet 100% of the requested functionalities, it’s important to emphasize the requirements that are most important to users, to help find the system that best meets the needs of your organization.
  • Requirements prove valuable even after implementation has begun, as they can help you test your system to make sure the software meets your organization’s particular needs before production use of the new system.
3. Who should help define and document requirements?

When it comes to documenting and revising requirements, work with your IT staff; incorporating technology standards into a set of requirements is a best practice. Yet it is also necessary to seek input from non-IT individuals, or business process owners from multiple departments, those who will use and/or be affected by the new software system.

Help these individuals or groups understand the capabilities of modern software systems by having them visit the sites of other organizations, or attend software industry conferences. You should also have them document the current system’s deficiencies. As for those in your organization who want to keep the current system, encourage their buy-in by asking them to highlight the system’s most valuable capabilities. Perspectives from both new system supporters and opponents will help you build the best system.

4. When do you revise requirements?

There are always significant revisions to requirements during the software procurement process — you need them to produce the best results. The same goes for the implementation process and future software enhancements where the vendor may offer many requirement revisions. When should you revise? The best way to approach it is to plan to revise requirements constantly. This enables the software to better meet current needs, and improves future software procurements.

Our experienced consultants have led many software procurement projects and have first-hand knowledge about the challenges and opportunities associated with purchasing and implementing systems large and small. BerryDunn maintains an active database of requirements that we continually enhance, based on work performed for various clients and on technological advancements in the marketplace. Please contact us and we can help you define your requirements for large software system purchases.

Share:

Topics: Management Consulting & Strategy, Healthcare, Medicaid, Senior Living, higher education, Technology & IT Security, Education, - Local Government

Leave a comment

STAY CONNECTED