Your COTS Project Requirements

This week, we continue with this guide to Assessing Your Agency’s Readiness for a COTS Solution by defining your core project requirements including business, data conversion, system interface, technical, hardware/infrastructure, and training/system documentation requirements.

 

Your Business Requirements

 

Different groups of users may require different user interface presentations (e.g., browser-based desktop applications, or standalone occasionally-connected mobile applications, or native smartphone-oriented computing) to complete a workflow (i.e., a business process). POSSE technology offers product modules that support these various presentations. Please indicate your end user interface platform preferences for your primary users groups.

 

A POSSE end user application usually incorporates “operational reports” such as receipts, letters, permit and license documents, inspection summaries, and certificates that may be printed and given to the customer at some point in the workflow. Reports to track performance, collect statistical information, and observe trends are typically required. Through vendor-provided training, these types of reports can be generated by in-house staff. If the requirement is for the vendor to provide these reports however, then properly identifying the quantity and complexity (low, medium, high) along with provision of appropriate samples (where availabile) will assist vendors to accurately estimate development costs.

 

A list of current or desired business processes (preferably documented as Use Cases) and samples of current input and output forms such as application forms, permits, licenses, receipts, etc., are extremely useful for estimating the required effort and scope of the client’s POSSE system configuration.

 

Specific business requirements are often described in a table format in an RFP as “Functional Requirements.” For best results, assign a priority for each requirement (Mandatory, Desirable) using such verbiage as “The proposed System will include…” rather than “The proposed software is capable of …” to indicate your clear expectation that the related cost should be included with the vendor’s price quote.

 

Your Data Conversion Requirements

 

In order to best mitigate project costs, Computronix recommends sharing the data conversion responsibility. Based on our extensive experience, we recommend that the client’s IT staff hold responsibility for the following conversion tasks:

  • Map legacy data back to legacy objects and screens, if required, in order to help us understand how to translate data into the POSSE object model.
  • Extract legacy data into a flat file format in preparation for loading.
  • Review, “scrub,” and/or reload any non-conforming data.

 

In our experience, it makes the most sense for the vendor to provide the following services:”

  • Provide data conversion training and mentoring.
  • Design and map data to the proposed object model.
  • Create and test load scripts.
  • Load data.

 

As pre-requisites for assessing data conversion requirements, it’s important to understand where legacy data resides, the extent to which client resources will be provided to assist with the conversion, and the client’s timelines for decommissioning legacy systems.

 

Your System Interface Requirements

 

Usually addressed in an RFP Appendix table or grid structure, system interface requirements may include the following:

  • Standards, extent of use of web services and/or messaging hubs; overview of enterprise architecture and SOA vision.
  • Description of each interface and performance required. Is the interface one-way or two- way, real-time, read-write, or batch overnight?
  • Platforms and specifications of external systems.
  • Any existing interfacing tools, such as gateways, and any specialized backend and/or third- party performance tools that may be available for use.

Your Technical Requirements

 

Usually addressed in an RFP Appendix table or grid structure, requirements may include the following:

  • Current workstation and server platforms and specifications and any planned or anticipated upgrades. Any mandatory requirements?
  • Current database preferences platforms and specifications. Any mandatory requirements?
  • Current infrastructure, networking, and protocols used. Any mandatory requirements?
  • Current Internet (and/or corporate website) architecture, security, and standards; content management systems and approaches?
  • Is there VPN or remote database access availability for the selected vendor?
  • What are the anticipated or required system features for each group of business users?
    • What features do inspectors need?
    • Front counter staff?
    • Cashiers?
    • Plans examiners?
    • Notification clerks?
    • Management?
    • External Internet-based users?
  • Is each feature mandatory or desirable?
    • What are the common functions required?
    • Which GUI presentation is desired for each group of users (browser, mobile/smartphone)?
  • Individual, specific technical requirements are often described in a table format in an RFP as “Technical Requirements.”
    • Please assign a priority weighting to each requirement (Mandatory, Desirable) and use such verbiage as “The proposed System will include…” rather than “The proposed software is capable of …” to indicate your expectation that the related cost should be included with the vendor’s price quote.

Your Hardware/Infrastructure Requirements

 

Usually addressed in a RFP Appendix table or grid structure, the details that need to be examined include the following:

  • Workstation specifications, both minimum and recommended.
  • Acceptable database, operating system, web server, and browser platforms.
  • Database and file server specifications.
  • Specifications for existing mobile/remote devices such as tablets, and smartphones.
  • Network architecture details.
  • Any data encryption requirements for remote computing and/or hosting.
  • Corporate standards for hosted or software-as-a-service (SaaS) solutions.
  • Any other mandatory corporate IT standards not previously identified.

Your Training and System Documentation Requirements


Please indicate your system documentation needs, and training needs/expectations for internal end users (staff), for internal super users (project team members, Subject Matter Experts, designated User Acceptance Testing team members, security administrators, system support and network administrators), as well as for external Internet users (customers, citizens).

 

Historically, a Train-the-Trainer approach offers the best balance of cost-effective knowledge transfer, i.e., training a small number of designated trainers in your organization (up to 8 people) in POSSE usage as configured for your organization. This site-specific usage training is supplemented with our standard System Administration and Support training and optional Dashboard and Ad-Hoc Report writing training.

 

The development of site-specific training materials and delivery of end user training based on the business applications configured for your organization can be provided by your end user trainers in order to control costs. If the preference is to have the vendor complete this work, it should be identified in the RFP, and proposals should be checked to ensure that the vendor deploys qualified and dedicated trainers who work with the project team in the preparation of tailored training materials. Computronix provides certified POSSE trainers from our Education Services division. Ask the vendor to identify training options (example: role-based training for super users, report writers, configuration technicians, developers) to choose from that can increase the organization’s ability to self-manage the application.

 

NEXT WEEK: Understanding your preferred implementation approach.