Your Reasons for Software System Change

This week, we continue with this guide to Assessing Your Agency’s Readiness for a COTS Solution with further examination of the process to Prepare Your RFP Package by defining your fundamental reasons for software system change and your critical success factors. 

To start, it’s beneficial to provide a description to assist vendors in understanding the “pain” factors that exist in your organization and how they are drivers for finding a new software solution.

Business and organizational pain is often growth driven. In such cases, a forecast of growth rates or a description of anticipated system scalability is valuable. Pain may also be driven by the need to replace outdated or unsupported technology. In such cases, vendors have a need to understand any critical timelines or dates for crossover to the new system as well as the expected life of the new software solution. To assist in this, it is vitally important to define all the factors that are demanding that your organization spend time and money on a new system.

Yours steps to define these factors should focus on the following efforts:

• Document reference to any needs assessment or feasibility studies that may have taken place to help identify root problems and causes your organization may be experiencing. Supply proposed problem solution strategies and identity the internal staff teams or external consultants who may have led these exercises.
  
  
• Provide any specific requirements to accomplish business process re-engineering and/or organizational change management/organization re-design that may be part of the project.
  
  
• Buy vs. Build – The overwhelming majority of RFPs issued in the market today indicate a clear preference for flexible and configurable COTS solutions like POSSE for a variety of reasons including lower costs, quicker deployment timeframes, pre-configured domain-specific templates, ease of self-management, incorporation of enhancements and product upgrades over time, documentation, training, ongoing support, etc. If your RFP will accept a Custom Application Development as a solution option, it’s important to understand what reasons are driving this choice? If your RFP invites both COTS and custom-build applications, clearly state your organization’s preference for one or the other.
  
  
• Are there any mandated timelines or other implementation-related drivers for achieving “go- live” of the new system, resolving existing problems, or meeting promised commitments made by your organization? Are there political and/or budget cycle motivators that impact implementation of the system?
  
  
• If possible, provide the budget or the budget range for the project. Vendors use this information to determine potential fit between client expectations and historical costs of delivering a solution based on their product set. This information is key in determining whether to proceed with the investment of time and resources required to prepare an RFP response. It is also helpful to know whether budget approval has been provided and/or whether funds have been secured. Also helpful are any plans to spread system acquisition and implementation costs over multiple years, or in several phases, in order to align with budget commitments and constraints.
  
  
• Are your organization’s expectations realistic when functional scope, budget, and timelines are considered?
  
  

Your Critical Success Factors

The above information provides vendors with a sense of what the priorities are in your organization, how your organization is likely to evaluate proposed software solutions, and how your organization could determine its own level of readiness for a POSSE implementation. It is important to understand how your organization will define project “success” so that deliverables can be measured and the project team maintains accountability to the project plan.

In our experience, an average-sized regulatory software system can be implemented within 12 to 18 months. Larger implementations may be phased into two or three smaller projects of similar duration. With these timelines in mind, it’s important to indicate any mandatory or drop-dead timelines for project start, system “go live” and project conclusion.

NEXT WEEK: The process to fully define your business requirements.