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

Deliver​​able	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) – is 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

 

The Roles and Responsibilities page has detailed descriptions of these roles and their associated responsibilities.

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.

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.

Preliminary risk analysis should consider the level of implementation risk associated with the proposed project.  If there is a significant amount of implementation risk, the Planning Team should consider mitigating the risk through a multiple-release implementation.  Staggering the implementation across multiple releases to production (by system functionality, module, scope, etc.) helps to prevent quality issues for projects with significant implementation risks.

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

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 all define 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 Work Breakdown Structure document or PMBOK, section 5.3.

If the Planning Team is considering a multiple-release implementation approach, ensure that the preliminary WBS includes all activities and time associated with multiple releases to production.  This would include multiple iterations of design, development, integration, testing, and implementation.

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.

If the Planning Team is considering a multiple-release implementation approach, ensure that the project staffing estimate accounts for the extended duration of resource allocation associated with multiple releases to production.

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 Responsibility Assignment Matrix.  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, Responsibility Assignment Matrix 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

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 to support the budget request for the project 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.

​​​