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. 

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

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

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

Back To Top

3.0 Roles

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

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

Back To Top

4.0 Tasks and Activities

4.1 Review Phase Prerequisites.

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

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

Specific reports and SDLC deliverables are required at certain dates.  The table below lists the requirements for this phase. Refer to the Documents Timeline page in the Related Links.

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.  Additional guidance is provided in the SDLC template.

• 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

Section 5.23 of the Project Management Body of Knowledge (PMBOK), fourth edition describes PSS development in detail.

4.4.4 Dos and Don’ts

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

4.5 Form the Project Acquisition Strategy.

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

Benefits and Limitations of Contract Types

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

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

4.6 Create Initial Work Breakdown Structure.

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

A WBS Dictionary provides more detailed descriptions of the work identified in the WBS.  For more guidance regarding the development of a WBS Dictionary, visit the WBS document or PMBOK, section 5.3.

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.  Refer to the Related Links for the Cost Estimating page for a more detailed discussion of cost estimating techniques and tools.

Some specialized areas of cost estimating typically overlooked during concept development include costs for hardware upgrades, security assessments, certification & accreditation (C&A) reviews, disaster recovery activities, and IV&V assessments.  All Planning Teams should ensure that their cost basis is as complete as possible to avoid future funding gaps.  Given the information known about the project at this point, all estimates are still considered preliminary.

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

4.9 Define Detailed Roles and Responsibilities.

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

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

4.10 Establish Governance Processes and Steering Committee.

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

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

 Sample Decision Rights Chart

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

4.11 Develop the ITPR.

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

4.11.1 Document Description

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

4.11.2 Required Content

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

4.11.3 Guidance for Document Development

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

4.11.4 Dos and Don'ts

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

4.12 Perform Phase-Closure Activities.

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

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

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