PROJECT MANAGEMENT METHODOLOGY

SECTION 3 -- PLANNING PHASE

Section 3: Project Planning

Table of Contents

Introduction...... 3-1 Overview...... 3-1 The Planning Process and the Project Plan ...... 3-1 Project Objectives and Scope...... 3-1 Work Breakdown Structure...... 3-1 Activity Definition and Sequencing ...... 3-1 Resource Planning ...... 3-1 Project Schedule Development...... 3-1 Risk Planning ...... 3-1 Procurement Planning...... 3-1 Quality Planning ...... 3-1 Communications Planning ...... 3-1 Change Management Planning...... 3-1 Budget Planning...... 3-2 Planning Throughout the Project ...... 3-2 Project Planning Transition Checklist ...... 3-2 Information Technology Components for Project Planning ...... 3-2 Overview ...... 3-3 The Planning Phase...... 3-3 The Intent of Project Planning...... 3-3 The Importance of Project Planning ...... 3-3 Project Planning Roles and Responsibilities...... 3-4 Terminology ...... 3-5 The Planning Process and the Project Plan ...... 3-7 The Planning Process...... 3-7 Steps in the Planning Process...... 3-8 The Project Plan...... 3-9 Critical Success Factors...... 3-10 Format of the Project Plan...... 3-10 Project Plan Review...... 3-11 Project Plan Template ...... 3-12 Project Objectives and Scope...... 3-17 Project Objectives ...... 3-17 Defining Project Scope...... 3-18 Project Scope Statement...... 3-18 Project Scope Management...... 3-18 Work Breakdown Structure...... 3-19 Work Breakdown Structure Definition...... 3-19 Work Breakdown Structure Development ...... 3-19 Work Breakdown Structure Format...... 3-21 Cost Benefit Analysis ...... 3-23 Helpful Hints for Developing the Work Breakdown Structure...... 3-26 Work Breakdown Structure – Table Format Development ...... 3-31 Sample Work Breakdown Structure – Table Format...... 3-32 Activity Definition and Sequencing...... 3-39 Developing Project Tasks ...... 3-39 Defining Project Tasks...... 3-39 Defining Task Relationships ...... 3-40 Defining Deliverables...... 3-40 Resource Planning...... 3-42 Overview of Resource Planning...... 3-42 Labor Resources...... 3-42 Non-Labor Assets...... 3-46 Additional Criteria...... 3-46 Team Development ...... 3-47 Resource Plan Template...... 3-48

December 2004 Page 3- ii State of Michigan PMM Section 3: Project Planning

Table of Contents

Project Schedule Development ...... 3-51 Project Schedule Development Introduction ...... 3-51 Overview of Project Scheduling...... 3-52 The Schedule Process...... 3-54 Schedule Techniques...... 3-54 Schedule Inputs ...... 3-58 Schedule Development and Maintenance...... 3-59 Schedule Baseline...... 3-64 Other Helpful Hints for Creating a Project Schedule...... 3-65 Risk Planning...... 3-70 Project Risk Planning Introduction...... 3-70 Step 1: Risk Management Strategy Development ...... 3-73 Step 2: Risk Identification...... 3-75 Step 3: Qualitative and Quantitative Risk Analysis...... 3-76 Step 4: Risk Response Planning...... 3-80 Risk Management Plan Template...... 3-83 Procurement Planning...... 3-86 Procurement Planning Defined...... 3-86 What to Procure...... 3-86 When to Procure (Decision Tools) ...... 3-86 How to Procure (Contract Types)...... 3-87 How Much to Procure...... 3-87 Procuring IT Related Goods and Services...... 3-88 Procurement Vehicles / Program Selection...... 3-88 Procuring Commodities (IT Related)...... 3-88 Hardware/Software Maintenance...... 3-89 Checklist of Forms Needed to Purchase Commodities ...... 3-90 Services ...... 3-90 Checklist for Forms Needed to Purchase Services ...... 3-92 Statement of Work Development...... 3-92 Monitoring Invoice Process...... 3-98 References For Additional Information...... 3-98 Acronyms...... 3-99 Quality Planning...... 3-100 The Quality Management Process...... 3-100 Quality Management ...... 3-100 Quality Tools and Techniques...... 3-101 Responsibility for Quality...... 3-103 Checklists...... 3-103 Quality Plan Template...... 3-103 Communications Planning...... 3-106 Communications Planning Defined ...... 3-106 Communications Information Requirements ...... 3-106 Communications Plan...... 3-107 Communications Plan Template...... 3-107 Performance Reporting ...... 3-115 Change Management Planning...... 3-110 Change Management Planning Defined...... 3-110 Purpose of Change Management Planning...... 3-111 Roles and Responsibilities ...... 3-111 Process ...... 3-111 Scope ...... 3-112 Project Baseline and Management Plans ...... 3-112 Control Items...... 3-112 Change Sources ...... 3-112 Issue Management ...... 3-115 Change Tracking...... 3-115

December 2004 Page 3- iii State of Michigan PMM Section 3: Project Planning

Table of Contents

Project Change Management Plan Template ...... 3-116 Budget Planning ...... 3-118 Budget Planning Introduction ...... 3-118 Overview of Project Budgeting ...... 3-118 Identify Cost Factors ...... 3-118 Create Cost Model ...... 3-119 Perform Risk Analysis...... 3-120 Document Assumptions ...... 3-120 Review the Cost Estimates...... 3-120 Budget Format ...... 3-121 IT Project Budget Estimate Template...... 3-121 Planning Throughout the Project ...... 3-124 Planning Throughout the Project ...... 3-124 Planning in the Initiation Phase...... 3-124 Planning in the Planning Phase ...... 3-124 Planning in the Execution and Control Phases...... 3-125 Planning in the Closeout Phase...... 3-125 Project Planning Transition Checklist...... 3-126 Project Planning Transition Checklist ...... 3-126 Usefulness of Project Checklists...... 3-126 Project Planning Transition Checklist Defined ...... 3-126 Project Planning Transition Checklist Creation ...... 3-127 Format of a Project Planning Transition Checklist ...... 3-127 Project Planning Transition Checklist Template ...... 3-127 Information Technology Components for Project Planning ...... 3-132 Information Technology Project Planning...... 3-132 Information Technology Project Scope Statement...... 3-133 Information Technology Work Breakdown Structure ...... 3-133 Information Technology Cost Benefit Analysis ...... 3-134 Information Technology Resource Plan...... 3-134 Information Technology Schedule Development...... 3-135 Information Technology Risk Planning ...... 3-135 Information Technology Quality Planning ...... 3-136 Information Technology Communications Planning ...... 3-136 Information Technology Project Budgeting ...... 3-137 Information Technology Planning Summary ...... 3-137 Sample Information Technology Work Breakdown Structure...... 3-138

December 2004 Page 3- iv State of Michigan PMM Section 3: Project Planning

Introduction

Introduction This subsection describes the intent of project planning, the roles and responsibilities involved, and some of the associated terminology.

The Planning Process and This subsection describes the process of planning and developing the project the Project Plan plan. The plan will provide the framework for the other planning documents as well as the other project phases.

Project Objectives and Scope This subsection discusses the need within an agency to understand the objective of the product/process being created and where this new project fits into the agency objectives. The creation of the project objectives and scope documents are described.

Work Breakdown Structure This subsection describes in some detail the need for a Work Breakdown Structure (WBS) and how to go about creating one.

Activity Definition and This subsection describes the further breakdown of the WBS including Sequencing detailed explanations of tasks, the different types of tasks, putting tasks in the correct order, and their control systems (charts).

Resource Planning This subsection discusses the need to assign project roles, details information on the selection of a project manager (PM) and the project manager’s responsibilities as well as the reporting relationships within the project infrastructure.

Project Schedule This subsection of the methodology describes the process undertaken to Development develop a project schedule and the associated network diagram.

Risk Planning This subsection describes the processes and plans that must be a part of good risk planning.

Procurement Planning This subsection describes what role procurement plays in a project as well as what goes into proper procurement planning.

Quality Planning This subsection explains how to identify which quality standards are relevant to the project and determine how to satisfy them.

Communications Planning This subsection describes the process for planning communications, including who will need what information, how often, etc.

Change Management This subsection describes the change management planning that will be used Planning later in the Control Phase.

December 2004 Page 3- 1 State of Michigan PMM Section 3: Project Planning

Introduction

Budget Planning This subsection describes the different types of budgets used in project planning as well as what reserves are and when they should be used.

Planning Throughout the This subsection describes the planning throughout different project phases to Project allow a better understanding of how they interrelate.

Project Planning Transition This subsection describes a helpful checklist for project managers that will Checklist make the transition from the Planning Phase to the Execution Phase much easier.

Information Technology This subsection describes some important considerations involved with Components for Project information technology (IT) projects. Specifically, it allows for the opportunity to develop processes that will make the project effort easier to Planning manage.

December 2004 Page 3- 2 State of Michigan PMM Section 3: Project Planning

Overview

The Planning Phase The Project Planning Phase follows the Project Initiation Phase and is considered to be the most important phase in project management. Time spent up front identifying the proper needs and structure for organizing and managing projects saves countless hours of confusion and rework in the Execution and Control Phases of the project.

Figure 3.1 depicts at what point in the Project Management Phases this section of the methodology will be discussed.

Project Management

Phases

INITIATION PLANNING

CONTROL EXECUTION

CLOSEOUT

Figure 3.1 Project Management Planning Phase

The purpose of this phase in the project management process is to establish business requirements, establish precise cost and schedule of the project (including a list of deliverables and delivery dates), establish the work organization, and to obtain management approval.

The Intent of Project Without planning, a project’s success will be difficult, if not impossible. Planning Team members will have limited understanding of expectations, activities may not be properly defined, and resource requirements may not be completely understood. Even if the project is finished, the conditions for success may not have been defined. Project planning identifies several specialized areas of concentration for determining the needs for a project. Planning will involve identifying and documenting scope, tasks, schedules, risk, quality, and staffing needs. The identification process should continue until as many of the areas as possible of the chartered project have been addressed.

The Importance of Project Inadequate and incomplete project planning is the downfall of many high- Planning profile, important projects. An adequate planning process and project plan will ensure that resources and team members will be identified so that the project will be successful.

December 2004 Page 3- 3 State of Michigan PMM Section 3: Project Planning

Overview

Project Planning Roles and Everyone on the project team and, in most cases, several stakeholders will Responsibilities play a part in the input to planning a project. The responsibilities for project planning are summarized below:

• Project managers are responsible for developing a Project Plan for a specific project. The project manager is responsible for ensuring that the overall planning requirements are fulfilled. This includes delegation of responsibility for specific plan documentation and sign-off for approval at the end of the Planning Phase.

• State agencies are responsible for developing internal procedures to ensure that the planning process is completed consistently with the agency’s business plan. All projects must be well thought out, support key stakeholder goals, and include documented processes that allow the project to be tracked and controlled until closure. When the situation calls for it, agency personnel should be involved in Project Plan approval.

• Functional/organizational management is also responsible for ensuring that there are adequate resources assigned to a project. This includes both managerial and product development assignments. A separate management line item is recommended so that management costs are not rolled into overhead costs. Management is a full-time job for most projects – it is not an activity well suited to being performed in small part by many staff members.

• Key stakeholders play an integral part in the planning of a project. They should have representative input and approval in the Project Plan and associated documents before the Project Execution Phase takes place.

Relationships of the planning processes described in this section of the methodology are depicted in Figure 3.2.

December 2004 Page 3- 4 State of Michigan PMM Section 3: Project Planning

Overview

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.2 Relationships among the Planning Processes

Terminology As with all the sections of this methodology, a full glossary of terms is provided in Appendix A; however, the following is a subset of terms relative to project planning:

Activity - The work or effort needed to achieve a result. An activity consumes time and usually consumes resources.

Budget - When unqualified, refers to an estimate of funds planned to cover a project for a specified period of future time.

Project Network Diagram - Any schematic display of the logical relationships of project activities. Always drawn from left to right to reflect project chronology. Often incorrectly referred to as a “PERT chart.”

Project Plan - A formal, approved document used to guide both project execution and project control. The primary uses of the Project Plan are to document planning assumptions and decisions, to facilitate communication among stakeholders, and to document approved scope, cost, and schedule baselines.

Quality - A composite of attributes (including performance features and characteristics) of the product, process, or service required to satisfy the need for which the project is undertaken.

Requirements Document - A formal document that outlines the high-level requirements of a technical project.

December 2004 Page 3- 5 State of Michigan PMM Section 3: Project Planning

Overview

Resource - Something that lies ready for use or that can be drawn upon for aid or to take care of a need.

Resource Planning - Determining what resources (people, equipment, materials) are needed in what quantities to perform project activities.

Risk - An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.

Risk Event - A discrete occurrence that may affect the project for better or worse.

Risk Management - The art and science of identifying, analyzing, and responding to risk factors throughout the life of a project and in the best interests of its objectives.

Schedule - The planned dates for performing activities and for meeting deliverables.

Stakeholders - Individuals and organizations who are involved in or may be affected by project activities.

Work Breakdown Structure (WBS) - A deliverable-oriented grouping of project elements that organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of a project component. Project components may be products or services.

December 2004 Page 3- 6 State of Michigan PMM Section 3: Project Planning

The Planning Process and the Project Plan

The Planning Process Project planning is not a single activity or task. It is a process that takes time and attention. Remember that the project is not the product/process deliverable itself, but rather all of the activities, documents, and pieces that go into producing the product or process.

Similarly, the intent of the Project Management Methodology in its entirety is to create a project management process that is repeatable and stable enough for all agencies and their personnel to use. This process includes people with many different backgrounds and from various functional areas. The process is created to ensure the flow of the planning efforts from beginning to end in such a way that all of the necessary areas affecting the project process (or created by it) are considered.

This same idea holds true on individual projects within the agencies. Project planning defines the project activities that will be performed, end products that will be produced, and describes how all these activities will be accomplished. The purpose of project planning is to define each major task, estimate the time and resources required, and provide a framework for management review and control. The project planning activities include defining the following:

• Specific work to be performed and goals that define the project • Estimates to be documented for planning, tracking, and controlling the project • Commitments that are planned, documented, and agreed to by affected groups • Project alternatives, assumptions, and constraints • Creation of baseline plans from which the project will be managed

The relationships among the planning processes are depicted in Figure 3.3 on the following page.

December 2004 Page 3- 7 State of Michigan PMM Section 3: Project Planning

The Planning Process and the Project Plan

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.3 Project Plan Identified in the Planning Processes

The planning process includes steps to estimate the size of the project, estimate the technical scope of the project, estimate the resources required to complete the project, produce a schedule, identify and assess risks, and negotiate commitments. Completion of these steps is necessary to establish the Project Plan. Typically, several iterations of the planning process are performed before a plan is actually completed.

Steps in the Planning Process The planning process consists of the following basic tasks:

• Defining the technical approach used to solve the problem • Defining and sequencing the tasks to be performed and identifying all deliverables associated with the project • Defining the dependency relations between tasks • Estimating the resources required to perform each task • Scheduling all tasks to be performed • Defining a budget for performing the tasks • Defining the functional area(s) used to execute the project • Estimating each task’s duration • Identifying the known risks in executing the project • Defining the process used for ensuring quality • Defining the process used for specifying and controlling requirements

These tasks are described in subsequent sections and each process is defined within the Project Plan Format Template. The Project Plan represents the basic tool for successfully executing a project.

December 2004 Page 3- 8 State of Michigan PMM Section 3: Project Planning

The Planning Process and the Project Plan

The Project Plan What is a Project Plan?

A Project Plan is a formal, approved document used to guide both project execution and project control.

PMBOK®, 2000

The Project Plan forms the basis for all management efforts associated with the project. It is a record of plans that is expected to change over time.

The assigned project manager creates the Project Plan. It should be as accurate and complete as possible without being several volumes in length. The Project Plan documents the pertinent information associated with the project; it should not be a verbose document. It is a document that allows the project manager to manage the details, and not be managed by the details. The Project Plan should cover the following topics at a minimum:

• General Project Information (points of contact, phone numbers, etc.) • Project Executive Summary • Project Scope • Critical Success Factors • Work Breakdown Structure • Organizational Breakdown Structure • Cost-Benefit Analysis • Resource Plan • Project Schedule • Risk Plan • Procurement Plan • Quality Plan • Communications Plan • Change Management Plan • Project Budget Estimate • Project Planning Transition Checklist

While each of these areas should be discussed within the Project Plan, it is still imperative to develop documents and processes that describe each of these in detail. These are areas discussed in detail in other subsections within the Project Planning section.

December 2004 Page 3- 9 State of Michigan PMM Section 3: Project Planning

The Planning Process and the Project Plan

Critical Success Factors As a part of setting objectives and scope, it is always a good idea to set critical success factors that can determine whether a particular phase of the project will be completed successfully. The deliverables stated within documents such as the Project Scope Statement and the Project Plan can be good indicators for determining if a project is meeting its stated success factors. It is also possible to set baseline dates against critical success factors to ensure that the project is meeting its success criteria.

For instance, a success objective for a particular project might be to have a Project Plan and schedule approved and baselined two weeks after initiation. Beyond that, a project success might be captured by having a working prototype of a product (database) or a beta test group of a process (agency training program) completed by a certain calendar date within the implementation period.

These success objectives need to be clearly stated and there must be a clear understanding within the project team as to why they are relevant to the project. The objectives should be aggressive and challenging and may be difficult to achieve at times. However, they will be the benchmark for which your project success will be set. Furthermore, they should coincide and be consistent with overall project scope and schedules.

Success objectives do not necessarily need to be formally documented and incorporated into the Project Plan, but should be a motivator for reaching success milestones.

Format of the Project Plan A format template for a Project Plan is provided on the following pages and separately in Appendix B.

The template is presented in an abbreviated form. The actual template and particular sections, once filled in with project data, will be longer than they appear in the blank template.

It is suggested that all areas of the Project Planning Phase be reviewed in detail before the actual Project Plan is created. In fact, the review and the subsequent documents/plans created from the review may be summarized within the Project Plan, or in some cases, is attached to the Project Plan. It is imperative, however, that all areas required in the Project Plan be addressed. As mentioned, the Project Plan is a repository of records that summarizes the general processes and plans that highlight the detailed processes within the project management methodology.

The information associated with the Project Plan evolves as the project moves through its various stages and is to be updated as new information develops about the project. This, of course, will require revision to the Project Plan itself. As previously stated, the Project Plan is a dynamic document that is expected to go through many changes during the life of the project.

Once the Project Plan is approved and baselined, the original content of the Project Plan should not be changed. The Project Plan was agreed to by management and was signed. If the scope is to be modified, then the schedule or budget may be revised. These revisions are treated as addendums to the Project Plan.

December 2004 Page 3- 10 State of Michigan PMM Section 3: Project Planning

The Planning Process and the Project Plan

Project Plan Review Once the project manager completes the Project Plan, it should be reviewed and approved by agency management. The level and extent to which the plan will be reviewed is based on the size of the project as stated in dollars or period of time. Ultimately, the review process allows for executive management buy-in and approval of the plan. Once the Project Plan is approved and signed, the project manager is given the authority to complete the current project efforts and carry on into the Execution Phase.

December 2004 Page 3- 11 State of Michigan PMM Section 3: Project Planning

Project Plan Template

State of Michigan (Insert Project Name Here) Project Plan

A. General Information Information in the project summary areas that was drafted during the project concept phase and should be included here. Information includes the project name, original estimates, plan revision numbers, points of contact, etc.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by: Prime Contractor: Date Awarded:

Please answer the following questions by marking “Yes” or “No” and provide a brief response as appropriate. Is this an updated Project Plan? If so, reason for update: Yes No

Budget for project by fiscal year and is project funded? If so, for what amount(s) and period(s) Budget Amount: Fiscal Year: Funded? Yes No Budget Amount: Fiscal Year: Funded? Yes No Budget Amount: Fiscal Year: Funded? Yes No

Agency Points of Contact This should be the list of individuals that will be involved with the project during the Execution Phase.

Position Name Phone E-mail Project Manager Senior Management Sponsor Senior Technical Sponsor Procurement Contact Project Team Member Project Team Member Customers:

Other Stakeholders:

Other:

December 2004 Page 3- 12 State of Michigan PMM Section 3: Project Planning

Project Plan Template

Prime Contractor Information Company Name:

Position Name Phone E-mail Project Manager Senior Technical Sponsor Contracts Contact Other

B. Executive Summary Information in the project summary areas was started during the project concept phase and should be included here. Information includes the project name, original estimates, plan revision numbers, points of contact, etc.

Business Need/Problem

Identify business need/problem that needs to be solved.

Statement of Work

This statement should be short and to the point. It should not contain language or terminology that might not be understood.

Project Objectives

Provide a brief, concise list of what the project is to accomplish.

Project Approach

Describe the strategy to deliver the project. For example, it may describe a phased strategy, contracting approach, reference to implementation, etc. Subsections may be created to present the strategy.

C. Project Scope Statement Describe what will be the included as part of the overall project.

Project Results/Completion Criteria

State what will be created in terms of deliverables (and their characteristics) and/or what constitutes a

December 2004 Page 3- 13 State of Michigan PMM Section 3: Project Planning

Project Plan Template

successful phase completion.

Approach to be Used

State in sufficient detail, what type of approach will be used to manage scope changes. State whether the project be done internally or require "outside" assistance.

Content of the Project

Define what work is to be done. Include relevant business requirements.

Exclusions

Define what work is not to be done. Include relevant business requirements.

D. Critical Success Factors Describe what will be the determining factors that are needed to ensure project success.

E. Additional Project Requirements Provides a detailed listing of project requirements, with references, to the Statement of Work, the Work Breakdown Structure, and specifications. This would also include any mechanisms used to assist in the management control over the project. Escalation procedures, cyclical management reporting, and project status reports should also be included.

No Requirement SOW Task Specification Date Comments/ . Reference Reference Reference Completed Clarification 1. 2. 3. 4. 5.

F. Technical Project Components Provide a detailed listing of the Requirements Definition, Specifications, Design, and Implementation and Training Plans for inclusion into the project activities.

December 2004 Page 3- 14 State of Michigan PMM Section 3: Project Planning

Project Plan Template

G. Signatures The signatures of the people below relay an understanding in the purpose and content of this document by those signing it. By signing this document you agree to this as the formal Project Plan.

Name/Title Signature Date

H. Project Plan Documents Summary Check the box for each document included in the project plan.

WORK BREAKDOWN STRUCTURE Describes a deliverable-oriented grouping of project elements which organize and define the total scope of the project.

RESOURCE PLAN Describes the major resources needed to proceed with the execution of the project.

PROJECT SCHEDULE Provides the project schedule using a Gantt chart. The schedule must include milestones, task dependencies, task duration, work product delivery dates, quality milestones, and action items.

RISK MANAGEMENT PLAN Provides a description of all risks identified for the project and a plan to integrate risk management throughout the project.

QUALITY PLAN Provides a Quality Plan that defines the person(s) responsible for project quality assurance, procedures used and resources required to conduct quality assurance.

COMMUNICATIONS PLAN Defines the information needs of the project stakeholders and the project team by documenting what, when, and how the information will be distributed.

CHANGE MANAGEMENT PLAN Provides the project team with a change management methodology for identifying and controlling project scope.

PROJECT BUDGET ESTIMATE Describes cost and budget considerations including an overview, additional resource requirements, and estimated cost at completion.

December 2004 Page 3- 15 State of Michigan PMM Section 3: Project Planning

Project Plan Template

PROJECT PLANNING TRANSITION CHECKLIST The Project Planning Transition Checklist ensures that planning activities have been finished, reviewed, and signed off so that the project may move into the Execution Phase.

December 2004 Page 3- 16 State of Michigan PMM Section 3: Project Planning

Project Objectives and Scope

Project Objectives Project objectives, as described earlier, are those criteria within the project that will determine whether the project is a success or a failure. If the product or process designed does not meet the objectives as laid out by the project stakeholders, then customer satisfaction will be jeopardized. Objectives can be described in two different ways:

• Hard Objectives - These relate to the time, cost, and operational objectives (scope) of the product or process. • Soft Objectives - These relate more to how the objectives are achieved, and which may include attitude, behavior, expectations, and communications.

Remember that objectives should be set at an acceptable level with the intent of delivering product or process that meet the objectives. The objectives should be documented and agreed upon in order to deliver a suitable product. In short, project objectives planning is about defining the acceptable limits and looking for ways to meet them.

The relationship of the project objectives and project scope to the rest of the Planning Phase components is shown in Figure 3.4.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.4 Project Objectives and Scope Identified in the Planning Processes

December 2004 Page 3- 17 State of Michigan PMM Section 3: Project Planning

Project Objectives and Scope

Defining Project Scope There is often confusion in project teams regarding the difference between project objectives and project scope. The term "project scope" refers to the magnitude of the effort to complete a project. Conversely, the term "project objectives" refers to a description of the desired outcome of the project. For example, the objective could be to build a new five-story building on the location of the back parking lot by next December. The scope could be to build the building with a prefabricated metal frame with a cement floor. Consequently, it is imperative that the project objectives and the project scope be clear to everyone to ensure project success.

Project Scope Statement The development of a written statement, known as the Project Scope Statement, provides the basis for future project decisions. This statement is of singular importance to the project, as was previously stated, because it sets the overall guidelines as to the size of the project. The content of this statement, at a minimum, will include the following:

• Project Results/Completion Criteria: What will be created in terms of deliverables (and their characteristics) and/or what constitutes a successful phase completion. • The Approach to be Used: What type of process or technology will be used, whether the project will be done internally or externally, etc. • Content of the Project: What is and is not included in the work to be done.

Inputs to the Scope: The following documents may be helpful in defining the project scope: • Project Work Statement • Project Objectives (including identified constraints and assumptions) • Project Feasibility Document • Project Concept Document • Project Charter

To ensure that the project scope is completed correctly and in its entirety, it is imperative that a Project Scope Statement be completed and signed by the key stakeholders.

Project Scope Management Project scope management can be just as important to scope planning as the Scope Statement itself. This effort describes how the project scope will be managed and how scope changes will be integrated into the project. It is a simple statement that discusses the likelihood of scope change within the project and how any changes will be identified. The efforts of scope management should integrate well with the Change Management Plan created later in the planning process. More formalized processes of scope management are normally used on larger projects in which the likelihood for scope creep or changing requirements is much greater.

December 2004 Page 3- 18 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Work Breakdown Structure The Work Breakdown Structure (WBS) component of the Planning Phase Definition provides the capability to break the scope into manageable activities, assign responsibility to deliver the project scope, and establish methods to structure the project scope into a form that improves visibility for management. The WBS also requires that the scope of the overall project be documented.

The relationship of the Work Breakdown Structure to the rest of the Planning Phase components is shown in Figure 3.5.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.5 Work Breakdown Structure Identified in the Planning Processes

A WBS is a hierarchical representation of the products and services to be delivered on a project. Elements of scope are decomposed to a level that provides a clear understanding of what is to be delivered for purposes of planning, controlling, and managing project scope. In its entirety, a WBS represents the total scope of a project. A WBS is neither a schedule nor an organizational representation of the project; instead, it is a definition of what is to be delivered. Once the scope is clearly understood, the project manager must determine who will deliver it and how it will be delivered. This is the one planning tool that must be used to ensure project success on any size project.

Work Breakdown Structure Figure 3.6, on the following page, depicts the process to develop a Work Development Breakdown Structure.

December 2004 Page 3- 19 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Assign High- Assign Develop High- Decompose Level Responsibility Level WBS WBS Responsibility to Elements

Perform Cost Create WBS Review and Benefit Baseline WBS Dictionary Approve WBS Analysis

Figure 3.6 WBS Development Process

Develop High-Level WBS Typically, the project charter provides the overall scope of the project and is used as the basis to define high-level WBS elements of project scope. The high-level WBS can be quickly defined by using predefined templates.

Assign High-Level Responsibility Once the high-level elements of the WBS are defined and the organization is established to deliver the project, the agency entities responsible to deliver the overall elements of scope are assigned responsibility for the high-level WBS elements. This will ensure a management focus to decompose the high-level elements into discrete products and services and thus complete the task of defining the entire scope of the project.

Decompose WBS The WBS is decomposed into discrete products and services to be delivered during the project. Higher level elements represent groupings of products and services to be delivered. Decomposition identifies discrete products and services. Elements are decomposed in the following way:

• A discrete product or service is identified • Responsibility to deliver the product or service is assigned to one individual or functional area • Scope is clearly understood • Cost is reasonably estimated • The element is manageable • Higher risk or more critical elements are decomposed to a lower level

Assign Responsibility to Elements After the WBS is decomposed to the lowest level, responsibility is assigned to all elements. Assignment at the higher level ensures that management is responsible for the entire project scope. Individuals assigned to the lower level elements are responsible for planning, controlling, and delivering the product. For more information on this topic, refer to the Resource Planning subsection.

Perform Cost Benefit Analysis

December 2004 Page 3- 20 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

After responsibility for each WBS element is established, a cost benefit analysis is performed on each WBS element to determine if the cost of that element contributes to the overall project as compared to it’s cost. Often times, the WBS element is required and a cost benefit analysis is unnecessary. For more information on this topic, refer to the Cost Benefit Analysis subsection.

Create WBS Dictionary Once defined, an element’s scope is described. This description is often referred to as a "Work Breakdown Structure Dictionary". The purpose of the work breakdown structure dictionary is to clearly describe what scope is to be delivered within each element so that the functional area responsible for delivery can accept it, plan it, and manage the delivery. The WBS Dictionary is often created during activity definition (refer to the "Activity Definition and Sequencing" subsection).

The work breakdown structure dictionary also provides boundaries and hand-offs between functional areas responsible for delivery. The WBS Dictionary is often a separate document that the WBS references.

Review and Approve WBS Senior management within the project reviews and approves the WBS and its supporting dictionary. Those personnel who are assigned responsibility should accept the responsibility to deliver the scope of each element. This step is essential in assuring management commitment to the project.

Baseline WBS Once defined and accepted by the responsible functional areas, the WBS is baselined and put under change control. This means that the work effort of project team members is consistent with the scope defined in the WBS. Changes to scope are controlled through a defined process, and the WBS provides a vehicle to capture, assess, review, and implement change.

Work Breakdown Structure The WBS is simple in its intent but can be elaborate in its presentation. The Format WBS may be a simple bulletized list of activities or detailed spreadsheet list of tasks and subtasks, depending on the size of the project. Regardless of its size, however, the importance of the WBS cannot be overstated. Work breakdown structures come in several formats. An example of a WBS is provided at the end of this subsection. A graphical representation (organization chart) can be seen in Figure 3.7 on the next page.

December 2004 Page 3- 21 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Work Breakdown Structure (WBS)

Initiation Planning Execution Control Closeout

Description Procurement Administrative Project Notebook Statement Planning Plan Execution Control Activities Closeout

Develop Description Develop Project Develop Procurement Distribute Perform Metrics & Perform Administrative Statement Notebook Plan Assignments Status Review Report Closure Perform Change Financial Feasibility Objectives & Execute Quality Planning Control Closure Document Scope Tasks Perform Scope Financial Project Develop Critical Develop Quality Control Audit Develop Feasibility Administration Document Success Factors Plan Perform Quality Archiving Develop Project Ongoing Project Control Communications Scope Statement Administration Personnel & Concept Document Planning Perform Schedule Facilities Work Breakdown Execute Quality Control Develop Concept Structure Develop Assurance Perform Cost Post Document Communications Plan Monitor Control Implementation Develop Work Performance Perform Risk Evaluation Report Breakdown Structure Project Charter Budget Planning Monitor Control Lessons Learned Risk Perform Contract Organizational Assemble Post Identify Cost Ongoing Information Administration Develop Project Brkdwn Structure Implementation Factors Distribution Perform Configuration Charter Evaluation Report Develop Org. Brkdwn Review Cost Management Development & Structure Estimates Integration Maintenance Develop Budget Activity Definition & Estimates Sequencing Develop Hardware Software Transition Maintenance Activity & Deliverable Procure Checklist Software Definition Hardware Maintenance Activity Complete Project Procure Software Sequencing Planning Checklist packages Perform Integration Project Schedule Requirements testing Definition Convert Develop Project Define Data Schedule Requirements Develop User Develop Manual Resource Planning Requirements Transition Management Develop Resource Specifications Acceptance Plan Testing Define Cost Benefit Plan Acceptance Specifications Analysis Test Develop Conduct Acceptance Develop Cost Benefit Specifications Analysis Testing Develop Test Configuration Design Report Management Prepare preliminary Installation Develop Configuration design Management Plan Prepare detailed Develop Installation design Plan Risk Planning Document Site design Preparation Identify Review Install at Risks design Locations Develop Mitigation Strategy IT related tasks Assemble Risk Plan

Figure 3.7 A Typical Software Development WBS

December 2004 Page 3- 22 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Cost-Benefit Analysis A Cost-Benefit Analysis (CBA) provides the information to make a balanced decision about the cost and benefits (or value) of various economic choices (for example, performing a single regression test vs. performing multiple regression tests). It is a methodology for the project team and the customer (client) to use when decisions need to be made among competing alternatives. It enables the project team to quantify the activities of the existing and alternative processes.

Once the work breakdown structure is nearing completion, the project team needs to consider alternatives to ensure the project delivers a timely, usable, and cost effective product or service.

When the project team conducts a CBA, it is defining its objectives and alternatives in terms of costs and benefits. It is also defining important assumptions, factors, and judgments to build the cost and benefits used in comparing alternatives. A CBA provides the basis for making sound business decisions. It can also be used as the basis to justify decisions; as a baseline to measure progress against stated goals; and as a guide to understanding the impact of proposed changes.

Intent of a Cost-Benefit Analysis

A cost-benefit analysis provides a method for making choices among alternatives based on their costs and benefits. When the project team and customer must choose between two or more options, the CBA will provide straightforward, quantitative information that can be easily and quickly used to support decisions.

Getting Started

The underlying foundation for analyzing the costs and benefits of proposed solutions includes the following sequence:

1. Define the project, objectives, alternatives, assumptions, ground rules, and the elements to be costed 2. Research the cost elements, analyze them, collect the appropriate data, decide on an estimating methodology, and then cost them all 3. Identify the principal functional and technical cost drivers and their sensitivity to changes in assumptions 4. Analyze risk items and perform sensitivity analysis, including collecting total lifecycle costs and benefits 5. Analyze the relative merit of alternatives 6. Present the results

Keep the approach flexible and tailorable so that the effort and results are consistent with the size and complexity of the alternatives being evaluated, the lifecycle phase, and the level and type of review being supported.

The following is an outline of the general steps needed to complete a CBA. The project team and customer can use the results to choose among alternatives and then track progress against defined goals.

December 2004 Page 3- 23 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Format and Content

It is always helpful to know, in general, how the final product and its content should look. This knowledge will help the project team organize work as it progresses. The amount of detail and information included in a CBA depends on the size and complexity of the individual project.

For large projects, a spreadsheet may be utilized to document the various alternatives and costs. For small projects, a short white paper or a few slides will suffice to cover the relevant information. Do not spend more time and money on the analysis than the program is worth. It should be a tool to help organize information so that economical decisions can be made. Typical appendices to a CBA might include the following:

• Detailed cost estimates for individual alternatives, including the basis for estimating each work breakdown structure element • A WBS outline and a dictionary that defines what is in each cost element • Detailed schedules that can later be used to manage the project • Specific references and guidance documents supporting the project • Data sources and references to support the estimating methodology • A glossary that defines abbreviations and terms used in the analysis

No matter how the information is organized, the document should stand on its own and accurately support agency recommendations.

Cost-Benefit Analysis Steps

The general steps for performing a CBA are listed below. Using this approach as a framework for developing a CBA will help the project team evaluate its status quo / alternative (as-is/to-be) processes, define the objectives more thoroughly, and address the alternatives consistently. Although the general outline should always be followed, the amount of detail used during each step will vary depending on the size and complexity of the individual project.

1. Define the Project. This step is the most critical. It forms the foundation for the rest of the effort. It includes identifying the problem to be solved, the objectives of the mission or function, and the alternatives that will satisfy the customer’s needs while staying within environmental factors such as assumptions and constraints. It also includes defining the work breakdown structure deliverables to be costed and the assumptions and ground rules for the status quo and alternatives models. The WBS becomes the outline for the rest of the work to be done. The WBS will be updated on a regular basis as the analysis progresses.

2. Research the Cost Elements. This step includes researching the cost elements that make up the WBS, collecting appropriate cost-driver data, analyzing and validating the data, deciding on an estimating methodology, and then costing all the elements. The need is to develop future profiles of the current system and the projected profiles of alternative proposed systems.

December 2004 Page 3- 24 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

3. Identify Cost Drivers. Once the basic estimating is done, there is a need to identify the principal functional, technical, and schedule cost drivers and their potential sensitivity to changes in assumptions or project decisions in preparation for the next step.

4. Analyze Risk and Sensitivity. Once the costs are calculated for each lifecycle phase, they are then aggregated to show total lifecycle costs and benefits. Based on this information, the project team will identify the cost-risk items and perform sensitivity analysis to determine whether changes might alter the original recommendations or simply assess what happens if some sensitive cost element exceeds the current estimate. The sensitivity analysis tests the impact of risk and uncertainty to determine which conditions might change the ranking of alternatives.

5. Analyze Alternatives. Next, analyze the relative merit of alternatives against each other, including their sensitivity to specified risks and potential changes. The results should also compare net benefits over time, return on investment (ROI), and show the break-even point for your investment.

6. Present the Results. The final step is to put together presentation materials to support your analysis and recommendations. Depending on the size and complexity of the project, this could be as simple as a white paper or briefing, or it could be more formalized.

Summary

Alternative costs should not be the only criteria used to evaluate new or improved processes. Following the steps outlined in this subsection for a CBA will provide the framework for systematically assessing monetary and non-monetary costs and benefits across existing and new processes. It is important to identify and estimate the costs and benefits using a common, comprehensive structure (WBS) so alternatives can be consistently compared and reflect accurate results and conclusions. This process provides a commonsense approach and outlines a sound methodology that will allow achievement of this objective.

The costs for each alternative for the WBS elements required to meet the objectives should be exhaustive. At the same time, the emphasis should always be on the quality of analysis rather than the quantity of analysis. Aim for a concise, clearly written CBA so that reviewers and senior management can easily follow the analysis, understand the key cost drivers, and understand how they affect the analysis. A quality CBA is achieved through a cooperative effort involving the project team and other functional personnel. Solid advance planning and definition are essential to completing a timely and useful CBA.

Planning requires early clarification of the tasking and a solid WBS based on a thorough exchange of information. Many of the tasks will be done in conjunction with, or at least overlap, other tasks. Also, many of the activities will go through several iterations as various aspects of the project are better defined.

December 2004 Page 3- 25 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Helpful Hints for Developing Templates the Work Breakdown All projects are unique; however, many projects are similar at a high level. Agencies that implement similar projects should develop templates to assist Structure in the planning process. A WBS template, a generic definition of project scope, provides an excellent starting point to tailor the specifics of a unique project. Templates should be at a relatively high level and in an automated format to allow for ease of use.

Because of the many types of projects that may exist in a single agency, different templates should be created. If tailoring a template requires extensive work, create your own WBS. It may be useful as a template for a later project.

Work breakdown structure templates provide the following:

• A generic structure for elements understood throughout the agency, allowing for consistent communication • The ability to ensure that the entire scope for a project is defined by starting with a template that breaks down WBS elements typically found in similar projects • A reduction in the amount of time spent developing a WBS

The following diagram, Figure 3.8, shows how WBS templates are used.

Figure 3.8 Work Breakdown Structure Usage

In the example above, the lined circles represent generic template elements that are not part of this particular project and should be deleted along with any associated “children” (subelements to the element in question). The boxes that are not shaded represent the breakdown of elements that are unique to the project and have been added to the template.

Review Inputs To ensure that the entire scope is defined and the WBS is structured to

December 2004 Page 3- 26 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

improve visibility to management, all information available describing the project should be reviewed. The review should be conducted before developing the WBS to ensure that the scope of the project and the management strategy in which to implement it are understood. Translating scope and strategy properly into the WBS is the most important step in developing a WBS. Typical inputs to WBS development are described in the Project Initiation Phase in Section 2 of this methodology.

Management Approach Each agency has a unique approach to managing projects. Approaches may affect the way products and services are delivered and how they are managed and controlled. The WBS should be designed to complement the project’s management approach. As an example, a software development project may entail a release strategy that provides different functionality of the software in two releases. The agency may use a structured waterfall development approach that entails creating a requirements document, a design document, and a source code. The resulting WBS may capture the strategy and the way it is controlled as shown in Figure 3.9.

Softw are Project

Release Release 1 2

Requi rem ents Requirem ents Do cument Document

De sign Design

Do cument Document

So urce Source

Code Code

Figure 3.9 Work Breakdown Structure Strategy

If the approach included only one requirements document independent of the release, the WBS would change to eliminate two documents, one under each phase, and have a third second-level item to capture one single document.

Product and Service Orientation

December 2004 Page 3- 27 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

The best way to view the purpose of a WBS is to understand that it focuses on what products and services are being delivered for the project. If management focuses attention on the individual components being delivered, the project will, in all likelihood, be delivered. If, on the other hand, management focuses on how the components are being delivered, they may not be able to see the forest for the trees.

Schedules focus on how a product or service is delivered. By design, schedules focus on activities and actions characterized by a verb-noun format. Products and services are not verbs. Therefore, verbs do not belong in a WBS. Once verbs are introduced into the WBS, there may be a tendency to focus on how the project is being delivered instead of what is being delivered.

Not an Organization Chart The WBS describes products and services to be delivered on a project. At the higher levels, similar products and services are grouped together to improve communication. For example, software at the highest level may represent software development and software procurement; at the lower levels, the distinction between development and procurement is made. Software procurement and development would probably be the responsibility of different functional areas at the lower levels. Therefore, it can be understood that the WBS is not an organizational breakdown, even though functional areas are assigned responsibility to deliver a product or service.

In many cases, because of the grouping of similar products and services, some functional areas may be responsible for all or most of a particular WBS leg. Because of automation, reporting a WBS in an organizational display is not difficult; therefore, it should not be organizationally based. Again, a WBS is product- and service-based.

Management Concurrence Usually the project manager and technical representatives of the project develop the WBS. Executive management is typically the prime recipient of WBS benefits. Therefore, all levels up to the project manager should understand the WBS including structure, scope, and use in reporting. Management must concur with, own, and use the WBS as a tool to manage the project. Without management ownership of the WBS, scope and its delivery can be less than optimal.

Work Breakdown Structure Dictionary The work breakdown structure dictionary describes in detail the scope of each element of WBS. The description includes what is to be delivered, attributes of the product or services, and, in some cases, what is not included within the element. Defining what is not included ensures that the responsible individual does not allow additional scope to be added. The work breakdown structure dictionary removes ambiguity. It can be used to communicate scope to contractors or subcontractors, in many cases forming the basis for a statement of work.

Simplicity Defining the scope of a project can be difficult (even for simple projects). As a tool for management focus, WBS size is important. If it is too large, it can be a management burden. Many WBS's have been made more complex

December 2004 Page 3- 28 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

than the project itself. A WBS should be created and elements broken down based on the amount of risk associated with the element of scope.

For example, in most cases, procuring desktop personal computers (PCs) is not high in risk. Therefore the element of scope can easily be left at the level of desktop PCs. The administrative deliverables, such as requirements specifications for each workstation, the purchase order to procure the PCs, the receiving document, and the installation checkout form, although deliverables, should not be identified in the WBS (although it should possibly be in the work breakdown structure dictionary) as separate elements.

Hardware procurement is not normally high in risk. Developed software is high in risk and should be defined further due to the increased risk. Developed software may be further broken down to identify a requirements specification document, a design document, and a source code. A balance needs to be struck between defining the entire scope properly and creating a complex WBS that is too large to be useful to management.

Coding Scheme Many projects are complex and require automated tools to assist in managing and reporting project information. A WBS, because of its hierarchical nature, requires that a parent-child (hierarchical) relationship be established and captured for automated reporting through the structure. To achieve the parent-child relationship, a coding scheme may be developed and assigned to elements. The simpler the coding scheme the better. The codes should not be assigned until the WBS is somewhat stable, requiring very few edits. This approach eliminates the use of complex schemes and the need to reassign codes because of changes in the WBS.

As shown in the simplified coding scheme example below, a WBS is also a family tree of related deliverables that make up an entire project.

Project XYZ Work Breakdown Structure 1.0 CMS Project 1.1 Project Management 1.2 Communications 1.3 Documentation 1.4 Hardware 1.5 Software 1.6 Systems Engineering 1.7 Facilities 1.8 Training

The WBS becomes the common basis for defining all of a project’s major deliverable components. It is also the basis for deriving the costs and benefits for the alternatives considered. The level of detail depends on the complexity of the project and how much definition is needed to derive accurate and complete costs and benefits. The lowest level within a WBS is the work package of activities needed to complete a deliverable. The sum of the cost to complete the activities in a work package is the cost of the deliverable, and the sum of all the deliverables is the total cost of the project.

Automation

December 2004 Page 3- 29 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Because the WBS represents the entire project scope and is coded using a hierarchical structure, automated databases and project management tools can enhance its ability to assist management in understanding project status. Using a database and the WBS code as a unique identifier, the entire WBS can be associated to most project management information elements.

Using desktop, client-server, and web-based reporting tools, the WBS can portray all aspects of project delivery. The WBS should be placed in an environment where tools can be used to manage the resulting project information.

Work Breakdown Structure and Project Reporting Because the WBS defines all products and services to be delivered and structures those attributes in a way meaningful to management, it should be used as the basis to report project status to management. Figure 3.10 provides a functional view of the types of project attributes that can be related to and reported against WBS elements.

Co st Change Track ing Management

WBS

Proj ect Quality Schedul es Management

Figure 3.10 Work Breakdown Structure Attributes

As stated earlier, if management is controlling the products and services to be delivered, the project will be delivered. If the elements that affect delivery are reported against the products and services, management control can be enhanced.

All attributes above require an association to the WBS element. Cost- tracking systems are normally part of an agency’s management information system and can be accessed to obtain cost data against each WBS element. Although financial systems may not be geared to track cost elements against a WBS, some negotiation can be made to obtain the desired information so it can be used (another reason to keep the WBS simple). Project schedules, quality, and change management systems are typically used on projects and have the inherent capability to report project information against a variety of

December 2004 Page 3- 30 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

customer-defined elements, including the WBS.

Other reporting relationships exist; this is only an example. The basic premise of this scenario is that it allows management to view those elements affecting project delivery. The WBS provides the mechanism to do so.

Rollup Reporting cost, schedule, quality, and change information to management via the WBS entails rolling up status information. It is termed “rollup” because the information is aggregated.

As an example, a schedule exists to deliver each product in the WBS (services may not always have a schedule). The schedule identifies the tasks to deliver the product. This is a many-to-one relationship (many tasks deliver one product). The schedule status information reported to management should be aggregated to the WBS element to display the planned (baseline) start and finish and the current start and finish for the WBS element. In this way, management can review the product’s delivery status against the baseline. If a problem exists, management can understand why and take corrective action.

Work Breakdown Structure – There are certain pieces of information needed to describe the WBS Table Format Development deliverable and then document it in a table format:

• Work Breakdown Structure Element or Number. From the WBS the agency has built (e.g., 1.5). • Work Breakdown Structure Task Name. From the WBS the agency has built (e.g., software). • Task Effort / Duration. From the WBS the agency has built (e.g., 65 hours of effort). • Resource Name. The individual who is responsible for the execution of this specific task. • Element or Dictionary Description. The definition, in simple terms, of the element and what it is intended to do for the project. • Cost. The total cost for the WBS element.

Other Elements of the Work Breakdown Structure Table Format As will be described in the Cost-Benefit Analysis subsection, the WBS is the foundation for deriving costs for each of the work packages (elements) of the project. Accordingly, the WBS table format can be expanded to include various columns that annotate costs associated with each element. These elements would include such things as element cost, cost derivations, methodologies used in estimating costs, and element costs of project duration (i.e., how costs are spread over time).

For a table format (spreadsheet) representation of the WBS, see the following pages. A Work Breakdown Structure Template can also be found in Appendix B.

December 2004 Page 3- 31 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Shaded areas are IT related tasks

WBS Task Name Effort / Resource Names WBS Dictionary Cost Duration 1 INITIATION 1.1 Project Description Statement Describe the characteristics of the product/process to be created. 1.1.1 Develop Project Description Project Manager, Statement Business Analyst 1.1.2 Project Description Statement Project Manager Milestone Completed 1.2 Project Feasibility Identify project constraints, alternatives, and related assumptions to analyze and discuss project feasibility. 1.2.1 Develop Project Feasibility Project Manager, Budget Document Analyst, Business Analyst

1.2.2 Project Feasibility Document Project Manager Milestone Approved 1.3 Project Concept Define project's reason for being initiated and compare to ensuring consistentcy with Agency's business plan throughout the identification of critical success factors, the product description statement, and other high planning information. 1.3.1 Prepare Project Concept Document Project Manager, Budget Analyst, Business Analyst

1.3.2 Project Concept Document Project Manager Milestone Completed 1.4 Project Charter Identify the name and purpose of the project. Also establish the statement of support from the issuer (management).

1.4.1 Prepare Project Charter Document Project Manager, Executive Manager, Business Analyst

1.4.2 Project Charter Approved Project Manager, Milestone Executive Manager 2 PLANNING 2.1 Develop Project Project Manager Develop a repository for all the Notebook/Document Management project plans System

2.2 Objectives and Scope Define the need within the agency to understand the objective of the product/process being created.

2.2.1 Develop Critical Success Factors Project Manager, Executive Manager, Business Analyst, Technology Owner

December 2004 Page 3- 32 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Shaded areas are IT related tasks

WBS Task Name Effort / Resource Names WBS Dictionary Cost Duration 2.2.2 Develop Project Scope Statement Project Manager, Prepare baseline plan. Executive Manager, External Resource, Functional Manager

2.2.3 Project Scope Statement Completed Project Manager Milestone

2.3 Work Breakdown Structure Create the structure that is a deliverable-oriented document that will be used to break down the work to be done within the project to a manageable level.

2.3.1 Develop Work Breakdown Structure Project Manager, Prepare baseline plan. Business Analyst, Technology Owner

2.3.2 Work Breakdown Structure Project Manager Milestone Completed 2.4 Activity Definition and Sequencing Develop the tasks that involve dividing the project into smaller, more manageable components and then specify the order of completion. 2.4.1 Activity and Deliverable Definition Project Manager, Business Analyst, Technology Owner

2.4.2 Activity Sequencing Project Manager, Business Analyst, Technology Owner

2.4.3 Activities Defined and Sequenced Project Manager Milestone

2.5 Project Schedule Development Develop a graphical representation of predicted tasks, milestones, dependencies, resource requirements, task durations, and deadlines. 2.5.1 Develop Project Schedule Project Manager, Prepare baseline plan. Functional Manager 2.5.2 Project Schedule Completed Project Manager Milestone 2.6 Resource Planning Identify and describe all the major resources needed to proceed with the execution of the project.

2.6.1 Develop Resource Plan Project Manager, Functional Manager, External Resource

2.6.2 Resource Plan Completed Project Manager Milestone 2.7 Change Management Develop a change management methodology for identifying and controlling the Scope of the project.

December 2004 Page 3- 33 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Shaded areas are IT related tasks

WBS Task Name Effort / Resource Names WBS Dictionary Cost Duration 2.7.1 Develop Change Management Plan Project Manager, Change Develop Project library Management

2.7.2 Change Management Plan Project Manager Milestone Completed 2.8 Risk Planning Describe all risks identified for the project and a plan to integrate risk mitigation throughout the project.

2.8.1 Identify Risks Project Manager, Executive Manager, External Resource, Business Area Rep., QA_SME

2.8.2 Develop Mitigation Strategy Project Manager, Executive Manager, External Resource, Business Area Rep., QA_SME

2.8.3 Assemble Risk Plan Project Manager, Administration, QA_SME 2.8.4 Risk Plan Completed Milestone 2.9 Procurement Planning Identify needs for the project, which can be best met by purchasing products or services from outside of the agency.

2.10 Quality Planning Develop a Quality Plan that defines the person(s) responsible for project quality assurance, the standards and procedures to be used, and resources required to conduct quality-related activities on the project. 2.10.1 Develop Quality Plan Project Manager, QA- SME 2.10.2 Quality Plan Completed Functional Manager Milestone 2.11 Communications Planning Define the information needs of the project stakeholders and the project team, by documenting what, when, and how the information will be distributed. 2.11.1 Develop Communications Plan Project Manager, Executive Manager, Business Analyst, Administration

2.11.2 Communications Plan Completed Functional Manager Milestone 2.12 Budget Planning Determine the costs of associated with the defined activities. 2.12.1 Identify Cost Factors Project Manager, Budget Analyst, Administration

December 2004 Page 3- 34 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Shaded areas are IT related tasks

WBS Task Name Effort / Resource Names WBS Dictionary Cost Duration 2.12.2 Review Cost Estimates Project Manager, Functional Manager, Budget Analyst

2.12.3 Develop Budget Estimates Project Manager, Budget Analyst, Business Analyst

2.12.4 Project Budget Estimate Completed Milestone

2.13 Project Planning Transition Create and review a transition Checklist checklist that ensures planning activities have been finished, reviewed, and signed off so that the project may move into the execution phase. 2.13.1 Complete Project Planning Project Manager, Transition Checklist Executive Manager 2.13.2 Project Plan Approved Project Manager, Milestone Executive Manager 2.14 Requirements Definition 2.15 Specifications 2.16 Design 2.16.1 Prepare Preliminary Design Development Coordinator Establish design model

2.16.1.1 Develop Enterprise Architecture 2.16.1.2 Prepare Data Flow Diagrams 2.16.1.3 Prepare Logical Data Model 2.16.2 Prepare Detailed Design Development Coordinator Detail design model

2.16.2.1 Prepare Physical Data Model 2.16.2.2 Prepare Data Dictionary 2.16.3 Document Design Development Coordinator Record design model

2.16.3.1 Develop Design Specification 2.16.4 Review Design Project Manager, Evaluate design model Development Coordinator

2.16.5 Approve Designs Milestone 3 EXECUTION 3.1 Project Plan Execution Execute the tasks that lead to the completion of a deliverable. 3.1.1 Execution Tasks Go Here Project Team Prepare status reports and collect/analyze project metrics. 3.1.2 Project Execution Complete Milestone 3.2 Project Administration Monitor the project in terms of comparing to the plans developed in the Planning Phase

3.2.1 Ongoing Project Administration Project Manager, Executive Manager, Administration, External Resource

December 2004 Page 3- 35 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Shaded areas are IT related tasks

WBS Task Name Effort / Resource Names WBS Dictionary Cost Duration 3.2.2 Execute Quality Assurance Plan Quality Assurance 3.2.3 Ongoing Performance Monitoring Project Manager

3.2.4 Ongoing Risk Monitoring Project Manager 3.2.5 Ongoing Information Distribution Project Manager, Administration 3.3 Development/Integration 3.3.1 Develop Software Senior Programmer Outline software 3.3.1.1 Develop server Application 3.3.1.2 Develop User Interface 3.3.1.3 Develop XYZ Interface 3.3.2 Procure Hardware Project Manager, Design hardware Procurement 3.3.2.1 Procure Server 3.3.2.2 Procure Workstations 3.3.3 Procure Software Packages Project Manager, Detail software package Procurement 3.3.3.1 Procure Databases 3.3.3.2 Procure User Interface Building Tool

3.3.3.3 Procure Operating System 3.3.4 Perform Integration Testing Senior Programmer Create/execute test plan 3.3.5 Convert Data Senior Programmer Convert information 3.3.5.1 Develop Conversion Plan 3.3.6 Develop User Manual Publications Develop work manual 3.3.7 Transition Management Project Manager, Development Coordinator

3.4 Acceptance Testing 3.4.1 Plan Acceptance Test Development Coordinator Design acceptance plan

3.4.2 Conduct Acceptance Test Development Coordinator Conduct test

3.4.3 Develop Test Report Development Coordinator Create test report

3.5 Installation 3.5.1 Develop Installation Plan Development Coordinator Create installation plan

3.5.2 Site Preparation Development Coordinator Prepare delivery site

3.5.3 Install at Locations Development Coordinator Install system at site(s)

3.5.3.1 Headquarters 3.5.3.2 Site One 4 CONTROL 4.1 Project Control Activities Ensure changes are documented, plans are updated, and the project team is informed.

December 2004 Page 3- 36 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Shaded areas are IT related tasks

WBS Task Name Effort / Resource Names WBS Dictionary Cost Duration 4.1.1 Perform Metrics and Status Report Project Manager Review 4.1.2 Perform Change Control Project Manager, Change Management

4.1.3 Perform Scope Control Project Manager, Change Management

4.1.4 Perform Quality Control Project Manager Conduct audits and reviews. 4.1.5 Perform Schedule Control Project Manager 4.1.6 Perform Cost Control Project Manager 4.1.7 Perform Risk Control Project Manager 4.1.8 Perform Contract Administration Project Manager 5 CLOSEOUT 5.1 Administrative Closure Prepare closure documentation of the project deliverables for the customer, and prepare for other administrative actions to ensure that the project and its assets are redistributed. 5.1.1 Perform Administrative Closure Project Manager, Administration 5.1.2 Financial Closure Functional Manager, Budget Analyst 5.1.3 Financial Audit Project Manager, Budget Analyst 5.1.4 Archiving Project Manager, Administration 5.1.5 Release Personnel and Facilities Project Manager, Functional Manager 5.2 Post Implementation Evaluation Document successes and failures Report of the project, and record all selected, pertinent metrics that influenced planned and actual budget and scheduled activities. Also document recommendations for other projects of a similar size and nature. 5.2.1 Lessons Learned Project Manager, Budget Analyst, Business Analyst, IT Analyst, Business Area Rep., Executive Manager, Team Manager, Quality Assurance, Technology Owner

5.2.2 Assemble Post Implementation Project Manager Evaluation Report

December 2004 Page 3- 37 State of Michigan PMM Section 3: Project Planning

Work Breakdown Structure

Shaded areas are IT related tasks

WBS Task Name Effort / Resource Names WBS Dictionary Cost Duration 5.2.3 Project Sign-off Project Manager, Milestone Administration, Budget Analyst, Business Analyst, IT Analyst, Business Area Rep., Change Management, Executive Management, Team Manager, Technology Owner

5.2.4 Recognition Project Team 5.3 Maintenance 5.3.1 Hardware Maintenance Senior Programmer Conduct maintenance 5.3.2 Software Maintenance Senior Programmer

December 2004 Page 3- 38 State of Michigan PMM Section 3: Project Planning

Activity Definition and Sequencing

Activity Definition and One of the most important parts of the project planning process is the Sequencing definition of activities that will be undertaken as part of the project. Activity sequencing involves dividing the project into smaller, more manageable components (activities) and then specifying the order of completion. Much of this has already been done within the process of creating the WBS. No matter how the WBS has been broken down, by the time the project manager gets to the activity level, the activities should be the same. To view examples of a WBS, refer to the WBS subsection within this section of the methodology.

The relationship of activity definition and sequencing to the rest of the Planning Phase components is shown in Figure 3.11.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.11 Activity Definition and Sequencing Identified in the Planning Processes

The WBS reflects activities associated with overall project management, requirements, design, implementation, transition management, testing, training, installation, and maintenance. The project manager is responsible for defining all top-level tasks associated with a project and then further decomposing them as planning continues.

Defining Project Tasks WBS tasks are developed by determining what tasks need to be done to accomplish the project objective. The choice of WBS is subjective and reflects the preferences and judgment of the project manager. As levels of the WBS become lower, the scope, complexity, and cost of each subtask become smaller and more accurate. The lowest-level tasks, or work packages, are independent, manageable units that are planned, budgeted, scheduled, and controlled individually. As efforts of similar scope and type are planned, the basic WBS tasks remain

December 2004 Page 3- 39 State of Michigan PMM Section 3: Project Planning

Activity Definition and Sequencing

fairly similar, but each project requires a specific set of tasks that address the uniqueness of the project's requirements. Certain top-level elements, such as project management, are included in the WBS of every project, regardless of its type, size, or complexity. Other items, like installation, may not apply to every project.

There is no simple formula to define how detailed a work breakdown needs to be. There are, however, some helpful guidelines for completion:

• Break down the work until accurate estimates of cost and resources needed to perform the task are provided. • Ensure that clearly defined starting and ending events are identified for the task. These may be the production of a deliverable or the occurrence of an event. • Verify that the lowest level tasks can be performed within a reasonable period of time—length of activities should be approximately in the range of 2% of the length of the project (e.g., a one-year project will have task durations between a day and a week). Each project must define “reasonable.” If the time period to complete a task is too long, an accurate project status in the Execution Phase may not be possible. An industry standard rule of thumb is to make work packages that can be completed within time frames of two weeks (80 effort hours). • Verify that people assigned to the project are all assigned a WBS task. Have a firm rule: If the task is not on the WBS, it is not performed.

The initially developed WBS evolves over the course of the Planning Phase. It is probable that the WBS will look quite different as the scheduling, estimation, and resource allocation portions of the plan are completed. Generally, if a WBS element does not start with a verb, it hasn't been broken down (decomposed) enough.

The WBS has multiple uses. It is both a task list for the Planning Phase and a structure for providing report status during the Execution Phase. As individual low-level tasks are completed, the project progress is assessed. The WBS also serves as a useful management communication tool by which results can be compared with expectations.

Defining Task Relationships The WBS denotes a hierarchy of task relationships. Subtask completion eventually rolls up into task completion, which ultimately results in project completion. There can, however, also be relationships between tasks that are not within the outlined hierarchy (perhaps from other projects). These relationships need to be noted, and the ultimate structuring of the tasks optimized to favor a minimum of horizontal dependencies and relationships. If the tasks are not organized efficiently, it becomes difficult to schedule and allocate resources to the tasks.

Defining Deliverables Deliverables associated with each task are shown in the WBS and are reflected in the Project Scope Statement section of the Project Plan. A sample of a deliverables template is shown in the following table. All deliverables are listed as they are identified. As the schedule is completed, the due date is filled in and responsibility for the deliverable is assigned as it is known (typically when the organization chart is defined). The date

December 2004 Page 3- 40 State of Michigan PMM Section 3: Project Planning

Activity Definition and Sequencing

delivered is a field that is filled in as deliveries are made.

Over the course of the project, a comparison of the due date and the date delivered provides a metric for how well deliverable dates are met by the project team.

Product Due Date Author/ Name Date Delivered POC Requirement Specification 4/1/2002 4/30/2002 G. Brown Design Specification 8/1/2002 G. Brown Test Plan 8/1/2002 A. Jones Implementation Plan 11/1/2002 B. White Source Code 12/1/2002 L. Brass Test Report 1/30/2002 A. Jones

While the deliverables list is a compilation of information identified in the WBS and the project schedule, it is useful to maintain a separate list because deliverable completion can be a key metric of project progress. Separate tracking of deliverables can help keep a project on track. It also serves as a useful communication tool with both stakeholders and the project team.

For more information on activity/task sequencing, refer to the "Project Schedule Development" subsection.

December 2004 Page 3- 41 State of Michigan PMM Section 3: Project Planning

Resource Planning

Resource Planning The resource planning component includes the ability to plan and manage the resources required to deliver a project. This starts with the agency selection and assignment of the project team and includes the management of the resources assigned to that team.

Overview of Resource Every agency has a limited number of resources to perform tasks. A project Planning manager's primary role is to find a way to successfully execute a project within these resource constraints. Resource planning is comprised of establishing a team possessing the skills required to perform the work (labor resources), as well as scheduling the tools, equipment, and processes (non- labor resources) that enable the staff to complete the project.

The relationship of resource planning to the rest of the Planning Phase components is shown in Figure 3.12.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.12 Resource Planning Identified in the Planning Processes

Labor Resources Labor resources are also known as "human resources". There are several parts to planning for the labor resource needs of a project:

• Determining the resource pool • Estimating the skill requirements • Determining the size of the project team • Resource profiles • Forming the team • Creating resource charts

December 2004 Page 3- 42 State of Michigan PMM Section 3: Project Planning

Resource Planning

Determining the Resource Pool As stated, resources usually are in limited supply. Therefore a project needs to establish its pool of available resources. The resource pool typically specifies the type, level (e.g., skill and experience), and time period that the resource is available. The resource pool is usually stored in a database to enable its analysis with project management tools.

Estimating the Skill Requirements Finding available staff with the skills required to perform a task is critical to project success. The project manager, for example, makes assumptions about the skills of the person performing a task. The skills of the people performing the work are directly related to the time that it takes to perform a task.

It is helpful in the planning process to develop a list of skills required, first for execution of the project and then for execution of each task. This skills list may then be used to determine the type of personnel required for the task.

The project manager pragmatically assesses the skills of the available people on the project. The project manager’s job is to determine the risks associated with the available skills and to build a plan that realistically accounts for those skills. Unfortunately, skill level is not a yes/no factor. People have varying degrees of skill, and the project manager needs to determine the level of schedule adjustment that should be made based on the staff skill level.

Where staff with the necessary skills is largely unavailable for assignment on the project, the project manager has an option to hire the necessary talent or contract services to perform the work.

Determining the Size of the Project Team The optimal size of the project team is driven by two principal factors. One is the total number of tasks to be performed, and the other is the effort needed to perform the tasks.

In developing the schedule and assigning the resources, the project manager determines the optimal mix of staff to activities. Doubling resources does not necessarily double productivity. For example, 365 engineers could not complete in a day a project estimated at one person per year. At some point, people begin to get in each other’s way. The significance of the project duration, as well as each major activity's duration, needs to be clearly understood and documented as part of the scheduling process.

Adding more people to an activity creates the need for additional communication and may also increase the need for equipment or tools. Large teams require a significant amount of coordination and teamwork. Sometimes a smaller team can accomplish much more than a larger one in a shorter period of time. The optimal selection also depends on the personalities of the team members and the communication and organizational skills of the project manager.

Having personnel on board when they are not essential is extremely costly. It is important for the project manager to understand the size of the team

December 2004 Page 3- 43 State of Michigan PMM Section 3: Project Planning

Resource Planning

required to perform the weekly scheduled work. For this reason, significant effort needs to be made in the Planning Phase to identify the resources required to complete each task at the appropriate time.

Resource Profiles A staffing plan is developed for each project. The staffing plan may be as simple as identifying one person to develop a simple database. For more significant projects, the staffing plan identifies when and how staff is brought onto and taken off the project team. For small projects, this may be simply stated as the assignment of three people full time to the project throughout its six-month duration.

For large projects, the problem is much more complex, and the creation of a detailed plan is a requirement. A graph similar to Figure 3.13, is useful in the Project Plan for large projects.

90

80

70

60

50

Week

40

Staff Per 30

Figure 3.13 Example Staffing Plan

Figure 3.13 shows the planned number of people required per week for a project team. The graph also depicts how actuals might be applied in the performance of the project.

The graphic representation of the staffing plan helps to point out peaks and valleys in staffing that has the potential of presenting serious project management problems. The project manager realistically determines how a relatively consistent staffing level can be maintained. The project manager must pay particular attention to releasing resources when they are no longer needed on the project. It is unrealistic to assume that the project can go from a five-person level to a ten-person level of effort in a month and then return to a five-person effort in another month. Resource leveling is supported by many project scheduling tools, but requires the special attention of the project manager in both the Planning and Execution Phases of the project.

December 2004 Page 3- 44 State of Michigan PMM Section 3: Project Planning

Resource Planning

Forming the Team Project organization is used to coordinate the activity of the team and to define the roles and responsibilities of team members. Project organization is needed for every project, and the project manager must always be identified.

Confusion and lack of productivity are the result of poor project organization. This is where many projects run into trouble. A good organization facilitates communication and clearly defines roles and responsibilities.

There are numerous ways to organize a project, and many projects require a unique organizational structure. There are no standard organizational methodologies that every project should use. A sample organization diagram is displayed in Figure 3.14 and shows the types of functions that are often assigned to a project.

XX Technology Project Project Manager PM Level 4 Subject Experts Project Admin PM Assist. Technical Lead

Software Task Project Resource Hardware / Comm Project Services External Manager Task Manager Task Manager Task Manager Contractor Staff PM - Level 3 PM - Level 2 PM - Level 3 PM - Level 3

Database Desktop Budgeting Scheduling WAN Training Documentation Manager Systems Mana ger Manager Manager Manager Manager PM - Level 2 Manager PM – Level 1 Level 1 PM – Level 2 PM – Level 2 PM – Level 2 PM – Level 1

Operating Project LAN Integration Systems Quality Manager Manager Project Mgr Manager PM – Level 2 PM – Level 2 PM – Level 2 Level 1

Figure 3.14 Sample Organization Chart

The larger the project, the more critical the organizational structure becomes. In a small project, a single team member may be responsible for several functions, whereas in a large project, each function might require full-time attention. A very large project, for instance, often requires a deputy project manager. A small project might have the senior technical staff member serving as a project manager. Definition of the project organization is a critical part of the planning process.

Project complexity is also a major factor when organizing a project. For example, a project that includes a large software development component typically includes a software development manager and a project manager. This arrangement allows for a concentration of resources on a high-risk area.

Unless a project is extremely small (about five people), it is useful to organize the project into functional teams. This approach leads to idea

December 2004 Page 3- 45 State of Michigan PMM Section 3: Project Planning

Resource Planning

synergy and improved communications. The project manager is responsible for defining and selecting the team leaders. Team leaders can off-load some of the work of the project manager and take responsibility for the completion of tasks. Team composition should be determined early in the planning phase, so that leaders are involved in the planning and also assist in defining a successful Project Plan.

Creating Resource Charts Because the Niku Portfolio Manager Suite (the State’s Enterprise PM Tool) is a dynamic and resourceful project management tool, project managers should utilize the option to load resources directly against tasks according to the work breakdown structure or by another means. This is an important step because the project manager will then be able to track resources and resource needs as far down as the task level.

Non-labor Assets All project teams require the tools to successfully perform the tasks assigned. In scheduling resources, the project manager must ensure that both people and necessary equipment to support those people are available simultaneously.

The need for adequate workspace is often overlooked when planning a project. If a 15-member project team is going to start work, there must be a facility to house the team. Ideally, the team should be placed in contiguous space (collocated) to facilitate interaction and communication. Team spirit and synergy is enhanced and chances for project success are increased when everyone is close together. While this may not always be feasible, it is a goal worth striving towards.

In addition to workspace, equipment for the team should be included in the Resource Plan. Ensuring the availability of equipment at critical points in the project is key in planning a successful project. Efficiency and morale are negatively affected by unavailability of equipment needed to perform a task. When considering equipment, it is also important to remember to give each team member the right tools (for example computer software) they need to do the job at the beginning of the project, ensuring that all people who need to share information can do so quickly is a time- and labor-saving effort.

Additional Criteria Identifying Resource Risks Risks are inherently involved with scheduling resources. Sound resource planning makes allowances for dealing with risks in one or more of the following ways:

• Where significant resource risks are identified, add a work breakdown structure task for risk management/risk reduction, and set aside financial reserves to deal with potentially delayed schedules. • Add time to those tasks where resources are known to be a problem. There is no rule of thumb for this multiplier; it depends on the degree of risk and the overall impact that resource problems can have on the project. • Add a percentage time multiplier to the schedule for specific individuals, particularly if new technology is being used or if the person providing the estimate is extremely optimistic. Remember that technical staff typically

December 2004 Page 3- 46 State of Michigan PMM Section 3: Project Planning

Resource Planning

underestimate the time required to do any particular task. • Where skill shortage is identified, add time and resources for training. By recognizing resource shortfalls and providing the necessary training, a project manager mitigates some level of risk.

Task Responsibility The schedule owner is usually a manager. The individuals doing the work are usually not managers. To facilitate communication, a person responsible for completing each task should be identified. This will improve the individuals’ understanding of the tasks they must accomplish and provide a point of contact to obtain schedule status. Identifying the person responsible makes it possible to produce reports for each person.

Team Development Team development is an important aspect of resource planning that is often overlooked. This is often viewed as an Execution Phase issue; however, if thought through early in the planning of the project, the issue can be dealt with during the Planning Phase.

Team development revolves around activities that are directed to enhance the cohesiveness of a team and get a better understanding of its strengths and weaknesses. Quite often the problem lies in team members seeing the work they do as functionally independent of other team members and therefore contributing very little, if anything, to the team itself.

The benefits of team development include improvement in project performance, improvements in agency skill areas, improvement in team interaction and behaviors, and a feeling of team satisfaction. The following are examples of team development tools and techniques:

Team Building Activities Activities that provide interaction among team members and two-way communications are encouraged. These include events such as team- building activities in which the project team members spend time together doing work-related or non-work-related activities in order to build a sense of team unity. Team-building activities can be work related, such as meetings in which different people discuss their views on project issues, or they can be fun extracurricular activities.

Collocation In today’s workplace with limited office space and functional specialties, it is sometimes difficult to collocate project team members. If the option of having all of your team members sit together is available, however, take advantage of it. Collocation fosters increased communication and often quick problem solving.

Training The idea behind training is to increase and hone the skills of the project team to improve project performance. Training can be both formal (taking classes in particular skill areas) and informal (receiving feedback from managers and team members). Project team members benefit professionally from learning new skills, and that benefit is returned to the project in the form of increased productivity and better products. Training is an element that should be considered early based on the skill needs of the project team, and

December 2004 Page 3- 47 State of Michigan PMM Section 3: Project Planning

Resource Planning

funds should be allocated for training purposes.

Resource Plan Template The Resource Plan Template can be found on the following page, as well as in Appendix B.

December 2004 Page 3- 48 State of Michigan PMM Section 3: Project Planning

Resource Planning Template

State of Michigan (Insert Project Name Here) Resource Plan

A. General Information Information to be provided in this section gives a specific name to the project as well as pertinent information about the personnel involved.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by:

B. Resource Profiles Determine the major resources that will be needed in order to proceed with the execution of the project. These resources may include the following: People, Money, Equipment, Facilities, Materials and Supplies, and Information Technology.

C. Project Resource Information For each of the resources needed on the project determine the following: 1) Cost estimates for each resource, 2) Availability of each resource, and 3) Estimated quality and output of people and equipment resources.

Resource Cost Availability Quality Output Estimate

December 2004 Page 3- 49 State of Michigan PMM Section 3: Project Planning

Resource Planning Template

D. Resource Staffing Plan After establishing the human resources required for the project, develop a staffing plan that shows the number of personnel, by type, that will be required on the project on a monthly basis.

Personnel Category Month Month Month Month Month Month

December 2004 Page 3- 50 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Project Schedule Following the definition of project activities, the activities are associated Development Introduction with time to create a project schedule. The project schedule provides a graphical representation of predicted tasks, milestones, dependencies, resource requirements, task duration, and deadlines. The project’s master schedule interrelates all tasks on a common time scale. The project schedule should be detailed enough to show each work breakdown structure task to be performed, name of the person responsible for completing the task, start and end date of each task, and expected duration of the task.

The relationship of project schedule development to the rest of the Planning Phase components is shown in Figure 3.15.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.15 Project Schedule Development Identified in the Planning Processes

Like the development of each of the project plan components, developing a schedule is an iterative process. Milestones may suggest additional tasks, tasks that may require additional resources, and task completion may be measured by additional milestones. For large, complex projects, detailed sub-schedules may be required to show an adequate level of detail for each task.

Once completed and approved by the project’s key stakeholders, this schedule will be used to manage the project and will be known as the "baseline schedule". During the life of the project, actual progress is frequently compared with the baseline schedule, which allows for evaluation of execution activities. The accuracy of the planning process can also be assessed.

Basic efforts associated with developing a project schedule include the following:

December 2004 Page 3- 51 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

• Define the type of schedule • Define precise and measurable milestones • Estimate task durations • Define priorities • Determine task relationships • Identify lead/lag between related tasks • Define the critical path • Document assumptions • Identify risks • Review results

Overview of Project The type of schedule associated with a project relates to the complexity of Scheduling the implementation. For large, complex projects with a multitude of interrelated tasks, a Network Logic Diagram (commonly referred to as a "PERT chart"– Program Evaluation and Review Technique) may be used. The Network Logic Diagram depicts interdependencies and associations which allows planning to include these relationships. A key feature of this method is the ability both to determine and to show the critical path of the project (see below for a discussion of critical path). A sample Network Logic Diagram is shown in Figure 3.16.

Requirements Definition (Analysis)

1

8/1 9/11 Define System Requirements (Business)

3 ITDE(0.3), ITI

8/8 8/21

Prepare for Analysis Analyze the Current Develop and Evaluate Plan the Next Stage Prepare Material for System Alternative Solutions Business Management

2 4 6 8 9 8/1 8/7 8/8 8/14 8/15 8/21 8/22 8/22 8/29 9/4

Conduct the Business Management Review RReeascsecessss Application Outline Transition, Architecture Security, and Training 10 5 ITDBA(0.3) 777 ITDBA(0.3) 9/5 9/11 8/8 8/14 8/8/8/15 8/21

RD Approved by IS Dir, DMA Dir, Cust Sponsor 10 9/5 9/11

Approval to Proceed to Next Stage 12

9/11 9/11

Figure 3.16 Sample Network Logic Diagram

December 2004 Page 3- 52 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

For small projects, a Gantt chart (or bar graph, named after Henry Gantt) is adequate. These schedules are two-dimensional representations that show the tasks and the time frame for completion. The Gantt chart is common in reporting status and in defining the schedule for small, simple projects with few interrelationships. A sample Gantt chart is shown in Figure 3.17 below.

ID Task Name Project St age August September October November

1 REQUIREMENTS DEFINITION RD (Analysis Stage) 2 Prepare for Analysis RD 0%

3 Define System Requirements (Business Mode) RD 0%

4 Analyze the Current System RD 0%

Reassess Application Architecture 5 Requirements RD 0%

6 Develop and Evaluate Alternative Solutions RD 0% 7 Outline Transition, Security, and Training Plan RD 0%

8 Plan the Next Stage RD 0% Prepare Material for Business Management 9 Review RD 0% 10 Conduct the Business Management Review RD 0%

RD Approved by IS Dir, DMA Dir, Cust 11 Sponsor, and Process Team RD 9/11

12 Approval to Proceed to Next Stage RD 9/11

Critical Summary Progress Critical Process Rolled Up Critical Task Rolled Up Critical Progress Task Process Rolled Up Task Baseline Rolled Up Task Progress Baseline Milestone Rolled Up Baseline Milestone Rolled Up Baseline Milestone Summary Rolled Up Milestone

Figure 3.17 Sample Gantt Chart

December 2004 Page 3- 53 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

The Schedule Process Figure 3.18 depicts the schedule process.

The first three steps of the process are discussed in this section of the Project Management Methodology, while the fourth step, Schedule Status, is a controlling function that is discussed in detail in the Section 5, Project Control.

Schedule Schedule Schedule Schedule Development/ Inputs Baseline Status Maintenance

Figure 3.18 Schedule Process

Schedule Techniques Schedule techniques provide a framework for developing and communicating the project’s schedule performance. The techniques should be chosen based on the agency’s management style, the project manager’s management style, and the nuances of the project. Communicated, understood, and approved by management, the techniques chosen will ensure that schedules provide the benefits intended. The following are some schedule techniques:

• Schedule detail • Schedule display • Schedule structure • Schedule data collection and validation • Automated tools

Schedule Detail Schedule detail involves the degree to which activities are detailed. A schedule for a project could plan to the hour. Although this degree of detail would be impractical for a five-year project involving hundreds of people conducting thousands of tasks, the degree tracked must be determined before developing schedules. Areas within the project that have a high degree of risk may be planned in greater detail, while others may not.

Rolling-wave planning introduces the concept of developing detailed schedules only for areas within a specified time frame or when sufficient information exists to plan in detail. For example, a detailed installation schedule for several sites may not be developed three years in advance of installation. Also, it may be developed only when sufficient information exists to identify tasks, task durations, sequencing, and interdependencies with other schedules.

As a technique, the usefulness of rolling-wave planning depends on each project manager’s confidence in high-level planning. Determining its applicability early in the planning process can reduce the amount of time spent developing detailed schedules that will change as a result of improved

December 2004 Page 3- 54 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

information. Identifying risk areas within a project should provide an indicator as to which areas require more detailed planning.

Figure 3.19 depicts the concept of rolling-wave planning.

Phase 1 Phase 2 Phase 3

Initial Plan

Refine Plan

Refine Plan

Time

Figure 3.19 Concept of Rolling-Wave Planning

The chart depicts an initial plan that consists of a greater degree of detail for the early phases of the project. Later phases within the initial plan contain less and less detail as they move further out in time. During each phase of a project, subsequent phases are reviewed and refined when improved information is available.

Caution should be used when implementing this technique as a tendency may exist not to plan sufficiently during the early phases of the project. Thorough planning is necessary to come up with initial schedule and cost estimates and risk identification.

Detailed planning involves creating a detailed schedule for all components of a project, independent of their timing. In the site installation example mentioned above, detailed scheduling would require task definition, duration, and dependencies for all sites to be installed. On the one hand, the benefit of detailed scheduling is the potential for better estimates. On the other hand, detailed schedules created far in advance are often changed by new or improved information. Changing those schedules may be burdensome.

December 2004 Page 3- 55 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Schedule Display Schedule display refers to the summation of schedule information presented to various levels of management. Detailed schedules may contain hundreds or thousands of tasks and milestones; displaying these to the executive level would not be productive, as upper management frequently requires summarized information that highlights potential or real problems. Once the problems are highlighted, upper management may proceed to lower levels of detail to understand the impact of a problem on the project and determine corrective action. The number of displays depends on the project’s size, its complexity, the number of agencies affected, and the degree of senior management visibility and involvement in the project. The table below identifies typical schedule displays and the intended audience.

Schedule Intended Name Audience Comments Executive • Executive Management Recipients are stakeholders, but do not have direct involvement or • Agency Chief control of the project. The executive schedule usually depicts Information Officer high-level milestone information only. • Agency Director • Board of Directors • Oversight Committee • Executive Customers Master • Project Manager Displays key milestones and high-level, summarized activities or • Senior Customer phases of the project. Usually contains the executive schedule’s information and a logical grouping of information from intermediate schedules. Also referred to as an "integrated program schedule", because it integrates multiple project schedules. Intermediate • Project Manager Contains summary and key tasks and milestone information of the • Senior Customer detailed schedules. Often reflects a logical grouping of the project • Functional Manager (phases or business process). • Line Management Functional • Functional Manager Depicts schedule information based on the responsibility of a functional group. Detail • Functional Manager The lowest-level schedule used to control the day-to-day activities • Team Leader of team members. • Individual Team Members

Information portrayed at any level is obtained from the detail schedule of the project, thus ensuring consistency in the information. The type of information displayed should be determined early in the process. This will ensure that the information displayed is useful to all management levels.

Schedule Structure Schedule structure involves storing and associating schedule information for later use. Schedule structure is directly influenced by the displays chosen. The way a schedule is structured is based on many factors, each of which must be understood so that the project schedules are organized to facilitate communication.

December 2004 Page 3- 56 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Factor Impact Work breakdown structure – based Schedule tasks must be associated with the work breakdown structure. schedules Displays are WBS-based. Functional organizations Functional organizations may want displays and control of their own schedules. Each functional group’s schedule may be isolated into a separate schedule. Process-based schedules May involve phases of a project or relationships of tasks to a business (lifecycle based) process. If a work breakdown structure is also used, two different associations are required (the work breakdown structure and process). Integrated master schedule Will require separate schedules for subprojects that are integrated by a single master schedule. Rollup mechanisms must be defined to update the integrated master schedule from detailed subproject schedules. Subcontractor schedules Will require defined automated or manual techniques to integrate with other project schedules and roll up to the integrated master schedule. Customer access The number of individuals involved in updating the schedules may create a data, and thus a schedule, integrity problem. Data access by customers should be considered to ensure that the schedule is updated to reflect current status and work effort. Automated tool The tool chosen will directly affect the ability to structure schedules, associate project information (for example, work breakdown structure and function), use project/subproject schedules, and allow customer access. In the case of the State of Michigan, the tool of choice is the Niku Portfolio Manager Suite.

Within one project, any or all the factors may affect the way schedules are structured. Figure 3.20 is an example of display and structure attributes. An integration schedule is used to link tasks and milestones of different schedules. In this way, an integrated schedule can be created that shows a true picture of the project.

December 2004 Page 3- 57 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Display

Executive or WBS-Based Schedule

Master

Schedule y

r

a

m

m

u

S

Intermediate y

a Schedules l

p

s Structure i

D Used to Integration Schedule Interrelate Sub-Projects

Detailed Schedules Sub-Project A Sub-Project B Sub-Project C Sub-Project D

May be Process or Functionally Based. Organization may include sub- contractors.

Figure 3.20 Schedule Display and Structure

Automated Tools There are numerous tools that support the development of project schedules. Many of these tools prepare either a Gantt or a PERT chart. These tools require experience in setting up projects and in defining task relationships and dependencies.

The State of Michigan has selected Niku Portfolio Manager Suite as its scheduling tool of choice. It is suggested that all project managers and project team members who will be working with project schedules take the time to get trained and become familiar with the Niku Portfolio Manager Suite and its features. Microsoft Project is an acceptable alternative scheduling tool for smaller, non-complex projects.

Schedule Inputs Inputs to schedule development include any aspect of the project that directly or indirectly affects how the project will be delivered. The following table provides a list of inputs and how they are used to develop schedules.

Input Comment Scope Scope is defined in the WBS. Each element of scope should have a defined schedule that depicts how it will be delivered. Agency Agency will affect the schedule through responsibility assignment (identifying the agency responsible to deliver scope or conduct activities).

December 2004 Page 3- 58 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Input Comment Resources The resources assigned to the agency will constrain schedules. The impact may be through either the number/availability or skill level of the team. Strategy Strategy refers to the business process or lifecycle process chosen for the project. Additionally, strategies will affect contracting or subcontracting, release strategies, or any aspect of the project that requires optional approaches; for example, make/buy alternatives. Assumptions Assumptions form a premise for a chosen solution; they are important in that they provide the rationale for a given solution. Assumptions should be reviewed continually, as they may be risks to the project (one may assume that the product will be available for test on a given date or that requirements will not change). Constraints Constraints are project attributes that restrict certain aspects of the project. Examples are • Time-frame limits • Funding limits • Resource limits • Technical limits Historical data Historical information should be consulted. Risk Risk areas should be reviewed carefully and schedules developed to a level of detail that can provide control over them. Risk mitigation or contingency plans should be defined within the schedules as appropriate. Dependencies Dependencies define relationships between agencies and tasks and provide a logical sequencing of the schedule. Dependencies provide the basis to calculate the schedule and attributes of Critical Path Method (CPM) analysis. Change All changes in scope, strategy, and work effort should be used to develop and maintain schedules.

Schedule Development and Schedule development and maintenance have the following objectives: Maintenance • To create a project schedule that displays a logical sequence of tasks to deliver the project. • To create a mechanism that portrays an accurate status of the project so that it can be used to control the project work effort. • To create a mechanism that can be used to understand the impact of change on the baseline schedule.

Figure 3.21 depicts the process to develop initial schedules and maintain schedules during the life of the project.

Identify Determin e Sequence

Schedule Tasks a nd Work Owners Mileston es Effort

Estimate Integrate Review and Task Task Approve

Duration Schedules Schedule

Figure 3.21 Schedule Development and Maintenance Process

December 2004 Page 3- 59 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Identify Schedule Owners Identifying the owners or individuals responsible for developing all or part of the project’s schedule is essential to ensuring that good schedules are developed and maintained. It is recommended that a work breakdown structure and or organizational breakdown structure be used as the basis for schedule development because the WBS identifies scope and the Organizational Breakdown Structure identifies the functional area to deliver it. The schedule process will assume that a WBS is used. Where a WBS is not used, it is essential that responsibility to deliver project scope be assigned and that an individual be responsible for the appropriate schedule processes.

Determine Tasks and Milestones For each lowest level WBS element, the tasks and milestones are identified to deliver the element. Tasks pertain to the effort to produce a product. Milestones pertain to a point in time and should be used as management checkpoints to measure accomplishment. The number of tasks and milestones identified should relate to what is known about the product, the level of risk, and the level of detail required of management. The result is a listing of tasks and milestones required to deliver the product. The flow diagram in Figure 3.26 provides an example of a training delivery plan.

The completion of key actions is important in all projects. These completions are denoted by milestones. A completion has no duration. For example, deliverables often are represented as milestones, while the effort to produce the deliverable is referred to as a "task".

While milestones are unique to each project, some common information technology project milestones are shown below:

• Requirements approval • Phase review approval • Prototype approval • Design reviews completion • Code reviews completion • Unit test completion • Integration test completion • Acceptance test completion • System acceptance by customer • Customer shipment • Documentation delivery

Milestones should be used to measure progress and as management checkpoints. Too often, progress on a given product is reported to be on schedule until the end. Then it is 25 percent complete and ten weeks behind schedule. By using milestones that truly measure performance and progress, this can be avoided. As an example, assume that the training plan for the project is critical. The list of tasks and milestones is shown in the following table:

December 2004 Page 3- 60 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Description Task/Milestone Review training requirements Task Develop plan outline Task Customer review of outline Milestone Revise outline Task Outline approval Task Develop draft training plan Task Customer review of draft plan Milestone Revise draft training plan Task Training plan approval Milestone

Milestones can occur at the end of each work package in the work breakdown structure and serve as a measurable item on which to base success of a task. Major project milestones should be summarized and included in the summary project schedule.

For contracted work, milestones are often used as a point in the project where interim payments might be made. If this approach is used, mutual agreement is necessary on the content of each milestone and the cost associated with that milestone.

Sequence Work Effort After the tasks and milestones to deliver a product are determined, they should be logically sequenced to reflect the way the work will be performed. Sequencing establishes the dependencies among the tasks and milestones and is used to calculate the schedule to deliver the product. The result of sequencing the example above is displayed in the Figure 3.26.

Precedence Relationship Types • Finish-to-start – The initiation of the work of the successor activity/task depends upon the completion of the work of the predecessor activity/task. • Finish-to-finish – The completion of the work of the successor activity/task depends upon the completion of the work of the predecessor activity/task. • Start-to-start – The initiation of the work of the successor activity/task depends upon the initiation of the work of the predecessor activity/task. • Start-to-finish – The completion of the successor activity/task is dependent upon the initiation of the predecessor activity/task.

The most common type of precedence relationship is finish-to-start, as shown in Figure 3.22, shown below.

Any of the defined dependencies may require specifying a lead or a lag to accurately define the relationship between two activities/tasks. A "lead" is a modification to a dependency relationship, which allows an acceleration of the successor activity/task. A "lag" is a modification to a dependency relationship, which directs a delay in the successor activity/task. For example, in a finish-to-start dependency with a five-day lag, the successor activity/task cannot start until five days after the predecessor has finished.

December 2004 Page 3- 61 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Review Customer Develop Training Review of Plan Outline Requirements Outline

Develop Revise Outline Draft Training Outline Approv al Plan

Customer Revise Draft Training Plan Review of Training Plan Approval Draft Plan

Figure 3.22 Work Effort Sequencing Example

Estimate Task Durations Estimating task duration is one of the most challenging aspects of project planning. It is also a key to later cost estimation. This is a refined process that occurs throughout the planning process, as it is directly affected by results of staffing and costing activities.

Accurate task duration estimates are defined in order to stabilize customer relations, maintain team morale, and as a necessary planning tool. With defined task durations, the team knows what to expect and what is expected of it. Task duration is rarely overestimated, but is frequently underestimated. Inaccurate estimates can result in an increase in the “frenzy level” of a project. The frenzy escalates as sponsors scramble for more money or the technical staff scrambles to complete a project in an unrealistic time frame. Often, the end result is cutting corners, excessive overtime, and a dissatisfied customer.

The estimation process is complex because activity duration is affected by numerous variables that must be dealt with concurrently in the Planning Phase. Some of these variables include staff availability, the skill level of the person assigned to the task, unexpected events, efficiency of work time, and mistakes and misunderstandings during the execution of the project.

When estimating the duration of a task, reality is a major factor. The knowledgeable scheduler takes into account absenteeism, holidays, meetings, discussions, and interaction among the staff. No one is 100 percent productive every hour of the workday. If a scheduled task assumes 100 percent productivity, the schedule rapidly falls apart. A successful schedule builds these types of factors into the duration estimates. An industry accepted rule of thumb for estimating staff productivity is that an employee spends 80 percent of their time on productive tasks, while the remaining 20 percent accounts for staff meetings, stretch breaks, shifting from one productive task to another, etc.

There are several techniques that support task duration estimation. The most

December 2004 Page 3- 62 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

common technique is based on the historical experience of a similar scope of work performed by the estimator. Collected and archived historical project data are used successfully by many organizations to achieve quality performance on project deliveries.

Historical records greatly support both the duration and the cost estimations, which are so important in this phase. Data based on staff skills are far more valuable than generalized industry estimates. If historical data do not exist, seek the advice of experts and others who have completed similar tasks. It is also good practice to consult the individuals who may be performing the activities/tasks for duration estimation.

When historical data or experts are not available, use a technique of getting estimates from multiple sources, comparing results, and estimating the duration based on multiple inputs. The success of this method is predicated on finding good sources for providing the estimates.

The duration of tasks (e.g., year, month, week, day, or hour) should be consistent with the amount of detail tracked and the risk. Often tasks become so detailed that they are really a checklist of items. In a complex, lengthy project, checklists and schedules should be separated to ensure that the management benefits of each are achieved.

Integrate Task Schedules Once the tasks and milestones are identified, sequenced, and have a planned duration, a schedule exists to deliver each product. Without integration, schedules are independent of each other and therefore may not depict timing issues related to the entire project. Individuals need to understand dependencies between each schedule. Integrating individual schedules provides a more accurate schedule and improves coordination between functional areas.

Schedule A

Original Task

Original Milestone Delay Caused by Integr ation Finish Caused by Inte gration Finish M ilestone Caus ed by Integration Interdependency From Schedule B

Figure 3.23 Schedule Integration Example

December 2004 Page 3- 63 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Meetings between schedule owners are conducted to understand, document, and capture the dependencies in the project schedule. The meetings should be held or the topic of dependencies discussed on a regular basis to ensure that the dependencies continue to reflect the current work effort. Figure 3.23 shows a schedule integration example.

In Figure 3.23, the dependency from Schedule B to Schedule A has caused a delay to a task. Because subsequent tasks have been sequenced in Schedule A, the delay trickles down to the final milestone. Owners of both schedules understand the impact on each schedule and can plan accordingly.

Review and Approve Schedule The development of a large or complex schedule requires input from more than one person. No one possesses all the knowledge or understanding of all the factors that affect schedules in every aspect of a project. Schedule review also prompts buy-in to the schedule. Buy-in on the schedule by the people who will actually perform the work is critical to success of the project. Participation in scheduling gives the staff a stake in the outcome of the project. On the other hand, imposed schedules decrease the opportunity for successful completion.

Once an initial cut at the schedule is ready, a team should perform a review. The people named to do the work (and who did not participate in the initial estimates) should review the work descriptions and the schedule. Interview the people and determine if the work descriptions are complete and accurate.

Determine if there is a common understanding of what has to be done. Get their independent estimates as to how long it will take to do the job. Where there are significant differences between the current schedule and new estimates, determine the reasons and either redefine the work packages or review and iterate the schedule estimates.

The final steps in schedule development are reviewing the schedule to ensure that it portrays the current work effort and then approving the schedule. There may be various levels of review and approval, which should be documented in a schedule process. Usually, schedule owners will review the schedule until they are satisfied that it represents the most effective and efficient work effort; then they will approve it. Once approved by the owners, the schedule is reviewed and approved by mid-level managers, the project manager, and senior management.

SEE THE “OTHER HELPFUL HINTS FOR CREATING A PROJECT SCHEDULE” ON THE FOLLOWING PAGE TO HELP WITH FURTHER ACTIVITIES DURING THE SCHEDULE DEVELOPMENT OF THE PROJECT.

Schedule Baseline A baseline is a set of agreed-upon data used for comparison. Therefore, a schedule baseline represents a set of schedule data used as a reference point to compare the current schedule performance against the reference point. The comparison allows for corrective action to ensure that the project remains on track. The baseline may be formal or informal. Although the process to create a schedule baseline is the same regardless of the formality,

December 2004 Page 3- 64 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

the baseline’s intended use is different. A formal baseline is used to communicate externally and manage internally. An informal baseline is not communicated externally and provides a point of reference used internally by project team members.

The process to establish a schedule baseline consists of determining what data should be baselined, ensuring that the data have been established and recorded, and saving the data for future comparison.

Baselines may be created for a variety of reasons. The number of baselines captured and stored for historical information may vary from project to project. The following are examples of the types of baselines that may be established for a project:

• Original. Once a project schedule is established, reviewed, and approved, it can be baselined as the original schedule baseline. The original baseline should never be changed and should always represent the project schedule as it was first envisioned. • Intermediate. The project team uses intermediate baselines as an informal method to compare schedule information. Typically, intermediate baselines are used to compare the current schedule against a schedule status from a given point in time, such as a previous cycle status. • Revised. A revised baseline may be established to capture the project schedule based on an approved change in project direction. In essence, the original schedule baseline may no longer provide a realistic means to compare future schedule performance, so a new revised baseline is created.

If there may be significant differences between the current schedule and new estimates, determine the reasons and either redefine the work packages or review and iterate the schedule estimates.

Other Helpful Hints for Templates and Historical Information Creating a Project Schedule Use schedule templates or historical information as the basis for schedule development, if applicable. Historical information can provide invaluable insight regarding tasks that otherwise might be overlooked and estimates for resources and durations for an improved basis for the plan.

Use a Work Breakdown Structure Because a WBS allows project participants to understand what they are delivering and a schedule describes how they will deliver it, a WBS is the logical starting point for developing a schedule. To ensure that management focuses on the delivery of products and services, the schedule should clearly relate to the WBS.

Take advantage of automated tools, including a database, to associate a WBS element to the schedule to deliver it. This will improve management visibility. Figures 3.24 and 3.25, on the following page, depict the relationship between the WBS and the schedule.

Figure 3.24 displays a WBS and two related schedules. The WBS contains two elements that represent two discrete products, which constitute the scope (the what) of the project. Two critical path method network schedules

December 2004 Page 3- 65 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

portray how each element will be delivered. The dashed arrow represents a dependency from a task in the 1.1 schedule to a task in the 1.2 schedule.

1.0

1.1 1.2 Products and Services to be Delivered What

Schedule to Deliver 1.1 - How Schedule to Deliver 1.2 - How

Integration Dependency Figure 3.24 Work Breakdown Structure-Schedule Relationship

Figure 3.25 depicts the same relationship represented as a Gantt chart. Take note that the WBS code is repeated for the corresponding tasks. In that way, the tasks to deliver each WBS element are associated and can be understood.

Aug 23, Aug 30, Sep 6, Sep 13, I WBS '9S8 M T W T F S '9S8 M T W T F S '9S8M T W T F S '9S8 M T W T F S D1 C1.d1 2 1.1 Integration 3 1.1 Dependency 4 1.1 5 1.1 6 1.1

7 1.1 8 1.2 9 1.2 10 1.2

11 1.2

12 1.2 13 1.2

Figure 3.25 Work Breakdown Structure Gantt Chart Dependency Relationship

December 2004 Page 3- 66 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Define Priorities Clearly defining the task priorities helps to resolve any scheduling or resource conflicts. Understanding the priorities and relationships of the tasks assists in resolving difficult scheduling conflicts.

Define the Critical Path The critical path is the largest path through a project. It determines the earliest possible completion of the work. The critical path must be carefully managed because if critical path tasks slip, the entire project is delayed. In order to manage the project, the schedule identifies the critical path and the project manager remains aware of its importance throughout the implementation of the project. Activities and tasks near the critical path should also be closely monitored, as they may easily be put on the critical path.

Document Assumptions Documentation of the assumptions made in developing the project schedule is critical to the success of the project. Without clear documentation of these assumptions, later changes to the schedule are very difficult and risky.

If, for example, a schedule was shortened because it was assumed that a highly skilled person would be performing the work, that assumption should be documented. Then, if a less skilled person is actually assigned to perform the task, the project manager can recognize the risk and make necessary changes and decisions. Without documentation of the assumption, the schedule could be later placed in serious risk without the project manager realizing it.

Identify the Risks Risks are inherently involved with scheduling limited resources. Good scheduling makes allowances for risks in one or more of the following ways:

• Where significant schedule risks are identified, add an additional WBS task for risk management/risk reduction, where financial reserves can be set aside to deal with potentially delayed schedules. • Add additional time to those tasks where risks are inherent. There is no rule of thumb for this multiplier; it depends on the degree of risk and overall importance of the schedule to the project. • Add a percentage time multiplier to the schedule for particular individuals, especially if new technology is being used or if the person providing the estimate is extremely optimistic. Technical staff often underestimates the time required to do any particular task.

Relationship to Other Management Information Schedules can be related to other management information. For example, some milestones may relate to delivering a project deliverable. Many projects require deliverable tracking. By relating the schedules to deliverable tracking, improved information can be achieved through integration. Automated scheduling tools typically have customer defined fields that can assist in integrating schedule information to other management needs. The following are examples of possible associations:

• Tasks to phases • Milestones to cost, revenue, and payment

December 2004 Page 3- 67 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

• Milestones to critical decision points • Milestones to performance measures required for earned value • Tasks to agencies or individuals • Tasks and milestones to a business process

Level of Effort (LOE) Services Level of effort is not scheduled. By definition, level of effort is a level of support. Support cannot usually be planned well in advance. This is not to say that products to support level of effort should not be planned. As an example, project control is an LOE service, and the automated system to support it is a product. A plan to implement the system should be developed. The subsequent project control support services need not be scheduled.

One Start—One Finish One aspect of a useful schedule is its ability to provide management with a tool to understand the impact of an issue on the project schedule. To accomplish this, the tasks within the schedule must be constrained (have dependencies between them) so that impacts can trickle through the schedule and the issues’ effects can be seen. Therefore, it is best that a schedule has only one task that starts the schedule; for example, “begin project.”

All other tasks are then constrained to the first task or subsequent ones. The schedule should have only one task that completes the schedule; for example, “project complete.” No task should be entered into the schedule without affecting something or being affected. The constraints or dependencies should be realistic. Many times it may be difficult to understand what a particular task is dependent upon. However, the task’s dependency and impact are always there or it should not be tracked in the schedule.

Descriptions Schedules are displayed to many different people within and outside the project. All potential recipients of schedule information should understand the descriptions of tasks and milestones, which should be as clear as possible. Cryptic or abbreviated descriptions should be avoided. Communication is the key.

Labor Resource Availability Knowledge of what labor resources may be available, and at what times, and in what patterns, is necessary for schedule development. The amount of detail and the level of specificity in the available labor resource pool description may vary. For example, for schedule development purposes, one need only know that two database administrators are available in a particular time frame, not necessarily who the particular individuals are.

Summary Tasks A group of tasks can usually be combined to represent some aspect of the project that is important to management; for example, the schedule to deliver a WBS element or a particular phase of the project. Automated scheduling tools have the capability to define summary tasks, often referred to as "hammocks", which enable tasks to be grouped. Task grouping improves communication and provides a framework to display summary information to upper management.

December 2004 Page 3- 68 State of Michigan PMM Section 3: Project Planning

Project Schedule Development

Management Concurrence Usually the project manager and technical representatives of the project develop the schedule. However, management is typically the prime recipient of schedule benefits. Therefore, all levels up to the project manager should understand the schedule. Management must concur with, own, and use the schedule as a tool to manage the project. Without management ownership, project performance may be less than optimal.

Simplicity Developing and maintaining project schedules is difficult and time- consuming. Frequently, schedules are developed and never maintained to reflect current status. This may be because of a lack of discipline or the time-consuming process inherent to scheduling. Additionally, risk should be a factor when determining the degree of rigor required for project schedules. Areas with a high degree of risk may require a greater degree of schedule control. Areas with a low degree may not require the same rigor.

Simplicity may be the best approach. Schedules should be developed to enable project participants to understand the delivery of the entire project. First developing schedules at a high level and then defining detailed schedules for high risk areas should satisfy the need for improved control with reduced burden.

Automation Schedules provide invaluable information to the management of a project. Automation can offer the means to improve reporting to management. Automated scheduling tools are commonplace in today’s project environments. The State of Michigan has adopted the Niku Portfolio Manager Suite and Microsoft Project for this purpose. However, integrating schedule information with other project information can provide additional capability that schedules alone cannot.

December 2004 Page 3- 69 State of Michigan PMM Section 3: Project Planning

Risk Planning

Project Risk Planning A risk is any factor that may potentially interfere with successful completion Introduction of the project. A risk is not a problem—a problem has already occurred; a risk is the recognition that a problem or opportunity might occur. By recognizing potential problems, the project manager can attempt to avoid or minimize a problem through proper actions.

The relationship of risk planning to the rest of the Planning Phase components is shown in Figure 3.26.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.26 Risk Planning Identified in the Planning Processes

The procedure that the team will use to manage project risks is defined in the Planning Phase, documented in the Project Plan, and then executed throughout the Execution Phase of the project. A Powerpoint presentation is available on the DIT Project Management Resource Center's website (www.michigan.gov/projectmanagement), in the PM Methodology section – which explains, in layperson's terms, what Risk Management is and what value it adds to the project. This presentation can be used to explain project risk management to your project team.

The Risk Management Plan, shown at the end of this subsection, documents the parameters used to manage risk throughout the project. In addition to documenting the results of the risk identification and analysis steps, it must cover who is responsible for managing various areas of risk, how risks will be tracked throughout the project, how contingency plans will be implemented, and how project contingency reserves will be allocated to handle risk.

Project reserves are resources (people, dollars, and commodities) that are available to the project if needed. Reserves can come in two types -- contingency reserves (known unknowns) and management reserves

December 2004 Page 3- 70 State of Michigan PMM Section 3: Project Planning

Risk Planning

(unknown unknowns). Contingency reserves are developed based on the results of risk planning, and are usually available for release at the project manager's discretion to address risks that materialize, and to ensure the project succeeds even if the risk occurs. Management reserves are developed at the discretion of management, and are put in place when the ability to obtain additional budget may compromise the success of the project. Management reserves are typically part of project budgeting, and not part of risk planning.

Project risks are identified, monitored and carefully managed throughout the life of the project. It is particularly important in the Planning Phase to document risks and identify contingency reserves that have been applied to the risks.

There are various areas that can affect a project's risk level: • The technology used on the project • The environment in which the project is executed • The relationships between team members • How well the project fits the culture or business area or strategic objectives of the agency • How great of a change will result from the project

Documenting Risks Risks are documented so that contingency measures can be taken to mitigate their effects. Risks to both the internal and external aspects of the project should be tracked. Internal risks are those items that the project team can directly control (e.g., staffing), and external risks are those events that happen outside the direct influence of the project team (e.g., legislative action).

As stated before, risk identification begins early in the Planning Phase of the project. A Risk Management Plan is started during the Planning Phase. Then, as scheduling, budgeting, and resource planning occur, the plan is updated to reflect further risks identified throughout the Planning Phase. The Risk Management Plan template can be found at the end of this subsection and in Appendix B.

Just prior to the Project Execution Phase, the Risk Management Plan should be reviewed again, and any new risks should be added to it. As the project progresses, members of the team identify new risk areas that are added to the Risk Management Plan. Also, during the Project Control Phase (concurrently with the Project Planning and Project Execution Phases), risks identified earlier may be removed.

Contingency Planning Contingency plans are developed as a result of a risk being identified. Contingency plans are predefined action plans that can be implemented if identified risks actually occur. If a risk event actually occurs, the contingency plan may need to be implemented and contingency reserves allocated, depending on the risk's impact.

As a guideline, contingency plans may initially be developed for the top five risks associated with a project, but don't forget to monitor the remaining

December 2004 Page 3- 71 State of Michigan PMM Section 3: Project Planning

Risk Planning

identified risks further into the project. For large projects, the top five risks of each major subsystem may be actively tracked. To properly implement a contingency plan, a contingency reserve is usually required where dollars and/or time are held by the project manager to apply to the execution of a contingency plan. Without maintaining a contingency reserve, the project manager is forced to go back for additional time or dollars for every risk as it becomes a problem. It is far more desirable to maintain a level of contingency reserve where problems can be dealt with from within the original budget and schedule of the project.

There are some situations where nothing can realistically be done to prevent or deal with a risk. In this case, the project must be managed in such a way that the probability of the event occurring is minimized. If the event does occur, the project manager must re-plan the project and include the effect of the risk event.

The Risk Management Process Risk management, as defined in the Project Management Institute's Project Management Book Of Knowledge (PMBOK®) 2000 Edition, separates risk management into the following six major processes: • Risk Management Planning • Risk Identification • Qualitative Risk Analysis • Quantitative Risk Analysis • Risk Response Planning • Risk Monitoring and Control

The State of Michigan's Project Management Methodology groups these processes into the following process steps: • Step 1: Risk Management Strategy Development • Step 2: Risk Identification • Step 3: Qualitative and Quantitative Risk Analysis • Step 4: Risk Response Planning • Step 5: Risk Monitoring and Control, which is part of the Execution and Control Phases, and will be discussed later in this Methodology.

The sequence of activities of the Project Risk Planning process is depicted in Figure 3.27 below.

The Risk Management Plan Template, shown at the end of this section, encompasses steps 1 through 4 of the Project Risk Management Process.

December 2004 Page 3- 72 State of Michigan PMM Section 3: Project Planning

Risk Planning

Step 1: Risk Step 3: Step 4: Risk Step 5: Risk Management Step 2: Risk Qualitative and Response Monitoring and Strategy Identification Quantitative Planning Control Development Risk Analysis

Figure 3.27 Project Risk Management Process

Step 1: Risk Management Risk management strategy development is the process of deciding how to Strategy Development approach and plan the risk management activities for a project. Risk management strategy development involves the creation of the various components and strategies for the Risk Management Plan. In step 1 of the risk planning process (Risk Management Strategy Development), the Risk Management Plan can be viewed as a high level planning document. By the end of step 4 of the risk planning process (Risk Response Planning), the Risk Management Plan is a detailed, action-oriented document to be used in Risk Monitoring and Control, found in the Project Execution and Control Phases of this Methodology.

It is important to plan for the risk management process to ensure that the level, type, and visibility of risk management are commensurate with both the risk and importance of the project to the organization.

The Risk Management Plan describes the development of the structure and implementation of risk identification, qualitative and quantitative risk analysis, risk response planning, and risk monitoring and control during the project life cycle.

Risk Management Plan Elements The Risk Management Plan may include the following components:

• General Project Information. Identifies the general project parameters, as will all PM Methodology templates. • Risk Management Strategy: • Risk Management Methodology. Defines the approaches, tools, and data sources used to perform risk management on this project. Different types of assessments may be appropriate, depending upon the project stage, amount of information available, and flexibility remaining in risk management. • Risk Assumptions. Defines any initial risk assumptions that are known at the current time. Include any risk factors standard to the performing organization. • Risk Management Roles and Responsibilities. Defines the lead, support, and risk management team membership for each type of action in the Risk Management Plan. Risk management teams organized outside of the project office may be able to perform more independent, unbiased risk analyses of project than those from the sponsoring project team.

December 2004 Page 3- 73 State of Michigan PMM Section 3: Project Planning

Risk Planning

• Risk Management Timeframes. Defines the frequency and duration of the risk management process, and when it will be performed throughout the project life cycle. Results should be developed early enough to affect decisions. The decisions should be revisited periodically during project execution. • Risk Ranking/Scoring Techniques. The ranking/scoring methods appropriate for the type and timing of the qualitative and quantitative risk analysis being performed. Methods and scoring of the various risk components must be determined in advance to ensure consistency. • Risk Thresholds. The threshold criteria for risks that will be acted upon, by whom, and in what manner. The project manager, customer, and sponsor may have a different risk threshold. • Risk Communications. Defines how the results of the risk management processes will be documented, analyzed, and communicated to the project team, internal and external stakeholders, sponsors, and others. • Risk Tracking. Documents how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Documents if and how risk processes will be audited. • Identification of Project Risks. Risk identification involves determining which risks might affect the project and documenting their characteristics. • Detailed Qualitative and Quantitative Analyses. This area includes identified project risk probabilities and impacts. The process of assessing the impact and likelihood of identified risks. This includes results from qualitative and quantitative analyses. • Risk Response Planning. The process of developing options and determining actions to enhance opportunities and reduce threats to the project's objectives. This process ensures that identified risks are properly addressed. The effectiveness of response planning will directly determine whether risk increases or decreases for the project.

Developing the Risk Management Strategy Inputs to develop the Risk Management Strategy section of the Risk Management Plan include the following: • The Project Charter • Any available organization specific risk management policies and procedures • Roles and responsibilities matrix from the Project Charter • The Work Breakdown Structure for the project • Any predefined risk templates (including and predefined risk categories) • Any key stakeholders risk tolerances that are identifiable • Project Type – Projects using state-of-the-art or first-of-its-kind technology or highly complex projects, tend to have more uncertainty

Risk Management Strategy development is accomplished through planning meetings. Meeting attendees include the project manager, the project team leaders, anyone in the organization with responsibility to manage the risk planning and execution activities, key stakeholders, and others, as needed.

December 2004 Page 3- 74 State of Michigan PMM Section 3: Project Planning

Risk Planning

Meeting attendees utilize the above inputs to help develop the Risk Management Strategy.

Step 2: Risk Identification Who Identifies Risk Risk identification is the responsibility of all members of the project team. The project manager is responsible for tracking risks and for developing contingency plans that address the risks identified by the team. Sometimes a risk identification brainstorming session can help in the initial identification process. Such meetings help team members understand various perspectives and can help the team better understand the big picture.

Risk identification involves determining which risks might affect the project and documenting their characteristics. Participants in risk identification generally include as many of the following as possible: project team, risk management team, subject matter experts from other parts of the organization, customers, end users, other project managers, stakeholders, and outside experts.

Risk identification is an iterative process. The first iteration may be performed by a part of the project team, or by the risk management team. The entire project team and primary stakeholders may make a second iteration. To achieve an unbiased analysis, persons who are not involved in the project may perform the final iteration. Often, simple and effective risk responses can be developed and even implemented as soon as the risk is identified.

When To Perform Risk Identification Risk identification is a recurring event; it is not performed once and then set aside. The risk identification process begins in the Project Initiation Phase, when initial risk areas are identified. During the Planning Phase, risks and mitigation measures are identified and documented. During the resource allocation, scheduling, and budgeting processes, associated risk planning is also documented. Risk identification, management, and mitigation continues after the Project Initiation Phase throughout the life of the project. New risks develop as the project matures and external and internal situations change.

When the probability of a risk event increases or when a risk becomes a reality and the project manager must deal with a real problem, re-planning occurs. At this point, the project manager and project team develop strategies that assess the impact of the risk event. This re-planning results in budget, schedule, or resource changes for completion of the project.

Risk Categories Risks that may affect the project for better or worse can be identified and should be organized into high level categories. These categories should be well defined and should reflect common sources of risk for the business or application area. Sample categories include: • Technical, quality, or performance risks. Examples include reliance on unproven or complex technology, unrealistic performance goals, changes to the technology used, and changes to industry standards during the project. Include an assessment of the customer's involvement in the definition of the product specifications, and the potential for these requirements to change.

December 2004 Page 3- 75 State of Michigan PMM Section 3: Project Planning

Risk Planning

• Project schedule risks. Examples include an assessment of the project team to meet key deliverable dates, and project duration accuracy. • Project management risks. Examples include poor allocation of time and resources, inadequate quality of the project plan, lack of project manager delegated authority, and use of project management disciplines. • Organizational risks. Examples include cost, time, and scope objectives that are internally inconsistent, lack of prioritization of projects, inadequacy or interruption of funding, and resource conflicts with other projects in the organization. • External risks. Examples include a shifting legal or regulatory environment, labor issues, changing customer priorities, local- state- or country-based risks, and weather. Also to be looked at in this area are vendor contract risks, including contractor relationships, type of contract, and contractor responsibilities in case of under-performance of project deliverables.

How to Identify Risk Risk can be identified through a variety of means: • Project deliverable descriptions and specifications. Risk is inherent in any new project, often because the product or process being created is completely new. In situations such as this, it is wise to look at the product descriptions and specifications to determine if there are any areas that have the potential for risk. • Project documents. Reviewing documents such as the Project Charter, work breakdown structure, budget estimates, staffing plans, assumptions and constraints, etc., may bring to light areas of risks that were not immediately apparent at the time of creation. • Subject matter expert interviews. Talking to people who have been on similar projects or looking through historical project files should give the project manager an indication of where risk may lie. Talking to individuals who have "been around," especially in a highly charged political environment, can be extremely beneficial. • Brainstorming sessions. Getting key stakeholders and project team members together into a room and documenting thoughts, free of immediate criticism, has the potential to generate ideas. These ideas can then be categorized and evaluated. A variation of brainstorming is the "Crawford Slip," which involves the use of yellow sticky notes for risk identification and categorization. • Analogy comparisons. Examining lessons learned from similar projects can help identify potential risk areas for the project at hand. Projects performed at your agency will most likely be the more relevant than examining a project database from another organization.

Step 3: Qualitative and Qualitative risk analysis is the process of assessing each risk priority, its Quantitative Risk Analysis likelihood of occurrence and potential impact to the project, and should be performed for all identified risks. Quantitative risk analysis is the process of analyzing numerically the probability of each risk and its likely occurrence. Quantitative risk analysis is normally performed after qualitative risk analysis. Quantitative risk analysis should be performed for identified risks that require precise probability and impact measures; risks where the quantitative data is readily available; risks associated with large scale

December 2004 Page 3- 76 State of Michigan PMM Section 3: Project Planning

Risk Planning

projects requiring such data, or for risks identified on projects that are predetermined to be of high risk.

QUALITATIVE RISK ANALYSIS The qualitative risk analysis process prioritizes risks according to their potential effect on project objectives. Qualitative risk analysis is one way to determine the importance of addressing specific risks and guiding risk responses. The time criticality of risk-related actions may magnify the importance of a risk.

Qualitative risk analysis requires that the probability and consequences of the risks be evaluated using established qualitative analysis methods and tools. Qualitative risk analysis should be revisited during the project's life cycle to stay current with changes in the project risks. This process can lead to further analysis in quantitative risk analysis or directly to the risk response planning step.

Inputs to qualitative risk analysis include the risk management planning information developed in step 1, which includes project complexity and technology maturity, data precision techniques, measurement scales, organizational risk factors, and risk assumptions. The potential project risks identified in step 2 and any other pertinent information that would help in the qualitative risk analysis process are also inputs.

Tools and techniques for performing qualitative risk analysis include the following:

Probability/impact matrix. A matrix is constructed that assigns risk ratings (very low, low, moderate, high, and very high) to risks or conditions based on combining probability and impact scales. Risks with high probability and high impact are likely to require further analysis, including quantification, and aggressive risk management. The risk rating is accomplished using a matrix and risk scales for each risk.

A risk’s probability scale may be defined to fall between 0.0 (no probability) and 1.0 (certainty), or any other scale that is used consistently across all risk factors. Assessing risk probability may be difficult because expert judgment is used, often without benefit of historical data. An ordinal scale, representing relative probability values from very unlikely to almost certain, can be used as well.

Qualitative risk analysis can produce the following results/outputs: An overall risk ranking for the project. Risk ranking may indicate the overall risk position of a project relative to other projects by comparing the risk scores. This rating can be used to assign personnel or other resources to projects with different risk rankings, to make a cost-benefit analysis decision about the project, or to support a recommendation for project initiation, continuation, or cancellation.

Prioritized risks. Risks and conditions can be prioritized by a number of criteria. These include rank (very low, low, moderate, high, and very high) or work breakdown structure level, such as Phase, Activity, and Task. Risks may also be grouped by those risks that require immediate attention and those that can be handled in a later part of the project.

December 2004 Page 3- 77 State of Michigan PMM Section 3: Project Planning

Risk Planning

QUANTITATIVE RISK ANALYSIS The quantitative risk analysis process aims to analyze numerically the probability of each risk and its consequence on project objectives. As stated above, quantitative risk analysis should be performed after qualitative risk analysis. Quantitative risk analysis should be performed for identified risks that require precise probability and impact measures; risks where the quantitative data is readily available; risks associated with large scale projects requiring such data, or for risks identified on projects that are predetermined to be of high risk.

Quantitative risk analysis uses techniques such as Monte Carlo simulation and decision analysis to: • Determine the probability of achieving a specific project objective • Quantify the risk exposure for the project, and determine the size of cost and schedule contingency reserves that may be needed • Identify risks requiring the most attention by quantifying their relative contribution to project risk, via a risk rating • Identify realistic and achievable cost, schedule, or scope targets

In order to quantify risks, a quantitative value must be assigned to each weighting factor. One such scale may use the following: • Very low = 10 percent (.1) • Low = 30 percent (.3) • Moderate = 50 percent (.5) • High = 70 percent (.7) • Very high = 90 percent (.9)

Examples of software development risk factors Project Size: Low = less than 10,000 lines of source code Medium = 10,000 to 100,000 lines of source code High = more than 100,000 lines of source code

Project Effort: Low = less than 1 person year Medium = 1 to 10 person years High = more than 10 person years

Project Cost: Low = less than $100,000 Medium = $100,000 to $1,000,000 High = more than $1,000,000

Inputs to quantitative risk analysis include the risk management planning information developed in step 1, which includes project complexity and technology maturity, data precision techniques, measurement scales, organizational risk factors, and risk assumptions. The potential project risks identified in step 2, the qualitative risk analysis outputs derived above, and any other pertinent information that would help in the quantitative risk analysis process are also inputs.

December 2004 Page 3- 78 State of Michigan PMM Section 3: Project Planning

Risk Planning

Quantifying Risk Factors Interviewing techniques are used to help quantify the probability and consequences of risks on project objectives. An interview with project stakeholders and subject matter experts may be the first step in quantifying risks. The information needed depends upon the type of probability distributions that will be used.

Documenting the justification of the risk ranges is an important component of the risk analysis because it can lead to effective strategies for risk response in the risk response planning process.

Additional methods for quantifying risk include: Sensitivity analysis. Sensitivity analysis helps to determine which risks have the most potential impact on the project. Sensitivity analysis examines the extent to which the uncertainty of each project element affects the objective being examined when all other uncertain elements are held at their baseline values.

Decision analysis. A decision analysis is usually represented in the form of a decision tree. The decision tree is a diagram that describes a decision under consideration and the implications of choosing one of the available alternatives. It incorporates probabilities of risks and the costs or rewards of each logical path of events and future decisions. Solving the decision tree indicates which decision yields the greatest expected value to the decision maker when all the uncertain implications, costs, rewards, and subsequent decisions are quantified.

Figure 3.28 depicts a decision tree. In order to make this decision correctly, one must determine whether it is more important to arrive on time or to travel economically. In this example, the decision to fly results in an expected value of $410 (-$300 + (.85 X $800) + (.15 X $200), while the decision to drive results in an expected value of $500 (-$150 + (.75 X $800) + (.25 X $200). In this case, the decision to drive would be made, baring other factors.

ty Arrive on bili oba $800 in sales Pr Time 5% Travel cost = $300 8 Fly 1 5% P rob ab Arrive Late $200 in sales ility Travel Decision

ty Arrive on bili $800 in sales oba Time Pr 75% Drive Travel cost = $150 25 % Pro bab Arrive Late $200 in sales ility Figure 3.28 Decision Tree Analysis

December 2004 Page 3- 79 State of Michigan PMM Section 3: Project Planning

Risk Planning

Simulation. A project simulation is a technique to emulate a process. Simulation is usually conducted a number of times to understand the process better and to measure its outcomes under different situations. Project simulations are typically performed using the Monte Carlo technique. There are software tools on the market that perform Monte Carlo simulations, such as Risk Radar and @Risk.

Quantitative risk analysis can produce the following results/outputs: A prioritized list of quantified risks. This list of risks includes those that pose the greatest threat to the project together with a measure of their impact. Figure 3.29 depicts the relationship between probability of occurrence and the anticipated impact of the occurrence. Risks can then be classified in categories, such as very high, high, moderate, low, and very low.

Probability of achieving the cost and time objectives. The probability of achieving the project objectives under the current plan and with the current knowledge of the risks facing the project can be estimated using quantitative risk. ce High Risk rren

Occu Medium Risk f o ty ili b a Low Risk Prob Impact of Occurrence Figure 3.29 Relationship of Risk Probability to Risk Occurrence Step 4: Risk Response Risk response planning is the process of developing options and determining Planning actions to reduce threats to the project's objectives. Risk Response Planning includes the further identification and assignment of individuals or teams to take responsibility for each agreed upon risk response.

Risk response planning must be appropriate to the severity of the risk, cost effective in meeting the challenge, timely, realistic within the project context, agreed upon by all parties involved, and owned by a responsible person. Selecting the best risk response from several options is often required.

Inputs to risk response planning include the risk management planning

December 2004 Page 3- 80 State of Michigan PMM Section 3: Project Planning

Risk Planning

information developed in step 1, including the level of risk that the organization will accept before taking action; the people and/or organizations that will take responsibility for the risk; and things and/or circumstances affecting/influencing multiple risks. Inputs to risk response planning also include potential project risks identified in step 2, the qualitative and quantitative risk analysis outputs identified in step 3, and any other pertinent information that would help in the risk response planning process.

Risk response strategies include: Risk Avoidance. Risk avoidance is changing the project plan to eliminate the threat of a specific risk event. Although the project team can never eliminate all risk events, some specific risks may be avoided. Creativity is often required in order to come up with proper risk avoidance strategies.

Risk Transference/Deflection. Risk transfer/deflection is seeking to shift the consequence of a risk to a third party via a contract provision with a third party, through an insurance policy, or a vendor warranty. This third party also takes ownership of the risk response. It is important to note that transferring the risk to another party does not eliminate it.

Risk Mitigation. Mitigation is reducing the probability and/or the consequences of an adverse risk event to an acceptable threshold. It is commonly known that taking early action to reduce the probability of a risk occurring or its impact on the project is more effective than trying to repair the consequences after it has occurred. Mitigation costs should be appropriate, given the likely probability of the risk and its potential consequences.

Risk Acceptance. This is a risk response strategy that prepares for, and deals with, the consequences of a risk event – either actively (developing a contingency plan) or passively (accepting the consequences). There is no plan on the part of the team to take action on this risk.

Contingency Measures The following represents a non-exhaustive list of mitigation strategies and/or contingency measures to consider when addressing project risk:

1. Provide appropriate training 2. Hire trained specialists 3. Install temporary hardware 4. Utilize internal hardware temporarily 5. Purchase additional equipment/facilities 6. Implement product functionality in a phased manner 7. Get agreement on who has decision authority; designate customer project coordinator 8. Locate project team in our offices 9. Negotiate better environment 10. Ensure that all the resources are provided 11. Suggest/sell functional specifications before development 12. Unilaterally develop functional specifications

December 2004 Page 3- 81 State of Michigan PMM Section 3: Project Planning

Risk Planning

13. Adjust deadline and get Customer buy-off 14. Do not commit to third party performance 15. Get third-party commitment at least equal to (if not more than) commitment 16. Get customer commitment to participate in the project 17. Increase estimates for the related tasks 18. Do not commit to a resolution time unless absolutely necessary and then only if a study is done by knowledgeable persons 19. Establish access to product support personnel 20. Hold regular meetings with customer 21. Maintain constant written and oral communication with remote personnel 22. Visit remote sites as needed 23. Demonstrate incremental results 24. Divide staff into teams and assign team leaders 25. Dedicate management resources 26. Establish final authority of project manager 27. Use proven hardware for development if possible 28. Reduce functionality to meet deadline 29. Document assumptions and understandings and get customer sign- off before investing substantial resources 30. Design an alternate (contingent) solution strategy

Risk response planning can produce the following results/outputs: Risk Responses within the Risk Management Plan. Each risk response should be written to the level of detail at which the actions will be taken. It should include some or all of the following:

• Identified risks, their descriptions, the area(s) of the project affected (e.g., work breakdown structure element), their causes, and how they may affect project objectives • Risk roles and assigned responsibilities • Results from the qualitative and quantitative risk analysis processes • Agreed responses including avoidance, transference/deflection, mitigation, or acceptance for each risk in the risk response section of the plan • The level of residual risk expected to be remaining after the strategy is implemented • Specific actions to implement the chosen response strategy. • Budget and times for responses • Contingency plans and fallback plans for major risks

Contractual provisions. Contractual provisions may be specified to identify each party's responsibility for specific risks, should they occur, and for insurance, services, and other items as appropriate to avoid or mitigate threats.

Contingency reserves. The probabilistic analysis of the project and the risk

December 2004 Page 3- 82 State of Michigan PMM Section 3: Project Planning

Risk Planning

thresholds help the project manager (or assigned risk manager) determine the amount of contingency needed to reduce the risk of overruns of project objectives to a level acceptable to the organization.

Inputs to the project plan. The results of the risk planning process must be incorporated into all areas of the project plan to ensure that agreed actions are implemented and monitored as part of the ongoing project.

Risk Management Plan The Risk Management Plan Template can be found on the following page, as Template well as in Appendix B.

December 2004 Page 3- 83 State of Michigan PMM Section 3: Project Planning

Risk Management Plan Template

State of Michigan (Insert Project Name Here) Risk Management Plan

A. General Information Information to be provided in this section is general in nature and provides the necessary information about the organization of the proposed project and project participants.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by:

B. Risk Management Strategy Define the risk management methodology to be used, the risk assumptions, the roles and responsibilities, the timeframes, risk ranking/scoring techniques, establish risk thresholds, define risk communications, and develop a risk tracking process.

1. Define the risk management methodology to be used

2. Define the risk assumptions

3. Define the roles and responsibilities

4. Define the timeframes

5. Define risk ranking/scoring techniques

6. Establish risk thresholds

7. Define risk communications

8. Define risk tracking process

C. Risk Identification Define the risk and the type of risk (personnel, equipment, customer, logistics, organization, or other).

December 2004 Page 3- 84 State of Michigan PMM Section 3: Project Planning

Risk Management Plan Template

Risk Category Risk Description

D. Qualitative and Quantitative Analysis Qualitative Analysis includes assessing the impact of risk events and prioritizing risk in relation to effect on project objectives. Quantitative Analysis includes assessing the probability of risk event occurring, establishing consequences of impact on project objectives, and determine weighting of risk.

Qualitative Analysis • Assess the impact of each risk event • Prioritize risk in relation to effect on project objectives

Risk Category / Risk Priority Risk Impact Assessment Event

Quantitative Analysis (optional) • Assess the probability of the risk event occurring • Establish consequences of impact on project objectives • Determine weighting of each risk factor

Risk Category / Probability of Consequences of Impact Risk Weighting Event Occurrence (Probability * Impact)

Risk probability: .1 = Very Low / .3 = Low / .5 = Moderate / .7 = High / .9 = Very High

E. Risk Response Planning Determine the options and actions to enhance opportunities and reduce threats to the project’s objectives. Assign responsibilities for each agreed response.

Risk Category / Risk Mitigation Outcomes Actions Taken / To Be Taken Risk Responses Event

December 2004 Page 3- 85 State of Michigan PMM Section 3: Project Planning

Procurement Planning

Procurement Planning Procurement planning is the process in which the project manager identifies Defined those needs of the project that can be met by purchasing products or services from outside the agency. Procurement planning deals with the following:

• What to procure • When to procure • How to procure • How much to procure

The relationship of procurement planning to the rest of the Planning Phase components is shown in Figure 3.30.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.30 Procurement Planning Identified in the Planning Processes

What to Procure It is very uncommon for an organization to be able to create or supply all the products necessary to complete a project internally. In those circumstances where it is necessary to go outside the agency, the response is to purchase the product or service from an external source or enter into a contract with an outside vendor to perform a service or develop the product for the agency. Whatever choice is made, there is definitely a considerable amount of forethought and planning that needs to go into such a decision.

When to Procure (Decision Decision tools are helpful in making decisions regarding procurement within Tools) the agency. Decision tools within procurement planning are not necessarily tools in the automated sense but are specific processes designed to facilitate decision-making.

December 2004 Page 3- 86 State of Michigan PMM Section 3: Project Planning

Procurement Planning

Make or Buy Analysis This is a simple method to determine the cost-effectiveness of creating a product in-house as compared to the cost of buying the product or having it produced outside the agency. All costs, both direct and indirect, should be considered when performing a make or buy analysis. The costs should then be compared with each other with consideration given to any compelling argument on either side by the project team. Consideration should also be given to the potential of leasing versus purchasing items. This could save money for the agency if cost is applied correctly against the useful life of the product or service supplied. Many of the decisions will be based on the length of need for the item or service as well as the overall cost.

Expert Judgment This process uses the expertise of people from within and outside the agency who have knowledge or training in the area in question to determine what steps should be taken. These people review the needs and the costs and deliver their opinion for consideration in the procurement decision.

How to Procure (Contract If a decision is made to purchase an item or service from outside the agency, Types) then another important decision is made to determine what type of contract should be used. The following are some common contract types:

Firm Fixed Price (Deliverable/Milestone Based) Contract. This is a contract that involves paying a fixed, agreed-upon price for a well-defined product or service. Special consideration must be given to these contracts to ensure that the product is well defined to reduce risk to both the agency and the contractor.

Cost Reimbursement Contract. This contract type refers to a reimbursement to the contractor for actual cost of producing the product or service. Costs within the contract are classified as direct (e.g., salaries to staff of the contractor) and indirect (e.g., salaries of corporate executives for the contractor). Indirect costs are normally based on a percentage of direct costs.

Firm Fixed Price Unit Price (Time & Materials) Contract. The contractor is paid a preset amount for each unit (e.g., $10 per widget produced) or unit of service (e.g., $50 per hour of service) produced. The contract equals the total value of all the units produced.

Retainage/Hold Back Contract. This contract type may be any one of the other types. The difference here is that a percentage or agreed portion of a contract payment is withheld (or “retained”) until a certain point in time, usually until final customer/client acceptance of the project’s deliverables. This is done in an effort to ensure full performance of the contract terms.

How Much to Procure This question can only be answered according to the needs of the project itself. However, serious consideration must be given at this point to the following questions:

• Will there be need beyond the immediate project for this product? • How much of the budget has been allocated for this product?

December 2004 Page 3- 87 State of Michigan PMM Section 3: Project Planning

Procurement Planning

• Is the need for the product clearly defined enough for the agency to know exactly how much of the product will be needed?

Underestimating or overestimating the cost or quantity of an item can have a huge impact on the financial success or failure of a project. Caution should be used when entering into any contract without clearly defined needs and objectives.

Procuring IT Related Goods The remainder of this section deals with procuring Information Technology and Services related goods and services in the State of Michigan. Please note that much of this information is subject to change. Please contact your designated Contract Compliance Inspector (or your procurement contact) to ensure that the most current, up to date information is available. These contacts can be found on pages 6 and 7 in the DIT phone directory at http://www.michigan.gov/documents/Phone_B1_56173_7.pdfT.

Procurement Vehicles / The following table lists the available contracting mechanisms available to Program Selection the Department of Information Technology:

Large Projects Initiative > $1M Invitation to Bid (ITB) Mid-Tier IT Projects < $1M Master Vendor Program IT Staff Augmentation <$250K START Program Telecom and Network Needs LinkMI / MMCC Contracts Technology Products &Training MMCC Contract / Training Contract Specialized IT & Telecom Needs Direct Enterprise Contracts Sole Source Services Requests Acquisition Services Policy Non-Contract Need < $25K Delegated Authority Purchase Order Non-Contract Need < $2500 SOM Procurement Card

Procuring Commodities (IT What is an IT commodity: Related) • Desktop Computers and anything that attaches to it • Laptop Computers and anything that attaches to it • Printers, scanners, digital cameras, PDA’s, or any other device • Desktop Software • Upgrades (memory, drives, etc) • Servers, mainframes and associated peripherals

Process Overview: • Process begins with a DIT-0015 or an on-line shopping cart from the MMCC catalog. This request captures details of the requested purchase, funding information, office approvals, and justification for purchase. • All requests are tracked via a tracking system. • Requests for nonstandard hardware or software are routed internally within DIT via a tracking system to obtain appropriate sign-offs and exception approvals. • Non procurement card requests are entered into MAIN according to the individual agency’s IT procurement profile.

December 2004 Page 3- 88 State of Michigan PMM Section 3: Project Planning

Procurement Planning

• Process metrics vary by length of approval path and type of purchase. Generally, standard requests are entered as PO’s within 3 days of receipt in DIT Procurement.

Michigan Master Computing Contract (MMCC) Three categories: 1. Desktop & Portable Hardware, & Microsoft Software 2. Servers, Local Area Network Hardware, Peripherals, & Operating Systems 3. Desktop, Enterprise & Network Software Note: All sections include limited optional services, primarily, as they directly relate to the installation or implementation of commodities bought via the contract.

How to procure these items: Each state agency has a procurement profile that details who is responsible in the agency for authorizing purchases, who are authorized to call in procurement requests, and whether the agency will approve requests in MAIN or on paper (or both). Each DIT Agency Information Officer and DIT Client Service Delivery Specialist have copies of their agencies procurement profiles. Other staff can obtain copies from their procurement liaison. Depending on the agency profile, methods to procure commodities include: • Call the DIT “Client Service Center” @ (517) 241-9700 or (800) 968-2644 for assistance in identifying the appropriate equipment to fit your needs or to secure a quote • For agencies that are processing on-line MMCC catalog orders, registered users can request quotes, build a shopping cart, and send it to DIT Procurement for approval in lieu of a DIT-0015. The website location is http://www.wwt.com/michigan • Or contact your IT Procurement Liaison – see page 5&6 of DIT Phone Directory: http://www.michigan.gov/documents/Phone_B1_56173_7.pdf

Commodities Process Metrics (estimation only) • From order to PO, Normal Desktop Acquisitions <5 units; 3 business days plus Agency approval path • From order to PO, non-contract commodities <$25,000; 7 days plus Agency approval path • From order to PO, non-contract commodities >$25,000; >30 days plus Agency approval path • Vendor commitment to ship <30 days • From receipt at Depot, 3-day turn around to Field Services • From Field Services to installation, 4 days

Hardware/Software The majority of the IT hardware and software maintenance is renewed on a Maintenance fiscal year basis. The process overview is as follows:

• DIT Procurement liaison maintains a spreadsheet of annual maintenance items and the cost; • In July of each year, DIT procurement sends updated spreadsheets to DIT Agency Services and Infrastructure Services staff, requesting review and recommendation on the renewal, support coverage or

December 2004 Page 3- 89 State of Michigan PMM Section 3: Project Planning

Procurement Planning

termination of maintenance for the various hardware and software items currently supported. • After DIT internal review, DIT Procurement obtains new quotes for those items recommended for renewal in the new year. • DIT procurement updates the spreadsheets with the new pricing information and forwards the spreadsheets to the appropriate agency for funding approval and any agency specific coding or funding information. • Upon receipt of funding approval from the agency, DIT Procurement makes the purchase via the appropriate contracting vehicle.

Maintenance renewals in mid year are handled via the DIT-0015 process.

Checklist of Forms Needed to Type of Request DIT-0015 AS-1 Form * Vendor Quote Justification Sole Source MMCC Exception Purchase Commodities

Commodities: (1) Releases from BPO, Under $25k, no GF X X X (2) Releases from BPO, Under $25k, w/GF X X X X (3) Releases from BPO, $25k plus, no GF X X X (4) Releases from BPO, $25k plus, w/GF X X X X (5) Non-BPO Requests Under $25k X X X (6) Non-BPO Requests $25k plus X X X X X

For non-standard requests, agencies must include a business case justification citing what need the requested commodity meets that the current standard cannot meet.

MMCC exceptions are done by DIT Procurement, not the requester.

*Note: Subject to change depending on executive directives.

Services The various contract vehicles and program selections to procure IT services are as follows:

Delegated Authority. DIT has delegated authority from Department of Management and Budget (DMB) Acquisition Services (AS) to complete technology service or product purchases of $25,000 or less. These purchases generally require a completed DIT 0015, Statement of Work, and/or Vendor Quote/Proposal. The procurement process can be completed internally and generally requires only 2-3 weeks to complete.

Statewide Contracts. Various product and service statewide contracts are managed by DMB AS. Statewide contracts are open to all agencies. Statewide contract procurements generally require a DIT 0015, Statement of

December 2004 Page 3- 90 State of Michigan PMM Section 3: Project Planning

Procurement Planning

Work, and/or Vendor Quote. The procurement process can be completed internally and generally requires only 2-3 weeks to complete.

Enterprise Agreements. Enterprise Agreements have been developed by DIT in cases where demand for a particular technology product or service is high, benefits can be gained by creating a single contract, and contractual terms and conditions allowed for aggregation. Enterprise Agreements are designed for multiple Agency use, but specific agencies must be added to the contract as needed. Enterprise Agreement purchases generally require a completed DIT 0015, Statement of Work, and/or Vendor Quote/proposal. The procurement process can be completed internally and generally requires only 2-3 weeks to complete.

Master Contracts. Mandatory use contracts managed by DMB AS are Master Contracts. Some Master Contract Examples include: JIT Office Supplies. When relevant, Contractor Compliance Inspector’s are required to use these agreements. Statewide contract procurements generally require a DIT 0015, Statement of Work, and/or Vendor Quote. The procurement process can be completed internally and generally requires only 2-3 weeks to complete.

Sole Source. Sole Source procurements are to be utilized when only one vendor possesses the unique and singularly available capability to meet the requirements of the customer or when it is not economically feasible to go to another vendor. Technology products or services can be purchased under a sole source contract if the purchase meets the requirements defined by DMB AS. This purchasing tool should be utilized only when absolutely necessary, as DIT, Office of State Employer (OSE), Civil Service (CS), DMB management, and the State Administrative Board scrutinize Sole Source procurements carefully. Given the additional scrutiny in the process, it requires a completed Statement of Work, Sole Source Justification (including DMB AS Sole Source Questions Document), AS-1, DIT 0015 and can take as long as 3 months to complete.

START Program. The Short-Term Augmentation of Resources in Technology (START) Program was developed to allow client agencies a relatively quick and easy way to hire technology staff augmentation resources. The program is limited to staff augmentation purchases of less than $250,000 with project durations no greater than 12 months. The program uses a pre-qualified list of service vendors. The process requires a quick turnaround competitive bid process and allows the agencies to use agency defined selection criteria. The procurement process requires a completed statement of work, START ITB template, and DIT 0015. The procurement process generally requires 3-4 weeks to complete from agency approval to purchase order issue. The process does vary greatly by agency, depending on the rigor required in the hiring process.

Master Vendor Program (MVP). DIT established the Master Vendor Program (MVP) to serve as the primary contract mechanism delivering mid- tier projects. Projects that qualify for this program must be less than $1,000,000 with a duration of less than 18 months. The procurement process requires a completed MVP Work Project Request, and DIT 0015. MVP is a streamlined bid process that is completed in 4-6 weeks.

December 2004 Page 3- 91 State of Michigan PMM Section 3: Project Planning

Procurement Planning

Invitation to Bid/Requests for Proposals. The ITB/RFP process is generally used to acquire technology products and or services for large projects (> $1M). It is recommended that the ITB process be utilized only when technology services cannot be purchased through other contracting mechanisms (i.e. Master Vendor, START, Enterprise Agreements). The procurement process is sometimes lengthy (6 months) and requires a statement of work, ITB Template, DIT 0015, and AS-1.

Checklist of Forms Needed to Purchase Services Type of Request DIT-0015 AS-1 Form * Statement of Work Request Project Work MVP ITB Template Vendor Quote Justification Sole Source

Services (1) New Request, Under $25k X X X X X (2) Amendment Under $25k X X X X (3) Blanket Contract Releases X X X X $25k plus (4) New Contracts $25k plus X X X X X (sole source) (5) New Contracts $25k plus X X X X X (to be bid out) (6) Contract Changes/Amend X X X X Over $25k (7) Master Vendor Program X X X Contracts (8) START Program Contracts X X X X

*Note: Subject to change depending on executive directives.

Statement of Work The core of any new contract (no matter the procurement vehicle used) is the Development Statement of Work (SOW). Every single contract requires a SOW; only the level of detail or complexity varies by procurement program. The Agency Project Manager should develop the SOW with the Contract Compliance Inspector’s assistance. Vendors should not be developing Statements of Work.

Because the SOW process is so important to the overall procurement process, each component of the SOW is outlined. The form follows the standard SOW template used by DIT and DMB AS.

1.0 PROJECT IDENTIFICATION 1.001 PROJECT REQUEST This section contains the basic project information, and includes: Project Title, Department, Client Agency, Project Manager Name, Phone, and DIT Contract Compliance Inspector Name and Phone Number.

December 2004 Page 3- 92 State of Michigan PMM Section 3: Project Planning

Procurement Planning

This section is typically one paragraph in length and provides an overview of the project.

1.002 BACKGROUND

This section is typically less than a page long and describes how the State got here from there. Note any concurrent projects and if this project is part of a larger project. Also explain critical success factors and the business objectives that have caused this SOW to be issued.

The overview should include the following information:

Briefly explain who (customer) requested what and when. Explain the history of the project (including any previous phases and their major deliverables that serve as input to this effort). Identify who performed this work.

Explain if there are other, related efforts taking place. Again, identify who is performing this work.

Explain the “critical success factors” (CSF) from BOTH a business and technology prospective. This answers how the customer will judge the success of the effort. The CSF should be few in number (3-5) and in priority order.

1.1 SCOPE OF WORK AND DELIVERABLES

1.101 IN SCOPE

List or describe what is “in-scope.” Be as detailed as possible as more specificity will help prevent scope creep. Identify any phases of the project and specific systems, applications that are involved. Attempt to identify the boundaries of the project. Avoid using phrases that begin with “assist” or “participate” because those words do not explain what the Contractor is going to actually do. If there are multiple parties involved, then define scope by owner.

The scope should include the following information:

Identify what phase (or phases) of the effort is covered by this document. Often this phase will create a SOW for, but not execute, the following phase. Identify specific systems, applications, programs, etc. These details should be part of the estimating basis for the project plan. These details may be summarized in this section with an appendix providing the complete detail. Identify specific task lengths as needed (i.e. application testing 3 weeks). Define project boundaries, that is, where the project’s responsibility ends and others’ responsibility begins. What documentation will be produced? How will interfaces to other systems or projects be handled? How will work be handed-off to ongoing support groups upon completion of development and testing? Avoid general terms such as assist or participate. Define how the vendor assists or participates.

December 2004 Page 3- 93 State of Michigan PMM Section 3: Project Planning

Procurement Planning

If multiple companies involved, then list scope by responsible party. Identify evaluation time frames to review and revisit the scope, update time estimates for task completion, etc.

1.102 OUT OF SCOPE

List or describe what is “out-of-scope.” This should not say that anything not listed above is out of scope. Out of scope items can always be brought back in-scope with a change order, but this will set the field of responsibility for the start of the SOW.

List the analysis of items unknown as in scope and the potential work identified as out of scope pending the results. Identify that out of scope items can be added using a change management process.

1.103 TECHNICAL ENVIRONMENT

Describe the technical environment. What are the hardware and software requirements? Are there separate development, production and testing environments? Any of these that are not known should be listed as Deliverables.

1.104 WORK AND DELIVERABLE

Contractor shall provide services and staff, and otherwise do all things necessary for or incidental to the performance of work, as set forth below:

Describe in detail what work Contractor will perform. Identify all tasks, work elements and objectives of the SOW, and timeline for completion of the major elements of the project. For each activity, list or describe the Deliverables associated with that activity. Each Deliverable must have acceptance criteria and process for review. If acceptance criteria are not available at the time the SOW is entered into, then there should be a Deliverable of acceptance criteria to the State BEFORE delivery of the Deliverable itself.

More detail on tasks and deliverables include:

Tasks Describe the work approach to detail how the project team will do the work, it can be broken down into Work Breakdown Structure (WBS). Identify which methodology is being used (if any). Briefly describe (or list) each specific task or activity that must be accomplished to meet the goals and objectives of the project.

Describe the task plan management. Include key points: • Develop a project plan using Microsoft Project • Require weekly time sheets from team members with actual effort and estimate to complete. • Weekly update to the project plan includes actual effort and estimate to complete. • Require review of the updated plan for variance to schedule or budget. • Modifications to the (baseline) project-plan allowed if and only when required through an approved change request.

December 2004 Page 3- 94 State of Michigan PMM Section 3: Project Planning

Procurement Planning

Deliverables A deliverable is an item that requires customer sign-off using a deliverable acceptance form (as defined by the Agency). The deliverables listed in the SOW should be identical to those in the project plan. The deliverables should be spread throughout the life of the project. Each deliverable must define what the customer is authorized to review and approve. Typically the Sponsor is listed, but they rely on others to really review, comment and verify.

Each deliverable must have acceptance criteria. Acceptance criteria define what must exist in order to secure customer approval. This may include creating (and securing approval) of a template or a pilot. This should reduce or eliminate judgmental approval or rejection. It is not necessary to delay completion of the SOW while determining acceptance criteria for every deliverable. Those acceptance criteria not readily determined should be defined through another deliverable. However, the key is to have acceptance criteria approved before creation of the deliverable.

Request a detailed project plan be attached, but a listing of tasks in this section is not required. Typically work products, internal “deliverables” not submitted or approved by the customer, are not listed.

1.2 ROLES AND RESPONSIBILITIES

1.201 CONTRACTOR STAFF, ROLES, AND RESPONSIBILITIES

Identify Contractor staff who will be involved, identify by name individuals that are to be designated as Key Personnel (if necessary), and describe in detail their roles and responsibilities. If an overall organization chart has been developed, then provide a reference to that chart as well. Note any part-time personnel. Descriptions of roles should be functional and not just by title. It is ok to duplicate roles that are listed in other sections of the SOW.

1.202 STATE STAFF, ROLES, AND RESPONSIBILITIES

Identify State staff who will be involved and describe in detail their roles and responsibilities. If an overall organization chart has been developed, then provide a reference to that chart as well. Note any part-time personnel. Descriptions of roles should be functional and not just by title. It is ok to duplicate roles that are listed in other sections of the SOW.

1.203 OTHER ROLES AND RESPONSIBILITIES

Identify “other” staff who will be involved and describe in detail their roles and responsibilities. This may include other State vendors, other projects, other State departments, etc. If an overall organization chart has been developed, then provide a reference to that chart as well. Note any part-time personnel. Descriptions of roles should be functional and not just by title. It is ok to duplicate roles that are listed in other sections of the SOW.

1.3 PROJECT PLAN

December 2004 Page 3- 95 State of Michigan PMM Section 3: Project Planning

Procurement Planning

1.301 PROJECT PLAN MANAGEMENT

Identify the project plan. Describe how the plan will be reviewed and updated on a regular basis.

1.302 REPORTS

Identify what reports are necessary and the process for preparation and review of the reports. Define a meeting schedule for reviewing the project.

1.4 PROJECT MANAGEMENT

1.401 ISSUE MANAGEMENT

Issues are those things that endanger the project. It includes imminent threats and events that may have already occurred. Identify how issues will be captured, reported and escalated. Define the issue escalation process to include whether escalation will be based on age, severity, budget impact, etc. and where the escalation levels are.

1.402 RISK MANAGEMENT

Risk and Issues are not the same. Risks are those things that you can assume or anticipate in a project. Issues are imminent threats or things that have already occurred. Risk management generally involves (1) identification of the risk, (2) assigning a level of priority based on the probability of occurrence and impact to the project, (3) definition of mitigation strategies, and (4) monitoring of risk and mitigation strategy. Risk assessment review should be conducted on a regular basis.

1.403 CHANGE MANAGEMENT

Describe the change management approach. Identify the process for changes, including the use of any change order forms and the people involved in review and approval. Define the criteria for changes. What are the triggers for the need for a change request? (e.g. If a particular project is a day late, is the whole project plan readjusted or is the day absorbed in another section?

More detail on Change Management include: • Describe the required change management approach. Change happens and documentation of the reason (need or benefit), impact (cost and/or schedule), must be maintained. • Describe how a change request is made (after each incident or only when a threshold is reached). Outline how the change request should be disposed (approval or rejected), and outline the number of business days after submittal. This disposal needs to be in writing and is typically 3 or 5 business days and rarely more than two weeks. • Describe criteria for change. • Change is the request to adjust any portion of the SOW, approved deliverable or approved change request. • Change can be (and should be) more than an adjustment to scope. • Change may be “compliance” or “non-compliance.” A compliance change request adjusts something agreed to. A non-compliance change

December 2004 Page 3- 96 State of Michigan PMM Section 3: Project Planning

Procurement Planning

request defines something that did not happen as planned. Examples include system not being available (lost time) or people not performing their duties per R&R and the project plan. • Change may be an incident of a risk. • Change can also be time extensions to the project.

1.5 ACCEPTANCE

1.501 CRITERIA

The following criteria will be used by the State to determine Acceptance of the Services and/or Deliverables provided under this SOW.

Describe in detail acceptance criteria and service levels expected. There are often multiple sub-Deliverables that must be accepted before the project level Deliverable can be presented and approved. Deliverables must be presented to the appropriate person and accepted in writing. The basis of the State’s ability to reject a Deliverable must relate to the written requirements of the SOW. Any rejection should be based on the acceptance criteria and the requirements of the SOW.

1.502 FINAL ACCEPTANCE

Final Acceptance is when the project is completed and functions according to the requirements. Any intermediate acceptance of sub-Deliverables does not complete the requirement of Final Acceptance.

1.6 COMPENSATION AND PAYMENT

State shall pay Contractor an amount not to exceed [______] dollars ($___) [specify maximum dollar amount] for the performance of all activities necessary for or incidental to the performance of work as set forth in this SOW. Authorized Services and Price List as follows:

List detail of compensation to be paid, e.g., hourly rates, number of hours per task, unit prices, cost per task, cost per deliverable, etc. If the list is too long, the document may become an “Attachment” to the Statement or Work. If Contractor will be reimbursed for any other expenses, describe them and any cost limits in this section. Costs should be broken down by acceptance of Deliverables, time periods, invoicing, labor vs. non-labor, etc. as appropriate to the subject of the SOW.

Identify the payment schedule; the options can be one of the following: • Time and Materials • Deliverables based payment • Milestone based payment • Final Lump Sum (Satisfactory Final Acceptance at Contract Conclusion). • Optional Provision: Holdback/Retainage - The AGENCY may withhold 10 percent from each payment until acceptance by the AGENCY of the final report (or completion of the project, etc.).

Identify that payment shall be considered timely if made by DIT within thirty (30) days after receipt of properly completed invoices.

December 2004 Page 3- 97 State of Michigan PMM Section 3: Project Planning

Procurement Planning

Expenses: Identify expenses that will be reimbursed during this project, if any. If allowable, identify only those expenses that are appropriate for the contract, and the requirements for reimbursement (prior approval must be obtained by the project manager, and reimbursement at current state-authorized rates only as outlined by DMB guidelines).

1.7 ADDITIONAL TERMS AND CONDITIONS SPECIFIC TO THIS SOW

State additional terms and conditions specific to this SOW not found in Contract, if any. Any additions should be reviewed for consistency with the term and conditions of the Contract.

Monitoring Invoice Process The invoice process for services involves various approvals before the payment process is complete. Reconciliation of the invoice should be completed according to the invoicing schedule outlined in the contract.

The Project Manager in cooperation with the Contract Compliance Inspector should practice the following guidelines: • Ensure that there is a sufficient dollars available on the purchase order to pay the invoice. • Ensure that the invoice received has been submitted according to contract terms (schedule defined in the contract). • Ensure that the contractual employee’s timesheet(s) is attached to the invoice. • Ensure that the hours on the invoice match the hours on the timesheet. • Check that the hourly rate of the employee matches the contract terms. • If the vendor is billing for travel expenses, verify that travel is allowed on the contract and that these expenses meet the State of Michigan guidelines and actual receipts are provided. • Ensure that the timesheet is accurate, the dates match the invoice period and the math is correct. • Ensure the correct signatures are on the timesheet (agency project manager, employee, and vendor manager). • If there is an error on the invoice, contact the vendor for resolution. • If the agency project manager has not signed the timesheet, forward for necessary approval. (Note: Some Agency Project Managers approve time and material invoices without requiring staff timesheets. It is an acceptable practice if the contract does not require timesheets.) • Ensure that the deliverable acceptance and approval documentation has been submitted with the invoice (signed letter or email from the agency project manager).

References for Additional Contracts & Procurement Services Information http://www.michigan.gov/techtalk/0,1607,7-167-21005_27253---,00.html

Ad Board Schedule & Bid Postings http://michigan.gov/doingbusiness/0,1607,7-146----,00.html

Vendor Interactions

December 2004 Page 3- 98 State of Michigan PMM Section 3: Project Planning

Procurement Planning

– Become a Registered State of Michigan Vendor http://www.cpexpress.state.mi.us/ – Check Bid Website Regularly http://michigan.gov/doingbusiness/0,1607,7-146-6572---,00.html – Attend a Business Opportunity Forum http://www.michigan.gov/doingbusiness/0,1607,7-146-6592-62348-- ,00.html – Utilize the DIT Vendor Resource Center http://www.michigan.gov/dit/0,1607,7-139-18391_22369---,00.html

Travel info http://www.michigan.gov/dmb/0,1607,7-150-9141_13132---,00.html

DIT Phone Directory http://www.michigan.gov/documents/Phone_B1_56173_7.pdf

DMB Acquisition Services - Estimated Time Goals http://www.michigan.gov/doingbusiness/0,1607,7-146-6592_16869--- ,00.html

Acronyms AD Board Administrative Board AS Acquisition Services BPO Blanket Purchase Order CSD Client Service Delivery CSF Critical success factor EDS Electronic Data Systems - vendor GF General Funds IO DIT Agency Information Officer ITB Invitation to Bid JEC Joint Evaluation Committee MAIN Michigan Administrative Information Network MMCC Michigan Master Computing Contract MVP Master Vendor Program OSE Office of State Employer PO Purchase Order SOW Statement of Work START Short Term Augmentation of Resources in Technology

December 2004 Page 3- 99 State of Michigan PMM Section 3: Project Planning

Quality Planning

Quality Planning The quality management process is the application of quality theory, methods, and tools to focus on customer requirements and to manage work processes with the objective of achieving continuous improvements or radical redesign.

The relationship of quality planning to the rest of the Planning Phase components is shown in Figure 3.31.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.31 Quality Planning Identified in the Planning Processes

Quality Management Quality management includes “all activities of the overall management function that determine the quality policy, objectives, and responsibilities and implements them by means such as quality planning, quality assurance, quality control, and quality improvement, within the quality system.” [Project Management Body of Knowledge] Figure 3.32 depicts a high-level quality project management process.

Conduct Conduct Conduct Quality Quality Quality

Planning Assurance Control

Figure 3.32 Quality Project Management Process

December 2004 Page 3- 100 State of Michigan PMM Section 3: Project Planning

Quality Planning

The purpose of using quality management is to improve products and services while achieving cost reductions throughout the project. Quality management requires broadening the scope of the quality concept to a systems approach. Many advocates of quality management will say that quality is an attitude or way of life that transforms the culture of an organization to one that emphasizes continuous quality improvement. Because the three processes depicted in Figure 3.36 interact with each other, as well as other processes within project management, quality management must be regarded as a system.

"Quality Planning" involves identifying which quality standards are relevant to the project and determining how to satisfy them. The activities within the quality planning process basically translate existing quality policy and standards into a Quality Plan through a variety of tools and techniques.

"Quality Assurance" is the evaluation of overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. It utilizes quality audits to ensure that quality standards and customer requirements are met. This is further described in Section 4, the Project Execution Phase, of this methodology.

Quality control involves monitoring specific project results to determine if they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance. This is further described in the Section 5, the Project Control Phase, of this methodology.

Successful quality processes always strive to see quality through the eyes of the customer. Customers are the ultimate judge of the quality of the product they receive. They will typically judge a project by whether or not their requirements are met. To ensure delivery of a quality product, the project team should ensure that requirements are addressed at each phase of the project.

It is important to include a process that validates that the currently defined requirements will be satisfactory to the customer. It is counterproductive to develop a system that meets a documented requirement if you and the customer know that the requirement has changed. The change management process helps to control the number of such changes, but quality processes must be in place in order to make changes when they are necessary.

Quality Tools and There are four basic techniques used in quality management: Techniques • Cost-Benefit Analysis • Benchmarking • Flowcharting • Modeling

Cost-Benefit Analysis Cost-benefit analysis involves estimating tangible and intangible costs and benefits of various project alternatives, and then using financial measures, such as return on investment or payback period, to assess the relative desirability of the identified alternatives. The quality planning process must consider cost-benefit trade-offs. “The primary benefit of meeting quality

December 2004 Page 3- 101 State of Michigan PMM Section 3: Project Planning

Quality Planning

requirements is less rework, leading to higher productivity, lower costs, and increased stakeholder satisfaction. The primary cost of meeting quality requirements is the expense associated with project quality management activities; therefore, it is important for the benefits to outweigh the costs.” [Project Management Body of Knowledge] See the Cost-Benefit Analysis subsection for more information.

Benchmarking By using the benchmarking method, the quality manager and project team compare both actual and planned practices of the current project against other similar projects performed within the agency in the past. As long as the two projects have comparable processes with measurable results, the quality manager will be able to take a step toward determining the quality success of a project by comparing the two.

Flowcharting Flowcharts are diagrams that graphically show how different elements of a system fit together in order to make clear the logical flow of data or processes. Examples of flowcharts include the following:

• Fishbone or Ishikawa Diagrams—these illustrate how various causes and sub-causes create or relate to process problems. • System or Process Flowcharts (modeling)—these show how various elements of systems interrelate.

Modeling Models are diagrams that describe details of procedures used for executing the tasks of projects. One such quality model can be seen in Figure 3.33 on the following page. Models should be based on standards and procedures that enable the quality manager to ensure quality during the project as follows:

• By enforcing quality standards and procedures through formal reviews, walkthroughs, and inspections. • By tracking and reviewing defects at each phase of the project.

For large, lengthy, or complex projects requiring a unique Quality Plan, the model will define, track, and measure the project’s quality goals. It is important for management to consider the quality goals early in the project and ensure that quality activities are integrated into the overall Project Management Plan. The Quality Plan is developed based on the quality procedures developed by the agency. These procedures address requirements that are specific to that state agency.

In short, these processes help team members determine where problems might occur so those problems can be fixed during the product creation rather than through rework.

December 2004 Page 3- 102 State of Michigan PMM Section 3: Project Planning

Quality Planning

Change Management Functionality Config. Management Performance Quality Quality Process Quality Attributes Definition Standards Measurement Procedures & Verification Methods, Tools, Techniques Quality Definition

Plan and Manage

Quality Assurance

Verify quality of solution being developed Quality Management

Qual ity Assess ment

Walkthrough Reviews Technical Verification & Accep tance Quality Quality Reviews Validation Test ing Audits Reviews

Phase Reviews Soluti on Accept ance Quality Assessment

Figure 3.33 Quality Assurance Model

Responsibility for Quality Every project member needs to buy in to the responsibility for producing a quality product. Through ownership of the agency’s quality policy, the individual team members become the most effective way to implement quality into products efficiently and completely. A quality policy cannot rely on adding quality at the end of a process; quality must be built into the work of each individual on the team. It is far more cost-effective to have team members add quality into their day-to-day jobs than to have a quality analyst find a problem after a process has been completed.

Checklists Quality checklists are often developed as part of the quality procedure definitions. The checklists and associated quality procedures are developed individually by each State agency according to its policy and the needs of the project. The Quality Plan is integral to, and a document contained in, the Project Plan.

Quality Plan Template The Quality Plan Template can be found on the following page, as well as in Appendix B.

December 2004 Page 3- 103 State of Michigan PMM Section 3: Project Planning

Quality Planning Template

State of Michigan (Insert Project Name Here) Quality Plan

A. General Information Information to be provided in this section gives a specific name to the project as well as pertinent information about the personnel involved.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by:

B. Project Scope Describe the project, either by inserting the Project Scope Statement or by providing a summary description of the overall project, its objectives, its customer, and its customer’s business needs.

C. Deliverable Description Describe project deliverables, including contract deliverables and milestone checklist.

D. Acceptance Criteria Describe acceptance criteria for deliverables as they will be used in product acceptance testing. List relevant quality standards.

E. Quality Assurance Activities Define Quality Assurance activities for the project including test and acceptance processes, documentation and operational support transition, milestone checklist, requirement verification processes, schedule and communication activities, and continuous improvement processes.

December 2004 Page 3- 104 State of Michigan PMM Section 3: Project Planning

Quality Planning Template

F. Project Monitoring and Control Define in-process control plans which address quality assurance activity areas, how control information will be collected, how information will be used to control processes and deliverables, what and when audits and reviews are required, and how variance to acceptable criteria will be reported and resolved.

G. Project Team Quality Responsibilities Describe quality-related responsibilities of the project team including specific tasks such as acceptance test, audit, review and checklist responsibility assignments.

December 2004 Page 3- 105 State of Michigan PMM Section 3: Project Planning

Communications Planning

Communications Planning Communications planning involves defining the information needs of project stakeholders as well as identifying which people need what information, when it will be needed, and how they will get it. Communication is the cornerstone of how work gets done among different parties within a project. Communications planning is a process that overlays all other parts of project planning as well as the other phases because it is the way in which we transfer what needs to be done, how it will be done, when it needs to be done, by whom it will be done, etc.

The relationship of communications planning to the rest of the Planning Phase components is shown in Figure 3.34.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.34 Communications Planning Identified in the Planning Processes

Communications Beginning to develop a Communications Plan involves understanding who Information Requirements within the agency or project organization will be needing what information and their relationship to the project. The number of team members involved with the project and their locations is also a consideration when making decisions on how best to handle project interaction.

To begin developing a communications infrastructure, it is necessary to know and understand considerable data. The information required by people throughout the project is often dictated by the organizational structure of the agency. Information that is disseminated should contribute to project success or highlight possible areas of communication failure.

Other data are also needed to assist the project manager in the creation of the Communications Plan. These data will help the project manager develop the infrastructure for creation and dissemination of information. The following questions highlight information needs:

December 2004 Page 3- 106 State of Michigan PMM Section 3: Project Planning

Communications Planning

• How quickly will people need the project information? • How often will they need information? • What is the most convenient form of media for all team members and stakeholders (electronic, paper, etc.)? • Are there already communications systems in place that can be taken advantage of? • How long will people be involved with the project and need to receive information?

Communications Plan After collecting information on the number and needs of the stakeholders involved with the project, it is the project manager’s responsibility to draft a Communications Plan that outlines the following:

• How information will be collected and updated. This section of the plan discusses how the project manager will collect information from certain project areas and how often updated information will be expected to be reported. It should also discuss what action will be taken if important information needs to be updated between project information collection cycles. • How information will be controlled and distributed. This section of the plan provides a description of how project information will flow throughout the agency and who will make decisions on where information flows. This section also discusses which stakeholders and team members will have access to which particular areas of information. The intent of the distribution part of this section is not to limit team members from being able to access data that they need, but to provide a structure to keep anyone looking to do damage to the project away from sensitive materials. Information security policies should be referenced here. • How information will be stored. This section of the plan gives project members an idea where physical project files will be kept within the agency as well as where electronic media might be stored for project team access.

Communications Plan The Communications Plan Template can be found on the following page, as Template well as in Appendix B.

December 2004 Page 3- 107 State of Michigan PMM Section 3: Project Planning

Communications Planning Template

State of Michigan (Insert Project Name Here) Communications Plan

A. General Information Information to be provided in this section gives a specific name to the project as well as pertinent information about the personnel involved.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by:

B. Timeliness Describe how quickly and how often the project information will need to be communicated to the stakeholders.

Stakeholders: (Monthly)

Sponsor: (Monthly)

Project Manager: (Weekly)

Project Team: (Biweekly)

Procurement: (Monthly)

Quality: (Biweekly)

C. Information Type Describe how different types of information will be disseminated. (Voice, electronic mail, spreadsheet, formal presentation.)

D. Existing Systems Discuss the communication systems already in place and how they will be leveraged on the project. Include any political environmental considerations.

December 2004 Page 3- 108 State of Michigan PMM Section 3: Project Planning

Communications Planning Template

E. Length of Involvement Describe how long individual stakeholders will continue to receive information on the project.

F. Environmental Considerations Study the political environment, understand stakeholder requirements and other environmental considerations.

G. Method for Updating the Communication Plan Describe how and when the Communications Plan will be updated throughout the project.

December 2004 Page 3- 109 State of Michigan PMM Section 3: Project Planning

Change Management Planning

Change Management Project change management planning is the development of a plan for Planning Defined handling changes to any project plans. It should ensure that any changes occurring within the project are promptly identified, coordinated, agreed upon, and properly managed. As more becomes known about a project, these plans are fine-tuned or updated; this type of evolution is not considered “change.” The plan should identify the necessary paperwork, tracking system specifications, processes, and approval levels for authorizing changes. It should also address how the project will ensure that the changes are beneficial, determine how the change will occur, and it will manage the changes as they introduced. It should cover any changes related to:

• Scope – Agreed-upon features and functions of a product or service being produced by the project, and all related objectives and deliverables; • Project Baseline Plans and Supporting Documents – Including the WBS, activity list, planned activity sequencing, activity duration estimates, resource plan, baselined schedule, and baselined cost estimates; • Project Management Plans – Including the risk management plan, communication plan, quality management plan, and procurement plan; • Issues – Process developed to monitor and manage issues (“Issues” have the potential to become “changes.”).

Change in any of these areas can be defined as: (1) an increase or decrease in any project characteristics (e.g., time, cost, requirements); (2) a deviation from agreed-upon specifications, definition, functionality, or plans, or an alternate approach to project work accomplishments; or (3) an alteration in a contract.

It is assumed that a request for change may occur in many forms – oral or written, direct or indirect, externally or internally initiated, and legally mandated or optional.

The goals of a Change Management Plan are: 1. Reasonable change activities are planned. 2. Changes are identified, defined, evaluated, approved and tracked through completion. 3. Project plans are changed to reflect the requested changes. 4. Changes are negotiated and communicated to all affected parties.

The relationship of change management planning to the rest of the planning phase components is shown in Figure 3.35.

December 2004 Page 3- 110 State of Michigan PMM Section 3: Project Planning

Change Management Planning

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.35 Change Management Planning Identified in the Planning Processes

Purpose of Change Since the future is unpredictable, project plans will never be entirely Management Planning accurate. In an effort to ensure that changes will not have a negative impact on project success, in terms of scheduled completion, budgetary constraints, quality, or customer satisfaction, changes to plans should be expected, and their handling should be planned.

Roles and Responsibilities • Project Sponsor • Project Steering committee, as appropriate • Project Manager • Project Team • Other Stakeholders

The project manager is responsible for project change management planning. The project sponsor, steering committee (as appropriate), and any other relevant project stakeholders should agree on the resulting plan. Project change management planning activities may be assigned to members of the project team, depending on the requirements of the plan. Generally, anyone associated with the project should be able to submit a project issue, or to request a project change.

The Process The process for project change management planning is shown in Figure 3.36 on the following page.

December 2004 Page 3- 111 State of Michigan PMM Section 3: Project Planning

Change Management Planning

TOOLS & TECHNIQUES: INPUTS: Control Items Product Scope Change Sources OUTPUTS: Project Baseline and Issue Management Change Mangement Plan Management Plans Change Tracking Version Control

Figure 3.36 Process for Project Change Management Planning

Scope In developing a plan to manage change within a project, there should be a complete understanding of what has been agreed upon with the customer regarding the specific features and functions of the product or service being produced by the project team, and any other related objectives or deliverables. This is the baseline product scope, which should be available in the scope statement. Deviations from this agreement constitute a change that should be promptly identified, additionally agreed upon, and properly managed. The project change management plan should ensure that this occurs.

Project Baseline and There should be a complete understanding of all project baseline plans (i.e., Management Plans schedule, budget), supporting details (e.g., WBS, activity list, planned activity sequencing), and management plans (e.g., quality management plans, risk management plans). Deviations from these plans should be assessed to determine whether a change has occurred that should be managed, or whether corrective action is needed that includes changes that should be managed. The handling of such deviations should be addressed in the project change management plan.

Control Items A project change management plan should begin with the identification of all plans and documents for which it is determined that any changes should be controlled. These plans and documents are considered “control items.” The listing of control items should include, at a minimum, the process inputs described above. The plan should ensure that all team members are informed of the control items and the method and purpose for controlling the items, so that if they should become aware of a change, they will know to inform the person who is responsible for managing the affected control item.

The plan should also ensure that control items are securely maintained to prevent accidental or undetected changes. A technique for accomplishing this might be write-protecting electronic versions of the approved control items.

Change Sources The project change management plan should include processes that ensure that situations requiring a change are promptly identified and addressed. To develop such processes, it is helpful to understand the potential sources or causes of changes. Changes in a project may occur for many reasons. Often they occur as a result of:

• Change in an external event, such as new legislation; • Error or omission in defining the scope of the product or service being developed by the project, such as failure to include a required feature for the system being developed; • Error or omission in identifying all activities required to complete the project;

December 2004 Page 3- 112 State of Michigan PMM Section 3: Project Planning

Change Management Planning

• Identification of a change that would add value to the project, such as new technology available after the planning process, which would allow the project to be completed sooner than planned; • Identification of new risks or changes to identified risks that result in the need for alterations to the risk response or contingency plans; • Change in funding levels; • Inability or failure of team members to follow the plans.

For such causes, the project change management plan should include strategies to identify potential needs for change, and to discover undetected changes in order to minimize their impact on project results, should they be needed. Some techniques that might be included in these strategies are:

• Project Risk Reviews – A strategy that might be included in a project change management plan as a means of identifying changes in risk that may require project changes. The project change management plan should define the processes that should be followed to ensure that changes required as the result of risk reviews are brought into the change monitoring process.

• Project Information System – May be included in a project change management plan as a source for identifying undetected changes or areas requiring a change. A project information system comprises all processes that gather the information, and which assist the project manager in monitoring the status of all project plans. The system may be manual, electronic, or a combination of both. While its complexity is dependent on the needs of the manager, the system should be comprehensive enough to ensure that the project manager can effectively monitor the implementation of each of the project plans. It should also provide all of the documentation deemed necessary to support decision-making, and also to provide historical information for the benefit of future projects. If the system is incorporated into a project change management plan, the plan should specify how changes or the need for changes, as identified by the system, are brought into the change monitoring process.

• Monitoring of Assumptions – Another strategy that may be employed to identify the need for project change. As projects are monitored, it might be discovered that one or more assumptions are no longer valid. As a result, plans developed on the basis of these assumptions may need to be changed. These changes need to be controlled to ensure that they do not have a negative impact on the project. The project change management plan should define how assumptions should be monitored; and, if changes are proposed as a result of monitoring, the plan should define the procedures that should be followed to ensure that the proposed changes are brought into the change monitoring process.

• Performance Measurement Techniques – Included in a project change management plan because they help in assessing the magnitude of actual performance variances from plans and baselines. Determining what is causing the variances may uncover the fact that an undetected change has occurred (e.g., team members not following the plan), or that a change needs to be made (e.g., there was an error in identifying all activities that needed to be followed to complete the project). Examples of performance measurement techniques include:

December 2004 Page 3- 113 State of Michigan PMM Section 3: Project Planning

Change Management Planning

o Earned Value Analysis – Most commonly used method of performance measurement, which integrates scope, cost (or resource), and schedule measures to help assess project performance. Earned value involves calculating three key values: Planned Value (PV) – Estimated cost, planned to be spent on activities, as of a given point in time; also referred to as the budgeted cost of work scheduled (BCWS); Actual Cost (AC) – Total cost incurred in accomplishing activities as of a given point in time; also referred to as the actual cost of work performed (ACWP); Earned Value (EV) – Value of the work actually completed.

These three values are used in combination to provide measures of whether or not work is being accomplished as planned. The most commonly used measures in which these values are used are: Cost Variance (CV) – Identifies how much the cost of actual project performance varies from the baseline budget, as of a given point in time (CV = EV – AC) Schedule Variance (SV) – Identifies how much actual project performance varies from the baseline schedule, as of a given point in time (SV = EV – PV)

Investigation of the causes of any variances determined to be significant may lead to the identification of a change or the need for a change, either of which should be controlled to ensure that it is properly managed.

These values could be further developed to allow a determination of: (1) how much more it will cost to complete the project, based on performance as of a given date; and (2) based on project performance as of a given date, how much the project will cost, in total.

o Variance Analysis – Compares actual start and finish dates with planned start and finish dates; provides useful information for the detection of variances that may indicate an undetected change or the need for a change. Software packages are available that can perform this analysis quite efficiently.

o Control Charts – Graphic displays of the results of processes over time and against established control limits; can be used to monitor any type of output variable, including cost and schedule variances, errors in acceptance testing, or other management results. Control charts are used to determine whether the process is “in control” or “out of control,” thereby indicating either that an undetected change has occurred, or that the process requires a change to bring it back under control.

December 2004 Page 3- 114 State of Michigan PMM Section 3: Project Planning

Change Management Planning

o Inspections – Measuring, examining, and testing to determine whether or not results conform to requirements; may also be called reviews, walkthroughs or audits. Inspections may be included in a project change management plan to identify areas where undetected changes may have occurred, or where changes are required to apply corrective action.

o Trend Analysis – Monitors performance by using mathematical techniques to forecast future outcomes, based on historical results. This analysis helps determine if the project is heading toward problems, so that they can be addressed either before they occur, or soon after. The causes behind the trends may indicate undetected changes or the need for changes. One or more team members should become familiar with the substantial body of knowledge on trend analysis techniques, in order to make use of it.

Issue Management Issues are problems that, if not addressed, might: • Change the project’s scope • Affect the project’s schedule • Diminish the project’s quality • Increase the project’s cost

Issues differ from risks in that they currently exist, whereas, a risk is a possible future event. Issues are potential sources of problems that could lead to changes, in order to resolve the problems. Therefore, they should be managed in order to ensure that they are addressed promptly, so as to prevent or minimize any negative impact on the project.

A tool that might be useful in capturing and tracking issues is the Issue Log - Designed to provide a mechanism for organizing, maintaining, and tracking the resolution of issues.

Change Tracking Once changes have been identified, it is important to have a plan for tracking changes to ensure that they are properly handled (i.e., agreed upon, approved, and reflected in updates to all of the baselines and plans affected) through implementation. The project change management plan should define the procedures to ensure that:

December 2004 Page 3- 115 State of Michigan PMM Section 3: Project Planning

Change Management Planning

• Changes and their impacts are understood by all who should know (including those who must approve the change, and those who must implement it); • Changes are agreed upon and approved; • All plans and baselines affected by the changes are appropriately updated; • No change proposal is overlooked or forgotten; • All proposed changes are addressed and, if approved, implemented in a timely fashion.

Two tools that might be useful in capturing and tracking proposed changes are:

• Change Request Form – Designed to capture all pertinent information related to a change that should be considered for approval.

• Change Log – Designed to provide a mechanism for organizing, maintaining, and tracking the resolution of all proposed changes.

Project Change The resulting output should be a project change management plan that defines the Management Plan procedures that would:

• Define and protect all control items; • Identify and control issues that may lead to changes; • Identify undetected changes; • Capture and monitor proposed changes; • Identify the need for changes; • Ensure that changes are agreed upon and approved; • Ensure that all affected project plans and baselines are updated as a result of approved changes; • Ensure that approved changes are implemented promptly; • Ensure document and product version control.

Ultimately, the project change management plan should help to ensure that the inevitable changes, which occur within every project, do not have a negative impact on the success of the project.

The Project Change Management Plan Template can be found on the following page, as well as in Appendix B.

December 2004 Page 3- 116 State of Michigan PMM Section 3: Project Planning

Change Management Planning

State of Michigan (Insert Project Name Here) Change Management Plan

A. General Information Information to be provided in this section gives a specific name to the project as well as pertinent information about the personnel involved.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by:

B. Change Management Roles and Responsibilities Describe the roles and responsibilities of the following project roles pertaining to reacting to, documenting, reviewing, approving, implementing, and monitoring changes imposed on this project.

Project Sponsor: Project Manager: Customer/Client Management: Customer/Client Staff: Project Team Leads: Project Team Members:

C. Change Management Governance Explain/describe in sufficient detail, the process for how changes are to be initiated, reviewed, approved, and implemented. Include a flow diagram or other pictorial representation, as appropriate. Include detail to the Project Sponsor level, Project Manager level, Project Team level, and Work Package level. Also, document any level (in amount or percentage) of delegated authority that the Project Manager has with regard to project changes.

D. Capturing and Monitoring Project Changes Describe the method to be employed on this project to capture and monitor approved changes. Also, explain the process to be employed for changing project baselines, including applicable touch points.

E. Communicating Project Changes Describe the proper communications channels for each category of project change, as depicted in the Change Management Governance section.

December 2004 Page 3- 117 State of Michigan PMM Section 3: Project Planning

Project Budgeting

Budget Planning Paralleling the project schedule development is budget planning. Budgeting, Introduction performed at the initial stages of project planning, is the determination of costs associated with the defined activities. The steps associated with budgeting are highly dependent on both the estimated lengths of tasks and the resources assigned to the project.

The relationship of budget planning to the rest of the Planning Phase components is shown in Figure 3.43.

Core Processes Objectives and Scope Activity Definition and Work Project Sequencing Budget Breakdown Schedule Planning Structure Development Resource Planning

Execution Phase Project Facilitating Plan Processes

Facilitating Processes

Procurement Communications Quality Management Management Management Planning Risk Planning Change Planning Management Management Planning Planning

Figure 3.43 Budget Planning Identified in the Planning Processes

Overview of Project Initial budgetary estimates are often based on availability of funds or may be Budgeting dictated by legislation. These parameters may or may not coincide with the actual funds needed to perform the project. For this reason, budget estimates are refined in the Planning Phase until they are baselined at the beginning of the Project Execution Phase.

Budgeting serves as a control mechanism where actual costs can be compared with and measured against the budget. The budget is often a fairly set parameter in the execution of the project. When a schedule begins to slip, cost is proportionally affected. When project costs begin to escalate, the project manager should revisit the Project Plan to determine whether scope, budget, or schedule needs adjusting.

Identify Cost Factors To develop the budget, the applicable cost factors associated with project tasks are identified. The development of costs for each task should be simple and direct and consist of labor, material, and other direct costs. Cost of performing a task is directly related to the personnel assigned to the task,

December 2004 Page 3- 118 State of Michigan PMM Section 3: Project Planning

Project Budgeting

the duration of the task, and the cost of any non-labor items required by the task.

Budget estimates are obtained from the people responsible for managing the work efforts. They provide the expertise required to make the estimate and provide buy-in and accountability during the actual performance of the task.

These team members identify people or labor categories required to perform the work and multiply the cost of the labor by the number of hours required to complete the task, as discussed in Scheduling. Determining how long the task performance takes is the single most difficult part of deriving a cost estimate. The labor costs should factor in vacation time, sick leave, breaks, meetings, and other day-to-day activities. Not including these factors jeopardizes both scheduling and cost estimates.

Non-labor charges include such items as material costs, reproduction, travel, cost of capital (if leasing equipment), computer center charges, and equipment costs.

Create Cost Model Labor and non-labor cost information is entered into a cost-estimation system or spreadsheet, depending upon the complexity of the project. Spreadsheets or the Niku Portfolio Manager Suite work well for projects of small to medium scope. Figure 3.38 is a sample of a budget using a spreadsheet.

Analysis in Hours Analysis in Dollars

WBS Activity Description Res Budget Actual Est to Est @ Variance Budget Actual Est to Est @ Variance # hours hours Complete Complete (+=More) hours hours Complete Complete (+=More)

2.0 DESIGN 2.1 Prepare Preliminary Design 3 900 1,150 0 1,150 250 90,000 115,000 0 115,000 25,000

2.1.1 Develop Enterprise Architecture 400 500 0 500 100 40,000 50,000 0 50,000 10,000

2.1.2 Prepare Data Flow Diagrams 300 250 0 250 (50) 30,000 25,000 0 25,000 (5,000) 2.1.3 Prepare Logical Data Module 200 400 0 400 200 20,000 40,000 0 40,000 20,000 2.2 Prepare Detailed Design 5 1,000 640 408 1,048 48 100,000 64,000 40,8000 104,800 4,800 2.2.1 Prepare Physical Data Model 600 600 8 608 8 60,000 60,000 800 60,800 800 2.2.2 Prepare Data Dictionary 400 40 400 440 40 40,000 4,000 40,000 44,000 4,000 2.3 Document Design 2 430 0 430 430 0 43,000 0 43,000 43,000 0 2.3.1 Develop Design Specification 430 430 430 0 43,000 0 43,000 43,000 0 2.4 Design Review 10 160

Total for the Project 4,820 3,620 1676 5,256 646 466,000 358,000 167,600 525,600 59,600

Figure 3.38 Sample Estimated at Completion Summary

December 2004 Page 3- 119 State of Michigan PMM Section 3: Project Planning

Project Budgeting

For large systems, the Niku Portfolio Manager Suite, or specialized cost management software, is typically preferred for cost estimation. A Project Estimate Summary worksheet is another appropriate model for costing and can be useful if completed prior to entering information into a tool. Tasks included in this sample should be tailored to specific project cases.

Costs should be assigned to the lowest level work breakdown structure work package task. These costs are then combined to determine a subtask cost. In turn, subtask costs are combined to determine the overall task cost, which can be summed to find the total project cost.

Perform Risk Analysis Identifying and quantifying project risk is inherently involved with budgeting any project. Good budgeting practices make allowances for dealing with risk in one or more of the following ways:

• Where significant budgetary risks are identified, add another work breakdown structure task for risk management/risk reduction, where financial reserves can be set aside to deal with potential budget problems. • Budget for those tasks where risks are inherent. There is no rule of thumb for this multiplier; it depends on the degree of risk and the overall importance of the task to the project. • Add a percentage multiplier to the budget where there are risks, especially if new technology is being used or if the person providing the estimate is extremely optimistic. Also, technical staff frequently underestimate the effort required to do any particular task. This could result in serious budget problems during implementation.

Document Assumptions As with developing a project schedule, documenting assumptions made while developing the project budget is critical to the success of the project. Without clear documentation of these assumptions, tracking to the budget is very difficult and risky.

If, for example, a budget assumed that the material would be acquired at one price rate and only substantially higher cost material was available to perform the task, there would be a budget problem. If the assumption is not documented, the project manager may inadvertently increase project cost unknowingly and may unwittingly jeopardize chances for the project’s success.

Review the Cost Estimates Development of project budgets typically requires more than one person. Rarely does a single individual have the knowledge and understanding of all the factors affecting every aspect of a project. A good process is to have the same people who reviewed the activity list and schedule review the budget.

Upon completion of a draft budget, interview the team and determine if the work descriptions, schedule, and associated budgets are complete and accurate. Determine if there is a common understanding of what it costs to do the tasks. Get independent estimates. Where there are significant differences, determine the reasons and either redefine the work packages, schedule, and budgets or review and reiterate the estimates.

December 2004 Page 3- 120 State of Michigan PMM Section 3: Project Planning

Project Budgeting

A large component of the budget is labor costs. Carefully determine that the reviewer is providing an estimate of the calendar time required to perform the task based on the actual labor hours needed. The total labor days per phase can also be checked against the rule of thumb that suggests the following distribution of development of an information technology project effort and cost:

• 40% for planning and design (For small to mid-size projects - approximately10% of the project budget should be earmarked for project management, for large projects - this amount is approximately 5 to 10% of the project budget) • 20% for development • 40% for component and system testing

It is extremely important to get buy-in on the budget from the people who will actually perform the work. Participation results in having a stake in the project's success and fosters accountability. Imposing budgets on staff without a buy-in may result in slippage.

Budget Format The project budget is included in the Project Plan as the Project Budget Estimate. The initial project budget is shown in the budgeted columns and the actual expenditures are compared on a regular basis to the plan.

IT Project Budget Estimate The Information Technology Project Budget Estimate Template can be Template found on the following page, as well as in Appendix B.

December 2004 Page 3- 121 State of Michigan PMM Section 3: Project Planning

IT Project Budget Estimate Template

State of Michigan (Insert Project Name Here) IT Project Budget Estimate

A. General Information Information to be provided in this section gives a specific name to the project as well as pertinent information about the personnel involved.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by:

Labor Labor Material Travel Other Total per Project Task Hour Cost Cost Cost Cost Task

1. Project Design

1.1 Develop Functional Specifications

1.2 Develop System Architecture

1.3 Develop Preliminary Design Specification

1.4 Develop Detailed Design Specifications

1.5 Develop Acceptance Test Plan

2. Project Development

2.1 Develop Components

2.2 Procure Hardware

2.3 Development Acceptance Test Package

2.4 Perform Unit/Integration Test

3. Install System

4. Train Customers

5. Perform Acceptance Test

6. Perform Post Project Review

7. Provide Warranty Support

December 2004 Page 3- 122 State of Michigan PMM Section 3: Project Planning

IT Project Budget Estimate Template

8. Archive Materials

9. Project Management

9.1 Customer Progress Meetings/Reports

9.2 Internal Status Meetings/Reports

9.3 Third-Party Vendor Interface

9.4 Interface to Other Internal Agencies

9.5 Configuration Management

9.6 Quality Assurance

Other:

Subtotals:

Risk (Contingency)

TOTAL (scheduled)

Comments: (List assumptions for costs as appropriate.)

December 2004 Page 3- 123 State of Michigan PMM Section 3: Project Planning

Planning Throughout the Project

Planning Throughout the Planning does not necessarily start or stop within the Planning Phase of the Project project. The following subsections discuss planning throughout the project phases.

Planning in the Initiation In the project’s Initiation Phase, a need that would result in a product is Phase identified. While only very general information may be known about the project at this time, it is important to capture this information for the Planning Phase. In this stage, the focus of planning is on the project definition and on getting the project underway.

A strategy for deriving a solution to the stated goals is important at this point. The problem being addressed by the project is clearly stated, the project goals and objectives are identified, and success criteria for the project are documented. Also, the assumptions, constraints, and risks that apply to the project are defined. Without a description of this initial concept information, the completed Project Plan is difficult to understand. Results of the technology assessment also are documented as a precursor to the technical approach that is later defined.

Planning in the Planning The Project Plan is completed in the Planning Phase of a project. For large Phase projects, this stage may be run as a mini-project with a team of people dedicated to performing the effort. For very small projects, the plan may be developed by a group of people as a part-time job. Because various skill sets are required to complete a successful Project Plan, it is a difficult task for one person to develop the entire plan.

During this project phase, details of the plan are determined and an approach is defined. The full Project Plan is then developed. The plan may include the following elements:

• A brief project summary • A work breakdown structure • A project organization chart • A schedule • An approach • A list of identified risks • An estimated budget and cost • A list of deliverables • A description of planned quality activities • A description of the change management process to be used • A summary of project requirements

Even during the Project Planning Phase, the development of the Project Plan is an iterative process. Each element of the plan is regularly revisited for changes and refinements, based on further analysis and decisions made in developing other plan elements. This refinement also develops buy-in from the project team and stakeholders.

It is critical to get buy-in to the Project Plan from the involved parties prior to actually starting the project. Approval of the plan commits the resources

December 2004 Page 3- 124 State of Michigan PMM Section 3: Project Planning

Planning Throughout the Project

needed to perform the work.

Planning in the Project Planning in the Project Execution and Control Phases consist of replanning Execution and Control when it is determined that the project is not on track with the current plan. This is an iterative process in which the plan (from the Project Planning Phases Phase) is executed and then reviewed and analyzed throughout the Control Phase. If it is necessary to make changes or adjustments, then the plan or plans are revisited.

This might occur for a variety of reasons. It is very important to realize that the Project Plan will change and that replanning is a natural part of the planning process. Replanning does not necessarily mean that a project is in trouble.

Frequent and extensive replanning may, however, indicate that there are some serious issues with the Project Plan. It is better to replan than to simply throw away the original plan and operate without a plan.

Planning in the Closeout A closeout process is performed once the project objectives have been met. Phase Closing a project should be fairly routine, and planning for turnover to operations is necessary here.

December 2004 Page 3- 125 State of Michigan PMM Section 3: Project Planning

Project Planning Transition Checklist

Project Planning Transition In order to transition from the Planning Phase to the Execution Phase of the Checklist project, it is important to make sure that all the necessary plans and documents pertinent to the project in question have been completed. This subsection discusses the process of ensuring that the activities have been finished, reviewed, and signed off so that the project may move into the Execution Phase.

Usefulness of Project A good way to ensure that all start-up tasks are completed prior to actually Checklists starting the project is to develop a transition checklist. The checklist can be developed and then used by others to ensure that the tasks necessary to baseline the project are completed.

A Project Planning Transition Checklist becomes a way for the project manager to organize and communicate tasks that should be completed prior to starting the project. For large projects, some of the start-up tasks could take as long as some of the initial planning steps.

Beyond serving as a communication document, the Transition Checklist can also trigger completion of tasks that the project team might overlook. The Planning Phase is usually characterized as one of impatience. In most cases, it takes a very long time to get the project through the Initiation Phase and actually approved and initiated.

Project Planning Transition The Project Planning Transition Checklist is a combination of an action list Checklist Defined and a tool to verify that necessary steps have been completed. The Transition Checklist should be organized according to the major areas of concern that will determine the project’s success. The Transition Checklist consists of the following components:

• Planning • Organization • Tracking and monitoring processes • Defining what will be tracked and monitored and the format for this information • Reviewing the schedules and formats • Reviewing the change management process and ensuring the assignment of this responsibility • Reviewing the change control process and ensuring that it is institutionalized • Determining how issues will be raised in the project and who will track their resolution • Defining the risk management process • Defining the change management process

The development and use of a Transition Checklist also provides the project team with the tools to ensure that all information has been reviewed and approved. This checklist can also help prioritize the sequence of items to be completed:

• Defining the project environment

December 2004 Page 3- 126 State of Michigan PMM Section 3: Project Planning

Project Planning Transition Checklist

• Completing the project baseline • Identifying project standards and tools • Identifying and refining the roles and responsibilities of the project team members • Setting expectations for the project team • Defining all the project control processes • Obtaining and allocating resources • Initiating project kick-off meeting

Project Planning Transition The project manager owns the Project Planning Transition Checklist, Checklist Creation although in most projects, the full team provides input. In large projects, the development and completion of the checklist might be assigned as an administrative support function.

Format of a Project Planning The format of the Project Planning Transition Checklist can be whatever the Transition Checklist project team defines, but it usually resembles more of an outline than a dissertation. It could be single-line items with space provided to complete the checklist with the current status of an item. Sample answers might be the following:

• Y = Item has been addressed and is completed • N = Item has not been addressed and needs to be to complete the process • N/A = Item has not been addressed and is not related to this project • P = Item has been addressed and some issue resolution is needed to complete the item or annotate it as “N/A”

If the item status information is modified, then the person responsible for the Transition Checklist should ensure that the information is given to the full project team for use.

Each item on the Transition Checklist should also have an area for comments and should note plans to resolve “N” or “P” entries.

The format can also be modified to the requirements of a particular project.

Project Planning Transition The Project Planning Transition Checklist Template can be found on the Checklist Template following page, as well as in Appendix B.

December 2004 Page 3- 127 State of Michigan PMM Section 3: Project Planning

Project Planning Transition Checklist Template

State of Michigan (Insert Project Name Here) Project Planning Transition Checklist

A. General Information Information to be provided in this section gives a specific name to the project as well as pertinent information about the personnel involved.

Project Id: Date: Controlling Agency: Modification Date: Prepared by: Authorized by:

WBS Item Status Comments/ # Plan to Resolve 1 Planning 1.1 Is the project statement -- scope, definition and objectives -- the same as agreed to in the project initiation process and/or in the vendor contract? 1.2 Has the Project Scope Statement been reviewed as part of the baseline process? 1.3 Is there a baseline plan against which to measure progress? 1.4 Does the baseline plan address the following areas: 1.4.1 Project Scope, Deliverables, and Milestones 1.4.2 Work Breakdown Structure 1.4.3 Task Plans, Estimates, Resource Assignments 1.4.4 Task Dependencies 1.4.5 Project Schedule 1.4.6 Milestone Schedule 1.4.7 Project progress tracking 1.4.8 Issue Resolution and Change Management 1.4.9 Quality Plan 1.4.10 Risk Management Plan 1.4.11 Project Organization Other Plans as needed: 1.4.12 Facilities Plan 1.4.13 Documentation Plan 1.4.14 Materials Plan 1.4.15 Training Plan 1.4.16 Back-up and Recovery Plan 1.4.17 Contingency Plan 1.4.18 Cut Over Plan 1.4.19 Warranty Plan

December 2004 Page 3- 128 State of Michigan PMM Section 3: Project Planning

Project Planning Transition Checklist Template

WBS Item Status Comments/ # Plan to Resolve 1.4.20 Transition Plan 1.4.21 Others 1.5 Is the plan for project resources adequate? 1.6 Are the original project schedule and budget realistic? 1.7 Is the plan for the organization of the project resources adequate? 1.8 Are there adequate project control systems? 1.9 Is there an information system for the project? 1.10 Were key project stakeholders brought into the Project Plan? 1.11 Were potential customers involved early in the planning process? 1.12 Was planning completed before the project was initiated? 1.13 Is the plan under configuration management? 1.14 If there are vendors, have they signed off on the Project Plan? 1.15 If there is an independent oversight contractor, have they signed off on the Project Plan? 2 Organization 2.1 Is the project organization documented and on file? 2.2 Is the Project Manager qualified and experienced in Project Management? 2.3 Have roles and responsibilities of the team been documented and clearly communicated to the team, customer, and stakeholders? 2.4 Is the organization structure appropriate for the project’s size and complexity? 2.5 Is there an identified role of a technical leader (i.e., Project Lead, Team Lead, Solution Architect)? 2.6 Is the quality function identified and assigned? 2.7 Is the Project Sponsor function identified and defined? 2.8 Is there a Change Management Board? 2.9 Have the Change Management functions been assigned? 2.10 Are there backup strategies for key members of the project? 2.11 Other Organization items: 3 Tracking & Monitoring 3.1 Are the various types of reports, their contents, frequency, and audience defined and communicated to the project team? 3.2 Are the input requirements from the team members clearly documented and communicated? 3.3 Have the reports to be produced, distributed, and filed been defined? 3.4 Has the format for tracking and monitoring schedules and costs been defined? 4 Reviewing

December 2004 Page 3- 129 State of Michigan PMM Section 3: Project Planning

Project Planning Transition Checklist Template

WBS Item Status Comments/ # Plan to Resolve 4.1 Have the various meetings, the purpose, context, frequency, and participants been defined and communicated? 4.2 What are the defined meeting materials? 4.3 Are the meetings set up to have assigned note takers that will add actions/issues to the issue list? 5 Issue Management 5.1 Is an Issue Management Process documented and filed? 5.2 Is this process communicated to the customer and team members? 5.3 Will an issue form be in use? 5.4 Will all project issues be unconditionally tracked through the issue resolution process? 5.5 Will all tasks resulting from issues be entered into the Project Plan and tracked through the plan? 5.6 Are there processes for unresolved issues to be escalated and resolved within a reasonable timeframe? 6 Change Control 6.1 Will there be a Change Control Process in place? 6.2 Is the Change Control Process documented and on file? 6.3 Will this process be communicated to the customer and project team? 6.4 Will there be a change request form in use? 6.5 Will all project deliverable and software configuration management be changed only through the change control process? 6.6 Will all change requests be unconditionally tracked through this process? 6.7 Will all change requests and current status be logged? 6.8 Will all tasks resulting from approved changes be entered into the Project Plan and tracked through the plan? 6.9 Will new change requests be acknowledged in a timely manner? 7 Risk Management 7.1 Will the project risks being managed be according to the project’s risk management process? 7.2 Will the Risk Plan be updated on a regular and frequent basis? 7.3 Will the Risk Status be reported to management on a regular and frequent basis? 7.4 Will the risk documents be filed? 7.5 Will there be documented contingency plans for the top 5-10 risks? 7.6 Will the Preventive Plans for the top 5 risks be identified, included in the Project Plan, and implemented?

December 2004 Page 3- 130 State of Michigan PMM Section 3: Project Planning

Project Planning Transition Checklist Template

WBS Item Status Comments/ # Plan to Resolve 8 Quality Assurance 8.1 Is there a Quality Assurance Plan documented and filed? 8.2 Are the quality assurance functions and related roles and responsibilities clearly defined? 8.3 Are there completion/verification criteria defined for each task producing an output? 8.4 Is there a process (test plans, inspections, reviews) defined for verifying outputs for each task? 8.5 Will tasks be marked “complete” only after QA has been successfully completed? 8.6 Will there be a formal process for submitting, logging, tracking, and reporting items undergoing QA throughout the submit-test-rework-resubmit-retest cycle? 8.7 Will statistics related to QA be collected, trends analyzed, and problems raised as issues? 8.8 Will the QA related information be reported regularly as part of the Status Reporting mechanisms? 8.9 Has a method and process for requirement tracking been developed?

B. Signatures The signatures of the people below relay an understanding that the key elements within the Planning Phase section are complete and the project team is ready to transition to the Execution Phase.

Name/Title Signature Date

December 2004 Page 3- 131 State of Michigan PMM Section 3: Project Planning

Information Technology Components for Project Planning

Information Technology Project Planning is the most important phase of any type of project, Project Planning including information technology projects. It is during this phase that the document baseline and processes that will be used to guide all the work to be done in the project will be created. Being able to manage communication, budgets, risk, and the other assorted project management competencies is of infinite importance because these processes create the infrastructure that allows technical project staff to commit themselves to producing quality documents and deliverables.

The table below relates the System Development Life Cycle (SDLC) deliverables to those of the Project Management Planning Phase. While the intent of this methodology is to focus on the development of the project management competencies, it is nonetheless important to note that the interrelation of these two life cycles is important to the success of the project. The project planning documents will feed off the information provided in the SCLC deliverables.

System Development Life Project Management Planning Phase Cycle Methodology Deliverables Deliverables • Project Scope Statement • Work Statement • Critical Success Factors • Requirements Documents • Work Breakdown Structure

e • Solutions Documents • Cost-Benefit Analysis

as

h • Specifications Documents • Resource Plan

P • Design Schedules Project Schedule

g •

• Detail Design Documents • Risk Plan

• Procurement Plan Plannin • Quality Plan • Communications Plan • Change Management Plan • Project Budget Estimate • Project Planning Transition Checklist

A review of the Project Management Methodology, reveals that the deliverables of the Project Planning Phase build upon each other. For instance, the Project Scope Statement defines the work breakdown structure, which in turn provides input to the Resource Plan and budget estimate. Ultimately, the sum of all of these elements creates the Project Plan from which the whole project flows. None of these documents can be created in a vacuum and none can be created without the input from the technical staff creating the SDLC deliverables.

The role of project management, however, is once again about responsibilities. The project manager is responsible for initiating, planning, executing, controlling, and closing as opposed to being involved with the technical development of the product itself. The remainder of this section explains what project managers need to do to ensure that the project management objectives are reached during the Planning Phase of an information technology project.

December 2004 Page 3- 132 State of Michigan PMM Section 3: Project Planning

Information Technology Components for Project Planning

Information Technology The Information Technology Project Scope Statement is intended to be a high-level document that outlines the following: Project Scope Statement • Project Results/Completion Criteria. What will be created in terms of deliverables (and their characteristics) and what constitutes a successful phase completion. • The Approach to be Used. What type of process or technology will be used, whether the project will be done internally or externally, etc. • Content of the Project. What will and will not be included in the work to be done.

In this respect, IT projects are no different than any other project. There is no need to have the level of detail in a Project Scope Statement that a formal Requirements Document includes. While the Information Technology Project Scope Statement makes reference to technology issues (such as the technology to be used), it is not intended to be a technical document. The audience of the Information Technology Project Scope Statement is interested in what will be achieved, rather than what the technical requirements will be to carry out the project.

The same holds true for project specifications documents. At this point in the specifications documents, the project staff is detailing the granular bits of information and outlining a level of specificity not necessarily needed at the project management level. Although it is advisable that the project manager be aware of the technical requirements and specifications of the project, this does not necessarily mean that it is the project manager’s responsibility to create and manage their development personally.

A management-level understanding of the technology requirements and specifications is the expectation for a project manager. Remember that the project manager’s responsibility is to provide management and guidance to the process—not to create the technical deliverable.

Further definition of the Project Scope Statement can be found in the Project Objectives and Scope subsection within this section. In addition, a Project Scope Statement Template is available in Appendix B.

Information Technology The work breakdown structure is one of the most important pieces of the IT Work Breakdown Structure project process. IT projects are by their nature complex and typically require many different skill sets. The WBS takes the activities and tasks that need to be accomplished and breaks them down to their lowest element, which is known as a "work package". These work packages will help define the skills and resources needed to deliver a successful IT project. In addition, IT projects typically have a life of their own and are different from the normal WBS because they will call on specialized skills required in the SDLC.

A good idea to keep in mind during the development of the WBS is to identify the major phases of the SDLC as they apply to the project and identify what must be done to achieve completion of those phases. This is done by meeting with the responsible organizations for the SDLC phases and activities.

A detailed description of the WBS (as well as some hints to assist the project

December 2004 Page 3- 133 State of Michigan PMM Section 3: Project Planning

Information Technology Components for Project Planning

manager in creating it) are available in the Work Breakdown Structure subsection of this section. Additionally, Figure 3.45 provides an example of a simple high-level Information Technology Work Breakdown Structure for review.

Information Technology Cost Cost-Benefit Analysis (CBA) is one of the areas where IT projects differ Benefit Analysis slightly from other projects, but the intention and result remain constant. The technical side of the analysis considers the trade-off of applying one technical approach versus another. There are usually several technology options available to all projects. The rate at which technology is changing and improving has a dramatic impact on the cost and reasonability of using selected technologies. Therefore, the project manager must be aware of the cost implications of comparing one technology to another when performing a CBA.

The fact that there are competing technologies adds another dimension to the CBA. The decision is no longer limited to the question of whether an agency can or should take on a project. The additional information that must be considered is the decision to implement one technology over another. This type of information is usually compared in a technical trade-off analysis, but, in fact, each technical trade-off made will most likely have a financial impact on the cost of the project itself and consequently will affect the CBA. In short, the project manager may find that doing a project is not beneficial or possible because the cost of the technology needed to develop or create the deliverable reduces the overall benefit to the agency itself.

For example, a cost driver such as the expense to purchase an enterprise license for a software package may be too steep to justify the benefit of a project, or the purchase may produce the additional expense associated with bringing agency staff up to a level to support the project deliverable. A detailed description of the CBA is available in the Cost-Benefit Analysis subsection in this section and in Appendix B.

Information Technology Once the tasks and activities have been defined, a Resource Plan will need to Resource Plan be created. This plan will include the technically skilled labor resources of the team and will define the actual management structure of the project. Furthermore, a defined set of non-labor resources can be identified as a result of review of the work breakdown structure. Resources on an IT project may include but not necessarily be limited to people, computers, hardware, software, tools, and facilities.

Skills and resources within an IT project are very important, and the WBS created by the project manager (not the technical staff) goes a long way toward pinpointing the necessary skills needed on high technology projects. With the vast array of technology applications and varying levels of knowledge in such areas, knowing what skill sets and resources will be needed ahead of time will be critical information for project success.

For instance, if a project manager knows that on a particular task a senior programmer will be needed for five days to code a module, it is critical to point this out to the functional manager responsible for the needed senior programmer and make sure that the programmer will be available during the

December 2004 Page 3- 134 State of Michigan PMM Section 3: Project Planning

Information Technology Components for Project Planning

specified time within the project. It is unlikely that in a situation such as this the skill sets of senior programmer could be replaced by the application of two junior programmers at the same time. Project managers have the responsibility to request specific skill sets and schedule their availability. It is the responsibility of the technical personnel to do the technical work when the time comes. In this instance, the project manager’s foresight, determination of needs, and eventual management actions will have a huge impact on the success and completion of the project.

Skill sets and their availability also have immediate impact on the duration estimates of activities and tasks. Being able to determine the difference in duration for an individual with a certain technical skill level versus one with another skill level can be a mind-bending experience. Knowing the capabilities of the project staff and determining the duration of the project activities given to them is critical.

In addition, the project manager must be able to discern from the discussions with the staff what the sequencing of the tasks will be. Realizing what tasks can be done in parallel and what tasks must be done in sequence will be crucial as the project manager attempts to create the project schedule. Only by careful analysis, planning, and asking the right questions will the project manager be able to determine the demands of the project.

Information Technology Technology programs are especially time sensitive. As mentioned before, Schedule Development special skill sets needed within the project may only be available at certain times. It is also important to note that outputs from a particular segment of an IT project are often the inputs to other sections or deliverables of the project. IT projects may have many different dependencies and relationships that may not be obvious to the project manager. Therefore, it is important that the functional manager involve the technical team when attempting to determine the project task durations.

Keep in mind, while planning a project and developing a schedule, that certain concessions and considerations must be incorporated for the technical problems that may occur. Technical problems and requirement changes are common inputs to IT project risk. Different elements of risk, such as the use of new or unproven technology, hardware or software delivery schedules, and the changing cost of technology, can all have a dramatic impact on an IT project as well. Thorough risk analysis, which is discussed later, on these and other factors cannot be stressed enough.

Using the Niku Portfolio Manager Suite (or creating a resources matrix) can also be very helpful in managing and monitoring resource utilization and schedule progress. Knowledgeable use of Gantt charts and similar graphical aids can improve visibility and readability for all levels of project stakeholders.

Information Technology Risk As noted, risk is inherent in all parts of the Information Technology Project Planning Planning Phase. Scope risk brings up the possibility of having to do additional work not previously identified to complete a project because the project was still unclear at the beginning of the Project Planning Phase. Resource risk deals with being able to find and retain at reasonable prices the

December 2004 Page 3- 135 State of Michigan PMM Section 3: Project Planning

Information Technology Components for Project Planning

resources needed to accomplish a project during the time they are needed. Schedule risk revolves around the uncertainty in the length of time it will take to perform an activity that has never been attempted within the agency. Budget risk manifests itself in the uncertainty of labor and non-labor asset costs.

All these are areas that have potential to slow down, stop, or kill a project if the impact is severe enough. That having been said, project managers, along with their staff, must plan to identify as many of the known risks as they can before project execution takes place. Next, they will have to determine the likelihood of the event taking place and plan preventative measures. There are different types of contingencies and contingency reserves for different types of risk.

Preventative measures for schedules can take the form of slack built into the project schedule. Similarly, an additional budget category titled "Management Reserve" can be created as a budgetary contingency. Regardless of how the risk is expressed, it cannot be ignored. Project managers must use their experience, knowledge, common sense, and project staff to plan effectively. These things, with the association of usable and scalable risk tools, will go a long way toward planning against project risk.

Project risk is described in greater detail in the Risk Planning subsection of this section. A Project Risk Plan Template is available in Appendix B.

Information Technology The IT quality planning process identifies the procedures and activities that Quality Planning the project team defines, plans for, and executes for quality management. It is recommended that a quality model be established and maintained by each state agency, and this model should describe the detailed quality procedures that are used for information technology.

The state agency’s quality model should be based on standards and procedures that enable the quality manager to ensure quality throughout the life of the project.

Information Technology It is interesting to note that communications planning and infrastructure is a Communications Planning very important component of successful IT projects. Consider the number of technical disciplines that may need to be involved with developing and executing a project. Often, the staff members who harbor needed technical skills come from different functional areas within an agency. Although the project should ideally be structured according to a matrix format (see Project Management Overview Section—Roles and Responsibilities), there is still quite a bit of communication that must take place between the project manager and the functional managers. A solid Communications Plan can help outline this process.

In addition, the scope of the Communications Plan reaches much further than the team that is working on the project itself. There are several stakeholders, including the customers, agency management, vendors, contractors, and other agencies (to name a few), who need to be considered when vital project status updates or information needs to be disseminated. The Communications Plan for the IT project needs to take all of the stakeholders

December 2004 Page 3- 136 State of Michigan PMM Section 3: Project Planning

Information Technology Components for Project Planning

into account. Each stakeholder has different information needs, and the frequency at which they receive them will be different as well.

Discussion on project communications planning is contained in the Communications Planning subsection of this section. Example Status Report Template and the Communication Plan Template are available in Appendix B.

Information Technology It must be reiterated that working with IT projects involves skills similar to Project Budgeting non-IT projects, but with much more attention paid to risk caused by diverse and changing technology. There is no area for which this is more true than when creating cost estimates and preparing project budgets.

Preparing a budget for an IT project is much the same as for any other project with respect to the steps taken in the approach. There are different types of cost factors, however, that may be associated with an IT project. For example, when working with new or developing technologies on an IT project, there may be cost factors such as subcontracting for services or skills not normally needed because the skills may not be immediately available from within the agency.

Furthermore, the cost of materials such as hardware and software are changing on a daily basis. Advances in technology and competition within the marketplace can affect prices on equipment and services dramatically from the time a Project Concept Document is created to the time the budget estimate is drafted to the time funds are spent on the project itself. The business and technology environment and the factors affecting it are the type of issues that a project manager must be aware of at all times.

Because of the issues described above, risk runs rampant in IT project budget estimating. The cost estimates should all be reviewed by the subject matter experts who are available within the agency and within the financial area as well. There are also several ways of obtaining information on costs for technology and services, such as databases and vendor contract pricing schedules. When possible, plan enough time to research your alternatives thoroughly for both labor and non-labor needs. Making quick or hasty decisions often means additional cost.

Detailed explanation and discussion of cost estimation and budgeting is available in the Project Budgeting subsection in this section. A Budget Estimate Template is available in Appendix B.

Information Technology As has been stated many times throughout this subsection, IT project Planning Summary management is not all that different than “normal” project management. IT projects are technical and therefore need a different process, such as the SDLC Methodology, to support them. Keep in mind that IT project management is not about creating the technical requirements, specifications, or deliverables, but developing a process to make the whole effort easy to manage. Project management is about planning. To quote Peter Drucker, “Plans are worthless but planning is invaluable.”

December 2004 Page 3- 137 State of Michigan PMM Section 3: Project Planning

Sample Information Technology Work Breakdown Structure

WBS TITLE RESPONSIBILITY DICTIONARY DESCRIPTION STATUS ELEMENT IT Project

Project Management Project Control This element includes project planning, checking project status, issue tracking and management, reporting, and cost management. Requirements This element includes managing system requirements. Management Configuration This element includes providing CM products and services for the project. Management (CM) CM Plan This element includes developing the CM plan including procedures for baseline identification, change control, status reporting, and conducting CM audits and reviews. CM Services This element includes conducting CM activities described in the CM plan and obtaining requisite CM training required to perform CM functions. Risk Management This element includes providing risk management products and services to the project. Risk Management Plan This element includes developing the risk management plan. It does not include maintaining the plan. Risk Management This element includes providing risk management services to the project, Services including maintenance of the risk management plan. Quality Management This element includes providing quality management products and services to the project. Contract Management This element includes providing contract management services to the project. Performance Measurement Project Performance This element includes identifying project performance measurements and Measurement Plan documenting the approach and mechanisms to validate performance against project and organization objectives. Project Performance This element includes the activities required to capture and report Report performance results against project and organization objectives.

Systems Engineering This element includes systems engineering products and services to be delivered for the project. Technical Alternatives This element includes a study of alternatives for implementation including Study technical, cost, and schedule options. Systems Architecture This element includes overall systems architecture documentation including Document hardware, systems and application software, database (DB), and local area network/wide area network (LAN/WAN). Backup and Recovery This element includes developing and documenting backup and recovery Procedures procedures for data, application, and replication servers and client systems (as required) to ensure full operation of the system. Database Management This element includes all activities related to DB design and management. Logical DB Model This element includes developing version 1.0 of the logical DB model. Physical DB Model This element includes developing version 1.0 of the physical DB model, including the data dictionary. Physical DB Structures This element includes developing and maintaining physical data structures. DB Services This element includes coordinating DB changes with other projects as part of change control activities, supporting analysis and design activities related to DB models, writing SQL scripts, performance tuning as required, and updating logical and physical data models as a result of approved changes.

Hardware and This element includes hardware and commercial-off-the-shelf (COTS) or Software developed software elements to be delivered on the project

Hardware This element includes hardware to be procured or modified to support the project. Development/Test This element includes procuring, installing, configuring, and testing the Environment development and test environments (if these activities will not disrupt the environments and both environments are supported on the same machine).

December 2004 Page 3- 138 State of Michigan PMM Section 3: Project Planning

Sample Information Technology Work Breakdown Structure

Operational This element includes modifying or procuring operational hardware required Environment for the project. It does not include installing or testing the hardware.

Data Servers This element includes modifying or procuring operational data server hardware required for the project. It does not include installing or testing the hardware. Application Servers This element includes modifying or procuring operational application server hardware required for the project. It does not include installing or testing the hardware. Client Hardware This element includes modifying or procuring operational client hardware required for the project. It does not include installing or testing the hardware. Replication Servers This element includes modifying or procuring operational replication server hardware required for the project. It does not include installing or testing the hardware. Communications This element includes procuring or modifying communications technology Infrastructure for WAN capabilities for the project.

Software This element includes procuring or developing COTS software for the end- user system or development tools and the analysis, design, coding, and unit testing of developed software. COTS This element includes all COTS development software, system software, and application software. COTS Operational This element includes procuring COTS software for the operational Software environment. It does not include installation, configuration, or test activities. Replication Software This element includes procuring COTS replication software. It does not include installation, configuration, or test activities.

COTS Development This element includes development software directly supporting design and Software coding activities.

Developed Software This element includes analyzing, designing, developing, and unit testing software products. Software Development This element includes developing the SDP, which defines software Plan (SDP) development activities and the management approach to control them.

Functional This element includes analyzing, documenting, and approving the system's Requirements functional requirements. Document (FRD) Preliminary Design This element includes analyzing, documenting, and approving the system's Document preliminary design. Detailed Design This element includes analyzing, documenting, and approving the system's Document detailed design. Interface Control This element includes developing and maintaining the ICD, which provides Document (ICD) detailed information on all required system interfaces. Source Code Elements include actual code development and unit testing activities.

Test Elements under this section include system, integration, software quality assurance (SQA), acceptance, pre-production, and beta site testing activities. Test Plan This element includes documenting the strategy and detailed plan to perform system, integration, SQA, acceptance, pre-production, and beta site testing. Test Procedures This element includes creating and documenting detailed procedures to test all requirements defined in the FRD. Test Results This element includes activities related to conducting tests and documenting results to ensure all requirements have been formally tested.

Training Elements under this section include training activities related to planning and training design, course material development, delivery, and support items as required to conduct system administration, end-user, and programming support training. Training Plan This element includes documenting the strategy and detailed plan to deliver training components for the system. Training Design This element includes designing and documenting system administration Documents and end-user training.

December 2004 Page 3- 139 State of Michigan PMM Section 3: Project Planning

Sample Information Technology Work Breakdown Structure

System Administration This element includes designing and documenting system administration Training Design training. Document End-User Training This element includes designing and documenting end-user training. Design Document Training Materials This element includes developing system administration and end-user training course materials. System Administration This element includes developing system administration training course Training Materials materials.

End-User Training This element includes developing end-user training course materials. Materials Training Course This element includes conducting system administration and end-user Delivery training courses. This element includes all travel and costs associated with delivering training. System Administration This element includes conducting system administration training courses. Training Delivery This element includes all travel and costs associated with delivering training.

End-User Training This element includes conducting end-user training courses. This element Delivery includes all travel and costs associated with delivering training. Technical Training This element includes training technical project team members as required.

Training Facilities and This element includes acquiring training facilities and equipment and Equipment ensuring they are ready for use.

Data Conversion This element includes activities required to convert existing data to the new environment including beta and other operational sites.

Data Conversion Plan This element includes developing a plan to convert the data from the original system to the target system. This plan will incorporate all activities required to effectively convert the system and ensure the data is converted properly. Conversion Software This element includes COTS or developed software utilities required to convert existing data. Conversion Data This element includes executing conversion routines, manual data converting, and data loading converted data onto the target data server(s).

Site Implementation This element includes developing and documenting a plan to implement the system at beta and operational sites. Implementation Plan This element includes defining a plan to implement the target environment into required beta and operational sites. The plan will incorporate all activities required to effectively implement the system at selected sites including proven integration with training and data conversion activities. Additionally, this element includes planning and conducting beta test activities. Implementation This element includes developing and documenting detailed procedures Procedures required to install the system at beta and operational sites. Included are detailed procedures to install data, application, and replication servers, as well as configuring client technology for proper connectivity to the system. Site Surveys This element includes site surveys to ensure requirements to support the system are identified and documented. Beta Site This element includes implementing the system at beta sites. Included is Implementation installing and testing all hardware and required software to support the system. Operational Site This element includes implementing the system at operational sites. Implementation Included is installing and testing all hardware and software required to operate the system.

Figure 3.39 Sample Information Technology Work Breakdown Structure

December 2004 Page 3- 140 State of Michigan PMM