SDLC Waterfall Phases

Phase 1: Initiation

 

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.

 The following is a listing of deliverables required of all projects for this phase of work.  

Deliverable

Goals

Developed By

Approved By

Concept Proposal –describes the need or opportunity to improve existing agency business functions using automation and technology.  This document identifies unmet strategic goals or mission performance improvements. ​

  • 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

Project Sponsor

Executive Sponsor

Agency Chief Information Officer (CIO)

Project Charter – identifies the Project Manager, Project Sponsor, and Executive Sponsor and authorizes the Project Manager to execute the project.

  • Develop a broad statement of the purpose of the project
  • Delineate clear project objectives
  • Identify the Executive Sponsor, Project Sponsor, and Project Manager

Project Manager

Executive Sponsor

Project Sponsor

Agency CIO

Project Organization Chart (Draft) – a graphical depiction of the project’s hierarchical positions and relationships.

  • Identify key project personnel
  • Define relationships between the team members
  • Identify required roles

Project Manager

Executive Sponsor

Project Sponsor

Agency CIO

 

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  

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.


 

 

 

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

The Project Sponsor ensures adequate funding for the project and oversees performance of the Planning and Development Teams. The Project Sponsor participates in managing project activities, principally approving key deliverables, resolving issues and risks, and measuring progress to move forward.
 
The Project Sponsor must have a clear understanding of the obligations of this role and have the time and resources to ensure proper execution of the project.  If a potential Project Sponsor will be unable to participate actively in the project and ensure the project’s success, that candidate should decline the role, and the Executive Sponsor, Agency CIO, and the Business Owner should appoint a new Project Sponsor.
 

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

First, describe the value and purpose of the project.  Identify why a new or improved business process is necessary and what business benefits the agency hopes to achieve by implementing the improvement.  The Project Sponsor should establish a business scenario and context in which the problem is expressed purely in business terms rather than in technical terms.  Provide background information at a level of detail sufficient to familiarize agency managers with the history, issues, and customer service opportunities that can be realized through improvements to business processes.
 
Avoid discussions of specific technology solutions at this point; potential solutions are investigated and documented in later phases.  Also, business case information should not offer or predetermine any specific solution, tool, or product.

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

The Project Manager must obtain deliverable approval signatures before proceeding to the Concept Development Phase.
 
Update the project documentation repository upon completion of the phase-closure activities.

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.

​ ​​​​​​​​​​

Phase 2: Concept Development

 

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.

 The following is a listing of deliverables required of all projects for this phase of work. 

Deliverable

Goals

Developed By

Approved By

Project Scope Statement (PSS) – documents the scope of a project and its business case with the high-level requirements, benefits, business assumptions, alternatives analysis, and program costs and schedules.

  • Records early research and decisions relevant to the project
  • Guides project execution to achievement
  • Describes the boundaries, specifically in and out of scope work, and scope control methods
  • Establishes a baseline of key characteristics of the project’s high level requirements, estimated project costs, and schedule for agencies and sponsors
  • Specifies acceptance methods and measurable acceptance criteria for all project deliverables
  • Documents alternatives analysis, including the cost-benefit analysis of alternatives

Project Manager

Project Sponsor

Agency Chief Financial Officer (CFO)

Agency CIO

Project Sponsor

Project Manager

Executive Sponsor

Information Technology Project Request – serves as the formal budget request for the project and has information provided by the PSS.

 

The ITPR is a mandatory deliverable for this project phase for all MITDPs.

  • Ensures alignment of MITDP with the State IT Master Plan (ITMP) and the requesting agency’s ITMP
  • Provides documentation of an IT project investment
  • Captures status, risk, schedule, funding and cost detail for agency IT project requests
  • Captures procurement information for agency IT projects
  • Provides a consistent and repeatable process in support of the State’s IT Project Oversight methodology
  • Ensures uniformity of IT project request submissions

Agency CFO

Agency CIO

Project Manager

Agency CFO

Agency CIO

Project Sponsor

Executive Sponsor

Project Organization Chart (Update) – a graphical depiction of the project hierarchical positions and relationships.

  • Identifies key personnel on the project
  • Defines the relationships between the team members
  • Identifies the required roles
Project Manager

 

Agency CIO

Project Sponsor

Executive Sponsor

Responsibility Assignment Matrix (RAM) - defines in detail the roles, authority, responsibility, skills, and capacity requirements for all project tasks needed to complete the project. The agency and contractor responsibilities are addressed in the RAM.

  • Communicates detailed roles, authority, responsibility, skills, and capacity requirements

 

Project Manager

Agency CIO

Project Sponsor

Project Staffing Estimates – details a preliminary estimate of resources required to complete the project and serves as an input for the project staffing management plan in the next phase.

  • Determines preliminary estimates of human resources required to successfully complete project

 

Project Manager

Agency CIO

Project Sponsor

Work Breakdown – provides a preliminary Work Breakdown Structure (WBS) and a WBS Dictionary to define all project activities from planning to implementation

  • Determines preliminary definition of all high level tasks to successfully complete

Project Manager

Agency CIO

Project Sponsor

 

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

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.

 

   

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.

Specific reports and SDLC deliverables are required at certain dates. The table below lists the requirements for this phase.
 

Key Deliverable

Date of Submission

Notes/Statute Links

ITPR

Mid-September, for the upcoming budget year (ex: mid-September 2008 for fiscal year 2010) - aligns with required budget submission date as established by the Department of Budget and Management (DBM) Office of Budget Analysis (OBA)

A corresponding DBM-DA-21 is required by OBA  

Statute:
SF&P §3A-308(b and c)
SF&P §3A-308(f)
http://mlis.state.md.us/

 

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. 

Contract Type

Benefits

Limitations

Fixed-price

Reduces State risk for cost overruns

Requires detailed, well-founded, and unambiguous requirements to guard against reductions in functionality

Requires detailed and unambiguous deliverable acceptance criteria to prevent cost overruns and schedule delays

Contractors incur risk of cost overruns

Time and materials

Valuable for use when scope is not specific

Risk of incurring large cost overruns to the State if not aggressively managed

 

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. 

Role Name

Major Decision Area

Decision and Subject

Decision Qualifiers

Executive Sponsor

Budget

Changes in project costs, + or -

Cost change of more than 5% of baseline

Project Sponsor

Scope

Scope changes + or -

Only minor scope changes, as defined by less than 3% of total scope

Project Manager

Scope

Cumulative scope changes + or -

Limited to 5% of project budget

 

 Sample Decision Rights Chart

  1. Define the project success measures and the collection, tracking, and reporting of this information.  Provide this information to the Planning and Development Teams.
  2. Specify the processes and procedures for how the Steering Committee will conduct continuous oversight.
  3. 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

The Project Manager must obtain deliverable approval signatures before proceeding to the Planning Phase. Update the project documentation repository upon completion of the phase-closure activities.

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.​​​


 ​​​

Phase 3: Planning

 

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).

 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.

 The following is a listing of deliverables required of all projects for this phase of work. 

Deliverable

Goals

Developed By

Approved By

Project Management Plan –

·         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)

·      Define how the project is executed, monitored, controlled, and closed

·       Document all actions necessary to execute, monitor, control, and close the project

Project Manager

Agency CIO

Project Sponsor

 

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
 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.


 

Back To Top

4.0 Tasks and Activities

Planning Phase Process Model 1 of 2 


 

Planning Phase Process Model 2 of 2  

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)

 All vendor-produced project plans must include the proper schedule and activity for creating, reviewing, revising, and accepting all required SDLC documentation.

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.

Control Scope – procedures for handling project change requests.

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").

Sequence Activities – identification of WBS dependencies and order among activities. Identify and document the logical relationships among schedule activities.

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

The agency must manage the master project schedule, including both agency and contractor tasks.  As such, it is critical that the Schedule Management Plan identify planned master schedule management activities to be executed throughout the project life cycle.

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.

Back To Top

5.0 Conclusions

The approval of the PMP, the execution of the Planning project status review, and the approval to proceed to the next phase signify the end of the Planning Phase.

 

​​
​​​

Phase 4: Requirements Analysis

 

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).

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 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.

Deliverable

Goals

Developed By

Approved By

Functional Requirements Document (FRD) – formal statement of a system’s functional requirements, including, but not limited to: functional process requirements, data requirements, system interface requirements, and non-functional or operational requirements.

  • Document detailed, measurable, consistent, and comprehensive system requirements
  • Eliminate ambiguity of expectations regarding system

Planning Team

Agency CIO

Project Sponsor

Business Owner

Project Manager

Requirements Traceability Matrix (RTM) – a table that links requirements to their origins and traces them throughout the project life cycle.  Developing the RTM helps to ensure that each requirement adds business value and that approved requirements are delivered.

  • Establish a baseline for requirements change control, design, and testing

Planning Team

Agency CIO

Business Owner

Project Manager

Procurement Documents – documents such as a RFP or a TORFP that elicit competitive and comprehensive offers from potential contractors for a product or service.  The document should specify the scope of the desired procurement, define the evaluation process, and delineate the deliverables and requirements associated with the project.

  • Elicit quality proposals from qualified contractors
  • Provide contractors with sufficient information to formulate an appropriate response including an accurate schedule and cost estimate

Procurement Officer

Project Manager

Agency CIO

Agency CFO

Project Sponsor

Business Owner

Project Manager

 

COTS Fit-Gap Analysis – identifies in detail the extent to which the COTS solution meets each of the validated requirements and how all gaps will be addressed in the new system.

  • Document the extent to which the COTS solution meets each validated requirement
  • Identify which requirements the COTS solution does not meet and specifically how the gaps will be addressed

Development Team

Agency CIO

Business Owner

Project Manager

Test Master Plan (TMP) – documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. 

  • Document and communicate tasks and activities needed to ensure that the system is adequately tested and can be successfully implemented

Project Manager

Agency CIO

Business Owner

Agency CIO

Business Owner

Project Manager

Business Process Change Management Plan – documents the specific plans to implement agreed-upon changes to the end users’ business processes.

  • Identify specific plans to execute business process changes
  • Address how business process changes will be implemented early and iteratively to mitigate business process change risks

Project Manager

Project Sponsor

Agency CIO

Business Owner

Project Manager

 

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
 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.


 

 

Back To Top

4.0 Tasks and Activities

Requirements Analysis Phase Process Model 1 of 4 


 

Requirements Analysis Phase Process Model 2 of 4 


 

Requirements Analysis Phase Process Model 3 of 4 


 

Requirements Analysis Phase Process Model 4 of 4 

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

To measure project effort at all life cycle phases, the Project Manager establishes timelines and metrics for success when planning project tasks.  This project performance information must be used as an input to the monthly and quarterly reporting provided to the DoIT Project Management Office (PMO).  The Project Manager also organizes and oversees systematic quality management reviews of project work as a part of project performance monitoring.
 

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

 Monitoring and control activities should address:
  • 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

If the Planning Team is considering a COTS solution, including either on-premise software or Software-as-a-Service (SaaS), ensure that risk identification and analysis considers the unique risks associated with these types of efforts. Risk management activities occur throughout project duration to track and mitigate any new or changed project risks. The results of risk monitoring and control activities must be documented in the project’s Risk Register and included in monthly and quarterly reporting to DoIT PMO.  The PMBOK has details for risk management activities in section 11, particularly sections 11.2 through 11.6.
 

4.5  Initiate Requirements Identification.

The Planning Team with Project Manager supervision identifies system requirements.  

 

Category

Description

Functional Requirements

Business processes, information, and interactions

Non-functional Requirements

Non-functional specifications that address system operations and/or technical characteristics (such as accessibility, encryption, security, hosting, environment, disaster recovery, level of service, performance, compliance, supportability, business continuity)

 

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

PMBOK has additional information regarding tools and techniques for requirements analysis.  During requirements elicitation, the Planning Team should note all assumptions and constraints that will affect implementation and operation of the system.  Requirements should also be prioritized based on relative importance and by when they are needed. 
 
In addition to functional requirements, requirements analysis identifies non-functional requirements such as operational and technical requirements.  Non-functional requirements describe characteristics or specific parameters of the system and include audit, availability, capacity, performance, and security requirements.  Other non-functional requirements include compliance with regulations and standards such as data retention and the Maryland IT Non-Visual Access Regulatory Standards.
 
The Planning Team should describe the system as the functions to be performed and not specific hardware, programs, files and data streams.  The Planning Team may perform these activities concurrently and iteratively to refine the set of requirements.  The requirements’ level of detail should be sufficient to develop information for deliverables as well as procurement documents.  All requirements must be consistent with the State of Maryland Information Technology Security Policy and Standards on the DoIT website.
 
Prior to the RFP, the requirements should be as unambiguous (measurable and testable), traceable, complete, and consistent as possible and must be approved by stakeholders.  For COTS implementation RFPs, agencies must balance the need to comprehensively and clearly define requirements and expectations while simultaneously ensuring that they do not limit procurement competition and unnecessarily disqualify solutions that may meet the business need.  As such, agencies must define requirements to a sufficient level of detail for prospective vendors to understand current business processes, mandatory requirements, and optional requirements.
 
In order to optimize the level of detailed requirements included in the RFP, agencies are strongly encouraged to first investigate available COTS options and functionality.  Planning teams should use the information gathered from industry research and product demonstrations to further refine requirements to be as unambiguous and comprehensive as possible.
 
Another way agencies may learn about available options is to conduct research regarding other states that have implemented similar systems and then leverage the lessons learned from the research in the requirements definition process.
 

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

Agencies are encouraged but not required to use statewide contract vehicles such as Consulting and Technical Services+ (CATS+).
 

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

For CATS TORFPs refer to the CATS+ TORFP Master Template on DoIT’s web site for instructions regarding requirements for SOW development.
 

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

Additional guidance can be found on DoIT’s web site in these documents:
  • 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

For COTS implementation projects, RFPs must include detailed current (or "as is") business requirements and require that responses include proposed future (or "To Be") business processes so that agencies may evaluate the level of organizational change required to implement the proposed solution.
 
RFPs should also require that proposals include a proposed data model that meets requirements, leverages the agency’s preliminary data model, and is compatible with solution capabilities.
 
In addition, RFPs must require that responses include a preliminary COTS fit-gap analysis so that agencies may evaluate the level of risk associated with customizing the proposed solution to meet both mandatory and optional requirements. This analysis must specify, for each requirement, whether a COTS configuration or customization will be required. COTS configuration options require no programmatic code and are completely tested by the contractor prior to COTS release, whereas customization requires programmatic code.
 
All RFPs and TORFPs must explicitly require complete compliance with the State of Maryland SDLC and other policies and guidelines. Specifically, each TORFP must include the following language:
 
The TO Contractor(s) shall be required to comply with all applicable laws, regulations, policies, standards and guidelines affecting information technology projects, which may be created or changed periodically.  The TO Contractor(s) shall adhere to and remain abreast of current, new, and revised laws, regulations, policies, standards and guidelines affecting project execution. The following policies, guidelines and methodologies can be found at www.doit.maryland.gov. Select “Policies and Guidance”.
 
These may include, but are not limited to:

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).

Effective requirements validation helps to ensure that requirements are defined to the level of detail necessary to properly build, test, implement and track throughout the life cycle.  In essence, the validation process is a proactive risk mitigation strategy to prevent underestimation and quality deficiencies resulting from ambiguous requirements.
 
Conducting the final COTS Fit-Gap Analysis at this stage allows the team to:
  • 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

Requirements validation and final COTS fit-gap analysis are frequently performed in parallel to ensure that the requirements validation is sufficiently influenced by an understanding of the COTS functionality. 
 

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

The Business Process Change Management Plan should address how the team will begin executing business process changes in the Development Phase and iteratively thereafter to mitigate the risks associated with significant business process change.
 

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

Agencies may use the SDLC templates to help ensure that all appropriate testing activities are defined and documented.

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

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. The Project Manager must obtain deliverable approval signatures before proceeding to the Design Phase. Update the project documentation repository upon completion of the phase-closure activities.

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.

​ ​​

Phase 5: Design

 

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).

 During the development of documentation, the Development Team should:
  • 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.

Deliverable

Goals

Developed By

Approved By

System Design Document – specifies the construction details of the system, each system component’s interaction with other components and external systems, and the interface that allows end users to operate the system and its functions.

·      Document the results of the system design process

·      Describe how the system with satisfy requirements

 

Development Team

Project Sponsor

Agency CIO

Project Manager

 

System Security Consensus Document (SSCD) – a single document containing all information relevant to completing the system’s Certification & Accreditation.

·      Define the system’s security architecture, security policies, risk assessments, and security tests

·      Consolidate all information for the C&A

Project Manager

Agency CIO

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

·      Describe planned activities to control access and protect the system and its information

Development Team

Project Manager

Agency CIO

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

·      Record retention and disposition responsibilities

·      Document retention and disposition requirements

·      Record management process

·      Document retention and disposition schedules

Development Team

Project Manager

Agency CIO

Disaster Recovery Plan – 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.

·      Identify plans to restore operability in the event of extended interruption of services

·      Define and document concept of operations

·      Document notification procedures

·      Record damage assessment procedures, recovery activities, and reconstitution procedures

Development Team

Project Manager

Agency CIO

Unit and Integration Test Plans (Begin) – detailed scripts used in the Development and Test Phases for evaluating the completeness and correctness of the smallest parts of the system and the components created from those parts. The test scripts are more specific than the Test Master Plan, which is high-level and more focused on processes.

·      Identify detailed scripts for testing system components

 

Development Team

Agency CIO

Project Manager

Conversion Plan (Begin) – describes the strategies and approaches for converting/migrating data from an existing system to another hardware or software environment.

·      Document all planned activities to ensure a smooth data conversion from a legacy system to a new environment

 

Development Team

Agency CIO

Integration Document – describes the assembly and interaction of the hardware, software, and any other components of the system.  This document is not applicable for projects that only implement Software-as-a-Service.

·     Document planned approach and activities for the integration of hardware, software, and other system components

Development Team

Agency CIO

Implementation Plan – describes how the information system will be deployed as an operational system.

·     Define all planned activities to ensure successful implementation to production operations

Development Team

Project Sponsor

Agency CIO

Operations or System Administration Manual (Begin) – The Operations Manual focuses on mainframe systems; the Systems Administration Manual is oriented for distributed (client/server) applications.  Both documents provide details on system operations. These manuals are not applicable for SaaS-only projects.

·      Provide detailed instruction for system operations

Development Team

Agency CIO

Maintenance Manual (Begin) – details effective system maintenance.  Appendices might document maintenance procedures, standards, or other essential information on areas such as backup, networking and connectivity, access and authentication, cabling, and critical services. This manual is not applicable for SaaS-only projects.

·     Provide maintenance personnel with the information necessary to effectively maintain the system

Project Manager

Agency CIO

Training Plan – outlines training needs for end users on the new or enhanced information system.

·     Ensure that the schedule accounts for all necessary training needs to successfully implement, operate, and maintain the system

Development Team

Project Sponsor

User Manual (Begin) – describes to end users how to make full use of the information system, including system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use.

·     Provide users with detailed information to fully utilize the system

Development Team

Agency CIO

Requirements Traceability Matrix (Update) – a table that links requirements to their origins and traces them throughout the project life cycle. 

·     Establish a baseline for requirements change control, design, and testing

Development Team

Agency CIO

Business Owner

Project Manager


 

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

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.

 

Back To Top

4.0 Tasks and Activities

Design Phase Process Model 1 of 4 


 

Design Phase Process Model 2 of 4 


 

Design Phase Process Model 3 of 4Design Phase Process Model 4 of 44.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

The Project Manager also organizes and oversees systematic quality management reviews of project work as a part of monitoring the project performance.
 
To measure project effort at all phases of the life cycle, the Project Manager establishes timelines and metrics for success at each phase of work when planning project tasks.
 

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

These activities occur throughout the project duration to track and mitigate any new or changed project risks. 
 

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

During the process of this decision-making, the Development Team may consult other technical resources, such as agency production operations staff to identify technical issues in the Operations and Maintenance Phase, for additional information.
 
Projects that only involve SaaS implementation will require less design effort and decision-making given that the web-based software already exists and will not allow for customization or significant configuration.  SaaS implementation efforts, however, still require design activities to ensure that data conversion and implementation methodologies and tools are defined and that system interfaces are designed.
 

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.

Creating the right balance in change management is difficult but critical to system development: too much control may cause work to be impeded; too little control may cause the project to devolve into chaos.
 
Establishing a solid configuration management repository and clear change management processes improve requirements traceability.  Requirements traceability begins in the Design Phase as the Development Team validates requirements and begins the process of creating exact specifications to meet those requirements.  Managing those requirements properly increases project success.
 
For more information on configuration management best practices, see Related Links.
 

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)

Not all projects require these elements for every type of system. Large-scale custom development projects need nearly all, but, for example, in a COTS implementation without customization, the user interface information will be in the User Manual and not required in a design document. For SaaS-only implementations, the SDD should emphasize system interface, integration, and data design. For a network deployment or hardware upgrade, the SDD should emphasize the deployment of the system. The Project Manager and the Project Sponsor must ensure proper documentation for development and to meet the requirements.

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

Decisions made during the prototyping process must be incorporated into the SDD.

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

In addition to the C&A policies, the Development Team should review other DoIT security policies and standards (posted on DoIT’s website) to determine which ones apply. The Development Team adds to the SSCD a plan to implement those policies that apply and identify security controls to remediate risks and vulnerabilities discovered during the risk assessment.
 
For SaaS implementations that involve system implementation in a vendor’s environment, formal C&As may not be required given that the system is not under the control of the State. Agencies, however, should take care to conduct the same level of planning and security assessment of vendor-controlled systems due to the greater security risks to State users. SaaS solutions may present greater security risks to agencies because agency data is stored in the vendor environment and travels over the Internet. Also, the vendor completely controls system infrastructure, security, and disaster recovery. As such, SaaS implementations require the same level of security planning and testing as other development projects.
 

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

The Project Manager conducts project-level and technical reviews of the Integration Document.
 

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

The Project Manager compares actual project performance to the baseline and the projected cost of the project to detect and understand 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, Development.
 
The Project Manager must obtain deliverable approval signatures before proceeding to the Development Phase.

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

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.

​​​​

Phase 6: Development

 

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).

During the development of documentation, the Development Team should:
  • 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.

Deliverable

Goals

Developed By

Approved By

Software Development Document – details the provisions, including specific coding instructions, unit test cases, and scripts, for developing and/or modifying each unit or module of the system; also includes development procedures for issue tracking and configuration management and any other information that aids in building the functionality of the system. 

·      Document all preparations related to the development and/or modification of each software unit and other items that will help explain the functionality of the software

·      Describe development methodologies

 

Development Team

Agency CIO

System (Application) Software – file or set of files that contain the application or software code on discs or other media. 

·      Provide software that meets the business needs and all requirements

Development Team

Agency CIO

Test Data – contains dummy data used for testing; the data is not sensitive or live.

·      Provide sample representative data to use in test activities

·      Ensure that testing results simulate production results

Development Team

Project Manager

Integration Document – describes the assembly and interaction of the hardware, software, and any other components of the system. This document is not applicable for projects that only implement SaaS.

·      Document planned approach and activities for the integration of hardware, software, and other system components

Development Team

Agency CIO

Test Analysis Report(s) – presents a description of the unit tests and the results mapped to the system requirements; also identifies system capabilities and deficiencies.

·      Record results of tests

·      Present the capabilities and deficiencies for review

·      Provide a means for assessing software progression to the next stage of development or testing

Development Team

Project Sponsor

Agency CIO

Conversion Plan (Update) – describes the strategies and approaches for converting/migrating data from an existing system to another hardware or software environment.

·      Document all planned activities to ensure a smooth data conversion from a legacy system to a new environment

Development Team

Project Sponsor

Agency CIO

Implementation Plan (Update) – describes how the information system will be deployed as an operational system.

·      Define all planned activities to ensure successful implementation to production operations

Development Team

Project Sponsor

Agency CIO

Operations Manual or Systems Administration Manual – The Operations Manual focuses on mainframe systems; the Systems Administration Manual is oriented toward distributed (client/server) applications.  These manuals are not applicable for SaaS-only projects.

·      Provide detailed instruction for system operations

Development Team

Agency CIO

Release Notes – provides summary information regarding the current release of the system being built; typically includes major new features and changes and identifies known problems and workarounds.

·      Document critical information regarding the system release

Development Team

Agency CIO

Maintenance Manual – details effective system maintenance.  Appendices might document maintenance procedures, standards, or other essential information. This manual is not applicable for SaaS-only projects.

·      Provide maintenance personnel with the information necessary to maintain the system effectively

Development Team

Agency CIO

Training Plan – outlines technical and user training needs on the new or enhanced information system.

·      Ensure the schedule accounts for all necessary training needs to implement, operate, and maintain the system successfully

Development Team

Project Sponsor

Agency CIO

User Manual – describes to end users how to make full use of the information system, including system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use.

·      Provide users with detailed information to fully utilize the system

Development Team

Project Sponsor

Agency CIO


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

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.


 

  

 

Back To Top

4.0 Tasks and Activities

Development Phase Process Model 1 of 4 

Development Phase Process Model 2 of 4 

Development Phase Process Model 3 of 4 

Development Phase Process Model 4 of 4 

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)

 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
  • Estimated time to completion
  • Resource utilization data
  • Changes to project scope

The Project Manager also organizes and oversees systematic quality management reviews of project work as a part of monitoring the project performance.
 
To measure project effort at all phases of the life cycle, the Project Manager establishes timelines and metrics for success at each phase of work when planning project tasks. 
 

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

Project stakeholders should be involved periodically throughout the Development Phase to ensure that the development team understands their expectations and that it develops the system in accordance with requirements
 

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.

The Development Team may need to develop migration utilities that will extract, transform, and load data from a legacy system to the new system.  The migration involves manually entering or systematically loading the data into the new system and verifying that the migrated data is correct.  Before any data is migrated, the Development Team should develop, test and validate initial portions of the Conversion Plan to determine if any plan modifications are necessary.  The scope of the test will vary depending on the scope of the project.  The Development Team should develop the data migration programs and tools according to the Conversion Plan and may need to repeat data migration testing for the release to production.
 

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 Project Manager compares actual project performance to the PMP and the projected cost of the project to detect and understand 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, Test.
 
Update the project documentation repository upon completion of the phase-closure activities.

Back To Top

5.0 Conclusions

At the end of the Development Phase, the Development Team has created a working information system. The completion of the System (Application) Software, approval of the Development Phase deliverables, the completion of the Development project status review, and the approval to proceed to the next phase, signify the end of the Development Phase.


 

​​​

Phase 7: Test

 

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).

During the development of documentation, the Development Team should:
  • 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.

 

Deliverable

Goals

Developed By

Approved By

Test Analysis Approval Determination - summarizes the system’s perceived readiness and is attached to the Test Analysis Report as a final result of the test reviews.

·         Document the perceived production-readiness of the system

·        Serve as an input to the project Readiness Document described below

Development Team

Project Sponsor

Agency CIO

Test Problem Reports - document problems encountered during testing; are also attached to the Test Analysis Report.

·        Document detailed results of testing

Development Team

Project Sponsor

Agency CIO

Information Technology Systems Certification & Accreditation - includes completion of a Security Risk Assessment, Sensitive System Security Plan, Security Operating Procedures, Security Test and Evaluation, and Certification Statements.  For SaaS efforts, vendors may provide alternative documentation and certification to provide assurance of the same level of security.

·        Assess technical and non-technical safeguards to determine the extent to which the system meets security requirements

·        Obtain formal declaration by a Designated Approval Authority (DAA) that an information system is approved to operate in a particular security mode using a prescribed set of safeguards at an acceptable level of risk

Development Team

Project Sponsor

Agency CIO

Defect Log – tracks and summarizes in a tabular format defects or bugs found during testing.  Defects may be documented via multiple commercially available bug tracking tools or manually in a spreadsheet.

·         Allow team members to track reported bugs, or defects

·         Clearly communicate summary of defects found

·         Record facts regarding known bugs, such as times reported, individuals who reported them, defect statuses, and team members responsible for addressing the bugs

Development Team

N/A – The Defect Log does not require approval.

Readiness Document – consolidates summary information regarding the current status of the system and the project and provides decision makers with the information necessary to make a “Go-No Go” decision.  It should include a checklist for all work products, User Acceptance Test results, other quality control checks such a peer review, and results of the system walkthroughs.

·         Provide information necessary to make the “Go-No Go” decision

·         Consolidate status information regarding the effective completion of the project and achievement of project objectives and SDLC requirements

·         Affirm achievement of all deliverable acceptance criteria

Development Team

Agency CIO


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

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.

 

 

Back To Top

4.0 Tasks and Activities

Test Phase Process Model 1 of 3 

Test Phase Process Model 2 of 3Test Phase Process Model 3 of 3  

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.

During the Test Phase, the Development Team frequently may discover problems with interfaces, data structure, and functions that require repair.
 
The Project Manager should confirm and review any testing tools and defect tracking mechanisms and the change management tool used in the software development.
 

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

The Project Manager also organizes and oversees systematic quality management reviews of project work as a part of monitoring the project performance.
 
To measure project effort at all phases of the life cycle, the Project Manager establishes timelines and metrics for success at each phase of work when planning project tasks.
 

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

These activities occur throughout the project duration to track and mitigate any new or updated project risks. 
 

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

Testing may follow either a black box testing or a white box testing methodology.
  • 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.

Regression testing focuses on revealing software errors in functions that did work correctly but stopped working due to modifications.  Regression testing typically involves repeating entire test scripts to ensure all functionality operates correctly after a unit or component has been modified.
 
The Development Team should prepare to perform non-functional tests such as load, usability, and security testing.  During load testing, performance tests stress the system and indicate if the system or software can handle large quantities of data or end users.  Usability testing checks if the user interface is easy to use and understandable.  The Development Team can automate testing to expedite the process and ensure consistency.
 
The Development Team should consider taking a phased approach to testing, planning separate test releases such as alpha, beta, and pilot releases.  Although each of these tests is considered part of acceptance testing, alpha testing usually involves testing an early version of the system, beta testing involves testing a close-to-complete and stable system, and pilots are completed systems released to a subset of the end user group.  This iterative approach to testing helps to mitigate quality risk by ensuring that all software flaws are addressed prior to complete production deployment.
 
Regardless of the testing methodology, the Development Team updates the RTM to reflect all test results and ensure traceability back to the original requirements.  When all testing is finished, an audit of the testing should show test results for every element of the system and traceability to its corresponding requirement.
 

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 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, Implementation.

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.

Back To Top

5.0 Conclusions

At the end of the Test Phase, the Development Team has completed a working, fully tested information system that meets all business and technical requirements. The approval of the Test Phase deliverables, the completion of the Test Phase project status review, and the approval to proceed to the next phase, signify the end of the Test Phase.


 

​​​

Phase 8: Implementation

 

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).

During the development of documentation, the Development Team should:
  • 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.

Deliverable

Goals

Developed By

Approved By

Complete System – includes all code – modules, components, and libraries – kept in the production version of the data repository.  For Software-as-a-Service, vendors provide the system for use, but do not hand-over actual code.

·      Deliver system that meets the business need and all requirements

·      Deploy system to production environment

Development Team

Agency CIO

System Documentation – includes all technical documentation delivered during the project (e.g. the SDD and the User Guide).

·      Provide all documentation necessary to effectively operate and maintain the system

Development Team

Agency CIO

Implementation Notice – formally requests approval for system changes made during the Implementation Phase.

·      Formally request approval for system implementation

Development Team

Agency CIO

Project Sponsor

Readiness Document – consolidates summary information regarding the current status of the system and the project and provides decision makers with the information necessary to make a “Go/No Go” decision.  It should include a checklist listing all work products, User Acceptance Test (UAT) results, other indicators of success measures and deliverable acceptance.

·      Provide information necessary to make the go/no-go decision

·      Consolidate status information regarding the effective completion of the project and achievement of project objectives and SDLC requirements

·      Affirm achievement of all deliverable acceptance criteria

Development Team

Agency CIO

Version Description Document – primary configuration control document used to track and control versions of software released to the operational environment. It also summarizes features and contents for the software build and identifies and describes the version of software delivered.

·      Allow for tracking and control of software releases to the operational environment

·      Document features and content in software builds

·      Identify the version of the software being delivered

Development Team

Agency CIO

Post-Implementation Review Report – summarizes the assessment of Implementation activities at the end of the Implementation Phase.

·      Summarize assessment of implementation activities

·      Evaluate the effectiveness of the system implementation after the system has been in production

·      Determine if the system does what it was designed to do

Project Manager

Agency CIO

Project Sponsor

Project Manager

Development Team

Standard Operating Procedures (SOP) (Optional) – defines in detail how the Systems Team will perform the business processes related to the operations and maintenance of the system.  Whereas the User Guide is focused on the use of the system specifically, the Standard Operating Procedures address all related business processes.

·      Provide detailed instructions for future business processes

·      Ensure consistent execution of business processes

·      Drive performance improvement and improve organizational results

Development Team

Agency CIO


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
  • Project Sponsor
  • Executive Sponsor
  • Project Manager
  • Development Team
  • Project Stakeholders

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.

 

 

Back To Top

4.0 Tasks and Activities

Implementation Phase Process Model 1 of 3Implementation Phase Process Model 2 of 3Implementation Phase Process Model 3 of 3  

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.
  • All testing is complete; the system has passed UAT.
  • The Implementation Plan is complete and current.
  • The Conversion Plan for legacy data and business processes is tested fully for accuracy and completeness.
  • Training plans to train end users on proper system use are complete.
  • The system documentation is complete and available.
  • The system has completed Certification and Accreditation according to DoIT guidelines.

 

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

The Project Manager also organizes and oversees systematic quality assurance reviews of project work as a part of monitoring the project performance.
 
To measure project effort at all phases of the life cycle, the Project Manager establishes timelines and metrics for success at each phase of work when planning project tasks.
 

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 dissemination 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 Chapter 10 contains additional details on project communications and information distribution.

4.4 Perform Risk Management Activities.

The Project 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

These activities occur throughout the project duration to track and mitigate any new or changed project risks. 
 

4.5 Initiate Implementation Activities.

The Development Team begins implementation with the following tasks:

  • Execution of standards, methods, and tools for deploying the system
  • Carrying out of Implementation Phase activities according to the detailed project WBS started during the Concept Development Phase
  • Review of the change management process to ensure all Test Phase modifications have been documented

 

4.6 Install System in Production Environment.

The Development Team installs the system in the production environment.  While installing the system, the Development Team should keep the configuration information updated by following the Configuration Management Plan defined in the Design Phase.

4.7 Send the Change Implementation Notice.

The Project Manager sends the Change Implementation Notice to all end users and organizations affected by the implementation.  In addition, the Project Manager informs those not directly affected by the implementation of possible disruptions to normal activity.  The Change Implementation Notice includes the following:

  • Implementation schedule
  • Brief description of benefits of the new system
  • Differences between the old and new system
  • Responsibilities of end users during the Implementation Phase
  • Instructions for contacting technical support, including contact names and phone numbers

 

4.8 Review the Security Plan.

The Project Manager reviews the Security Plan for required security policies and procedures during the Implementation Phase.  Confirm that end users will receive training on DoIT security policies and procedures according to the Training Plan.  All documents about security policies and procedures are available at the DoIT State Information Technology Security Policy and Standards Web page.

4.9 Execute the Training Plan.

The Project Manager oversees end user training on the new system.  Use the previously designed training plan and the User Guide to train the end users effectively.  Request end user feedback to determine if the training was effective.

4.10 Develop the Standard Operating Procedures.

The Development Team may elect to develop SOP to provide documented and detailed instructions for performing all future business procedures associated with the system operations and maintenance.  The SOP may reference procedures already documented in the User Guide, Operations Manual, Administration Manual, and Maintenance Manual.  The SOP should focus on non-technical procedures necessary to execute future business processes.

4.11 Confirm System Documentation Completeness.

The Project Manager reviews all system documentation to confirm that it is complete and correct.  Review carefully the Operations Manual or System Administration Manual and User Guide to ensure they are ready for the Operations and Maintenance Phase.

4.12 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 Design Phase.  End users continue to implement necessary business process changes and monitor and communicate the implications of these changes. 

4.13 Monitor the Marketplace.

The Project Manager and the 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.14 Conduct Post-Implementation Review.

The Project Manager – with extensive input from the Agency CIO, Project Sponsor, Executive Sponsor, the Development Team, and key project stakeholders – conducts the Post-Implementation Review (PIR).  Held after implementation is complete and the project effort is to be formally closed, the PIR is a formal evaluation of the actual level of project success.  The PIR may also help agencies learn valuable lessons for future projects.

4.14.1 Review the Project Performance

Review the project performance to assess whether the project delivered promised benefits, met the agency project objectives, operated within scope, and produced the promised deliverables on time, within budget, and using the allocated resources.  Assess how the project performed against each of the targets defined during the Initiation, Concept Development, and Planning phases. Identify whether the project:

  • Delivered the business benefits described in the Business Case
  • Achieved the objectives specified in the Project Charter and Project Scope Statement
  • Remained within the original scope
  • Produced the necessary deliverables as defined in the WBS
  • Met the quality targets defined in the Quality Management Plan
  • Was completed within the planned project schedule
  • Delivered within the budget defined in IT Project Request and any approved changes

4.14.2 Assess Stakeholder Satisfaction

Assess general stakeholder satisfaction and any perceived gaps that may require additional scrutiny.

4.14.3 Review the Project Conformance

Assess whether the project conformed to the management processes described in the project plans, and identify the extent to which the project has conformed to the nine project management knowledge areas of PMBOK:

  • Time Management
  • Cost Management
  • Quality Management
  • Scope Management
  • Risk Management
  • Integration Management
  • Procurement Management
  • Human Resource Management
  • Communications Management

4.14.4 Identify Project Achievements

List the major achievements for the project, and describe the positive effect of each achievement on the business.

4.14.5 Identify Gaps in Project Fulfillment/Project Failures

List any project failures or gaps in promised functionality and describe their effect on the organization.

4.14.6 Identify Lessons Learned

Describe the lessons learned from undertaking this project, and list any recommendations for similar projects in the future.

If after the review the Project Manager finds the project’s implementation to be unacceptable, the Agency CIO may issue follow-up instructions and instruct the Project Manager to correct the deficiencies.  If contractors completed the development, the Project Manager may determine that additional remediation work is within the scope of the statement of work or in the original contract.

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 Implementation Phase tasks. This review addresses the following:

  • Status of Implementation Phase activities
  • Planning status for operations and maintenance phases
  • Status on resource availability for operations and maintenance
  • "Go-No Go" decision made to proceed to next phase, based on Implementation Phase information
  • Transfer system management responsibility to Systems Team personnel

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 updates the Risk Register.  The Project Manager updates the Maryland Enterprise Architecture Repository with any new or updated components before beginning the next phase, Operations and Maintenance.
 
Document any end user requests for system changes to mitigate misunderstandings between end users and the Development Team.  Review the Contracts Management checklist found with the Templates and Checklists area for unfinished contract tasks before closing out the Implementation Phase.
 
The Project Manager must obtain deliverable approval signatures before proceeding to the Operations and Maintenance Phase.
 
Update the project documentation repository upon completion of the phase-closure activities.
 

4.16 Perform Project Close-Out Activities.

The Project Manager closes the project and transitions the system to the agency Systems Team once the system is implemented in production and operates in a stable manner.  Activities include:

  • Transition of outstanding requirements to the Systems Team
  • Disbanding of the Development Team and completion of team performance reviews
  • Resolution of remaining contractor invoicing and contract compliance issues
  • Close out of procurements
  • Conducting of a lessons learned assessment of the project work to understand project difficulties and areas for improving future agency project work
  • Obtaining of final project acceptance by the Project Sponsor
  • Archiving of all relevant project documents as historical data.  Refer to the Data Retention Plan completed in the Development Phase.
  • Verification that all changes are conducted in accordance with the approved Change Management Plan

Back To Top

5.0 Conclusions

When the Implementation Phase concludes, the system begins operating and continues to do so until the organization determines it has outlived its usefulness and starts planning for a replacement system. The approval of the Implementation Phase deliverables and the completion of the Implementation project status review, and the execution of project close-out activities, signify the end of the Implementation Phase.


 

​​​​

Phase 9: Operations and Maintenance

 

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).

During the development of documentation, the Systems Team should:
  • 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.

The following is a listing of deliverables required of all projects for this phase of work.

Deliverable

Goals

Developed By

Approved By

Standard Operating Procedures (Updated) – defines in detail how the Operations & Maintenance (O&M) team will perform the business processes related to the operations and maintenance of the system.  Whereas the User Guide is focused on the use of the system specifically, the Standard Operating Procedures address all related business processes.

·     Provide detailed instructions for future business processes

·     Ensure consistent execution of business processes

·     Drive performance improvement and improve organizational results

Systems Team

Agency CIO

Performance Reports – tracks routine metrics as system performance indicators.

·     Report on agreed upon system performance measurements

·     Include key performance indicators

System Manager

No approval required

Implementation Notice – formally requests approval for system changes made during the Implementation Phase.

·     Formally request approval for system implementation

Project Manager

Agency CIO

 

Program Trouble Reports – provide details regarding an incident related to any aspect of an IT service.

·     Document and track system incidents

·     Communicate need to address a disruption in service and/or a reduction of quality of service

Systems Team

No approval required

In-Process Review Report – formally reports the health of the system.  It includes summary of performance reports but is more formalized and usually developed quarterly.

·     Provide Agency CIO with routine insight into system performance

·     Include results of user satisfaction reviews

System Manager

Agency CIO

Agency CIO

User Satisfaction Review – determines the current user satisfaction with the performance capabilities of the system

·     Quantify user satisfaction levels

System Manager

Agency CIO

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, disposition of remaining equipment, and archiving of life cycle products.

·     Address all facets of archiving, transferring, and disposing of the system and data

System Manager

Agency CIO

Business Owner

 

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 

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.

 

 

Back To Top

4.0 Tasks and Activities

Operations and Maintenance Phase Process Model 1 of 2 Operations & Maintenance Phase Process Model 2 of 2

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

The System Manager also organizes and oversees systematic quality management reviews of phase work as a part of monitoring the phase performance.
 

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

These activities occur throughout the project duration to track and mitigate any new or changed project risks.
 

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

The system log, the Operations Manual, journals, and other logs are invaluable in emergencies and should be kept in a central repository with other operational documentation.
 
The System Manager reviews the Program Trouble Reports, which document problems with the system through an automated system.  The reports typically include:
  • Date and time
  • Issue reporter
  • Problem description
  • Apparent cause
  • Assigned developer
  • Resolution
  • Test results

Other information may be included and depends on the reporting system.  The reporting system should permit an audit of the entire process from problem identification to problem resolution and case closure.
 

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.

​​​​

Phase 10: Disposition

 

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).

During the development of documentation, the Systems Team should:
  • 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.

The following is a listing of deliverables required of all projects for this phase of work. 

Deliverable

Goals

Developed By

Approved By

Disposition Plan (Update) – 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, disposition of remaining equipment, and archiving of life cycle products.

  • Address all facets of archiving, transferring, and disposing of the system and data

System Manager

Agency CIO

 

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  

 

RACI Key

Responsible – Describes role that executes the activities to achieve the task. 

Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides. 

Consulted – Describes roles that provide subject matter expertise.

Informed – Describes roles that receive information about the task.

     

 

Back To Top

4.0 Tasks and Activities

Disposition Phase Process Model 1 of 3 

Disposition Phase Process Model 2 of 3 

Disposition Phase Process Model 3 of 3

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.

These actions should prepare the information system for termination.
 

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.

​​​​