CATS+ Guidance for Writing a TORFP - Business Services

Before starting with the CATS+ TORFP Template, agencies should engage in business need discussions among management, the agency business unit, IT staff, and procurement office. Agencies should gather pertinent documentation, e.g., SDLC documents, agency policies, business procedures, industry information, other agency input, and system documentation. These activities will help generate sufficient documentation of requirements for the TORFP.

Note that Business Services often entail external applications and handling of agency information. Accordingly, the TORFP should include thorough requirements on confidentiality, system security, data security, disaster recovery, and ownership rights. Certain Business Services also may require project management as noted the guidance below. Questions about developing a TORFP may be referred to the DoIT Procurement Office at itpo.doit@maryland.gov.

Below are recommended best practices to help ensure a quality TORFP and timely release. This information is advisory only, some elements may not apply to specific TORFPs.

Requirements Gathering:

  • Identify agency personnel responsible for developing, reviewing and approving requirements
  • Interview key stakeholders from the business unit, IT staff, and procurement office
  • Gather pertinent agency policies and procedures
  • Gather existing system documentation, e.g., O&M manuals, SOPs, manufacturer information, etc.
  • Contact other agencies experienced with vending out the prospective services (benchmarking).

Requirements Checklist (some may not apply to the specific TORFP):

  • Security:
    • Data security
    • System security
    • Disaster recovery
    • Confidentiality
    • Security standards
  • Business / functional requirements
    • Required work processes
    • Products / deliverables
    • Productivity goals
    • Work tracking
    • Use of State hardware / software / materials / facilities
    • Use of TO Contractor hardware / software / materials / facilities
    • Customer support requirements
    • Work policies / procedures
  • Technical / system requirements:
    • Interfaces, e.g., Web, database, user screens
    • Levels of access, e.g., State, TO Contractor, public
    • Availability, e.g., 7 days per week, 98 percent uptime
    • Software applications, e.g., report tools
    • Databases
    • Operating systems
    • Hardware
    • Networks
    • System / application performance goals, e.g., speed, reliability
    • System / application maintenance
    • Accessibility standards, e.g., low-vision users
    • Enterprise Architecture requirements
  • Non-business / non-technical requirements
    • Project management
    • Process management
    • Meetings / conference calls
    • Training
  • Service Level Agreements (SLA) (See Section 2.4.4 below)
  • Consumables / supplies:
    • Purchased by State or TO Contractor
    • Procurement vehicle
    • Volumes
    • Delivery / storage / inventory
    • Waste management, e.g., recycle used paper
  • Ownership of property
    • Hardware / software
    • Materials
    • Intellectual property
  • Performance measurements (See Section 2.6.4 below)
  • Performance problem mitigation (See Section 2.6.5 below)
  • Transition plan ahead of TO expiration
  • Tasks to be performed by the State in conjunction with the TO
  • Documenting Requirements:
    • Divide routine, recurring tasks like daily job runs and data backups from non-routine, non-recurring tasks like software upgrades and small system enhancements (See Section 2.5.1 below)
    • Ensure task descriptions are complete and unambiguous, e.g., instead of “run required jobs” use “run jobs according to the IT Division daily / weekly / monthly processing schedule”
    • Ensure task descriptions allow ways to test, observe, or otherwise verify task completion
    • Allow plenty of lead time for requirements identification and approval
    • Obtain review and approval of requirements from key stakeholders from the business unit, IT operations staff, and procurement office.
  • The TORFP Process:
    • Allow sufficient lead time to replace current services contracts
    • Allow sufficient lead time for internal and external reviews of TORFPs. For planning purposes, assume at least two iterations once the TORFP is submitted to DoIT.
    • Obtain input from key stakeholders on the TORFP scope of work
    • Inform DoIT of new O&M initiatives well in advance