Before starting with the CATS+ TORFP Template, herein referred to as "O&M," agencies should have completed later-phase System Development Life Cycle (SDLC) activities if applicable and engaged in stakeholder discussions with the agency business unit, IT staff, and procurement office. These activities will help generate sufficient documentation of technical, business, and non-technical requirements for system O&M. O&M task orders normally are task based with requirements defined as duties and responsibilities. Questions about developing a TORFP may be referred to the DoIT Procurement Office at central.procurement@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 operations staff, and procurement office
• Gather existing system documentation, e.g., O&M manuals, SOPs, manufacturer information, etc.
  

Requirements Identification:

• Define the knowledge, skills, and experience required to operate, support, and maintain the system
• Identify procedural steps for:

• Routine operations, e.g., jobs processing
• Routine support tasks, e.g., user help
• Routine maintenance, e.g., table refreshes, data back-ups, etc.
• Unique maintenance tasks, e.g., system patches, software / hardware upgrades, etc.

• Define any software or hardware required to support and maintain the system, e.g., development tools
• Define how work tasks will be identified, approved, assigned, and tracked:

• Consider a fixed hours / price structure for routine operations, maintenance and support tasks
• Consider a "work order" process for ad hoc maintenance tasks (See Section 2.6.1 below)
• Allow flexibility and evolution of duties; include a method to approve task changes via mutual agreement with the TO Contractor
• Require the use of a work order tracking application

• Define the criteria for evaluating work performance (See Section 2.6.2 below)
• Determine work schedule requirements, e.g., define normal, weekend, holiday, and emergency work hours.
• Define Service Level Agreements (SLA) for responding to system problems (See Section 2.5.4 below)
• Identify any State-owned hardware, software applications, materials, etc. the TO Contractor may use
• Identify any hardware, software, and materials to be supplied by the TO Contractor, e.g., development tools
• Describe how hardware and software will be purchased if needed for O&M (See Section 2.5.6 below)
• Describe what functions, e.g., initial software testing, the TO Contractor may perform at its facility
• Define non-technical duties, e.g., attending meetings, monthly activity reports, user training, etc.
• Identify the process for mitigating contractor personnel problems (See Section 2.11 below)
• Identify how personnel substitutions will be requested, reviewed, and approved (See Section 2.10 below)
• Identify any deliverables under the TO, e.g. bi-weekly activity reports
• Consider a requirement for initial “knowledge transfer” to the TO Contractor about the system
• Define transition steps for future O&M hand-off to the agency or another contractor
• Define any O&M 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:

• Review and understand the TORFP process.
• Develop a procurement schedule (See Example Procurement Plan)
• Allow sufficient lead time to replace current 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