CONCEPT DEVELOPMENT

Step 1: Concept Development

In Step 1, the predominate IPMC process group is Planning. (See Appendix B for a detailed discussion of the Planning process group.) During Concept Development, the project manager accomplishes the detailed planning to prepare for project execution. It is here that the project manager develops the project management plan, including the project Work Breakdown Structure (WBS) that communicates the specifics of the project scope and the requirements of the product or service that the project will produce. With an understanding of the project scope the team prepares the project master schedule and time phased budget that become the basis for project performance measurement (such as earned value management). During the concept development phase processes are put in place that will insure close control over the project scope, schedule and budget. Other processes are initiated to identify and assess project risks and insure product quality. Specific strategies are developed for the acquisition of project labor and materials.

It is during this phase that the project manager or project sponsor ensures senior officer and business owner approval of the project scope, schedule, budget, risks, acquisition strategy, and product requirements. A best practice is to have the appropriate senior officer(s) and business owner actually sign the Project Management Plan and subordinate plans that contain the above information.

Important distinctions exist between Step 1 Concept Development tasks and the tasks required to prepare and communicate information for the Exhibit 300 process (See Appendix D for a more detailed discussion of the Exhibit 300). The major distinction is that the Step 1 Concept Development process is goal driven, with milestones being reached after intermediate project goals are achieved; while the Exhibit 300 process is an annual process, requiring actions throughout the year to meet OMB submission dates. In the Step 1 Concept Development phase the project plans are created to control the project. This is also the period of time when the groundwork is laid for Exhibit 300 reporting by entering the project planning data into the project management software.

Milestone I: Prototype Development Approval

The Milestone I review is intended to have the Project Manager address areas necessary to warrant approving the commitment of resources to a prototype or pilot effort. At Milestone I, the PM demonstrates a well-founded business case for the effort. Prototype efforts are encouraged within VA, as a general principle, in order to speed time to market and to increase the likelihood that the delivered product will fit the end users’ true needs. For certain projects, the project requirements and maturity of the technology will have already been established. In these cases, the project may proceed to a combined Milestone I/II review.

Milestone I includes development of the Exhibit 300, either a “Planning Application” or a “Full Acquisition”. The applications can be combined depending on whether preliminary funding or full funding is being requested.

If preliminary funding for project development is needed, a preliminary Exhibit 300, the “Planning Application” should be prepared. The “Planning Application” will be reviewed by the Office of Information and Technology (technical review), the EIB Panel (strategic and financial review), the EIB, and the SMC (if required) for approval and funding.

If full funding is needed for the upcoming budget year a complete Exhibit 300 “Full Acquisition” should be prepared. The Exhibit 300 will be reviewed by the Office of Information and Technology (technical review), the EIB Panel (strategic and financial review), the EIB, and the SMC (if required) for approval and funding.

Planning Application (Exhibit 300) for Preliminary Funding: The Planning Application further defines this concept. It also includes a high-level evaluation of alternatives for an IT solution. The document should address functional, security, performance, and reliability requirements, concept of operations, high-level use cases, business case, technical approach, acquisition, testing and fielding strategy, training and documentation requirements, schedule, staffing, and skills requirements. Comparisons of alternative concept solutions normally result in identification of the most promising system concept. The Exhibit 300 also needs to include Return-on-Investment and Cost Benefits analysis estimates.

If the project is approved, preliminary funding will be provided and the project will be included in the budget request. The, Full Acquisition Exhibit 300, will be required for the project by the following summer, before the budget year for which it is funded begins. This should document in more detail the scope, schedule, cost resource requirements, test strategy, risk profile and mitigation plan, project organization and staffing, operational support strategy, detailed life-cycle cost, and detailed business case. OMB Circular A-11, Part VII, Section 300 provides full instructions for this document.

Concept Development for Full Funding: If full funding is needed for the upcoming budget year a complete Exhibit 300 (“Full Acquisition”) should be prepared. At Milestone I, additional documentation (in addition to the information from Milestone 0) is required that supports Exhibit 300, such as:

In addition, the project may need to be presented to the administration if required.

IT Security

4.3.1 System Security Plan (SSP). The SSP documents the security risks (not project risks) and overall system security categorization in terms of potential level of impact (Low, Moderate, High) for each of the security objectives of confidentiality, integrity, and availability of federal information and information systems. The plan documents the security processes that will be implemented and tested in the Security Controls Assessment (SCA) plan. The SCA plan is the basis for System Certification and Accreditation and acceptance of residual security risk. The System Security Plan includes the following components:

4.3.3 Contingency and Disaster Recovery Approach – Prepare an approach for responding to man-made or natural incidents or disasters.

4.3.4 Federal Information Security Management Act (FISMA) Self-Assessment and Plan of Action and Milestones (POA&M). FISMA requires the completion of an annual self-assessment to identify security deficiencies. Many organizations have an automated tool to facilitate completion of the survey and tracking of deficiencies in the form of P0A&M that are submitted to OMB quarterly. OMB guidance also requires POA&Ms to be addressed by system owners/program managers in order to obtain a security score of 4 in the Exhibit 300 process.

4.3.5 Preliminary Security Risk Assessment. The basic assessment of the confidentiality, integrity, and availability risks that help determine what security controls are necessary to protect the information contained in this information system. Completing the FISMA self-assessment constitutes a preliminary risk assessment.

See Appendix I for Federal and VA-specific guidance on IT Security deliverables for this stage.

Privacy Impact Assessment

The E-Government Act of 2001 (E-Gov) requires a Privacy Impact Assessment (PIA) to be conducted for any new information collections. Primarily, the PIA formalizes and documents how private data is to be protected. It must describe:

The PIA is to be initiated in the early stages of system development and completed as part of the required System Development Life Cycle reviews. Privacy must be considered when requirements are analyzed and decisions are made about data usage and system design.

Details on the PIA, its privacy principles, and steps for completing one can be found at: http://www.cio.gov/documents/pia_for_it_irs_model.pdf

One Enterprise Architecture

From the perspective of the One- EA, at Milestone I PMs are expected to focus on the information relevant to their project in row 2 of the One EA Zachman Framework. This information is described in Chapter 4 of version 2.1 of the One Enterprise Architecture. Chapter 4 defines the functionally of information systems in terms of their target processes, functions and sub functions, data, and their integration points with other information systems both inside and outside the enterprise.

IT Operations Considerations

Projects that will involve organizational telecommunications and operations infrastructure should consider the following questions leading up to Milestone I:

Network Capacity Planning:

Step 1: Significant Project Management Activities

The following is a summary listing of the significant project management activities and outputs for Step 1.

Step 1: Responsibility Assignment Matrix

The Responsibility Assignment Matrix below is provided as a “best practices” tool that the PM can adapt and fill out for the appropriate tasks and responsibilities of his or her project. For additional guidance, the PM should refer to the appendices of this guide and consult his or her Administration or Staff Office PMO.