The Initiation Phase begins when agency management determines that a business process requires enhancement through an agency information technology (IT) project and investment in the application of IT assets. Enhancements or changes to business processes may be prompted by business process improvement activities, changes in business functions, IT advancements, and/or external sources, such as changes in public law or federal statutes.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Initiation Phase should comprise:

• Establishment of project sponsorship
• Development of the Concept Proposal and Project Charter
• Identification of the Project Manager
• Formation of the Planning Team
• Identification and initial analysis of the business improvement(s)
• Approval to progress to the Concept Development Phase 

Goals

The purpose of the Initiation Phase is to start the project.

Back To Top

2.0 Deliverables and Approvals

System Development Life Cycle (SDLC) deliverables help State agencies successfully plan, execute, and control agency IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC document templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content. 

The development and distribution of SDLC deliverables:

• Ensure common understanding among Planning Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

During the development of documentation, the Planning Team should:

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Planning Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present.  The length of deliverables may vary depending on the size, scope, and complexity of the project.  
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should initially be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.

Department of Information Technology (DoIT) will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities of this phase: 

• Executive Sponsor
• Project Sponsor
• Agency CIO
• Business Owner
• Project Manager
• Project Stakeholders  

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

Personnel within the agency identify a need for a project.

4.2 Begin Initiation Activities.

The project begins with the following tasks:

• Investigation of sponsorship options
• Identification of Initiation Phase participants

4.3 Establish Project Sponsorship.

The Executive Sponsor, Agency CIO, and Business Owner appoint a senior manager to be the Project Sponsor, who will champion the project effort.  The Project Sponsor is the principle authority on matters regarding the expression of business needs, the interpretation of functional requirements language, and the mediation of issues regarding the priority, scope, and domain of the business requirement.  The Project Sponsor must understand what constitutes the project’s scope and be accountable for project success.  For some agencies, the Executive Sponsor may also serve as the Project Sponsor.

Select a Project Sponsor with the following skills:

• Sufficient domain and managerial experience
• Interest in the project
• Capacity to attend to the project
• Political acumen to assist the team in solving problems and removing roadblocks to progress

4.4 Develop the Concept Proposal.

The Project Sponsor develops the Concept Proposal.  The Executive Sponsor and CIO approve its final draft.

4.4.1 Document Description

The Concept Proposal achieves these goals:

• Investigate and document information about the project request
• Highlight unmet strategic goals
• Identify needed agency mission performance improvements
• Obtain commitment to the project from key stakeholders, principally external stakeholders
• Avoid identifying specific vendors or products as solutions

4.4.2 Typical Content

The key elements of the Concept Proposal are specified below. Please note that additional descriptions are included when necessary to provide additional clarification regarding content to be specified in the document.  Additional guidance is provided in the SDLC template.

• Title of Investment – a working name for the project
• Business Owner and Authorization Signatures
• Date
• Description of Proposed Investment – a brief description of the investment proposed (e.g., a software development effort, a modernization of a current system, purchase of commercial-off-the-shelf (COTS) software, an integration effort, operations and maintenance strategies, etc.), and an initial discussion of requirements needed for ongoing Systems Team operations and maintenance support. Describe the type of project, if it qualifies as a Major IT Development Project (MITDP), and if it is cross cutting.  For additional guidance regarding the definition of these terms, review the IT Project Request (ITPR) guidelines and instructions.
• Mission Goals – the appropriate agency Managing for Results (MFR) goals
• Performance Gaps – an evaluation and description of the current state of the agency and the current business and technical performance gaps to be addressed by the project
• IT Architecture – a high-level description of how the proposed project will impact the existing agency technical environment (e.g., describe how the proposed project is envisioned to be incorporated into the existing agency architecture)
• IT Strategic Plans – how the proposed project relates to the agency’s strategic IT plans
• Anticipated Benefits – benefits that will accrue by implementing this project and detailed identification of the stakeholders, internal and external, who will be affected
• Investment Business Case – how the proposed investment is expected to support agency mission functions, a justification for the proposed investment (e.g., the investment supports simplified or redesigned work processes, reduces costs, or improves effectiveness), the magnitude and importance of the investment in relation to those goals, a discussion of the timing of the investment, and an assessment of whether other governmental agencies or State components are impacted
• Rough Order of Magnitude Funding Request – a rough order of magnitude estimate for the total acquisition costs and identification of the projected funding source for the investment throughout its life cycle 

4.4.3 Guidance for Document Development

The Concept Proposal should be no more than two to five pages.  The Concept Proposal establishes the justification for the project and the rationale for a funding request.  A persuasive Concept Proposal establishes a strong foundation for the project request as it moves through the funding cycle.

4.4.4 Dos and Don’ts

To meet funding cycle requirements, conduct Initiation Phase tasks and complete the deliverables before or during the summer months to be prepared for Concept Development ITPR tasks, which are due no later than mid-September.

4.5 Identify the Project Manager.

The Project Sponsor chooses the Project Manager, who carries the responsibility and accountability for project execution. Agencies are encouraged to appoint certified Project Management Professionals (PMP) as project managers because PMPs have specific training in project management methods, share a common lexicon, and have competency in the State project management standards.  For small efforts, the agency may assign a new project to a manager within an existing organization with an inherent support structure.  Agencies with limited Project Manager availability should consider developing an early procurement to secure a dedicated Project Manager.  It is critical that this Project Manager be an advocate of the State agency and be completely independent of the future implementation vendor Project Manager.  Maintaining this independence of the Project Manager role will ensure objective project performance reporting.

4.6 Form Planning Team.

With input from the Project Sponsor, the Project Manager designates members of the Planning Team.  For new major projects, hiring and reassignment of many technical and business specialists may be required.  Ideally the Planning Team is maintained as the project working unit at least through the Requirements Analysis Phase.

Although specific needs may vary by project, typical planning teams comprise a Project Manager, Business Analysts, Systems Analysts, Technical Leads, Business Leads, Project Sponsor, Steering Committee, and Project Stakeholders.

Develop a preliminary Planning Team organization chart, illustrating key personnel on the project and identifying relationships between team members.

4.7 Develop Project Charter.

The Project Manager writes the Project Charter with input from the Agency CIO and Project Sponsor.  The Agency CIO, Project Sponsor, and Executive Sponsor authorize the Project Charter’s contents.

4.7.1 Document Description

The Project Charter formally authorizes work to begin on the project, links the project to ongoing work in the agency, and establishes the framework of an agreement between the Project Sponsor requesting the project and the Planning Team proposed to deliver it.

4.7.2 Typical Content

The key elements of a Project Charter are included below. Please note that additional descriptions are included when necessary to provide additional clarification regarding content to be specified in the document.  Additional guidance is provided in the Template/Waterfall.

• Project purpose and justification
• Measurable project objectives and related success criteria
• High-level requirements
• High-level project description and project characteristics
• Preliminary risk statement
• Summary milestone schedule
• Project governance requirements (i.e., describe how the project will be managed and overseen, what constitutes project success, who decides the project is successful, and who signs off on project progress, changes, and completion)
• Assigned Project Manager
• Project Manager scope of responsibilities and formal authorization to carry them out
• Name and authority (signature) of Project Sponsor

4.7.3 Guidance for Document Development

The Project Charter establishes the baseline for documenting and tracing the achievement of a project’s objectives.  It is important that agencies spend sufficient time on clearly defining measureable objectives and success criteria.  The business requirements must also be defined clearly for requirements development in subsequent phases.

4.7.4 Dos and Don’ts

Ensure that the Project Charter identifies only one Project Sponsor.

4.8 Perform Phase-Closure Activities.

The Project Manager and the Planning Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other stakeholders after completing all Initiation Phase tasks. This review addresses:

• Status of Initiation Phase activities
• Planning status for the Concept Development Phase
• Status on resource availability
• “Go-No Go” decision made to proceed to next phase, based on Initiation Phase information

Back To Top

5.0 Conclusions

The completion of the draft organization chart, the approval of the Concept Proposal and Project Charter, the completion of the Initiation project status review, and the approval to proceed to the next phase, signify the end of the Initiation Phase.

​ ​​​​​​​​​​

The Concept Development Phase may begin after the approval of the Concept Proposal and Project Charter, the completion of the Initiation project status review, and the approval to proceed to the Concept Development Phase. The focus of the phase is two-fold: 1) evaluate feasibility of alternatives and 2) clearly define and approve project scope, including the system, all deliverables, and all required activities.  The Concept Development Phase activities are inputs into the development of the ITPR, which is a required output of this phase.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Concept Development Phase should comprise:

• Analysis of the business need
• Definition of project scope
• Evaluation of technical alternatives
• Formation of the project acquisition strategy
• Baseline analysis of risks
• Approval of project costs and obtaining of current fiscal year funding
• Definition of planning roles and responsibilities
• Development of the initial Work Breakdown Structure
• Development of the ITPR
• Determination of project viability
• Detailed analysis and investigation of project details to further define the project scope
• Approval to progress to the Planning Phase

Goals

The purpose of the Concept Development Phase is to define the project scope and prepare formal funding requests.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content. 

The development and distribution of SDLC deliverables:

• Ensures common understanding among Planning Team and project stakeholders,
• Serves as a reminder of specified plans as projects become increasingly complex,
• Provides Agency senior management and other State officials insight into project risks and ongoing performance,
• Encourages the execution of repeatable and consistent processes,
• Facilitates the implementation of project management and IT best practices, and
• Results in a comprehensive record of project performance useful for many purposes (staff knowledge transfer, budgetary and other assessment activities, lessons learned).

During the development of the documentation, the Planning Team should:

• Write project documentation that is comprehensive and easy to understand with no redundant information.
• Develop an organized document repository for critical project information so that the Planning Team can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; however, agencies might accept deliverables in different formats as long as the required information is provided. The content of deliverables may vary depending on the size, scope, and complexity of the corresponding system.
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be initially developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.

DoIT will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities of this phase:

• Secretary of DoIT
• Agency CIO
• Agency CFO
• Executive Sponsor
• Project Sponsor
• Project Manager
• Planning Team
• Project Stakeholders

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The Project Manager ensures the following prerequisites for this phase are complete:

• A business need for the project exists.
• The Initiation Phase was successfully completed.
• The Project Charter and the Concept Proposal were developed and approved.

4.2 Analyze the Alternatives.

The Planning Team analyzes all feasible technical, business process, and commercial alternatives for meeting the business need.  The results of this analysis should show a range of feasible alternatives based on life cycle cost, benefits, technical capability, operational feasibility, and scheduled availability.  Typically, this analysis should narrow the system technical approaches to only a few potential, desirable solutions that should proceed into the subsequent life cycle phases.  The results of this analysis should be documented in the PSS.

4.3 Study and Analyze Preliminary Risks.

The Project Manager performs a high-level analysis of early project risks to complete the PSS; this analysis is not to be confused with development of the project Risk Management Plan in the Planning Phase. The results of this analysis should be documented in the PSS.

4.4 Develop the Project Scope Statement.

The Project Manager with the Project Sponsor, supported by the Agency CIO, CFO, and Executive Sponsor, prepare the PSS, which replaces the System Boundary Document.  

4.4.1 Document Description

The PSS establishes a common understanding of project scope among project stakeholders and describes the project’s major objectives.  The end users’ technology representatives define the technical requirements.  Planning Teams should begin with the business objectives, goals, and high-level requirements identified in the Project Charter and expand upon them to ensure that all requirement types are addressed.  The team will further define these high-level requirements in the Requirements Analysis Phase.

4.4.2 Typical Content

Key elements of a PSS are included below.  Please note that additional descriptions are included when necessary to provide clarification regarding content to be specified in the document. 

• Objectives – measurable success criteria, such as cost, schedule, quality, or technical objectives
• Scope Description – the result of the project’s effort, which may include an assessment of how the proposed project will be incorporated into the agency framework
• Functional and Technical Requirements – known high-level conditions or capabilities that must be met including core non-functional requirements related to platforms, enterprise architecture requirements, interface definitions, disaster recovery standards, security, availability, scalability, latency, throughput, usability and maintainability.  Planning Teams should begin with the high-level requirements identified in the Project Charter and expand upon them to ensure that all requirement types are addressed.  The team will further define these high-level requirements in the Requirements Analysis Phase.
• Boundaries – what is included and excluded within the project
• Data Migration Strategy – high-level strategy for migrating legacy data/information to new system
• Deliverables – all outputs and deliverables from the project including, but not limited to, SDLC deliverables, systems documentation and project management artifacts. This information should be organized by SDLC phase.
• Acceptance Criteria – unambiguous and measurable processes and conditions for review and acceptance of the proposed deliverables. This information should be organized by SDLC phase.
• Constraints – limitations to team and development options
• Assumptions – specific assumptions and potential impacts of those assumptions if false
• Alternatives Analysis – Alternatives analysis evaluation criteria, proposed alternatives, results of alternatives analysis evaluation, and description of recommended alternative program
• Cost-Benefit Analysis – Identification of costs and benefits of alternatives
• Risks – initial known risks of the project
• Schedule Milestones – known schedule requirements and constraints
• Fund Limitation – funding limitations, if any, and timing of limitations
• Cost Estimates – Estimate of the total project cost and a statement of the general accuracy of the estimate (Rough Order of Magnitude (ROM), etc.) Hidden costs, such as Independent Verification and Validation (IV&V) expenses, long-term operations and maintenance costs, upgrades, support contracts, costs of certified developers, and integration costs should all be considered.  The information included here should be consistent with cost estimates in the ITPR or a refinement of the spending plan in the ITPR.  Care should be taken to ensure that costs are categorized by SDLC phase in a manner that allows for consistency with reporting needs of DoIT oversight. 
• Standards – specifications documents with which the project must comply

4.4.3 Guidance for Document Development

The Project Management Body of Knowledge (PMBOK), describes PSS development in detail.

4.4.4 Dos and Don’ts

• Do attempt to define the full scope of the system including legacy system interfaces.
• Do spend time clearly defining acceptance criteria for project deliverables. 
• Don’t limit scope definition to the scope of the system alone.  The PSS must address the scope of all project deliverables.

4.5 Form the Project Acquisition Strategy.

The Planning Team decides the best contract type for the project – fixed-price (FP) or time and materials (T&M) – and reviews recommendations with the Agency CIO, Project Sponsor, and Executive Sponsor.  DoIT policy encourages agencies to utilize FP and fixed scope contracts whenever practical to mitigate the risk of project cost overruns.  An optional T&M component to a FP contract addresses potential change orders. 

Benefits and Limitations of Contract Types

Agencies are strongly encouraged to consider utilizing established master contracts as part of their acquisition strategy.  More information regarding State master contracts may be found on the DoIT website.

The Planning Team must document the project acquisition strategy in the ITPR described later in this document.  Refer to the DoIT website to learn more about relevant acquisition procedures.

4.6 Create Initial Work Breakdown Structure.

The Project Manager develops a preliminary Work Breakdown Structure (WBS) and a WBS Dictionary to define all project activities from planning to implementation.  Although a detailed WBS is completed during the Planning Phase, preliminary planning of project activities is necessary during the Concept Development Phase in order to estimate associated resources and costs to perform the work.  Preliminary activity definition will begin in the Concept Development Phase and further refined during the Planning Phase to ensure that all activities are defined in detail.  The WBS will identify all of the specific work activities that need to be performed to complete the project.  A WBS is a deliverables-oriented, hierarchical decomposition of the work needed to accomplish the project objectives and create the required deliverables.  The document identifies, organizes, and defines the total scope of the project.  A basic WBS is below:

A WBS Dictionary provides more detailed descriptions of the work identified in the WBS. 

4.7 Estimate Project Staffing and Resources.

The Planning Team estimates the staffing and resource support necessary for the project by assessing each WBS activity and its labor, equipment, and material requirements.  The Project Manager documents these estimates in a project staffing estimate, a precursor to the Planning Phase Staffing Management Plan.

4.8 Estimate Project Funding.

Based on the planned WBS activities and estimated resources to perform the work, the Planning Team estimates the total cost of the project in a logical and structured way to obtain sufficient project funding. Cost estimating methods include analogous estimating, resource cost rate estimating, bottom-up estimating, function point analysis, and parametric estimating. Cost estimates may be created using tools such as Microsoft Project, COnstructive COst Model II (COCOMO II), REVIC, and Costar. Some specialized areas of cost estimating typically overlooked during concept development include costs for hardware upgrades, security assessments, certification & accreditation (C&A) reviews, disaster recovery activities, and IV&V assessments. All Planning Teams should ensure that their cost basis is as complete as possible to avoid future funding gaps. Given the information known about the project at this point, all estimates are still considered preliminary.

When organizing costing information, Planning Teams should review ITPR and ITMP reporting formats to ensure easy financial reporting of cost data.  Cost information must be organized and identified by SDLC Phase. Cost estimating includes identification and consideration of various costing alternatives, so prior estimating experience is essential to obtain accurate cost estimates. If the Planning Team lacks experience in estimating project costs, consider outside assistance.

4.9 Define Detailed Roles and Responsibilities.

The Project Manager further defines and documents project roles and reporting relationships and creates a RAM.  Critical to this effort is definition of the roles of business users and education of all stakeholder groups regarding their upcoming roles and accountabilities.

During the Concept Development Phase, human resources planning is conducted.  Project organization planning, started in the Initiation Phase, continues here with additional detail.  Section 9 of PMBOK, Project Human Resource Management, defines the processes to organize and manage teams and the three key outputs: Project Organization Charts, RAM, and Staffing Management Plan.

4.10 Establish Governance Processes and Steering Committee.

The Project Sponsor and Agency CIO further define and establish the governance structure identified in the Project Charter by establishing a framework for action, information distribution, and decision making.  This framework should be applied consistently during the project life cycle.  Developing a governance structure entails these steps:

1. The Project Sponsor typically chairs the Steering Committee.
2. Identify and assemble a senior level team of project stakeholders to make up the Steering Committee, representing the diversity of project interests across both business and technical domains.
3. Define the reporting relationships of the team members, and jointly agree upon decision making authorities.  The relationships and authorities can be recorded in the Project Organization Chart or a RACI matrix.
4. Define the team decision rights.  The following table is an example of how decision rights may be documented. 

 Sample Decision Rights Chart

5. Define the project success measures and the collection, tracking, and reporting of this information.  Provide this information to the Planning and Development Teams.
6. Specify the processes and procedures for how the Steering Committee will conduct continuous oversight.
7. Assign administrative functions.

4.11 Develop the ITPR.

The Agency CFO and Agency CIO with the Project Manager prepare the ITPR and are jointly responsible for its quality and completeness.  Every MITDP requires an ITPR, which must be approved by the legislature before the MITDP may begin.  The ITPR formally requests approval to begin or continue a project and forms the basis of funding requests for DoIT and the Maryland legislature. The PSS has most of the information required by the ITPR.  The ITPR requires about 40 hours of work to research and document all areas. The Project Sponsor, Executive Sponsor, Agency CIO, and Agency CFO must thoroughly review and formally authorize the ITPR before submission.

4.11.1 Document Description

The ITPR is the mechanism for requesting approval to begin a new project, continue an existing project, or fund a new or existing project.  ITPRs must be submitted the fiscal year before a project begins (including planning), regardless of whether a request for funding is necessary.  The agency must submit an ITPR for each fiscal year that a project is under way and for one fiscal year following project completion.

4.11.2 Required Content

The DoIT website provides a complete list of required content for the ITPR.

4.11.3 Guidance for Document Development

The Planning Team selects a preliminary development path for the project while completing the ITPR.  Generally, projects are expected to follow the State’s published SDLC, but some projects may be managed more efficiently with other development methodologies.  Refer to the Alternate Methodologies page for a more complete discussion on alternative development approaches and when they may apply.

4.11.4 Dos and Don'ts

• When developing the baseline ITPR, organize project cost estimates into appropriate categories to make project cost tracking consistent with ITMPs.
• Do fill out all the information as completely as possible.
• Do keep the information updated annually including project financials, risk, schedules and pertinent information.

4.12 Perform Phase-Closure Activities.

The Project Manager and the Planning Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completing all Concept Development Phase tasks.  This review addresses:

• Status of Concept Development Phase activities
• Communication of finalized project scope
• Planning status for the Planning Phase
• Status on resource availability
• Risks associated with moving into the next phase
• Updated assessment of project feasibility
• "Go-No Go" decision made to proceed to next phase, based on Concept Development Phase information

Back To Top

5.0 Conclusions

The completion of the project organization chart, completion of the RAM and project staffing estimate, approval of the PSS and ITPR, completion of the Concept Development project status review, and approval to proceed to the next phase, signify the end of the Concept Development Phase.​​​

 ​​​

The Planning Phase focuses principally on required project planning work. Proper comprehensive project planning is essential to a successful IT project, and incomplete project planning and analysis are frequently root causes of project failure. Most project planning is conducted as part of the PMBOK Integration Management work, which includes defining the processes necessary to identify, define, combine, unify, and coordinate all project activities for successful project deployment.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Planning Phase sho​uld comprise:

• Assessment and description of the procurement management strategy
• Elaboration and refinement of the project scope, schedule, risks, and costs
• Assessment and description of activities to coordinate all relevant subsidiary plans
• Definition of procedures for how the project will be executed, monitored, controlled, and closed
• Planning the future course of action
• Development of the Project Management Plan(s) (PMP)
• Approval to progress to the Requirements Analysis Phase

Goals

The purpose of the Planning Phase is to plan all project processes and activities required to ensure project success and to create a comprehensive set of plans, known as the PMP, to manage the project from this phase until project termination.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control agency IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC document templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content. 

The development and distribution of SDLC deliverables:

• Ensure common understanding among Planning Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Planning Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present.  The length of deliverables may vary depending on the size, scope, and complexity of the project. 
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be initially developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.  DoIT will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities during this phase:

• Agency CIO
• Project Sponsor
• Executive Sponsor
• Project Manager
• Procurement Officer
• Project Stakeholders
• Secretary of DoIT

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The Project Manager ensures the following prerequisites for this phase are complete:

• The business need for the project continues to be valid.
• An alternatives analysis was performed.
• The project scope is clearly defined and approved.
• The acquisition strategy is finalized.
• The ITPR is approved.
• The Agency CIO, Project Sponsor, and Executive Sponsor approved the PSS.

4.2 Select Development Path.

After completing the first three phases of the SDLC, agencies can select from one of several development paths suited to the specific project. By selecting the appropriate development path, an agency can reduce documentation redundancy.  These development paths are as follows:

• Single-Release Projects – smaller efforts that have one SDLC cycle.  Single-release projects may involve custom development, COTS implementations, or hardware/network implementations or upgrades.
• Multiple-Release Projects – larger efforts that have multiple releases, phases, or milestones. Multiple-release projects may also involve custom development, COTS implementations, or hardware/network implementations or upgrades.

4.3 Initiate Planning Activities.

The Planning Team begins planning with the following tasks:

• Review other standards and methods that will affect the project. At minimum, the Planning Team should review PMBOK and SDLC guidance for all project phases, the State Information Technology Security Policy and Standards, and the statewide disaster recovery standards. For information regarding State security policies and disaster recovery standards, visit the DoIT website.

4.4 Develop the PMP and Subsidiary Plans.

The Project Manager conducts and/or supervises the analysis required to understand all the dimensions of the project and documents this analysis in the PMP and its subsidiary plans.  The Project Manager may assign some investigation and analysis tasks to other agency staff or members of the Planning Team.

4.4.1 Document Description

The key elements of the PMP include:

• Details about the functional units involved, job tasks, cost and schedule performance measurements
• Milestones and review scheduling (indicate which milestones are contractually mandatory and which ones are optional)
• Definition of all project management processes
• Identification of tools and techniques to accomplish project management processes
• Dependencies and interactions among processes
• Timelines and metrics for success at each phase of work
• Methods for maintaining the integrity of the performance measurement baselines, resource calendar, schedule baseline, cost baseline, scope baseline, and quality baseline
• Further elaboration of the project scope, tasks, schedule, allocated resources, and interrelationships with other projects

4.4.2 Typical Content

The PMP must include the following subsidiary plans:

• Scope Management Plan
• Schedule Management Plan
• Cost Management Plan
• Quality Management Plan
• Staffing Management Plan
• Communication Management Plan
• Risk Management Plan
• Procurement Management Plan
• Change Management Plan
• Stakeholder Management Plan (optional)

4.4.3 Guidance for Document Development

Throughout the life cycle, review all planning processes regularly and revise as needed to ensure continued applicability.  Also, review and update the PMP and subsidiary plans at least quarterly. 

4.4.4 Dos and Don’ts

• Do include in the plans all vendor, agency, and government tasks to identify and monitor dependencies.  Without a holistic project plan, assessing a project’s schedule becomes difficult, and the likelihood of missing scheduled deliverable dates increases.
• Do consider internal and external factors that will affect the project throughout its life cycle.
• Do include all SDLC-required documents and activities.

4.4.5 Develop the Scope Management Plan.

The Project Manager with input from the key project stakeholders writes the Scope Management Plan and then creates the milestone list.  The Scope Management Plan briefly reiterates the project scope, defines its verification and control procedures, and describes how requirements will be defined.  The Scope Management Plan must address these scope management processes: Collect Requirements, Verify Scope, and Control Scope.

Collect Requirements – a process identifying how requirements will be further defined.  Identify the requirements definition methodology, tools, techniques, and documentation to be utilized and the planned processes to ensure that requirements are defined to be complete, concise, consistent, and unambiguous.  This section should clearly demonstrate how the Planning Team will define and validate requirements for all requirement types specified in the Functional Requirements Document template.

Verify Scope – a process defining how various products/deliverables will be periodically verified and formally accepted.  This section of the Scope Management Plan should describe:

• Process to obtain project stakeholders’ formal acceptance of the completed project scope and associated deliverables.  This process typically involves verifying that deliverables meet acceptance criteria.
• Processes to verify periodically the project scope.  This includes reviewing deliverables to ensure that each is completed satisfactorily. 
• Processes for inspecting, measuring, and testing the contractual deliverable to verify it meets the established acceptance criteria.

Procedures to ensure all potential project scope changes are vetted properly through the established Change Control process. With the Procurement Officer, define procurement-related change control measures, i.e., change order processes.

4.4.6 Refine WBS, Develop the Baseline Schedule and Develop the Schedule Management Plan.

The Project Manager, with input from the key project stakeholders and the initial WBS, refines the WBS into further detail,  develops the baseline schedule and defines the Schedule Management Plan.  The initial WBS, developed during the Concept Development Phase, will be progressively elaborated to define specific work activities, activities sequence, estimate resources, and estimate duration that will need to complete the project.  The refined WBS will be used to develop an initial, baseline schedule.  The Schedule Management Plan establishes the specific procedures for how the project schedule will be managed and controlled and is as detailed as necessary to control the schedule through the life cycle based on the size, risk profile, and complexity of the project.  The Project Manager should consider the six schedule management processes described below in the development of the schedule baseline and the Schedule Management Plan.  The development of the schedule baseline will involve activity definition, activity sequencing, activity resource estimation, and activity duration estimation.  The Schedule Management Plan should be focused on the methods for controlling the schedule.

Define Activities – identification of the specific work activities that need to be performed to complete the project. Although preliminary activity definition begins in the Concept Development Phase, this definition is further refined during the Planning Phase to ensure that all activities are defined in detail.    The Planning Team creates a more detailed WBS, develop an initial, baseline project schedule and describes the proposed process for how the baseline schedule will be maintained and monitored in the Schedule Management Plan.

The Project Manager includes IV&V processes as discrete WBS work tasks if the project is subject to IV&V review.

• DoIT can initiate independent IV&V reviews at any stage of the life cycle.
• Some projects have Legislative requirements for periodic IV&V reviews.
• Plan for the scheduling, scope, and cost of such activities in the PMP.

 Other WBS considerations include:

• A PMP always includes a WBS that organizes and defines the total work necessary to complete the project objectives.
• The WBS should subdivide the project work into incrementally smaller, manageable portions.
• Each subsequent WBS level represents increasingly detailed definitions of project work.
• The lowest-level WBS components are called “work packages.”
• Work packages are considered sufficiently detailed if they require between 8 and 80 hours to accomplish (known as the "8/80 rule").

Estimate Activity Resources – estimation of the type and quantities of resources required to complete identified activities.

Estimate Activity Durations – estimation of the approximate duration to complete work packages. Using the refined WBS, the team members most familiar with the identified work package should estimate the duration of scheduled activities.

Develop Schedule – develop the baseline project schedule after analyzing all defined WBS activities and work packages, sequence, resources, and duration. This section also includes identification of tools to use for managing the project schedule.

Control Schedule – methods for controlling changes to the schedule.

• Procedures and schedule performance indicators for reporting project progress and who will be accountable for reporting and maintaining the schedule
• Definition of the schedule change process, including approvals and notification
• Procedures and schedule for reviewing and updating the baseline plan
• Procedures for schedule performance corrective actions

4.4.7 Develop the Cost Management Plan.

The Project Manager and the Procurement Officer create the cost baseline and the Cost Management Plan. Beginning with the preliminary cost estimates identified in the Concept Development Phase, the Project Manager develops updated cost estimates to perform the work included in the updated schedule.   The Cost Management Plan establishes the activities and criteria for planning, structuring, and controlling project costs. Cost estimating and cost controls are the most important evaluation and control items in State projects. Costs and cost variances must be reported regularly to DoIT and other oversight organizations. Any cost change over five percent requires legislative approval. 

The Project Manager should consider the three cost management processes described below in the development of the cost baseline and the Cost Management Plan. The development of the cost baseline will involve updated cost estimation and budget determination. The Cost Management Plan should be focused on the methods for controlling costs.

Estimate Costs – development of a complete estimate of the funding needed to complete project activities, including operations, maintenance, and support costs for the life of the project. Estimate costs by evaluating each WBS work package, and logically partition and report costs into incremental, manageable pieces, including:

• Internal and external labor – cost of work performed by State employees and external vendors
• Materials – cost of items (e.g. office supplies) consumed during business operations and service delivery
• Equipment – cost of hardware and any other kind of physical asset employed in business operations
• Services – cost of all services provided by external vendors
• Facilities – costs associated with providing physical locations for work to be performed
• Contractual requirements – cost of complying with all contractual requirements, such as SDLC requirements
• Inflation allowances – addresses the amount of expected price increases of business operations and service delivery
• Contingency reserves – planned funds allocated for cost uncertainty

Determine Budget – combination of work package costs to establish an overall budget. Aggregate the estimated costs of each scheduled activity or work package, and establish a total cost performance baseline for measuring project performance. When aggregating the estimated costs, add a budget line item for IV&V. Not all projects are selected for IV&V reviews, but cost allocations for the activity are advisable for all MITDPs. Also consider:

• Reserve Analysis – Establish contingency reserves or allowances for unplanned but required changes. Management contingency reserves are budget line items allocated for unplanned changes.
• Funding Limit Reconciliation – Reconcile the expenditure of funds with the funding limits set by the performing organization on the disbursement of funds for the project.

Control Costs – establishment of procedures to manage the established cost baseline, so the project is completed on time and on budget. These procedures assist in assuring that cost expenditures do not exceed the authorized funding, by period, deliverable, or in total.

• Procedures for monitoring overall cost performance to detect and understand cost baseline variances
• Procedures for monitoring and reporting work performance against funds expended
• Description of how Project Managers will routinely monitor the status of the project to manage changes to the cost baseline
• Description of cost tracking and reporting procedures
• Plans for conducting periodic cost control reviews throughout the project life cycle
• Plans for quarterly ITPR reporting and periodic budget reviews

 Planned cost control activities must address the following:

• Influencing the factors that create changes to the approved cost baseline
• Managing the actual changes as they occur
• Preventing any unapproved changes from being implemented
• Informing appropriate project stakeholders of all approved changes and associated costs
• Acting to bring cost overruns within budgetary limits

The Cost Management Plan should identify how the team will update other relevant project documents (e.g. PMP) when cost variances are identified.

When identifying cost performance monitoring plans, consider performance measurement techniques identified by PMBOK. For example, PMBOK, Chapter 7 describes earned value techniques, which compare the budgeted cost of work performed to the budgeted cost of work scheduled and the actual cost of work performed.

Ensure that planned financial reporting for MITDPs adheres to the DoIT quarterly reporting guidelines.

4.4.8 Develop the Quality Management Plan.

The Project Manager with input from key project stakeholders and the Procurement Officer creates the Quality Management Plan and the quality baseline, which identify the relevant quality standards and determine how those standards will be satisfied. The Quality Management Plan should address three quality management processes: plan quality, perform quality assurance, perform quality control.

Plan Quality – verification processes to ensure that the system is successful, that project stakeholders are satisfied, and that deliverables are accepted.

• Plan for how requirements traceability will be conducted throughout the project to ensure that system outcomes developed in later phases are tested to ensure they meet the system baseline requirements
• Plan what work the team will do to demonstrate adequate compliance to baseline requirements
• Assign the agency business users the task of developing user acceptance criteria for future traceability
• Include processes to develop use cases and test cases and conduct user acceptance testing
• For transformation, migration, and legacy modernization projects, identify the preliminary strategy for how the Planning Team envisions converting/migrating the legacy data and how this strategy will ensure data is converted completely and accurately (any data cleansing challenges should be identified here)
• Plan for how key project stakeholders and the Development Team will acquire the proper expertise to verify deliverables and develop and execute test cases if this expertise is not already in place
• Link functional requirements of project deliverables to established user acceptance criteria

Perform Quality Assurance – procedures for ensuring the effectiveness of quality management processes and quality standards.  This section of the Quality Management Plan describes how and when the team will monitor and report effectiveness and how the team will implement corrective actions to ensure that quality management processes and standards are defined and implemented to ensure optimal project performance.

• Plan for a possible IV&V assessment at any phase of the SDLC or multiple times during the project life cycle. IV&V assessments are part of an overall quality plan as an independent check-up on the overall health of the project to date, pointing out its strengths and areas that need improvement to help the project be successful, on time, and within the allotted budget

Perform Quality Control – review activities focused on the quality of deliverables, including the system, to determine adherence to quality standards and criteria. This section of the Quality Management Plan describes the procedures for evaluating deliverable and project performance and for recommending necessary changes. Quality control procedures should address monitoring overall project performance, including cost and schedule performance, as well as the quality of all project activities and deliverables. Quality control activities for the system should identify the testing activities, tools, techniques, and desired outputs to ensure quality attributes are built into the design and tested throughout the life cycle. Quality control tools and techniques may include quality inspections, inspection schedules, and/or quality audits, and outputs may include bug fix logs of inspection errors referenced against a Requirements Traceability Matrix. Testing is an ongoing activity that can provide early warning long before the application is released into production if it is not up to standard.

4.4.9 Develop the Staffing Management Plan.

The Project Manager with input from key project stakeholders creates the Staffing Management Plan and the Resource Calendar.  Staffing Management Planning further determines:

• Project roles
• Responsibilities
• Reporting relationships

The Staffing Management Plan elaborates on staffing work completed in the Concept Development Phase – the preliminary organization chart, RAM, and preliminary staffing estimates – by describing how and when human resource requirements will be met.

The Staffing Management Plan will contain for each team member:

• Role – a description of each team member’s responsibility on the project
• Authority/Reporting – level of decision-making ability defined in terms of project resources, project schedule, formal approvals, and project reporting structure. Teams work most efficiently when individual responsibilities match individual authority levels.
• Responsibility – definition of what each team member must complete for the project
• Competency – the skill set necessary and the expected level of effort (capacity) for the project to be successful.  Initiate proactive responses when realizing a team member lacks the proper skill set or capacity. Proactive responses include, but are not limited to, training, hiring additional staff, schedule changes, and/or project scope changes.

 A Staffing Management Plan contains:

• Staff Acquisition Strategy – how staffing will be acquired to do the work.
• Internal agency resources and estimates of external (contractor) needs.
• Initial staffing logistics – where will the team work (on site, off site, or both)
• Agencies are strongly encouraged to provide, at a minimum, a fully dedicated Project Manager for all MITDPs undertaken.
• Timetable – when each resource will join and exit the team based on the updated WBS. A resource histogram is an accepted tool in this area (refer to PMBOK, section 9.1.3).
• Training Needs – plan to develop a training plan as part of the project so that team members can acquire needed skills if they do not already have the required level of competency.

 A Staffing Management Plan must consider resource needs for the full life of the system including operations and maintenance. Because internal agency resources assigned to the project will no longer be able to perform their operational duties, the Staffing Management Plan should identify the additional resources required to support agency operations without interruption.

Additional optional areas of the Staffing Management Plan include:

• Plans for staff recognition
• Safety policies
  

4.4.10 Develop the Communication Management Plan.

The Project Manager with input from key project stakeholders develops the Communication Management Plan. Communication planning is one of the most important subsidiary plans in the PMP. It describes the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and disposition of project information. For more information on communications planning, see PMBOK.

The Communication Management Plan describes the detailed processes and techniques the team will use to collect, store, and report on project progress. It is often multi-dimensional; as there are multiple stakeholder groups that require information on the project, the Communication Management Plan details who needs exactly what information, when they need it, how it will be delivered, and by whom.

The Communication Management Plan is an important first step in managing project stakeholders’ expectations, which is an important factor in project success. The Project Manager is primarily responsible for ensuring that project communications are conducted appropriately throughout the project, but the work of disseminating information can be delegated to other team members.

Consider DoIT a key stakeholder when developing the Communication Management Plan. Align project status reports with the data needs of DoIT.

Key elements of the Communication Management Plan include:

• Segregation of users into groups and determination of the type of information each group requires
• Description of tools, media, and format for project communications
• Description of the distribution channels for information
• Determination of the frequency of information delivery
• Assignation of Planning Team responsibility for information collection and distribution
• Format and information requirements needed from the team, including future contractor personnel
• Plan for reporting project performance

Project performance reporting involves collecting all project baseline data and distributing performance information to project stakeholders. Performance reporting (i.e. status reporting) generally provides information on scope, schedule, cost, quality, issues, and risks, completed activities within the reporting period, activities that have not been completed and why, upcoming activities, and a list of pending, approved and rejected project changes.

4.4.11 Develop the Risk Management Plan.

The Project Manager with input from key project stakeholders creates the Risk Management Plan (RMP) and the Risk Register, which detail how teams will identify, manage, and mitigate risk. Active management of project risks increases the probability of positive events and decreases the chances of negative events within the project life cycle. This subject is described in detail in Chapter 11.1 of the PMBOK guide.

Developing a RMP during the Planning Phase reinforces the concept that risk identification and mitigation are highly important activities, which, if properly addressed, serve to reduce overall project risk. Whenever practical, involve the Executive Sponsor and the Project Sponsor in risk identification and mitigation activities throughout the project life cycle. Identify in the RMP how the Project Manager will routinely provide the Executive Sponsor and the Project Sponsor with complete insight into all known risks.

Be sure to give special consideration to security risks and the processes for evaluating whether the system meets state security standards.

DoIT maintains a system of five risk categories and 12 to 15 sub-categories. These risk classification values are included in the Risk Management Plan template. When developing a RMP, use this classification schema for easier project reporting throughout the life cycle.

Key elements of the RMP include:

• Risk Planning – how to approach, plan, and execute risk management activities
• Risk Identification – determination of initial risks that might affect the project, identification of processes for flagging emerging risks, and descriptions of each risk characteristic. Risk identification is an iterative process because new risks will emerge as the project progresses through its life cycle.
• Risk Analysis – quantitative and/or qualitative analysis of each identified risk. Usually, qualitative risk management techniques are the most applicable for State projects. These types of risk analysis methods, as well as the conditions under which each method can be used, are described in detail in Chapter 11 of the PMBOK.
• Response Planning – mitigation, transfer, and/or avoidance strategies to reduce risk
• Monitoring and Control – procedures for tracking risks, monitoring residual risk, identifying new risks, executing response plans, and evaluating risk management effectiveness. Add new risks to the risk register as they are identified and response strategies are developed.

 A RMP typically contains the following sections:

• Methodology – the approach, tools, and information sources for risk management activities
• Roles and Responsibilities – lead, support, and other team members responsible for risk management activities and each team member’s responsibilities
• Budget – the budget incorporated into cost estimating activities for risk mitigation (included in the overall project budget). Best practices suggest a risk mitigation budget of 5-15% of total project costs, budgeting on the higher end for projects with high-risk profiles.
• Timing – how often risk management processes will be performed
• Risk Management Activities –risk management activities to be included in the project work schedule
• Risk Categories – a comprehensive process of systematically classifying risk consistently
• Risk Probability and Impact – project-specific risk probability and impact measurement methods
• Reporting Formats – the content and format of the project Risk Register, which is typically a work tool or spreadsheet that documents and tracks risk information

An RMP also includes an issue management plan with an actively managed issues log that identifies, assigns responsibility, and tracks issues through to closure.

4.4.12 Develop the Procurement Management Plan.

The Project Manager and the Procurement Officer create the Procurement Management Plan to define the procedures to purchase or acquire all products and services needed from outside the team to perform project tasks. The Project Procurement Management processes include six key steps. For more detailed information, please refer to PMBOK. The Project Manager should update the schedule to include all procurement activities identified as part of procurement management planning. The Procurement Management Plan should identify plans for the following procurement management processes:

Plan Purchases and Acquisitions – development of solicitation documents to seek responses from multiple businesses that wish to provide a needed service for the agency. These documents must have sufficient detail and concrete measurable criteria to ensure consistent, comparable bidder responses but also be flexible enough to allow consideration of contractor suggestions for better ways to satisfy the requirements. If an agency elects to have contractors conduct some SDLC activities, the contractor must be explicitly instructed in procurement documents to describe the methods it will use to develop SDLC documents, supply all pertinent SDLC document samples with the bid packages, and supply a schedule for when these key documents would be received. It is also good policy to fix price deliverables and provide detailed acceptance criteria in advance in order to avoid later confusion and cost overruns.

Plan Contracting – development and preparation of documents needed to support the Request Vendor/Contractor responses process and the Select Vendor/Contractor process.

Request Vendor/Contractor Responses – release of a Request for Proposal (RFP) or Task Order Request for Proposal (TORFP).

Select Vendor/Contractors (proposal evaluation process) – receipt of bids, quotes, or proposals and application of pre-determined, published evaluation criteria to select qualified contractors or sellers. Evaluation criteria vary based on overall project needs. Key project stakeholders should be involved in evaluating all aspects of proposed solutions from a technical perspective.

Contract Administration – verification that the contractor meets contractual requirements and performs in accordance with the terms and conditions of the agreed contract. The key areas of contract management include:

• Reading and understanding all deliverables and terms and conditions of the contract
• Actively managing the terms and conditions of the contract
• Inspection and verification of all deliverables before sign-off and payment
• Verification that any contractual changes have been subject to the change management process and have been properly assessed and approved
• Assurance that the RMP is followed and that project risks are actively managed and mitigated
• Receipt of status reports based on the deliverable schedule; reviewing and providing feedback to the contractor in a timely fashion. (Contractor reports at a minimum must include an up-to-date project schedule, costs, performance, and status of deliverables.)

Contract Closure – establishment of procedures to verify and document project deliverables and formalize the Project Sponsor’s acceptance of those deliverables.  If the project is cancelled, the Project Manager documents the reasons and obtains sign-off from the Project Sponsor. Also, determine processes for the contract and administrative close-out in this part of the PMP.

Involve key project stakeholders in determining effective acceptance practices for project deliverables. Use a requirements traceability matrix to verify deliverables have met contractual standards. After the key project stakeholders verify the deliverable meets the requirement, the Project Manager executes formal acceptance.

4.4.13 Develop the Change Management Plan.

The Project Manager with input from the Procurement Officer creates the Change Management Plan, which documents how project changes will be monitored and controlled from project inception through completion. The Change Management Plan should address:

• Process for approving/rejecting project change requests
• Process for monitoring and managing the rate of implemented change requests
• Process for maintaining baseline integrity by releasing only approved changes for incorporation into project products
• Process for configuration identification – how configuration items will be selected and identified, how products and documents are labeled, changes are managed, and accountability is maintained
• Process for configuration status accounting – how information is recorded and reported regarding configuration item data, including a listing of approved configuration identification, status of proposed changes to the configuration, and the implementation status of approved changes
• Process for configuration verification and audit – how configuration items will be verified and audited to ensure that they are correct and that corresponding changes are registered, assessed, approved, tracked, and correctly implemented
• Documentation of the complete impact of requested changes

4.4.14 Develop the Stakeholder Management Plan.

The Project Manager with input from key project stakeholders creates the Stakeholder Management Plan, which documents how individuals, groups, and organizations will impact the project and how they will be impacted by it. Because of their varied interests, influence, and other characteristics, they will require different strategies to maximize support for the project and minimize resistance to it.

Note that Stakeholder Management was added as a separate knowledge area in PMBOK fifth edition. Therefore, it is an optional deliverable in the project planning phase. New projects should consider including it, while projects in progress do not need to backtrack and create it.

All stakeholders who could possibly impact the project or be impacted by it should be identified in the sub-plan. The eventual strategy for some groups might be to do little or nothing for them, because of their low impact or low influence, but including them produces a comprehensive and thorough plan. The team might also find that stakeholder needs change over time, requiring more attention than believed at the beginning of the project.

Although any component of the Project Management Plan has the potential to be sensitive, the Stakeholder Management Plan should receive particular consideration for limiting its distribution and involvement of some groups. Some stakeholders might resent how they are characterized, analyzed, or otherwise described within the plan.

The Stakeholder Management Plan should address:

• Identify Stakeholders – identify by name and title the people, groups, and organizations that have significant influence on project direction and its success or who are significantly impacted by the project.
• Plan Stakeholder Management – identify the strategies and mechanisms that will be used to achieve the greatest support of stakeholders and minimize resistance.
• Manage Stakeholder Engagement – outlines the processes and steps that will be undertaken to carry out the planned strategies.
• Control Stakeholder Engagement – describes the methods that will be used to monitor stakeholder engagement and alert the project team if problems are surfacing.

4.5 Develop Optional Support Items.

When appropriate, agencies may develop other planning documents, such as:

• Resource Calendar – calendar that documents working days and resource availability and any know schedule limitations

4.6 Perform Phase-Closure Activities.

The Project Manager and the Planning Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completing all Planning Phase tasks. This review addresses the following:

• Status of Planning Phase activities
• Planning status for the Requirements Analysis Phase
• Status of resource availability
• Final assessment of project feasibility
• “Go-No Go” decision made to proceed to next phase, based on Planning Phase information

The Project Manager must obtain deliverable approval signatures before proceeding to the Requirements Analysis Phase.

Update the project documentation repository upon completion of the phase-closure activities.

The Requirements Analysis Phase begins when the previous phase objectives have been achieved. Documentation related to user requirements from the Concept Development Phase and the Planning Phase shall be used as the basis for further user needs analysis and the development of detailed requirements.​

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Requirements Analysis Phase should comprise:

• Definition of approved requirements
• Creation of the Functional Requirements Document and Requirements Traceability Matrix
• Development of planned test activities
• Performance of needed procurement activities
• Completion of a COTS fit-gap analysis and requirements validation
• Development of a Business Process Change Management Plan
• Approval to progress to the Design Phase

Goals

The purpose of the Requirements Analysis Phase is to transform the needs and high-level requirements specified in earlier phases into unambiguous (measurable and testable), traceable, complete, consistent, and stakeholder-approved requirements.  During the Requirements Analysis Phase, the agency will conduct any procurement needed for the project.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content.

The development and distribution of SDLC deliverables:

• Ensure common understanding among Planning Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Planning Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present.  The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project. 
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.

DoIT will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities in this phase:

• Agency CIO
• Agency CFO
• Project Sponsor
• Executive Sponsor
• Business Owner
• Project Manager
• Planning Team
• Project Stakeholders
• Procurement Officer
• Secretary of DoIT

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The Project Manager ensures the following prerequisites for this phase are complete:

• Project Management Plan and schedule showing target completion dates for requirements analysis activities
• Schedule Management Plan addressing the current state of the project’s schedule, the factors that might influence it, and management of those factors (See additional information in the PMBOK, fourth edition, section 6.)
• Approval and baseline of the PSS, RMP, and PMP

4.2 Monitor Project Performance.

The Project Manager monitors project performance by gathering status information about:

• All changes to baseline data
• Change management information
• Activity progress with status details
• List of complete and incomplete deliverables
• Activities initiated and finished
• Quality assurance testing and test results
• Estimated time to completion
• Resource utilization data
• Changes to project scope
• Costs authorized and incurred

4.3 Update PMP and Communication Management Plan.

The Project Manager routinely updates the PMP (at least quarterly) to ensure the PMP reflects project performance accurately.  Review project performance controls and risks for deviations from the baseline.

Information dissemination is one of the Project Manager’s most important responsibilities.  The Project Manager reviews and updates the Communication Management Plan at least quarterly to account for potential changes in project stakeholders.  The Project Manager distributes the updated PMP and risk management information according to the revised Communication Management Plan.  PMBOK, Chapter 10 contains additional details regarding project communications and information distribution.

4.4 Perform Risk Management Activities.

The Project Manager conducts risk management activities, including:

• Identification – determination of risks, emerging risks, and risk characteristics
• Risk Analysis – quantitative and/or qualitative analysis of each identified risk.  Usually, qualitative risk management techniques are the most applicable for State projects.  Risk analysis methods, as well as the conditions under which each method might be used, are described in detail in PMBOK, Chapter 11.
• Response Planning – planning of methods for developing mitigation, transfer, or avoidance strategies to reduce risk
• Monitoring and Control – definition of procedures to track risks, monitor residual risk, identify new risks, execute response plans, and evaluate risk management effectiveness

• Status of identified risks and risk responses
• Planned results versus actual results of risk responses
• Effectiveness of previously planned risk responses
• New risks
• Closed risks
• Risk process improvements
• Comparison of the amount of contingency reserves remaining to the amount of risk remaining to determine if remaining reserve is adequate

4.5  Initiate Requirements Identification.

The Planning Team with Project Manager supervision identifies system requirements.  

System Requirement Types

The Planning Team begins a detailed analysis of the current architecture and elicits, analyzes, specifies, prioritizes, verifies, and negotiates business functions and requirements that the proposed system must deliver and support.  The business requirements are generally known as functional requirements and describe what the system has to do.  Interacting closely with project stakeholders and end users to identify the functional requirements, the Planning Team may use different tools and techniques such as:

• Interviews
• Focus groups (consisting of end-users)
• Facilitated workshops (e.g. Joint Application Development/Design sessions)
• Group creativity techniques
• Group decision making techniques
• Questionnaires and surveys
• Observations
• Prototypes
• Storyboarding

4.6 Construct the Requirements Traceability Matrix.

The Planning Team constructs the RTM from the elicited requirements.

4.6.1 Document Description

The RTM is a tool that links requirements to their origins and provides a method for tracking the requirements and their implementation through the development process.

4.6.2 Typical Content

At minimum, the RTM should contain for each requirement:

• Requirement Description
• Requirement Reference in the FRD
• Source
• Current Status
• System Component/Module
• Fit-Gap
• Configuration or Customization
• Verification Method
• Requirement Reference in Test Plan
• Date Completed

4.6.3 Guidance for Document Development

Attributes associated with each requirement should be recorded in the RTM.  As the project progresses, the Planning Team updates the RTM to reflect new requirements, modified requirements, and any change to a requirement’s status.  During the Design Phase, requirements are mapped to design documents to ensure all requirements are planned for in development. When the system is ready for testing, the RTM lists each requirement, the system component addressed by that requirement, and the test to verify correct functionality and implementation.

4.6.4 Dos and Don’ts

• Do consider an automated tool if the system has many requirements; commercial and open source software tools support RTM work.  A spreadsheet may be sufficient depending on the size of the system.
• Do utilize the RTM to document configuration and customization to address requirement gaps.

4.7 Draft Process Models.

The Planning Team develops process models of the system’s functions and operations: models of the current system (As-Is processes) and models of the target system (To-Be processes).  To derive further requirements for the system, the Planning Team decomposes the process models iteratively into increasingly smaller functions and sub-functions to define all business processes.  Both As-Is and To-Be business process definition is required for all projects, except projects that introduce entirely new business functions.  For entirely new business functions, To-Be business process should be defined. This step is necessary to ensure that agencies do not misapply technology to outdated, inefficient, and dysfunctional business processes.   The Planning Team should ensure the project stakeholders and end users approve the process models.

For COTS implementation projects, including SaaS acquisitions, the To-Be process model for the target system cannot be finalized until after the completion of the COTS fit-gap analysis.  Although agencies should include a preliminary target system To-Be process model in the RFP, the functionality of the selected COTS package must influence the finalized future processes.

4.8 Draft Data Model.

The Planning Team develops a draft conceptual data model to document the business processes
and underlying data.  The data model depicts the data structure, its characteristics, and the relationships between the data using graphical notation.  A data dictionary supports the data model as the repository of information about the data, including details on entities, their attributes, and relationships between the entities.

The Planning Team can elaborate further on the requirements after drafts of the data model and data dictionary are complete.  As the data model is refined, the Planning Team must include data exchanged with external systems.  The Planning Team should review and cross-reference the process model and the data model to ensure the requirements exist and are consistently defined.

Although COTS implementation RFPs should include the preliminary data model for the future system, this model must be finalized after the COTS selection to ensure that it is compatible with the solution.

4.9 Document System Interfaces.

The Planning Team identifies and defines internal and external interface requirements for the system.  The internal interface requirements involve data interactions within the system and likely focus on performance or reliability.  The external interface requirements may influence non-functional requirements such as security, performance, and accessibility.  The Planning Team updates the RTM with new or modified requirements.

4.10 Assemble the Functional Requirements Document.

The Planning Team develops the FRD, which contains the complete system requirements and describes the functions that the system must perform.  The draft FRD must be included in the RFP and finalized after the requirements validation and COTS fit-gap analysis.

4.10.1 Document Description

This document compiles all requirements including functional and non-functional requirements, process and data models, and interface definitions.  The FRD describes the logical grouping of related processes and functions within the system and the business requirements these requirements satisfy.  The document must capture the full set of requirements independent of any development approach, methodology, or organizational constraints.  The final FRD helps the Project Manager obtain consensus among the Planning Team members and project stakeholders that the proposed specifications will result in a solution that satisfies project stakeholders’ needs.

4.10.2 Typical Content

The key elements of an FRD include the following items.  Additional guidance is provided in the SDLC template.

• Project description
• Points of contact
• Data requirements
• Functional process requirements
• Security requirements
• Audit trail requirements
• Data currency requirements
• Reliability requirements
• Recoverability requirements
• System availability requirements
• Fault tolerance requirements
• Performance requirements
• Capacity requirements
• Data retention requirements
• Glossary

4.10.3 Dos and Don'ts

• Do include requirements that are complete, consistent, measurable, and indivisible.
• Do involve all project stakeholders in the identification and validation of requirements.
• Don’t confuse requirements with design specifications.  Erroneously including design specifications in the FRD may unnecessarily limit competitive responses to the implementation solicitation.

4.11 Develop Procurement Documents.

The Procurement Officer with the assistance of the Project Manager develops all procurement documents.  Agencies are strongly encouraged to complete and issue procurement documents for system implementation after requirements are defined and documented in detail; this timing allows potential contractors to evaluate, scope, and price project work properly.  Depending on the scope of service solicited, procurement documents may be developed in other SDLC phases.

Procurement documents such as RFPs and TORFPs are distributed to elicit competitive and comprehensive offers from potential contractors for a product or service.  RFPs and TORFPs specify the scope of the desired procurement, define the evaluation process, delineate the deliverables and requirements associated with the project, and establish a contractual agreement for the delivery of the good or service.  Careful planning and development of procurement documents help avoid or mitigate project risks or transfer project risks to the contractor.

4.12 Determine Contract and Solicitation Type.

The Procurement Officer determines the type of contract and solicitation based on work from the Planning Phase.  The type of contract determines the level of risk shared between the State and a contractor.  Fixed-price contracts generally reduce the risk to the State by ensuring that any cost increase due to adverse performance is the responsibility of the contractor, who is legally obligated to complete the project.  FP agreements should tie contractor payments to the completion and agency acceptance of project deliverables.  A FP contract is best used when the service or product to be developed is fully defined before the start of work.  Time-and-materials contract types are more appropriate for level of effort engagements or projects with significant unknowns. The Procurement Officer also determines the type of solicitation:

• Invitation for Bid (IFB), which requires an award for lowest price by the Code of Maryland Regulations (COMAR)
• RFP, which allows additional flexibility for curing and a balanced weighting of evaluation criteria between price and technical solution

4.13 Write the Scope of Work (SOW).

The Procurement Officer with the Project Manager writes the SOW, which defines the project boundaries. One of the most critical parts of a procurement document, the SOW describes in detail the project deliverables, deliverable requirements, and the work required to create those deliverables. Agencies should leverage the information in the PSS to ensure consistency. The level of quality, specificity, and completeness of the SOW significantly impacts the quality and overall success of the project throughout its life cycle.

A well-written SOW:

• Enables offerors to clearly understand requirements and their relative importance
• Improves chances of receiving higher quality proposals
• Minimizes future needs for change orders, which lead to increased project cost and delayed project completion
• Allows both the State and the contractor to assess performance
• Reduces risk of future claims and disputes

4.14 Establish Proposal Evaluation Criteria.

The Business Owner and Project Manager with input from the Agency CIO develop the proposal evaluation criteria to rate proposals. The proposal evaluation criteria should be specific, objective, and repeatable and must be included in the RFP, so offerors know how the State will evaluate their proposals and under which criteria the winner will be awarded a contract or task order. Considerations for proposal evaluation criteria include:

• Proposals should be ranked rather than scored. Technical and financial proposals are evaluated and ranked separately. Technical proposal rankings are completed first and then financial rankings.
• Evaluation criteria must be clearly defined.
• All criteria must be aligned to the SOW.
• All criteria must be objective and not generic or ambiguous.
• References must be requested and must be verified as part of the due diligence in selecting the best value proposal.
• Evaluating and comparing financial proposals from different technical approaches can be difficult. In these situations, use a pricing model based on agency-provided assumptions.
• When using experience in evaluation criteria, identify clearly contractor experience or contractor personnel experience as the criteria because frequently people assigned to the project are instrumental in its success, not necessarily the contractor for whom they work.

The PMBOK provides the following example evaluation criteria:

• Understanding of need
• Overall or life cycle cost
• Technical capability
• Risk (including risk associated with increased business process change)
• Management approach
• Technical approach
• Warranty
• Financial capacity
• Production capacity and interest
• Business size and type
• Past performance
• References
• Intellectual property rights
• Proprietary rights

• CATS TORFP Preparation, Solicitation, and Award Process web page
• CATS I State Advance Purchasing and Inventory Control System (ADPICS) Processing Procedures
• Writing a Quality Task Order Request for Proposal
• TORFP Checklist

  The PMBOK, fourth edition, section 12.1.3.5, provides further guidance regarding proposal evaluation and source selection criteria.

4.15 Develop the RFP.

The Procurement Officer with the assistance of the Planning Team develops the RFP after the FRD is approved and baselined and the SOW is finalized.

4.15.1 Document Description

The RFP is an invitation to contractors to submit a proposal to provide specific services, products, and deliverables.

4.15.2 Typical Content

The key elements of an RFP include at minimum:

• Administrative information
• SOW
• Technical requirements
• Contractor expertise required
• Invoicing
• Reporting requirements
• Proposal format and submission requirements
• Procedure for awarding contract or task order agreement
• Evaluation criteria
• Sample contract forms and agreements

4.15.3 Guidance for Document Development

RFPs and TORFPs should:

• Facilitate accurate, appropriate, and complete responses from prospective contractors
• Elicit multiple, competitive responses and allow for consideration of contractor suggestions for better ways to satisfy requirements
• Facilitate easy and consistent evaluation of responses
• Minimize cost, schedule, and quality risks to the State
• Comply with mandatory COMAR 21 requirements
• Document any known project risks so offerors can understand and respond with solutions that may mitigate these risks

A.     The nine project management knowledge areas in the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK). The TO Contractor(s) shall follow the project management methodologies that are consistent with the most recent edition of the PMBOK Guide. TO Contractor’s staff and subcontractors are to follow a consistent methodology for all TO activities.

B.     The State’s SDLC methodology at: www.DoIT.maryland.gov - keyword: SDLC.

C.     The State’s IT Security Policy and Standards at: www.DoIT.maryland.gov - keyword: Security Policy.

D.    The State’s IT Project Oversight at: www.DoIT.maryland.gov - keyword: IT Project Oversight.

E.     The State of Maryland Enterprise Architecture at www.DoIT.maryland.gov - keyword: MTAF (Maryland Technical Architecture Framework).

F.     Nonvisual Access Clause for Information Technology Procurements at www.DoIT.maryland.gov – keyword: Nonvisual Access.

All RFPs and TORFPs must explicitly require contractors who propose alternative development methodologies to include an SDLC compliance approach, which describes in detail how they will comply with all SDLC requirements, in their proposals.

4.15.4 Dos and Don’ts

• Do write concise and clear RFPs.
• Do include deliverable acceptance criteria.
• Do identify when deliverables are required.
• Do identify contractor performance metrics.
• Do include deliverables specifically relevant to the type of project.
• Don’t complete the RFP until the draft FRD is completed and approved.
• Don’t confuse the RFP with a planning document.  Planning must be completed well before the RFP and documented in the PMP.

4.16 Establish Evaluation Committee.

The Procurement Officer and Project Manager solicit input from the Agency CIO and Business Sponsor and designate agency personnel and end users for the Agency Evaluation Committee (AEC). AEC staff should include:

• Business and technical subject matter experts (SMEs) who are knowledgeable about their respective domains and can evaluate responses
• Enough members to cover all select seller activities
• Members who have sufficient time to participate in the evaluation

4.17 Select Contractor(s).

The AEC follows a formal evaluation process to review and select the contractor using the evaluation method and evaluation criteria defined earlier. Under the guidance of the Procurement Officer, the AEC evaluates each proposal according to all applicable State laws and regulations. The AEC determines technical ratings based on the evaluation criteria outlined in the RFP/TORFP. After the technical rankings, the Procurement Officer forwards financial proposals for each qualified proposal to the AEC. The AEC establishes the financial rankings and determines the combined technical and financial ranking of each qualified proposal. Based on these rankings, the AEC recommends an awardee based on best value.

Specific procedures for CATS Task Order contractor selection and award are included on the CATS+ TORFP Preparation, Solicitation, and Award Process web page and the CATS+ State ADPICS Processing Procedures document. Refer to these documents and others on DoIT's website.

4.18 Validate Requirements and Finalize COTS Fit-Gap Analysis.

Immediately after the initiation of the COTS contractor, team members must work together to validate requirements and complete the COTS fit-gap analysis to achieve the following:

• Ensure that requirements are correct, unambiguous, complete, consistent, ranked for importance, testable, and traceable.
• Ensure a common understanding of requirements among stakeholders, the agency team, and the vendor team.
• Plan how each requirement will be verified. The output of the requirements validation process is documented in an updated RTM and FRD.
• Determine all gaps between the capabilities provided by the COTS components and the capability required for the system, as well as the customization required to address the gaps The resulting COTS Fit-Gap Analysis document must identify requirements that:
• Exist in the COTS with no change required
• Exist in the COTS but require configuration
• Need to be added to the COTS product
• Need to be removed from the COTS product
• Need change in business process
• Identify and document in the COTS Fit-Gap Analysis how each validated requirement will be achieved by the COTS solution (i.e., through configuration, customization, or business process change).

• Validate and correct assumptions regarding the fit between stakeholder expectations and COTS functionality
• Improve stakeholder understanding of COTS features and functionality
• Leverage existing COTS functionality with modifications to business processes
• Obtain a more accurate understanding of the activities and effort necessary to meet stakeholder expectations
• Obtain information necessary to finalize "To Be" business processes

4.19 Finalize "To Be" Business Processes.

In order to leverage existing COTS functionality, COTS implementation projects require much more stakeholder negotiation and compromise. As planning teams complete the COTS fit-gap analysis, they may decide to modify business processes to use base COTS functionality, minimize customization risk, and minimize customization costs and associated schedule extensions. After the completion of the final COTS fit-gap analysis, agencies must update and finalize the “To Be” business process model to be consistent with decisions made in the fit-gap analysis.

The updates for "To Be" business processes are typically driven by the gaps identified in the fit-gap analysis. As the Planning Team, including stakeholders and vendors, discuss the options to address identified gaps between COTS functionality, requirements, and stakeholder expectations, they should consider the possibility of modifying business processes to utilize existing COTS functionality. The final decision for each gap should be based upon a cost-benefit analysis that considers the level of organizational change and risk associated with modifying the business process. For SaaS efforts, agencies should understand configuration limitations and the increased need for business process change and plan early to address the risks associated with the change. To ensure that stakeholders have the information they need to finalize and adopt “To Be” business processes, stakeholders must participate in hands-on experiments with the solution to fully conceptualize how the business need will be met.

4.20 Develop Business Process Change Management Plan.

Agencies must explicitly identify and document the plan to implement agreed-upon changes to the end users’ business processes. This plan should account for all types of end users and the changes necessary for individuals and organizations.

The Project Manager must identify all necessary activities, resources, tools, and associated estimates to achieve required changes to the business processes.  It is critical that the Project Manager obtain input from representative end users to ensure that the Business Process Change Management Plan is comprehensive, realistic, and accepted by stakeholders. Upon completion of the plan, the project schedule and other project management plans must be updated to account for all necessary implementation activities and time required for effective adoption.

Specifically, the Business Process Change Management Plan must address the following:

• Process, tools, and stakeholders necessary to manage business process changes
• Assigned members of the Change Office
• Work Breakdown Structure, resource assignments, and schedule for iteratively implementing business process changes
• New processes and procedures to be developed and implemented
• Communication, training, and adoption methods
• Expected results of business process changes and method of evaluation
• Process for modifying the Business Process Change Management Plan

4.21 Staff Development Team.

The Project Manager locates and assigns qualified, available agency personnel to be members of the Development Team. Ensure the Development Team understands the PSS.

4.22 Develop Test Master Plan.

The Project Manager with extensive input from the Agency CIO and Business Owner develops the TMP, which documents the testing of all aspects of the system. Defining the test plans this early in the life cycle allows teams, project stakeholders, and agency management to obtain a more accurate understanding of the effort and schedule required to ensure system quality.

4.22.1 Document Description

The TMP documents the scope, content, methodology, sequence, management of, and responsibilities for test activities.

4.22.2 Typical Content

The TMP must identify the scope, content, methodology, sequence, management of, and responsibilities for all test activities, including:

• Unit/module testing
• Subsystem integration testing
• Independent security testing
• System testing
• Independent acceptance testing
• Regression testing
• Beta testing

4.22.3 Guidance for Document Development

The Project Manager should specify in the TMP how test activities will be managed, including organization, relationships, and responsibilities. The TMP should also document how test results will be verified and how the system will be validated.

The Project Manager updates the RTM to include a TMP reference that indicates the testing of each requirement. Elaboration of testing plans occurs in the Design and Development Phases.

4.22.4 Dos and Don'ts

• Do consider all types of testing activities required to meet project requirements.
• Do involve end users in determining the nature and extent of tests to be conducted.
• Do address how the TMP will be updated to include progressively more detail as the system is developed.

4.23 Perform Phase-Closure Activities.

The Project Manager compares actual project performance to the PMP and the projected cost of the project to determine any variances from the cost baseline during the phase-end review. The Project Manager also performs a comprehensive risk assessment of the project to update the Risk Register before beginning the next phase, Design.

• Status of Requirements Analysis Phase activities
• Planning status for all subsequent life cycle phases, with significant detail about the Design Phase (such as the status of pending contracts)
• Status on resource availability
• Project scope control as described in the PSS
• Changes to the project schedule and estimated completion date
• "Go-No Go" decision made to proceed to next phase, based on Requirements Analysis Phase information
• Verification that all changes are conducted in accordance with the approved Change Management Plan

Back To Top

5.0 Conclusions

The approval of the Functional Requirements Document, Requirements Traceability Matrix, and the Test Master Plan as well as the completion of the Requirements Analysis project status review and approval to proceed to the next phase signify the end of the Requirements Analysis Phase.

​ ​​

During the Design Phase, the system is designed to satisfy the requirements identified in the previous phases.  The requirements identified in the Requirements Analysis Phase are transformed into a System Design Document that accurately describes the design of the system and that can be used as an input to system development in​ the next phase.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Design Phase should comprise:

• Transformation of all requirements into detailed specifications covering all aspects of the system
• Assessment and planning for security risks
• Approval to progress to the Development Phase

Goals

The purpose of the Design Phase is to transform the requirements into complete and detailed system design specifications.  Once the design is approved, the Development Team begins the Development Phase.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content. 

The development and distribution of SDLC deliverables:

• Ensure common understanding among Development Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Development Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present. The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project.
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.  DoIT will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities of this phase:

• Project Sponsor
• Executive Sponsor
• Agency CIO
• Project Manager
• Development Team
• Project Stakeholders
• Security Officer
• Secretary of DoIT

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The Project Manager ensures the following prerequisites for this phase are complete:

• The PMP and the schedule showing the target termination date for the system are current.
• The PSS is current and complete.
• The FRD is complete.
• Procurement for development work is complete.

4.2 Monitor Project Performance.

The Project Manager monitors project performance by gathering status information about:

• Cost expenditures to date and cost variances from the cost performance baseline
• Change management information
• Activity progress with status details from all Development Team members
• Vendor contract compliance
• Vendor status reports
• Risk Register review
• Late tasks review
• List of complete and incomplete deliverables
• WBS activities started and finished
• Estimated time to completion
• Resource utilization data
• Changes to project scope

4.3 Update PMP and Communication Management Plan. 

The Project Manager updates the PMP routinely (at least quarterly) to ensure the PMP reflects project performance accurately.  Review project performance controls and risks for deviations from the baseline.

Information distribution is one of the most important responsibilities of the Project Manager. The Project Manager reviews and updates the Communication Management Plan at least quarterly to account for potential changes in project stakeholders. The Project Manager distributes the updated PMP and risk management information according to the revised Communication Management Plan.  PMBOK, section 10 contains additional details on project communications and information distribution.

4.4 Perform Risk Management Activities.

The Project Manager conducts periodic risk management activities during the Design Phase; these activities include:

• Identification – determination of initial risks that might affect the project and emerging risks as well as each risk characteristic
• Risk Analysis – conducting quantitative and/or qualitative analysis of each identified risk. Usually, qualitative risk management techniques are the most applicable for State projects. These risk analysis methods, as well as the conditions under which each method might be used, are described in detail in PMBOK, section 11.
• Response Planning – planning of methods for developing mitigation, transfer, or avoidance strategies to reduce risk
• Monitoring and Control – definition of procedures to track risks, monitor residual risk, identify new risks, execute response plans, and evaluate risk management effectiveness

4.5 Submit the Quarterly Update Review.

The Project Manager assembles all project documentation, including the Communication Management Plan, PMP, issue logs, and any other relevant artifacts reflecting day-to-day management of the project, each quarter and submits this information to DoIT as a quarterly update review.  DoIT reviews this information, particularly differences from the previous quarter and determines whether to recommend any action.

4.6 Initiate Design Activities.

The Development Team has several important decisions to make as the solution begins to take shape.  During the process of creating the design, the Project Manager and Development Team should consult with other agencies for possible components to integrate into the new system, potentially saving money through reuse.  Project stakeholders should be involved periodically throughout the Design Phase to ensure that the development team understands their expectations and that it develops the system in accordance with requirements.

The Development Team makes critical design decisions, including:

• Approach decisions
  • Validate proposed COTS components
  • Prototype to refine and improve understanding of requirements
  • Select development and implementation methodologies and tools
  • Determine how user support will be provided, how the remaining life cycle phases will be integrated, and newly identified risks and issues handled
  • Determine user acceptance criteria (refer to the User Acceptance page in Related Links)
• Execution decisions
  • Identify modifications that must be made to the initial information system need
  • Identify modifications that will be made to current procedures
  • Identify modifications that will be made to current systems/databases or to other systems/databases under development
  • Determine how conversion of existing data will occur
• Continuation decisions
• Determine continued development activities based on needs identified in design
• Identify availability of sufficient funding and other required resources for the remainder of the life cycle

4.7 Manage Configuration and Change Processes.

The Development Team sets up a configuration management repository and establishes change management procedures to track changes to the system, ensure requirements compliance, and enhance development quality.

This effort involves three inter-related concepts:

• Configuration management – focuses on establishing and maintaining consistency in the system’s performance and its functions throughout its life cycle.
• Change management – the process of requesting, planning, implementing, and evaluating changes to the system; this process supports changes to the system and allows for their traceability.
• Change control – ensures that changes to the system are introduced by a controlled and coordinated method; change control is a part of change management.

4.8 Revalidate Functional and Non-Functional Scope.

The Project Manager schedules a review of the system requirements, both functional and non-functional, to ensure the scope has not changed since the end of the Requirements Analysis Phase.  This review ensures that the design specifications are consistent with the requirements and with user expectations.

4.9 Develop the System Design Document.

The Development Team constructs the System Design Document (SDD), which maps the system requirements to the technical implementation and contains details about the environment, hardware architecture, software architecture – including subsystems and components, files, database design – and internal and external interfaces.

4.9.1 Document Description

The System Design Document describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, human-machine interfaces, detailed design, processing logic, and external interfaces.

4.9.2 Typical Content

The key elements of the SDD include the following. Additional guidance is provided in the SDLC template.

• Software components
  • A description of software modules and their use to build operating components
  • A list of components and how they are connected including middleware
  • Traces of key business processes through all components
  • Design for individual custom components (e.g. class diagrams, behavioral diagrams, persistence models, concurrency strategies and tactics, interfaces, inputs and outputs)
  • Documentation of all protocols and data transfer syntax and semantics for all internal and external interfaces
  • Dependencies between modules as well as external programs or source code for custom components
  • Dependencies between components
• Diagrams
  • A deployment diagram
  • A network diagram
  • Data flow diagrams
  • Data model
  • Context diagram for each component
• Supporting technologies
• Description of security architecture
• Description of availability and scalability strategy
• Description of how to monitor the production system
• Project or system decisions
• Description of the build process
• Description of the deployment process
• Map of requirements/features to the modules and components that implement them
• Documentation of architecture, frameworks, and design patterns used or developed in the design and the rationale for their selection
• User interface design if COTS interfaces will be customized (Refer to Nonvisual Access Regulatory Standards on the Maryland.gov site)
• User acceptance testing scripts and activities (Refer to the User Acceptance page in Related Links)

4.9.3 Guidance for Document Development

The effort to develop the SDD may iterate through several cycles from a general design to the desired level of granularity as significant architecture decisions are made and the design moves toward the target architecture.

The SDD documents the transformation of abstract business requirements to detailed hardware and software specifications for construction and assembly.

Agencies are strongly encouraged to iteratively prototype system components during the Design Phase to:

• Enable stakeholder involvement in system design
• Keep the project focused on business needs
• Demonstrate evolving design concepts
• Facilitate effective communication between stakeholders and the vendor team
• Obtain stakeholder buy-in
• Identify functional and technical issues early
• Validate that the design solution being developed provides the best overall fit and satisfies functional and non-functional requirements
• Demonstrates a common understanding of the solution achieved through negotiation with stakeholders
• Reduce uncertainty and risks associated with implementation

4.9.4 Dos and Don’ts

• Do conduct periodic design reviews as the Development Team formulates design and develops the SDD.
• Do utilize prototyping to elicit stakeholder feedback in the design process.
• Do ensure that the SDD addresses all aspects of the system design in detail.
• Don’t postpone any aspect of detailed design until a later phase. 

4.10 Update the Requirements Traceability Matrix.

The Development Team updates the RTM after the SDD is approved. An RTM aids in moving from requirements to design and enabling the Systems Team to track problems occurring in the Operations and Maintenance Phase back through testing and design to original requirements.

4.11 Update Test Plans.

The Development Team builds on the TMP created in the Requirements Analysis Phase as the system architecture and its components are specified. Refine test cases and procedures as the design process continues.

4.12 Build a System Security Consensus Document.

The Project Manager coordinates a comprehensive security risk assessment, which addresses threats, vulnerabilities, risks, outcomes, and security controls and documents the results in the SSCD. The risk assessment evaluates compliance with baseline security requirements, identifies threats and vulnerabilities, and assesses alternatives for mitigating or accepting residual risks.

4.12.1 Document Description

The SSCD includes a definition of the system and its security architecture, security policies, risk assessments, and security test plans.

4.12.2 Typical Content

The key elements of the SSCD include at minimum:

• Mission description
• System identification
• Environment and threat description
• System architecture description
• Certification and Accreditation team
• Tailored Certification and Accreditation process

4.12.3 Guidance for Document Development

The SSCD is designed to retain all information for the C&A in one document. State policy for IT systems requires that all Executive Branch agencies certify and accredit the IT systems and sites under their ownership and control. The Development Team should review the DoIT Information Technology Security Certification and Accreditation Guidelines and the project’s SSCD for any actions needed to enable the system to become certified and accredited prior to implementation. These documents are available at the DoIT State Information Technology Security Policy and Standards webpage.

In addition, the Development Team should review all applicable federal government guidance to ensure relevant security requirements are addressed:

• National Security Agency (NSA) Security Recommendation Guides
• Federal Information Security Management Act (FISMA)
• National Institution of Standards & Technology (NIST) Special Publication 800-12 An Introduction to Computer Security: The NIST Handbook
• NIST Special Publication 800-30 Risk Management Guide for Information Technology
• NIST Special Publication 800-41 Guidelines on Firewalls and Firewall Policy
• NIST Special Publication 800-44 Guidelines for Securing Public Web Servers.
• NIST Special Publication 800-45 Guidelines for Electronic Mail Security
• NIST Special Publication 800-55 Security Metrics Guide for Information Technology Systems
• NIST Special Publication 800-83 Guide to Malware Incident Prevention and Handling
• NIST Special Publication 800-88 Media Sanitization Guide
• NIST Special Publication 800-100 Information Security Handbook

4.13 Develop the Security Plan.

The Development Team develops the Security Plan to address security risks identified in the SSCD.

4.13.1 Document Description​

The Security Plan documents the scope, approach, and resources required to assure system security.

4.13.2 Typical Content

The key elements of the Security Plan include at minimum:

• Security personnel and their responsibilities
• Secure operating environment description
• Sensitivity of information handled
• External system dependencies
• Access authorization
• Information sharing restrictions
• Physical protection requirements
• Countermeasures to be used to mitigate vulnerabilities identified in SSCD
• Description of how security requirements will be met
• Description of security support structure
• References to relevant security policies and standards
• Network audit policies to be executed including the C&A schedule
• Security incident reporting
• Work breakdown and schedule of security activities

4.13.3 Guidance for Document Development

The Development Team should create the Security Plan after the SSCD to ensure that all known vulnerabilities and requirements are addressed. The purpose of the Security Plan is to specifically identify all planned controls and activities necessary to meet security requirements. The document also outlines responsibilities of all system users.

4.14 Develop a Disaster Recovery Plan.

The Project Manager also coordinates with the Development Team and project stakeholders to define a Disaster Recovery Plan (DRP) for the system.

4.14.1 Document Description

The DRP is an IT-focused plan designed to restore operability of targeted systems, applications, or a computer facility due to a natural or man-made extended interruption of an agency’s business services.

4.14.2 Typical Content

The key elements of the DRP include at minimum:

• Concept of operations
• Notification procedures
• Plan activation criteria
• Damage assessment procedures
• Recovery activities
• Reconstitution procedures

4.14.3 Guidance for Document Development

The Development Team should conduct a Business Impact Analysis (BIA) to identify IT resources, identify outage impacts and allowable times, and develop recovery priorities.

The information gathered during the BIA serves as critical input to the DRP. The DRP should also address operability risk mitigation strategies identified during the security risk assessment.

Additional DRP guidance may be found in the State of Maryland Information Technology Disaster Recovery Guidelines found on the DoIT website.

For SaaS-only implementations, the SaaS vendor should be able to provide the State with their Disaster Recovery Plan.

4.14.4 Dos and Don’ts

• Do protect the DRP with the same level of controls used to protect sensitive data from unwarranted disclosure.

4.15 Plan the System Integration.

The Development Team develops an Integration Document to assemble the software units, software components, and the hardware into the system. The document includes procedures, responsibilities, and a schedule for combining the units into a working information system.

The Project Manager and Development Team review the Integration Document while considering:

• Traceability to the system requirements
• Consistency with system design
• Quality of units based on test results

4.16 Plan the System Implementation.

The Development Team begins documenting implementation procedures for the system in the target environment, including any necessary resources and information. The implementation procedures include migration strategies to support running parallel activities during the transition. The Conversion and Implementation Plans should address data migration task to ensure a smooth implementation. The Conversion Plan should address the design and development of conversion approach to extract, transform, and load data into the new system. The approach may require the development of conversion programs and utilities during the Development Phase and subsequent iterative testing of conversion programs and utilities during the Testing Phase.

Identify implementation resources from the Development Team, which may be a combination of State employees and external vendors, based on the technologies and the implementation methodology. The implementation resources must have technical skills, the ability to communicate issues and changes, understanding of both the problem domain and the implementation environment, and good leadership.

The Conversion Plan, Implementation Plan, and the Training Plan should be in draft form by the end of the Design Phase.

4.17 Plan for Operations and Maintenance Activities.

The Project Manager and Development Team draft an Operations or System Administration Manual and a Maintenance Manual. The System Teams will use these documents during the Operations and Maintenance Phase to support the system.

Schedule a review near the end of the Design Phase to evaluate any particular operations or maintenance requirements for system administration. Operations and Maintenance planning is not applicable for SaaS-only implementations, however SaaS vendors should be able to provide documented evidence that operations, maintenance, and system administration activities are planned in detail and consistently executed as planned.

The User Manual should be in draft form at the end of this phase.

4.18 Create a Data Retention Plan.

The Development Team creates a formal Data Retention Plan according to the policies and standards established by the State Archivist.

4.18.1 Document Description

The Data Retention Plan describes the project policies for data and records management.

4.18.2 Typical Content

The key elements of the Data Retention Plan include at minimum:

• Retention and disposition responsibilities
• Retention and disposition requirements
• Retention and disposition schedules
• Management process

4.18.3 Guidance for Document Development

State of Maryland has legally mandated data retention policies that apply to all State agencies and State-created entities and any public records.  The State Archivist’s website has records management guidance, including the laws, rules, and regulations, at http://www.msa.md.gov/msa/intromsa/html/record_mgmt/homepage.html. The Code of Maryland states that “The willful, unauthorized destruction or alienation of any public record is a misdemeanor subject to criminal penalties.”  The State policy is that “a public record may not be disposed of without authorization from the State Archivist” and expects any part of the State, county, or local governments to follow this policy.  This site provides additional guidance on how to develop a records retention schedule, which in turn helps the agency and Development Team create a Data Retention Plan for the project.

The Project Manager reviews the Data Retention Plan with the Development Team and project stakeholders to ensure acceptance and compliance.

4.19 Conduct Design Reviews. 

The Project Manager oversees periodic system design reviews of the system functions, performance requirements, security requirements, and platform characteristics.

A system/subsystem design review is held at the end of the Design Phase to resolve open issues regarding one or more of the following:

• System-wide or subsystem-wide design decisions
• Architectural design of a software system or subsystem

A software design review is held at the end of the Design Phase to resolve open issues regarding one or more of the following:

• Software-wide design decisions
• Architectural design of a software item
• Detailed design of a software item or portion thereof (such as a database)

4.20 Perform Phase-Closure Activities.

The Project Manager and the Development Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completion of all Design Phase tasks.  This review addresses:

• Cost expenditures to date and cost variances to the cost performance baseline
• Status of Design Phase activities
• Planning status for all subsequent life cycle phases, with significant detail about the next phase
• Status on resource availability
• Project scope control as described in the Project Scope Statement and any required adjustments
• Changes to the project schedule and estimated completion date
• Vendor contract compliance
• A final design review of the system covering issues raised in earlier design reviews
• “Go-No Go” decision made to proceed to next phase, based on Design Phase information
• Acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy
• Verification that all changes are conducted in accordance with the approved Change Management Plan

Back To Top

5.0 Conclusions

The Design Phase results in one of the two key elements to the project: the design. Without a detailed design, the second key element, the system, cannot be constructed, implemented, trained upon, or operated.  The decisions made in this phase regarding technology, frameworks, implementation, and configuration and change management ensure a sound foundation for the project.  While ambiguous requirements are the greatest source of project failure, a poor design ranks second.  The approval of the Design Phase deliverables, the completion of the Design project status review, and the approval to proceed to the next phase, signify the end of the Design Phase.

​​​​

The Development Phase features a key step in the project: system construction. The previous phases lay the foundation for system development; the following phases ensure that the product functions as required. To complete the Development Phase successfully, two elements are required: 1) a complete set of design specifications and 2) proper processes, standards, and tools. The focus of the Development Phase is on the preparation of a production-quality release of the selected COTS solution.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Development Phase should comprise:

• Installing and building the system
• Testing and integrating the units into larger components
• Preparing the technical environment for the system
• Approval to progress to the Test Phase

Goals

The purpose of the Development Phase is to convert the system design prototyped in the Design Phase into a working information system that addresses all documented system requirements.  At the end of this phase, the working system will enter the Test Phase.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a ramework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content. 

The development and distribution of SDLC deliverables:

• Ensure common understanding among Development Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Development Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present.  The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project.
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase. 

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.  DoIT will periodically request copies of these documents as part of its oversight responsibilities. 

Back To Top

3.0 Roles

The following personnel participate in the work activities of this phase:

• Agency CIO
• Project Sponsor
• Executive Sponsor
• Project Manager
• Development Team
• Project Stakeholders

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The Project Manager ensures the following prerequisites for this phase are complete:

• The Project Management Plan is current, and the schedule showing the target termination date for the system is current.
• The Development Team has completed:
• System Design Document
• Test plans for unit and integration testing (draft)
• Conversion Plan (draft)
• Implementation Plan (draft)
• Integration Document (draft)
• Operations or System Administration Manual (draft)
• Maintenance Manual (draft)
• Training Plan (draft)
• User Manual (draft)

• All changes to baseline data
• Change management information
• Activity progress with status details
• List of complete and incomplete deliverables
• Activities initiated and finished
• Estimated time to completion
• Resource utilization data
• Changes to project scope

4.3 Update PMP and Communication Management Plan.

The Project Manager updates the PMP routinely (at least quarterly) to ensure the PMP reflects project performance accurately.  Review project performance controls and risks for deviations from the baseline.

Information distribution is one of the most important responsibilities of the Project Manager.  The Project Manager reviews and updates the Communication Management Plan at least quarterly to account for potential changes in project stakeholders.  The Project Manager distributes the updated PMP and risk management information according to the revised Communication Management Plan. 

4.4 Perform Risk Management Activities.

The Project Manager conducts risk management activities during the Development Phase; these activities include:

• Identification – determination of initial risks that might affect the project and emerging risks as well as each risk characteristic
• Risk Analysis – conducting quantitative and/or qualitative analysis of each identified risk. Usually, qualitative risk management techniques are the most applicable for State projects. These risk analysis methods, as well as the conditions under which each method might be used, are described in detail in PMBOK, section 11.
• Response Planning – planning of methods for developing mitigation, transfer, or avoidance strategies to reduce risk
• Monitoring and Control – definition of procedures to track risks, monitor residual risk, identify new risks, execute response plans, and evaluate risk management effectiveness

4.5 Initiate Construction Activities.

The Development Team begins construction by:

• Verifying selection for standards, methods, tools, and computer programming languages
• Developing the Software Development Document
• Carrying out Development Phase activities according to the detailed project WBS prepared during the Planning Phase
• Performing configuration management and change control
• Documenting and resolving problems and non-conformances found in the software products and tasks with an issue-tracking process

4.6 Install and Test Base Software.

The Development Team installs the base software and configures components to meet requirements.  This frequently involves initializing and loading databases, registering components with the operating system, setting parameters, initializing security features, scripting screens and reports, developing other scripts, and verifying and testing the results of configuration.  Requirements and design decisions should drive specific activities conducted as part of the installation and testing of the base software.  This activity involves COTS installation and configuration, sometimes referred to as “tailoring”—not customization, modification, adaptations, or extensions that require access to source code.

4.7 Customize and Test Software.

To meet business needs, many COTS implementation projects require some level of customization or modifications to the base software beyond mere configuration.  COTS customization is inherently risky because COTS software modifications frequently negate much of the productivity increase gained from using COTS components and may jeopardize supplier maintenance, support, and upgrades.  As such, decisions to customize COTS solutions must be made with care and after significant efforts to obtain stakeholder consensus to meet business needs through available COTS functionality. SaaS projects do not involve customization.

For projects that do require COTS customization, the team modifies COTS components and develops the custom components necessary to satisfy all requirements and incorporates custom components with pre-existing components.  Care should be taken to ensure that modifications are modular in nature to help mitigate some of the inherent risk in customization.  This activity is performed after the base software is installed, configured, and verified. 

Customization may also require the development of “glue code” to make the COTS software components function as required.  Glue code serves as a layer between the system and the COTS components, wrapping the data in such a way to ensure that upgrades are as seamless as possible.  Again, the amount of custom code should be kept to a minimum, because the greater the amount of custom code, the greater the complexity and difficulty in addressing bug fixes.

The Development Team creates test procedures and data for testing each software unit and database.

The Development Team performs unit tests of each software unit and documents the results in the Test Analysis Report(s).  The Development Team also updates the Requirements Traceability Matrix (RTM) to include pointers to test results and updates the test requirements.

The Development Team conducts routine code reviews to monitor progress and quality according to:

• Traceability to the requirements and design of the system
• Quality of coding documentation
• Test coverage of units
• Resolution of testing deficiencies
• Appropriateness of coding methods and standards used

4.8 Prepare Test Data.

Test data should be prepared with real and varied data in realistic amounts to ensure that testing results mirror production results as much as possible.  Including real data in the test environment allows stakeholders, during acceptance testing, to relate more to the system in a meaningful way and improves effectiveness of testing business rules and algorithms.

4.9 Develop and Conduct Preliminary Data Migration Testing.

Having correct data in the new system is essential to its functioning as intended.  A data migration plan is important for transformation, migration, and modernization projects; entirely new systems will likely have no data to convert and have no Conversion Plan.

A few points about data conversion:

• Information can be discarded easily, but adding information requires effort.
• Computers can only add information according to rules; people can add information in any manner.
• Converting data to a new format with additional features does not create the new information but adds space for it.  A person must enter the new information.
• Some data conversion can occur directly; other data conversion, however, requires several time-consuming steps.
• Data conversion may result in the loss of information if the target format has fewer features than the source format.

4.10 Integrate Software.

The Development Team integrates the software units and software components and tests as the aggregates are developed.  The Development Team must ensure that each aggregate satisfies the requirements of the software item and that the software item is integrated at the conclusion of the integration activity.

4.11 Conduct Integration Testing.

The Development Team conducts integration testing of integrated software units.  Integration testing involves the testing of aggregated software units, which were previously unit-tested.  Through integration testing, Development Teams are able to verify requirements of major groupings of the software.

The Development Team summarizes the testing results in the Test Analysis Report(s). The Development Team also updates the RTM to include pointers to test results. 

4.12 Update the System Implementation Plan.

The Development Team updates the implementation procedures as necessary for the system in the target environment.

4.13 Plan for Operations & Maintenance Activities.

The Project Manager and Development Team review Development Phase deliverables, and the Project Manager adds any necessary tasks to the project plan for the Operations & Maintenance Phase.

4.14 Begin Execution of Business Process Change Management Plan.

In the Development Phase, the Project Manager ensures that all planned business process change activities are conducted in accordance with the Business Process Change Management Plan approved in the Requirements Analysis Phase.  End users begin to implement necessary business process changes and monitor and communicate the implications of these changes.  This may involve development of required policies and procedures, restructuring the organization, and implementing mechanisms to encourage system adoption.

4.15 Monitor the Marketplace.

The Project Manager and Development Team must continue to maintain current market information to identify and evaluate new and changed COTS components and to determine or update their upgrade approach appropriately.

4.16 Complete the System Documentation.

The Development Team finalizes the following documents:

• Conversion Plan
• Implementation Plan
• Maintenance Manual (not applicable for SaaS)
• Operations or Systems Administration Manual (not applicable for SaaS)
• Training Plan
• Release Notes
• User Manual

4.17 Perform Phase-Closure Activities.

The Project Manager and the Development Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completion of all Development Phase tasks.  This review addresses:

• Status of Development Phase activities
• Planning status for all subsequent life cycle phases, with significant detail about the next phase
• Status of resource availability
• Project scope control as described in the Project Scope Statement/System Boundary Document and any required adjustments to the scope
• Changes to the project schedule and estimated completion date
• "Go-No Go" decision made to proceed to next phase, based on Development Phase information
• Verification that all changes are conducted in accordance with the approved Change Management Plan

The Test Phase focuses on an empirical investigation in which the results describe the quality of the system: testing cannot confirm a system functions properly under all conditions but can establish that it fails under specific conditions.  A well-known maxim in software implementation is the earlier a defect is found in the development process the less expensive the fix. Testing early in the system life cycle reduces risks such as schedule delays or cost overruns due to incomplete or unacceptable components. 

In the Test Phase, testing of the system proves that the system meets all requirements, including those for performance and security. The in-depth security testing of this phase identifies any parts of the system that will not satisfy accreditation criteria.  Finally, acceptance testing confirms the developed system satisfies the end users who identified the business need and the requirements.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions​

1.0 Objectives / Goals

Objectives

Successful completion of the Test Phase should comprise:

• Proof through system, security, and user acceptance tests that the system meets all requirements, functions according to design parameters, and satisfies all business, technical, and management stakeholders
• Assurance that the system functions as described in the Operations Manual and User Manual
• Conversion of data from the legacy system
• Approval to progress to the Implementation Phase

Goals

The purpose of the Test Phase is to guarantee that system successfully built and tested in the Development Phase meet all requirements and design parameters. After being tested and accepted, the system moves to the Implementation Phase.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content. 

The development and distribution of SDLC deliverables:

• Ensure common understanding among Development Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Development Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present.  The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project.
• Recycle or reference information from earlier documents where possible and beneficial.
• The following is a listing of deliverables required of all projects for this phase of work.

All deliverables other than those identified as Updates should be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.

DoIT will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities during this phase:

• Project Sponsor
• Executive Sponsor
• Agency CIO
• Project Manager
• Development Team
• Project Stakeholders

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The Project Manager ensures the following prerequisites for this phase have been completed:

• The PMP is current, and the schedule showing the target termination date for the system is current.
• All software and hardware items or units have been constructed and tested.
• Unit and integration test plans and result are final.
• The Conversion Plan for migrating data completely and accurately from the legacy system to the new system is complete.

4.2 Monitor Project Performance.

The Project Manager monitors project performance by gathering status information about:

• All changes to baseline data
• Change management information
• Activity progress with status details
• List of complete and incomplete deliverables
• Activities initiated and finished
• Testing performed and test results
• Estimated time to completion
• Resource utilization data
• Changes to project scope

4.3 Update PMP and Communication Management Plan.

The Project Manager updates the PMP routinely (at least quarterly) to ensure the PMP reflects project performance accurately.  Review project performance controls and risks for deviations from the baseline.

Information distribution is one of the most important responsibilities of the Project Manager.  The Project Manager reviews and updates the Communication Management Plan at least quarterly to document potential stakeholder changes. The Project Manager redistributes the updated PMP and risk management information according to the revised Communication Management Plan.

4.4 Perform Risk Management Activities.

The Project Manager conducts risk assessments during the Test Phase; these activities include:

• Identification – determination of initial and emerging risks that might affect the project as well as each risk characteristic
• Risk Analysis – conducting quantitative and/or qualitative analysis of each identified risk. Usually, qualitative risk management techniques are most applicable for State projects. These risk analysis methods, as well as the conditions under which each method might be used, are described in detail in section 11 of PMBOK.
• Response Planning – planning of methods for developing mitigation, transfer, or avoidance strategies to reduce risk
• Monitoring and Control – tracking risks, monitoring residual risk, identifying new risks, executing response plans, and evaluating risk management effectiveness

4.5 Perform Legacy Data Conversion Testing.

The Project Manager reviews, executes, and fully tests the Conversion Plan to migrate legacy data to the new system.  One method of verifying data integrity is parallel operations during which the old system runs simultaneously with the new system.  The output from each system is compared; if all is correct, the new system is certified.  If the new system fails in any way, continue operations on the old system until all problems are resolved.

4.6 Initiate Testing Activities.

The Development Team ensures that all data is loaded to test databases and prepares any internal or external interfaces.

4.7 Conduct System Testing.

The Development Team conducts the system tests according to the test plans and documents all results in the Test Analysis Report, Test Problem Reports, and Test Analysis Approval Determination.  System testing is conducted on a complete, integrated system to determine compliance with all requirements.  System testing includes tests to ensure that the developed system meets all technical requirements, including performance requirements.

Return any failed components to the developers for debugging; move the passing components on to security testing.

Testing may be one of two approaches:

• Static testing – conducting reviews, walkthroughs, and inspection
• Dynamic testing – executing the code for a set of test scripts

• Black box testing approaches the system with no knowledge of the internal components, structure, or functions.  Methods used include boundary value analysis, all-pairs testing, fuzz testing, model-based testing, and specification-based testing.  Black box testing provides an unbiased opinion about the code but has the disadvantage of being blind to interconnections and the rest of the system.
• White box testing allows a tester to have knowledge of the internal code and structure of the system.  Some methods of white box testing include fault injection methods, mutation testing, and static testing.  Combining white box testing with black box testing allows evaluation of the completeness of the test suite and infrequently tested parts of the system and ensures critical functions have been tested.

4.8 Conduct Security Testing. 

The Development Team again reloads the test databases, executes the security/penetration tests, and documents all test results.  Return any failed components to the developers for debugging; move the passing components on to acceptance testing after all components have passed system and security testing.

Test security controls prior to the system deployment to uncover all design and implementation flaws that might violate DoIT’s security policy. Security testing involves numerous methods, such as analyzing system design documentation, inspecting test documentation, and independently executing functional and penetration testing.

State policy for IT systems requires that all Executive Branch agencies certify and accredit IT systems and sites under their ownership and control.  The Development Teamshould review the DoIT Information Technology Security Certification and Accreditation Guidelines and the project's SSCD any actions necessary to enable the system to become certified and accredited prior to implementation.  These documents are available at the DoIT State Information Technology Security Policy and Standards webpage.

4.9 Conduct Acceptance Testing.

The Development Team reloads the test databases to start and document the acceptance testing. Users participate in acceptance testing to confirm that the developed system meets all user requirements as stated in the FRD.  Acceptance testing shall be done in a simulated user environment; the users use simulated or real target platforms and infrastructures.  Review, rework, and retest any failed components.  When all components pass acceptance testing, the system is ready for implementation.

4.10 Update System Documentation.

During the Test Phase, problems with interfaces, data structures, and functionality are frequently discovered and require fixes.  The Project Manager ensures that the documentation reflects any changes from all previous phases as well as changes that occurred during this Phase.  This documentation includes the Conversion Plan, the Operations or Systems Administration Manual, the Maintenance Manual, the Training Plan, and the User Guide.  The Project Manager coordinates these updates.

4.11 Continue Execution of Business Process Change Management Plan.

The Project Manager ensures that all planned business process change activities are conducted in accordance with the Business Process Change Management Plan approved in the Requirements Analysis Phase.  End users continue to implement necessary business process changes and monitor and communicate the implications of these changes. 

4.12 Monitor the Marketplace.

The Project Manager and Development Team must continue to maintain current market information to identify and evaluate new and changed COTS components and to determine or update their upgrade approach appropriately.

4.13 Review Implementation Procedures.

Bearing in mind any modifications that result from testing, the Project Manager and Development Team review implementation procedures, including any necessary resources and information, for deploying the system in its target environment.

4.14 Make System "Go-No Go" Decision.

The Agency CIO and Project Sponsor decide whether to perform additional testing or to proceed to the next phase, Implementation.  They review the system requirements, the user acceptance criteria, and the user acceptance test results and consult with others about the condition of the project and the state of completeness of the system.  Using the requirements and acceptance criteria as a quantitative base, they consider other qualitative factors through a collaborative discussion to arrive at the “Go-No Go” decision.  This critical project decision can move the system to a production state.

4.15 Perform Phase-Closure Activities.

The Project Manager and the Development Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completing all Test Phase tasks. This review addresses:

• Status of Test Phase activities
• Planning status for all subsequent life cycle phases, with significant detail about the next phase
• Status of resource availability
• Project scope control as described in the Project Scope Statement and any required adjustments to the scope
• Changes to the project schedule and estimated completion date
• "Go-No Go" decision made to proceed to next phase, based on Test Phase information
• Verification that all changes are conducted in accordance with the approved Change Management Plan

The Project Manager must obtain deliverable approval signatures before proceeding to the Implementation Phase.

Update the project documentation repository upon completion of the phase-closure activities.

The Implementation Phase has one key activity: installing and releasing the new system in its target environment. Supporting actions include training end-users and preparing to turn the system over to ​maintenance personnel. After this phase, the system enters the Operations and Maintenance Phase for the remainder of the system’s operational life.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives 

Successful completion of the Implementation Phase should comprise:

• Production installation and release
• Training of end users on the system

Goals

The purpose of the Implementation Phase is to deploy and enable operations of the new information system in the production environment.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated. The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize. State agencies may use formats other than the templates, as long as the deliverables include all required content.

The development and distribution of SDLC deliverables:

• Ensure common understanding among Development Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Development Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present.  The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project.
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.  DoIT will periodically request copies of these documents as part of its oversight responsibilities.

During the Operations and Maintenance Phase, the information system’s availability and performance in executing the work for which it was designed is maintained.  The State realizes the largest value for the system during this phase.  System operations continue until the system’s termination date, when the next phase, Disposition, begins.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Operations and Maintenance Phase should comprise:

• Management of changes to the system to support end users
• Monitoring of system performance
• Performance of required security activities such as backups, contingency planning, and audits
• Continuation of end user support through training and documentation

Goals

The purpose of the Operations and Maintenance Phase is to ensure the information system is fully functional and performs optimally until the system reaches its end of life.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content.

The development and distribution of SDLC deliverables:

• Ensure common understanding among Systems Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Systems Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present. The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project.
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.

DoIT will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities during this phase:

• Agency CIO
• System Manager
• Systems Team
• Process Improvement Review Board
• Security Officer
• Procurement Officer
• Business Owner
• Project Stakeholders 

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The System Manager ensures the following prerequisites for this phase are complete:

• System has been successfully deployed and is fully functional.
• Operations or System Administration Manual is complete and current.
• User Guide is complete and current.
• End-users have received training on proper system use.
• System documentation is complete and available.
• All deficiencies noted in the Implementation Phase are being corrected.
• System has completed Certification and Accreditation according to DoIT guidelines.

4.2 Monitor Phase Performance.

The System Manager monitors phase performance by gathering status information about:

• All changes to baseline system performance
• Change management information
• Activity progress with status details
• Activities initiated and finished
• Testing results and deliverable acceptance
• Resource utilization data

4.3 Update PMP and Communication Management Plan.

The System Manager updates the PMP routinely (at least quarterly) to ensure the PMP reflects project performance accurately.  Review project performance controls and risks for deviations from the baseline.

Information dissemination is one of the most important responsibilities of the System Manager.  The Project Manager reviews and updates the Communication Management Plan at least quarterly to account for potential changes in project stakeholders.  The System Manager distributes the updated PMP and risk management information according to the revised Communication Management Plan.

4.4 Perform Risk Management Activities.

The System Manager conducts risk management activities during the Implementation Phase; these activities include:

• Identification – determination of risks that might affect the project and emerging risks as well as each risk characteristic
• Risk Analysis – conducting quantitative and/or qualitative analysis of each identified risk. Usually, qualitative risk management techniques are the most applicable for State projects.  These risk analysis methods, as well as the conditions under which each method might be used, are described in detail in section 11 of PMBOK.
• Response Planning – planning of methods for developing mitigation, transfer, or avoidance strategies to reduce risk
• Monitoring and Control – tracking risks, monitoring residual risk, identifying new risks, executing response plans, and evaluating risk management effectiveness

4.5 Support System Operations.

The Systems Team supports the system and its end users as an integral part of the information system’s day-to-day operations.  The Operations or System Administration Manual defines tasks, activities, and responsible parties for these daily activities and must be updated as changes occur.  By monitoring the system continuously, the Systems Team ensures that the production environment is fully functional and performs as specified.  Critical support tasks and activities include:

• Guarantee of required system availability
• Implementation of non-emergency requests during scheduled outages
• Ensuring the documentation in the operating procedures of all processes, manual and automated
• Acquisition of critical system supplies (e.g. paper, cabling, toner, tapes, removable disks) before the supply is exhausted
• Performance of routine backup and recovery procedures
• Performance of physical security functions by ensuring all system staff and end users have the proper clearances and access privileges
• Ensuring currency and testing of contingency planning for disaster recovery
• Ensuring periodic training on current and new processes for end users
• Ensuring monitoring and meeting of service level objectives while taking remedial actions for any deficiencies
• Monitoring of performance measurements, statistics, and system logs

• Date and time
• Issue reporter
• Problem description
• Apparent cause
• Assigned developer
• Resolution
• Test results

4.6 Perform Software and Data Administration.

The Systems Team constantly monitors and performs software and data administration.  Team members also monitor software performance to ensure transactions are executed correctly and accurately.  The Systems Team performs administrative tasks such as:

• Performance of production control and quality control functions
• Interfacing with other functional areas to maintain system integrity
• Installation, configuration, upgrade, and maintenance of databases and update of any related system documentation
• Development and performance of data and database backup and recovery routines for data integrity and recoverability as documented in the Operations or System Administration Manual
• Development and maintenance of a performance and tuning plan for online processes and databases
• Performance of configuration and design audits to correct software, system, parameter, and configuration deviations 

4.7 Perform System Maintenance.

The System Manager and the Systems Team continuously monitor the performance of the system in regard to hardware, software, databases, and network.  Daily operations of the system require identifying and implementing minor modifications for it to function optimally and correctly.  Document these modifications using a Change Implementation Notice in the configuration management repository, and follow the change management process to receive approval for the modifications.  The Change Implementation Notice contains a requested change to the system by a user and its priority or urgency.

Maryland law states that agencies must have the approval of the Agency CIO:

…before making expenditures on major information technology development projects (MITDP), which were defined as projects that included planning, procuring, creating, installing, testing, or providing initial training on an IT project in which:

• the estimated total cost equals or exceeds $1 million;
• the project is undertaken to support a critical business function associated with the public health, education, safety, or financial well-being of the citizens of Maryland; or
• the Secretary of Budget and Management determines that the project requires the special attention and consideration given to a MITDP.

-- SB212, Acts of 2008

Change requests that meet the following criteria are maintenance work:

• Estimated cost of modifications are below maintenance costs
• Proposed changes can be implemented within one system year
• Impact to system is minimal or necessary for accuracy of system output   

4.8 Enhance System Configuration.

The Systems Team implements changes to the information system to upgrade hardware and add new or remove old functionality.  These enhancements might originate with user requests for specific capabilities or from the Systems Team’s identifying solutions to substantive routine system problems. Document any enhancements using a Change Implementation Notice, and follow the change management process to receive approval for the enhancement.  All maintenance and enhancements are part of a continuous improvement process for the system.

After the system has been implemented, any major system modifications required must follow the configuration management process from planning through implementation.  

4.9 Monitor System Security.

The Security Officer monitors the security of the information system according to the System Security Plan.  As modifications occur, the Security Officer confirms the System Security Plan is current.  As a part of reviewing system security, the Security Officer performs a risk assessment and analysis; the results provide the basis for new or modified security controls.  The Security Officer also oversees routine testing of the Disaster Recovery Plan.

When a security incident occurs, the Systems Team sends an incident report to the System Manager.  These incident reports must be filed with the State’s Incident Response Group.  The System Manager routinely reviews the regular system security reports with the Security Officer.

The System Manager routinely reviews DoIT’s security policies and standards on DoIT’s website and guidelines endorsed by NIST and the NSA.  The System Manager and Security Officer coordinate with project stakeholders on regular disaster recovery tests for the system.  Additional information on security and disaster recovery and best practices is available on the NIST Computer Security Division – Computer Security Resource Center website.

4.10 Update System Documentation.

The System Manager reviews and updates all system documentation, particularly the Operations Manual and Disaster Recovery Plan, as changes occur or on a regularly scheduled basis.

4.11 Review System Performance with End Users.

The System Manager routinely reviews the information system performance with end users to identify changes and problems.  A User Satisfaction Review, which might include a Customer Satisfaction Survey, can obtain feedback on operational systems to help determine if the systems are accurate and reliable.

The System Manager with the Agency CIO conducts the In-Process Review usually quarterly but at least annually.  Agencies should conduct the In-Process Review in mid-year to prepare for annual IT Project Request budgets, due in September.

During the In-Process Review, the System Manager evaluates system performance against baseline performance, user satisfaction with the system, adaptability to changing business needs, and new technologies that might improve the system.  Project stakeholders may request ad hoc reviews when deemed necessary.  The User Satisfaction Review, which can be added to the In-Process Review, can indicate the need for a Process Improvement Review Board meeting or initiation of a proposal for a new system.  The agency should establish a Process Improvement Review Board comprised of project stakeholders representative of all groups impacted by the system.  The Business Process Review Board participates in the In-Process Review meetings to ensure proper communication and decision-making.

4.12 Prepare the Disposition Plan.

4.12.1 Document Description

The Disposition Plan identifies how the termination of the system/data will be conducted, and when, as well as the system termination date, software components to be preserved, data to be preserved, disposition of remaining equipment, and archiving of life cycle products.

4.12.2 Typical Content

The key elements of the Disposition Plan include the following.  Additional guidance is provided in the SDLC template.

• Introduction – Includes purpose and scope, points of contact, project references, and glossary
• Notifications – Describes the plan for notifying known users of the system being shut down and other affected parties
• Data Disposition – Describes the plan for archiving, deleting, or transferring to other systems the data files and related documentation
• Software Disposition – Describes the plan for archiving, deleting, or transferring to other systems the software library files and related documentation
• System Documentation Disposition – Describes the plan for archiving, deleting, or transferring to other systems the hardcopy and softcopy systems and user documentation
• Equipment Disposition – Describes the plan for archiving, deleting, or transferring to other systems the hardware and other equipment
• Project Staff – Describes the plan for notifying project team members of the shutdown of the system, and the transfer of these team members to other projects
• Project Records – Describes the plan for archiving, deleting, or transferring to other projects the records of project activity
• Facilities – Describes the plan for transferring or disposing of facilities used by the project staff for the system being shut down

4.12.3 Guidance for Document Development

The objective of the Disposition Plan is to end the operation of the system in a planned, orderly manner and to ensure that system components and data are properly archived or incorporated into other systems.  At the end of this phase, the system will no longer exist as an independent entity.  The completion of the systems life cycle is carefully planned and documented to avoid disruption of the organizations using the system or the operation of other systems that will use the data and/or software of the present system.

The Agency CIO and Business Owner review and sign the Disposition Plan.

4.12.4 Dos and Don’ts

• Do ensure that the Disposition Plan is consistent with the State Archivist’s records management guidance.
• Do plan to inform users of the decision to terminate operation of the system before the actual termination date.
• Do plan to archive all documentation, including the life-cycle products generated during the earliest tasks of the life cycle as well as the documentation for users and for operation and maintenance personnel.

4.13 Perform Phase-Closure Activities.

The System Manager and the Systems Team prepare and present a system status review for the Agency CIO and other project stakeholders after performing Operations and Maintenance Phase tasks. This review addresses:

• Status of Operations and Maintenance Phase activities
• Planning status for the Disposition Phase
• Status on personnel resource availability for Disposition Phase
• Verification that all changes are conducted in accordance with the approved Change Management Plan

The System Manager also updates the Risk Register before beginning the Disposition Phase.

Back To Top

5.0 Conclusions

During the life of the system, the Operations and Maintenance Phase is the longest and most expensive as the information system provides the most value to the organization in this phase. After system functionally becomes obsolete, the information system is ready to move to retirement in its final phase, the Disposition Phase.

​​​​

The Disposition Phase is the end of an information system’s life cycle. The information system is formally retired according to organizational needs, laws and regulations, and the Disposition Plan. The disposition activities ensure that the information system is terminated in an orderly manner and that vital information about the system is preserved according to applicable records management regulations and policies for future access.

The decision to proceed with the Disposition Phase is based on recommendations and approvals from an In-Process Review during the Operations and Maintenance Phase.

Contents

1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals

Objectives

Successful completion of the Disposition Phase should comprise:

• Notification of end-users
• Notification to Systems Team with reference to interfacing systems
• Shutting down the system
• Disposal of residual assets from the retirement
• Archiving data and system components

Goals

The purpose of the Disposition Phase is to shut down the operational information system in a controlled manner.

Back To Top

2.0 Deliverables and Approvals

SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated.  The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize.  State agencies may use formats other than the templates, as long as the deliverables include all required content. 

The development and distribution of SDLC deliverables:

• Ensure common understanding among Systems Team members and stakeholders,
• Serve as a reminder of specified plans as projects become increasingly complex,
• Provide agency senior management and other State officials insight into project risks and ongoing performance,
• Encourage the execution of repeatable and consistent processes,
• Facilitate the implementation of project management and agency IT best practices, and
• Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).

• Write comprehensive, easy to understand documents with no redundant information.
• Develop an organized document repository for critical project information, so Systems Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
• Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
• Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present.  The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project. 
• Recycle or reference information from earlier documents where possible and beneficial.

All deliverables other than those identified as Updates should be developed in this phase.  Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.

Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table.  A signature page or section should accompany each deliverable requiring approval.

DoIT will periodically request copies of these documents as part of its oversight responsibilities.

Back To Top

3.0 Roles

The following personnel participate in the work activities during this phase:

• Agency CIO
• Business Owner
• System Manager
• Systems Team
• Project Stakeholders 
• State Archivist  

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

The System Manager ensures the following prerequisites for this phase are complete:

• The Disposition Plan drafted in the Operations and Maintenance Phase
• The Data Retention Plan drafted in the Design Phase

4.2 Monitor Phase Performance.

The System Manager monitors phase performance by gathering status information about:

• Activity progress with status details
• Complete and incomplete deliverables
• Estimated time to completion
• Resource utilization data

4.3 Initiate Disposition Activities.

The Systems Team audits comprehensively the information system, its equipment, its data, and its documentation:

• Compare the audit report with the information in the configuration management repository to identify and address any deficiencies.
• Compare the audit report with the information in the asset management repository to identify and address any deficiencies.
• Identify and consider any risks to system disposition.
• Perform any actions noted in the Operations and Maintenance Phase Review.

4.4 Review the Security Plan.

The Systems Team reviews the Security Plan for any requirements for system termination. Both the Security Plan and the Disposition Plan govern the disposition of hardware, software, and data.  The State’s security policies follow guidelines endorsed by the NIST and the NSA.  Information regarding Disposition Phase activities can be found in several different NIST Special Publications, including Generally Accepted Principles and Practices for Securing Information Technology Systems, SP800-14, and Guidelines for Media Sanitization, SP800-88.  Other information on State security policies is available on DoIT’s website.

4.5 Review the Data Retention Plan.

The Systems Team reviews the formal Data Retention Plan that the Development Team and project stakeholders created in the Development Phase.

The State of Maryland has legally mandated data retention policies that apply to all State agencies and State-created entities and any public records maintained.  The State Archivist’s website has records management guidance, including laws, rules, and regulations, at http://www.msa.md.gov/msa/intromsa/html/record_mgmt/homepage.html.

4.6 Update the Disposition Plan.

The Systems Team updates the Disposition Plan as additional detailed plans are defined or changed. 

4.7 Notify End Users and Systems Teams for Interfacing Systems of the System Retirement.

As early as possible, the System Manager notifies all end users of the system's retirement and the termination date.  The System Manager also notifies any Systems Teams working on other systems that interact with the retiring system of the impending termination date.

4.8 Notify the State Archives about the System Termination.

The Systems Team notifies the State Archivist’s office of the system termination. Submit the proper forms for storing state records according to the Data Retention Plan.

4.9 Shut Down the System.

The Systems Team shuts down all software and hardware components in the system on the termination date according to the Disposition Plan.

4.10 Archive or Transfer Data.

The Systems Team transfers data from the old system to the new system or the State Archives according to the Disposition Plan and the Data Retention Plan.

4.11 Archive or Transfer Software Components.

The Systems Team transfers software components to the new system or the State Archives according to the Disposition Plan and the Data Retention Plan. The archived system is the entire application including logs, data, documentation, issue reports, and any other information created during the life cycle of the system.

4.12 Archive Life Cycle Deliverables.

The Systems Team transfers all life cycle deliverables or documentation to the State Archives according to the Disposition Plan and the Data Retention Plan.

4.13 Dispose of Equipment.

The Systems Team assesses the system hardware components and determines whether to reuse, recycle, destroy, or sell the equipment.

4.14 Perform Phase-Closure Activities.

The Systems Team prepares and presents a phase status review for the Agency CIO, Business Owner, and other project stakeholders to address status on Disposition Phase activities.

The System Manager also conducts the Post-Termination Review within six months after system disposition.  The Post-Termination Review documents the findings of the Disposition Phase Review and the lessons learned from shutting down and archiving the terminated system; this report also identifies the repository for all archived products and documentation. The Agency CIO and Business Owner review and sign the Post-Termination Review Report.

Back To Top

5.0 Conclusions

The Disposition Phase is the end of the operational system.

​​​​