8.8 Analyzing and planning the IT procurement

Normally, the agency's business owner (i.e., project manager) and a team of technical subject matter experts will prepare the requirements definition, but procurement officials will want to ensure that the requirements have been well-planned and are adequate to define the procurement details in the scope statement and statement of work (refer to chapter 12, Statements of Work for IT Procurements). The solicitation's scope and/or statement of work will reflect the results of the requirements definition, analysis and planning. Below is a table that offers various high-level questions that a project team may need to consider when identifying and planning the project's requirements. The table below provides a generic tool. More detailed guidance consistent with VITA's technology program directives may be found at the following website: PM Templates & Tools.

1

What are the project's primary objectives/ goals?

Determine the high-level goals of the procurement including all technical, functional, performance, performance or service-level expectations, schedule, user and customer audience objectives. Include services, hardware, software and licensing requirements. Consider modular or phased projects to accommodate your schedule/budget. Discuss long-term goals or life expectancy of the system/project.

2

What are the project's secondary objectives/ goals?

Determine the mid- and lower-level objectives for technical, functional, performance, performance or service-level expectations, schedule, user and customer audience elements of the procurement. Include services, hardware, software and licensing requirements.

3

What does the project need least?

Be honest in evaluating all unnecessary elements in this procurement, possibly removing results of questions 1 and 2 and moving them to question 12.

4

What is the current environment?

Prepare textual and graphic descriptions of the current technical and user environment, including personnel, other programs, agencies/entities and services affected.

5

What dependencies exist or may evolve?

Provide detail of other internal and external networks, servers, applications and/or systems, interfaces and legacy systems that will be affected by this procurement, including other agencies/entities/users and the VITA Partnership.

6

Is this procurement consistent with agency-specific and the Commonwealth's strategic planning?

Identify any direct or potential conflicts this procurement may create with your own agency's or the Commonwealth's short-term or long-term enterprise strategies or other objectives. Contact your current AITR for assistance with this question.

7

What can be done in-house?

Re-visit questions 1 and 2 and match current staff or roles to the detailed objectives.

8

What does the agency need to procure from external sources?

Answers should include all hardware, software (COTS and/or newly developed), support services, implementation, design, interface development, training, maintenance, etc. Be sure to conduct a search of existing statewide contracts that may serve some or all of these needs: (https://vita.cobblestonesystems.com/public/).

9

What is the budget?

Define the project's definite and projected budget sources and timing. Include budget sources for out-year support and maintenance and any phased procurement activity, and/or federal funding.

10

What is the in-house estimate?

Developing a work breakdown structure to use as the basis of your estimate is recommended, as this could parlay into the requirements and/or statement of work portions of the procurement documentation (i.e., solicitation and contract). This approach also helps to ensure that all details of the project's life cycle are considered and may offer justification during proposal evaluations.

11

What is the schedule?

Identify any hard and soft project schedule dates—overall and milestone events to use for any technical dependency concerns and for budget expenditure (and supplier payment) planning.

12

What can we put off buying?

Move answers from question 3 here. Include optional purchases for a next phase acquisition, if appropriate, and possible out-year support and maintenance depending on budget constraints.

13

What are our risks?

Brainstorm and identify all risks that could potentially affect the technical, functional and performance requirements including, installation, implementation, existing or relational applications/systems/user environments, interface development, production, testing, roll-out; budget and financial; schedule; licensing restrictions, etc. Apply mitigation resolutions when possible that could affect your agency, supplier and/or other third-party agencies/agents.

14

What specifications and standards must apply?

Create a document that lists names, numbers, version, etc., and provide links, if available, of all agency-specific, Commonwealth, VITA and/or federal, if federal grants apply, specifications and standards that are required for proper contract performance for all solutions, services and/or products being procured.

The requirements analysis should begin with an agency's business or organizational requirements and those requirements should translate into project requirements included in the solicitation. If meeting the stated requirements will be unreasonably costly or take too long, the requirements may have to be negotiated down, down-scoped or down-sized, through discussions with SMEs, customers or users. The requirements analysis should cover the whole scope of the project. It must be comprehensive and thorough and must consider the views and needs of all the project stakeholders.