california project management methodology express/participant ca-pmm express.pdf3.2.1 refresh the...

CaliforniaProject Management

Methodology

Knowledge Structures, Inc.(916) 488-6075www.ksinc.com

PMI Registered Education Provider Number 1334Program Number 00012

Objectives• At the conclusion of this session each

participant will be able to:– Describe the CA-PMM

– Navigate and complete the Concept Toolkit

– Navigate and complete the CA-PMM Toolkit

– Describe the OCIO policies regarding the use ofthe CA-PMM

The approach that will be described in this course is “scalable” to projects of any size. The selection of theprocesses to be used on any project, and the depth to which they are applied, is the responsibility of theproject manager. What is important is that each element is carefully considered for the project at hand.However, the OCIO has created a policy that provides sizing guidelines. Processes are appliedaccordingly.

Common project management vocabulary can facilitate communication when used consistently across allprojects in an organization.

IT Policy Letter 09-01• Purpose: CA-PMM serves as the state’s IT

project management standard

• Background: May 15, 2008 SupplementalReport of the 2007 Budget Act Item 0502-001-9730 1

IT Policy Letter ITPL 09-01 dated April 9, 2009 introduced the policies relating to and implementation ofthe California Project Management Methodology. ITPL 09-01 includes the purpose, background, policy,State Administrative Manual (SAM) and State Information Management Manual (SIMM) changes, andcontact information relative to the CA-PMM.

In the May 15, 2008 Supplemental Report of the 2007 Budget Act, section 3.0 IT Project Managementspecifies the mandate for refresh of the project management methodology outlined in the StateInformation Management Manual which was originally created in 1997. Specifically, section 3.0 of thereport includes:

3.0 IT Project Management

3.1 Establish Enterprise Program Management Office

3.2.1 Refresh the California Project Management Methodology

3.2.2 Establish CA-PMM as the Project Management Standard

3.3 Establish Project Governance Structure

3.4 Establish Qualifications for Project Managers

Policy• CA-PMM Toolkit Implementation

• IT Project Complexity

• Status Reporting

• CA-PMM Training Requirements

• Scheduling Software

• Use of Additional or Supplemental ProjectManagement Tools

Role of the OCIO: …full responsibility and authority for

• Advising the Governor on the strategic management and direction of the state’s informationtechnology resources.

• Establishing and enforcing state information technology strategic plans, policies, standards andenterprise architecture.

• Minimizing overlap, redundancy and cost in state operations.

• Coordinating activities of agency information officers and the Director of Technology Services.

• Improving organizational maturity and capacity in the effective management of informationtechnology.

• Establishing performance management and ensuring state information technology services areefficient and effective.

• Approving, suspending, terminating and reinstating information technology projects.

Methodology Framework

ITPP

Concept Initiation Planning Executing Closing

Project Concept Project CharterProject

Management Plan

FSR and /or other Project Approval

Documents (e.g. , APD , IJP , BCP)

Analysis Design Build Test Implement

System Development Life Cycle

Procurement

Project Management Life Cycle

Project

Management Life

Cycle

Project

Management Life

Cycle

Project

Management Life

Cycle

Project

Management Life

Cycle

Project

Management Life

Cycle

Project Approval Life Cycle

Procurement Life Cycle

There are many life cycles in use within an IT project. The CA-PMM addresses ONLY the projectmanagement life cycle.

CA-PMM

The CA-PMM represents the minimum standard for project documentation. It is the mission of theOCIO PMO to review project documentation to insure that projects are being initiated, planned, andexecuted with a thoughtful, consistent management approach.

The level of documentation required by the OCIO will vary slightly depending on certain projectcharacteristics. We will discuss those guidelines in a moment.

The diagram on the above slide shows the first three stages of the CA PMM Project ManagementLifecycle. Note that each stage has a set of one or more key tasks that must be done to produce the majoroutput of each stage.

The green triangles represent the stage gate that must be hurdled to move from one stage to the next.Typically those stage gates are in the form of a formal review by the sponsor or steering committee. Theblue triangles point to the major output of each stage.

Also note the stage that floats above Initiating and Planning: Monitoring and Controlling. Once a ConceptStatement has been approved, and Initiating has begun, we begin to monitor and control the project. The“stage” of Monitoring and Controlling runs in parallel with all of the other stages from the start to thefinish of the project.

CA-PMM

The diagram on the above slide shows the final three stages of the CA-PMM. Again, note that there arekey tasks in each stage.

We will explain the particulars and importance of these key tasks as we move through the program. Thecompletion of most of the key tasks are supported by a template. We will work with these templates tomake sure that you will be able to use them once you are back on the job.

CA-PMM and External Approvals

Minimum Criteria for an IT Project?• Consumes at least 500 hours of effort• Provides an IT solution to a business

problem/opportunity• Is a unique effort• Has a start date• Has a target finish date• Has defined objectives• Has named deliverables• Has a defined budget and resources

Your Project• Business problem or opportunity

• Duration

• Multiple human resources

• All team members can be engaged

• Cannot be completed or underway

• PM must have 100% attendance

Select a project using the following criteria:

• The project must be work related.

• Can be a real project or one you would like to do.

• Cannot be an exact duplicate of a project you have done before or the execution of anestablished process or procedure.

• The project must use multiple human resources.

• The anticipated project duration should be at least a year.

• Then discuss your proposed project with your team. The team will then choose one project towork on for the remainder of the class.

• The person whose project is selected is expected to have 100% attendance in this class.

The project manager on your team will be asked to give a 1-2 minute description of the project to theclass.

Proposed project: ____________________________

Project manager: _____________________________

CA-PMM Toolkits• Concept Toolkit

– Concept Statement– Size Estimating

• CA-PMM Toolkit– Project Information– Plan Updates– Template Inventory– Main Menu

Initiating Planning Executing Closing Acronyms

Toolkit ReadMe File• Microsoft Excel® Basics• Getting Started• Toolkit Contents• Workbook Navigation• Using the Workbook• Saving and Exiting• Printing• Contact Us

Concept Stage

Concept

1. Project Concept Statement2. Size Estimate

Concept Statement*

CA-PMM Concept StageThe Concept Stage communicates high-levelinformation about a project idea.

*The Concept Statement is used in the IT Capital Plan and is provided to the OCIO.

In this section, we begin our journey through the CA PMM Project Management Lifecycle. Knowledge ofthe stages will help you to define a path through a project from concept to successful implementation.

In each of the stages, we examine individual steps in detail. You will practice many of the steps in theclassroom using the project that you just selected.

We begin with Concept.

In the Concept stage of a project, ideas for a proposed project go through due diligence to identify, at ahigh level rather than in great detail, their potential value, their alignment with organizational strategy,and whether they overlap with other existing or proposed projects.

Concept Statement Content• Description• Need Statement• Benefit Statement

– Tangible– Intangible

• Consistency• Impact to Other Agencies• Solution Alternatives• Recommendations• Project Approach

The start of a successful project is a clearly articulated statement of the project idea by the customer. Thisshould include a high-level statement of:

• A brief description of the project

• The need for the project

• The benefits to be derived from the project both tangible and intangible

• The potential impact on other agencies

• Alternative ways of meeting the recognized need or of achieving the desired benefits

• A recommendation about whether to proceed

• The approach to the project, if known

If approved, the Concept Statement becomes the basis for serious consideration of the project.

Exercise• Complete the following sections in the

Concept Statement for your project:– Description

– Need Statement

– Benefit Statement

– Solution Options (Solution Alternatives)

– Conclusion (Recommendation)

– Project Approach (if known)

• Timing: 20 minutes

Size Estimating• High-level estimate of:

– Effort

– Duration

– Cost

– Resources

This is a one-time sizing estimate produced at the Concept phase for decision-making purposes andproject prioritization.

This model is optional, however, a sizing estimate MUST be produced.

A size estimate is a high-level estimate of the proposed project in terms of the overall effort, cost, andduration (total hours, work days, weeks, or months).

It is useful, and usually considered essential, for strategic concerns such as project approval, portfolioassessment, and resource needs.

There are various methods for making a size estimate. We will introduce one such method in thefollowing slides.

Effort Distribution Estimating• Developed during the Concept Stage

• Supports management decision making

• Does not have a high level of accuracy

• Relies on historical data

Effort Distribution Estimating considers the proportion of effort needed on similar projects as an indicatorof the effort that will be distributed on the current project.

Effort Distribution Estimating is used to develop a high-level estimate, or Rough-Order-of-Magnitude(ROM) estimate, of a proposed project’s size or duration.

It is used to support management in the decision to proceed further with a project idea to the point ofapproving a Project Charter, or not. Typically, it is then incorporated into the Project Charter.

This type of estimating is suitable for use in projects or project phases that are:

• Based on a well-defined and consistently used lifecycle methodology.

• Medium to large in size, that is, with a duration of six to 12 months. Longer projects should bedivided into sub-projects that are small enough to estimate within a six-to-12-month time frame.

The term Rough Order of Magnitude (ROM) if often used and is generally accepted to have a range of -50% - +100%.

Effort Distribution Estimating is best suited for developing size (ROM) estimates for medium to largeprojects that have a well-defined and consistently used life cycle methodology. The method is not suitablefor projects introducing new or emerging technologies, but it can be suitable for major enhancements suchas software upgrades, network expansion, etc. You must have past organizational experience/history touse the Effort Distribution Model. This approach is best applied to:

• Medium to large projects

• Well-defined lifecycle methodology

• Not suitable for new or emerging technology projects

• Suitable for major enhancements

Effort Distribution Estimating StepsStep 1a: Select a Phase-Based Model

Step 1b: Calibrate the Model

Step 2: Identify a Base Phase

Step 3: Develop Effort Estimate for the Base Phase

Step 4: Compute Total Project Hours

Step 5: Extrapolate the Effort of Each Remaining Phase

Several steps are needed to create a credible size estimate based on effort distribution. These aresummarized on this and the next slide, and explained in the several slides that follow.

The first few steps include:

• Create or select a project model of containing phases that correspond to (are the same as) thecurrent project. The project model can be based on the experience of the PM, other teams ormanagers in the organization, historical data about other projects completed in the organization, orindustry data.

• Include all phases in the project model along with their base percentage, which represents theproportion of effort in each phase. (For example, the Design phase represents 20% of total projecteffort.)

• Calibrate the model, that is, adjust it to fit the specific characteristics and needs of the currentproject being estimated.

• Select a base phase, or combination of base phases, to estimate in detail. Bootcamp Class: Use aWBS to form a basis for computing estimates for the remaining parts of the project.

• Extrapolate the effort estimates for the remaining project phases.

Steps - continuedStep 6: Compute Phase Work Months

Step 7: Develop Resource Estimate

Step 8: Compute Duration

Step 9: Prepare Phase-Based Gantt (high-level)

Step 10: Estimate Cost

Next, using the data estimated or extrapolated for each phase estimate:

• Develop an estimate of the number of full-time resources that will be needed to complete eachphase.

• Estimate the duration of each phase with reference to an optimal or expected number of resourcesthat will be available to do the work.

• Prepare an overview of the project schedule on a high-level Gantt chart showing project phases.

• Estimate the cost of phases and the total project.

Step 1: Phase-Based Model• Reflects how effort is distributed across

phases

• Is based on any of the following:– Organizational historical data

– Personal history and experience

– Another project team

– Industry data

– Vendor supplied data

Remember that historical data from comparable projects or industry sources is needed. And, this aproachis not appropriate for use with new or emerging technologies.

15%Implementation6

5%Transition to M&O7

10%Test5

30%Development4

20%Design3

15%Analysis2

5%Procurement1Model %Phase Name

PhaseNumber

Step 1a: Phase-Based Model

Total = 100%

In this example, procurement uses 5% of the total project effort, Analysis 15%, Design 20%, and so on.Note that the total of the phase percentages equals 100%

15%Implementation6

5%Transition to M&O7

15%Test5

30%Development4

25%Design3

15%Analysis2

5%Procurement1

Model%Phase Name

PhaseNumber

Step 1b: Model Calibration

Total = 110%

In this example, the historical model has been calibrated to match the current project. The project manageror estimator has determined that the Design and Test phases will require more than the usual amount ofeffort. Note that in the calibrated model the total of the phase percentages exceeds 100%.

This model should be calibrated based on your organization’s life cycle and history.

Step 2: Select Base-Phase• The Phase most familiar to you

– Minimum of 15% of total project effort

– Ideally at least 30%

It is essential to select a Phase, or Phases, that represent at least roughly one-sixth to one-third of totalproject effort. Otherwise, the extrapolation of total project effort would be made from too small of a baseand the resulting estimate would not be credible.

Step 3: Estimate Base-Phase Effort• Create a work breakdown structure of the

base phase

• Develop effort estimates to complete thebase phase using task-based estimates

The next step is to develop a detailed estimate of effort hours for the base phase(s). The most accuratemethod of estimating is task-based estimating in which the work of the project is broken down to a levelof detail sufficient to make a reliable prediction of how much effort will be needed to complete each task.

TotalProjectHours=%÷

EffortEstimate%Base Phase

28333.30÷850030%Development

Step 4: Total Project Hours

In this example, detailed task estimates have been completed for both the Development Phase. The totalestimate, 8500 hours, becomes the basis for extrapolating the total estimate for the entire project (8500divided by 30% = 28,333 hours). In the next slide we will see that the remaining project phases areestimated according to the respective percentages of total project effort.

1417.05283335%Procurement

1417=.05*283335%Transition to M&O4250.15*2833315%Implementation

Total Estimated Hours 31,167

4250=.15*2833315%Test8500=.30*2833330%Development7083=.25*2833325%Design4250=.15*2833315%Req. Analysis

EffortEstimate=%*

TotalProjectHours

%Phases

Step 5: Phase Effort

The effort estimate for each historical phase is the product of the multiplier X the project total, forexample, Procurement = 28,333 X .05 = 1417 hours.

Design and Test were calibrated at 110%, so the total is based on the calibrated model.

Note that the Total Estimated Hours is slightly different from the Total Project Hours. This is due torounding and is not a cause for concern.

Step 6: Phase Work months• Productive hours per work month/FTE

– Prod Hours/Day * Prod Days/Month

• Example:– 6.5 * 19 = 123 hrs Per Month

The next step is to determine the number of productive work hours required per month from a dedicatedfull-time employee. The productive hours per month will vary depending on the productivity environmentof the project. This is typically computed by multiplying the average productive hours per day by theaverage workdays per month.

In this example, it is estimated that project team members will devote 6.5 hours per day to project workand that there will be on average 19 working days per month, for a monthly average of 123 working hoursper month.

That number, 123, is the number that will be used calculate the number of months of effort required foreach phase of the project.

In this example, the project manager has used a constant rate of productive hours for all project phases.But, especially on projects lasting more than three months, the productive value (hours worked permonth) may vary seasonally, such as during summer or year-end holiday periods.

It is important to establish a realistic number of productive hours per month, one that reflects the actualconditions in the organization and not what someone would like the numbers to be.

You can unprotect and modify days/year or hours/day.

69.1=123÷8500Development

11.5=123÷1417Transition to M&O34.6=123÷4250Implement34.6=123÷4250Test

57.6=123÷7083Design34.6=123÷4250Req. Analysis11.5=123÷1417Procurement

WorkMonths=

FTEHrs/mo÷EffortPhase

Step 6: Phase Work months

The number 123 is the product of the average projected daily hours work multiplied by the averagenumber of working days per month.

From the previous slide, that number was derived by multiplying 6.5 hours per day by 19 days per month(6.5 X 19 = 123).

Thus, the Procurement portion of the project will require 11.5 “work months,” or 11.5 months of effort.

This is calculated automatically.

Step 7: Resource Estimates• Number of Optimal Full Time Equivalent

(OFTE) resources

• Formula: OFTE = Work Months + 1

Because not all of the details about the project will be known at this early stage, it may not be possible todevelop a WBS in great detail. Still, it is necessary to figure out a reasonable approximation of the size ofthe team -- the total number of resources that could be absorbed by the project. This estimate is called theOptimal Full-Time Equivalent (OFTE).

As shown in the formula on the slide, compute OFTE resources by adding the number one to the squareroot of the total work months. The logic behind this formula is on the following slide.

This is calculated automatically.

The Point of Diminishing Return…• 15 tasks

• Each task can be completed by one person in one day

• All of the tasks are independent of each other

• Resources Needed– 1 Person 15 days

– 2 People 8 days– 3 People 5 days

– 4 People 4 days

– 5 People 3 days

– 6 People 3 days– 7 People 3 days

– 8 People 2 days

OptimumResourceUsage

Diminishing Return

The question of what is the “best” number of people, and thus the logic of the OFTE formula, can be seenon this slide.

• With only one resource completing all tasks, the project will have the longest possible duration(here, 15 days).

• At first, adding resources to the project is efficient, because with two people the project will becompleted in 8 days.

• The time savings diminishes as we add resources. You will note that using four resources on thisproject produces the greatest level of balance between resources and time to complete.

• Eventually, adding more resources to a project reaches a point of diminishing returns.

7=1+5.934.6Test

8=1+7.657.6Design7=1+5.934.6Req. Analysis

9.5=1+8.369.1Development

7=1+5.934.6Implement

4.5*=1+3.411.5Procurement

=

=

1

1

4.5+3.411.5Transition to M&O

OFTE+Square

RootWork

MonthsPhase

Step 7: Resource Estimates

*round to the nearest half

In the above example, the number of Optimal Full Time Equivalent resources estimated for theprocurement phase is 4.4. Obviously, we would not estimate FTE’s in increments of one-tenth. In a laterstep we will deal with adjusting that number.

Step 8: Phase Duration (OFTE)

2.5*=4.5÷11.5Procurement

2.5=4.5÷11.5Transition to M&O

5=7÷34.6Implement

5=7÷34.6Test

7.5=9.5÷69.1Development

7=8÷57.6Design

5=7÷34.6Req. Analysis

Estimated*Duration=OFTE÷

WorkMonthsPhase

*round to the nearest half

The next step is to estimate the duration of each phase. This is a simple calculation. Divide the number ofwork months (month of person effort) by the number of Optimal Full Time Equivalent resources. Youwill note that we have rounded upward the estimated duration to the nearest half month.

Phase Duration (PFTE)

9.5=4÷37.3Test

6=2÷12.4Transition to M&O

9.5=4÷37.3Implement

10=7.5÷74.6Development11.5=5.5÷62.1Design

6=6÷37.3Req. Analysis4=3÷12.4Procurement

EstimatedDuration=PFTE÷

WorkMonthsPhase

The number of PFTE should be equal to or less than the OFTE

The next step in the process is to apply your sense of the realistic number of FTE’s that will be availableto work on the project. This is called the Probable Full Time Equivalent (PFTE) resources.

The PFTE can be equal to or less than OFTE, but it should not be more because adding resources does notalways speed up the completion of work as illustrated earlier.

The right-hand column shows the estimated duration, in months, for each phase.

To compute the estimated duration for a phase, divide the estimated work months by the number of PFTE(rather than the OFTE).

We do not recommend using range values when estimating the individual components of estimate. At thisstage in the project, the estimate is being done for the purpose of making a management decision.Therefore, there is no need to convey all of the multiple uncertainties related to how each phase wascalculated. A range is added to the final estimate.

Step 8: Project Management Effort• Project management effort adds 5% – 20%

to total project effort

• Does not necessarily impact duration; runs inparallel with project work

Even if a project manager spends no time producing product deliverables such as code or web pagecontent, communicating, making decisions, and all the activities that are necessary to keep the projectmoving consumes a considerable amount of time. Typically that effort will consume between ranges eightpercent and to 20% of the total project effort.

PM effort does not add to the total duration of a project because the work of the PM occurs in parallelwith the production work. However, the project management effort needs to be included in the total effortof the project for purposes of estimating the total project cost.

10%Test

10%Transition to M&O15%Implement

15%Development20%Design20%Req. Analysis10%Procurement

PM EffortPhase

Project Management Effort

Be realistic about the percentage of effort of phase based on TOTAL effort for that phase. ProjectManagement effort is “what %” of the total effort for the entire phase.

In this example, the amount of estimated PM effort varies from phase to phase. For example, the PM willbe more involved in the daily management of team members who do analysis and design work and lessinvolved in procurement and other phases.

The percentage of effort added for PM effort can vary because of a number of different factors, such as:

Political environment Team location

Project complexity Team size

Project manager’s skills Team/customer synergy

Step 9: Phase-Based Gantt

The durations plotted above include additional lag daysincorporated by the project manager.

Some or all project phases may overlap in time, and so does project management effort. Therefore, tocome up with an estimated project completion date, it is necessary to develop a phase-based Gantt chart.

Step 10: Cost Estimating• Burdened rate

• Estimated effort for each phase

• Compute the cost estimate for each phase

• Consider additional expenses

Estimated Effort x Burdened Rate = Estimated Cost

Estimates of total project cost incorporate a “burdened” rate (wages or salary plus a percentage for payrolltaxes, employee benefits, and general overhead) that is multiplied by the estimated effort for each phase.Additional expenses such as equipment and supplies should be added as well.

The next slide contains a sample sheet of calculations of cost estimates for a project based on effortdistribution plus these additional factors.

$600K$38K+$562K$9559141.155143Dev

$2708KEstimated Project Cost

$702K+35%$2006KTotal Cost

$95k=$5K+$90K=$95*943=1.10*857M&O

$306K=$25K+$281K=$95*2957=1.15*2571Imp

$194K=$15K+$179K=$95*1885=1.10*1714Tst

$401K=$10K+$391K=$95*4115=1.2*3429Des

$328K=$35K+$293K=$95*3085=1.2*2571An

$95K=$5K+$90K=$95*943=1.1*857Pro

TC=AE+LC=BR*TEE=1+PM*EHPH

Cost Estimating

The chart above illustrates how project cost is ultimately estimated.

The column headings are as follows:

PH = Phase

EH = Effort Hours

1 + PM = 100% + Project Management Effort %

TEE = Total Effort Estimate

BR = Burdened Rate

LC = Labor Cost

AE = Additional Expenses

TC = Total Cost

Note that in the Concept Statement Toolkit an additional 35% has been added to the cost to account forthe high-level nature of the estimate. If your organization requires a single-point estimate, always providethe top end of the range.

Size Estimating Template

Exercise• Complete the Estimating Summary for your

project:– Estimated Effort Hours for selected Base Phase

– Percentage of Project Management Effort

– Probable Internal FTEs

– Probable External FTEs

– External Hourly Rate


Initiating Stage

Initiating Purpose“Those processes performed to define a newproject or a new phase of an existing project byobtaining authorization to start the project orphase.” –PMBOK 4th Edition

3. Project Charter4. Issue Log

Project Charter

Initiating

The diagram above is the Initiating Stage of the CA-PMM Diagram.

The primary purpose of Initiating is to obtain formal authorization for a project (or authorization for anew phase in a multi-phase project).

The case for authorization is summarized in the Project Charter, which includes a clear statement of thepurpose of the project, its key objectives, and a number of other important factors.

The Charter links the project to the ongoing work or business strategy of the organization, as appropriate.

The Charter is supported by the Preliminary Scope Statement, which offers an initial definition of theboundary conditions of the project’s product, that is the features, functionalities, and other attributes thatwill or will not be included.

The Initiation Stage is often begun by the organization that is requesting the product or service.

The project sponsor “owns” the charter. A core project staff person may assist in the preparation, butapproval and funding are handled outside the project boundaries.

It is critical to involve the customer and other stakeholders during the Initiating stage, gaining their “buy-in” at the outset of the project and paving the way for their involvement in later project activities.

The Project Charter• General Information

• Complexity Assessment

• High Level Project Org.

• Project Priorities

• Assumptions and Risks

• Organizational/Functional Stakeholders

• Project Charter Approvals

General Information• Background

• Objectives

• Measurement

• Solution

• High Level Business Requirements

• Preliminary Scope Statement

• Impact Assessment

• Deadline

Payroll Outsourcing Project– Reduce cost of producing payroll by 25% by December 31.

– Zero reduction in quality.

Provision of contract and verified byannual security auditSecurity

<0.1%Payroll errors

On-time delivery >99.9% to all payrollrecipientsOn-time payroll delivery

-25% relative to last year’s payroll costCost reduction

MetricsMetricsCritical SuccessCritical SuccessIndicatorsIndicators

Objectives and Measures

Now we will add measures to our objectives.

• In the first, the objective is to reduce annual payroll costs by 25% relative to last year’s cost.

• In the second, we seek to have tough standards for on-time delivery. We want to ensure that, onaverage, only one out of every 1000 payroll deliveries is made late.

• In the third, we also have tough standards. We want to ensure that the error rate in payrolldeliveries (e.g., wrong address, wrong payee, wrong amounts, incorrect PTO) is, on average, lessthan one in every 1000 deliveries.

• Finally, we will verify compliance with security policies and procedures through an annual auditthat will review both the security process and results.

Critical Success Indicators are the description of the quantifiable measurements determined before theprojects starts that demonstrate that objectives are being achieved. Metrics are the agreed uponmeasurements (numbers) of the critical success indicators.

High Level Requirements• Major components (deliverables) of a CAR

– Engine– Power train– Electrical system– Brake system

• Key features (requirements) of a CAR– Keyless entry– Rear-seat DVD player– GPS navigation system– Side airbags

• Must Have

• Should Have

• Nice to Have

High Level Business Requirements should reflect the capabilities that are necessary tomeet the project’s Objectives.

Exercise• Complete the following General Information

sections in the Project Charter:– Background

– Objectives

– Solution

– High Level Business Requirements


Preliminary Scope Statement• Current Scope

– Key Product Deliverables

– Features

• Future Opportunity

• Outside of Scope– Product, Function, or Feature

– Reason

We think it’s important to think about product scope in three different dimensions:

• Current scope: Scope as it has been defined to date. This one is simple. It is the features,functionalities, etc., that stakeholders have agreed to include in the product of the project.

• Future opportunity: Scope to be included in order to enable us to develop future opportunitiesmost efficiently. This one is often forgotten in project planning. The bottom line is that you needto think about future projects that are likely to build on yours. Perhaps you already know that therewill be a follow-on hardware update, a new software release, or the next stage of a process-improvement activity. Is there anything you can incorporate in your project to facilitate the workof the next project? We will have an example of this in the slides that follow.

• Outside of scope: Relevant features, functions, etc., that are not to be included in scope. Skippingto the bottom of the list on the slide, this item details what will not be included in the project. Thatcould be very long! The purpose here is not to form a long list, but rather a list that eliminatesambiguity for stakeholders regarding borderline elements of scope.

Future Opportunities

New house

Current ScopeCurrent Scope

Piping sized toaccommodatefuture pool

Swimming pool

RecommendedRecommendedScopeScope

AdjustmentAdjustmentFutureFuture

OpportunityOpportunity

On this slide, we show examples of future opportunities.

In the first, imagine you are building a new house. Your current budget doesn’t allow for the swimmingpool you’ve always wanted, but you believe you will have enough money for it after you land that bigproject later this year.

While you are excavating your property and bringing water to the new house, you can put in the waterpipes that will later support a swimming pool. This will be a comparatively small cost to the currentproject and will save time and money when it’s time to build the pool.

Similarly, your project might be chartered to develop a new software system to support your salesdepartment. The department is not quite ready for e-commerce, but they believe they will need to makethe move by next year. Anticipating that move, you include in your project the functions necessary toconnect to existing financial systems.

Outside of Scope

Requires additional budget that isunavailable at this time

Patio Cover

RationaleRationaleOutside of ScopeOutside of Scope

Stating what is not within scope can help prevent ambiguities and misunderstandings.

The Preliminary scope statement, in general, facilitates the stakeholders as they build a commonunderstanding of project scope.

Summary Milestones• Summary milestones are typically the big

milestones that senior managers track

• Referred to as “summary” milestonesbecause you roll up the detail in order toproduce progress reports regarding theachievement of the milestone

Let’s take a simple example of summary milestones by imagining that your project is to build a newhouse on land that you already own. You have hired a general contractor to do the work for you and youhave agreed on the following summary milestones:

• House plan selected (end of January)

• Final blueprint approved by owner (mid February)

• Building permits obtained (unknown)

• Foundation completed (unknown)

• Framing completed (unknown)

• Roofing completed (unknown)

• Exterior completed (unknown)

• Interior finish and trim completed (unknown)

• Utilities installation completed (unknown)

• Landscaping and driveway completed (end of October)

• House ready for occupancy (end of year)

Your general contractor should be able to provide you with regular reports regarding the achievement ofthe milestones: schedule and cost information, problems and their resolutions, etc.


sections in the Project Charter:– Preliminary Scope Statement

Current Scope

Future Opportunities

Outside of Scope


Impact Assessment• System, Process, Project

• Nature of Impact

• Owner

• Action Required

The Impact Assessment template is designed to help identify and track system, process, or project impactsbetween your project and others.

System, Process, Project: Identify the system, process, or project that will be affected by or impact yourproject.

Nature of Impact: Identify the type of impact (either impacts your project or is impacted by your project)and the specifics of what is entailed. For example: Our project will produce a large amount of data thatwill place a burden on enterprise IT.

Owner: Identify the person who has the action to deal with the impact issue.

Action Required: Identify what the owner of the action must do. For example, determine whetherenterprise IT will be able to support our processing needs in the time frame needed.

Due: The date by which the action must be completed.

Deadline• Is there a deadline for this project?

• What are the reasons for this deadline?

• What happens if we miss the deadline?

• What trade-offs are possible?

By definition, all projects have scheduled completion dates, or deadlines. You need to understand thereasons for the deadline and you need to know whether it’s a “hard” or somewhat flexible deadline.

Some deadlines are inflexible, for example:

• Completion of a corporate display for a scheduled trade show

• Updating of tax-related software before the next tax season starts

Other deadlines may be discretionary, set perhaps by a senior manager or sponsor at a date of theirchoosing.

A good way to think about a deadline is to ask: “What happens if we miss the deadline?” In the case ofthe display for the trade show, the company might miss an important business opportunity. Similarly, iftax software isn’t ready on time, customers could be lost and reputations scarred.

When faced with a “hard” deadline, you need to ask whether trade-offs in other project attributes mightbe made in order to meet schedule. Think about the four basic project attributes: schedule, scope, budget,and quality.

• Would additional money help to complete the corporate display or tax software on time? Could afew features be trimmed?

When faced with a discretionary deadline, there might be room to negotiate a schedule change.


sections in the Project Charter:– Impact Assessment

– Deadline


Complexity Assessment*• Business Complexity

• Technical Complexity

• Complexity Diagram

• Suggest PM Skill Set Guidelines

*The Complexity Assessment is provided to the OCIO as the “Criticality Rating” inthe IT Project Oversight Framework (SIMM 45)..

II

I

IV

III

Complexity Analysis is useful for a variety of purposes.

• Staffing decisions: in general, the skill level of resources assigned to the project should align withits complexity level.

• Project manager assignment should be based on complexity: A high zone-two project requires aproject manager with a strong technical background while a high zone-three project requires apolitically savvy project manager.

• Aggregate complexity of corporate project portfolio: Several projects can be plotted on thecomplexity chart to get a quick view of a project portfolio.

• Ranges used in estimates should be driven by complexity.

• The size of the budget reserve should be driven by complexity. Simple, routine projects do notrequire a reserve whereas highly complex projects could have a reserve in the amount of 25% ofthe budget.

Business Complexity

This figure depicts a chart designed to assess the Business Complexity. The column in the middle,Business Attributes, lists a number of attributes applicable to the project at hand. The columns to its leftand right list the characteristics associated with the low and high end of the complexity continuum, wherethe value of 0 implies no complexity and the value of 4 means high complexity.

While creating the specific list for a project, include only those attributes that apply to the project in asignificant manner. Careful selection will ensure that none of the attributes will have a complexity ratingof 0. Record a value indicating the level of complexity of each applicable attribute in the Rating column atthe right.

Use your best judgment.

Use “0” if the item is not applicable. The key is to think about each item. Can be tailored to meet theneeds of your project.

Technical Complexity

Technical EnvironmentThe chart above depicts a list of technical environment attributes and their assessed values for a sampleproject. When assessing the complexity of a specific project, you will need to create a tailored attributelist to reflect the needs of that project. When developing this list, include only those attributes that applyto the project in a significant manner.

The number of attributes in the two categories (Business and Technical) does not have to be the same. Forexample, you might choose to specify eleven business complexity attributes and only ten (or fewer)technical complexity attributes, or vice versa.

The steps for computing a project’s Technical Complexity are the same as those used for computingBusiness Complexity.

Tech

nica

l

Business

Slide 60

Complexity ZonesIV

II

III

I

Tech

nica

l

Business

Routine/Low

HighTechnicalComplexity

MediumTechnicalComplexity High

BusinessComplexity

MediumBusinessComplexity

VeryHighComplexity

Simple, familiar

Technically challenging,routine business

Businesschallenges,

routine technology

Highlycomplex from

bothperspectives

In the above figure we see that the two-dimensional space in the complexity diagram is divided into fourprimary zones:

Zone IV: Projects in this space are highly complex – very high business and technical complexity.

Zone II: This space of the diagram depicts high technical complexity projects and is further divided intotwo sub areas:

High Technical Complexity and Medium Technical Complexity.

Zone III: This space of the diagram depicts high business complexity projects and is further divided intotwo sub areas:

High Business Complexity and Medium Business Complexity.

Zone I: Projects in this space are of low complexity – simple or routine projects.

It should be obvious that projects get more complex as they move from the lower left-hand side to theupper right-hand side.

Tech

nica

l

Business

Slide 61

Project Complexity Example

IV

II

III

I

Routine/Low

HighTechnicalComplexity

MediumTechnicalComplexity High

BusinessComplexity

MediumBusinessComplexity

VeryHighComplexity

4

3

2

1

0 1 2 3 4

Tech

nica

l Com

plex

ity

3.6

Business Complexity

3.5In this chart, the triangle symbol represents the project we just assessed using the values on the technicaland business complexity templates. The placement of the proposed project in Zone IV indicates that thisis a highly complex project because practically all of the business AND technical attributes are ratedtowards the higher end of the 0 to 4 complexity scale.

A note of caution: do not be concerned with the precision of a project’s placement within the complexitydiagram. The purpose of this template is to ascertain key complexity contributors and the zone in whichthe project falls.

For that matter, do not be overly concerned with the precision of any individual item rating. Specificmajor issues or risks identified in this exercise can either be carried forward as items for risk analysis ordealt with separately. Note that ANY item that has a complexity rating above 3 should become an input torisk assessment.

Suggested PM Skill Set Guidelines

Project Management Levels are guidelines only.

Oversight• For Oversight Purposes:

– Zone I = Low Criticality/Risk

– Zone II and III = Medium Criticality/Risk

– Zone IV = High Criticality/Risk

II

I

IV

III

Replaces the “Criticality Rating” in SIMM 45: IT Project Oversight Framework. All other sections ofSIMM 45 apply.

Note that your project’s Criticality Rating has been delegated to your department for assessment whichwill be sent to the OCIO as part of the feasibility study report package.

Exercise• Complete the following Complexity

Assessment section in the Project Charter


High Level Project Organization

A high-level project organization chart is an essential starting point for designing a project team, that is,the set of roles, responsibilities and interactions among the project management team and up and downthe chain of command.

This version of a proposed organization chart includes distinct levels of management-team interaction:

• Executive-level sponsorship, steering committee, and governance committee.

• Management level responsibility, including the PM, team leaders (shown as Technical Managerand Business Manager on this slide) and, possibly, a Project Director if the project is part of aportfolio of projects managed by different individuals.

Team member roles will be developed during the Planning Stage.

Note about executive-level decision-making: The purpose of having a Steering Committee (a.k.a.Executive Committee, in many organizations) is to include senior managers from various cross-functionalgroups who are affected by or involved in the project in the decision-making process.

This is especially important for more complex projects where the sponsor alone may not have theauthority or the organizational and political clout to make decisions, or to allocate resources amongcompeting projects, or to set broader business and/or policy objectives for the organizations.

To put it more simply, a Steering or Executive Committee can give the Sponsor the extra clout he or sheneeds to make effective decisions regarding the project.

Exercise• Complete the High Level Project Org. section

in the Project Charter by identifying theindividual or group names who will be fillingthe following roles (as appropriate):– Executive Sponsor– Steering Committee (cross functional group)– Project Director– Project Manager– Project Support– Technical Manager– Business Manager


Project Priorities• Priority Analysis

• Consequences

• Negotiations

• Control

We must also determine which of these constraints will be “driving” future project decisions. The driveris the constraint that has the least flexibility.

The challenge is that not all of the key stakeholders will necessarily see it the same way. While budgetmay be the “driver” for the sponsor, the schedule may be the “driver” from the customer’s point of view.

The job of the project manager is to work with the sponsor and key stakeholders in order to determinewhat is driving the project from the respective points of view and then to develop a consensus. Ifconsensus is not possible, it is up to the sponsor to determine which constraint will be driving projectdecisions.

Definition of Quality• Be sure you have a good understanding of

“quality”

• Different stakeholders may have differentdefinitions of quality

• Discuss quality with your customers andquality assurance group

• Develop a master list of quality attributes forthe types of projects your organizationundertakes

• Tailor it to individual projects

Let us focus on the Quality component of the project equation for a moment. A number of projectmanagers have great difficulty defining the “quality” of the end product. They also find the concept ofassigning quality a ranking other than 1st unacceptable. A common concern voiced by many projectmanagers is: “It is not easy to discuss the subject of assigning quality a low ranking with the customerbecause it would seem like we intend to compromise the quality of the end product.”

We strongly advise you to work with your quality assurance group to define a master list of qualityattributes for the types of projects your organization undertakes most frequently. Once a master list hasbeen created, individual project managers can develop project-specific lists.

Perception of Quality

“Quality is in the eye of the beholder”—to update the old adage. The problem with the quality attribute isthat different stakeholders may have different views on the quality component of the final product. At thestart of most projects, the stated priorities often conflict (e.g., a tight schedule in the face of vaguelydefined scope, a low budget, and unrealistic quality expectations). Also, different stakeholders may havediffering priorities and interests. The existence of such conflicts makes it essential that priorities be welldefined and clearly understood by both the customer and the project team.

Project Priority ThresholdsScope – The minimal scope that must bedelivered

Budget/Cost – The maximum amount ofmoney the customer is willing to spend

Schedule – The latest the project must befinished and implemented

Quality – The level of quality below which theproduct will be unacceptable

There will be situations when there is pressure to change the “weight” of one or more of the components.When this is the case, ask the sponsor what trade-offs he/she is willing to accept. In other words, what istheir “bottom line.”

The objective here is to establish priorities that best serve the needs of the project as a whole rather thanthe needs of any one group. This convergence is facilitated by assessing and comparing the consequencesto the business if the highest priority of each key stakeholder is not met. Once consequences have beenexamined and trade-offs have been developed, a governing set of priorities for the project should emerge.

The final ranking is negotiated, not calculated.

In the case of non-convergence, the project manager may need assistance from the sponsor to helpdifferent stakeholders come to a common understanding of the Intra-Project Priorities.

CAVEAT: Although this is explained above, the most important thing to remember is that the finalranking of priorities is never a mere numerical calculation adding up the totals in each row or column. Itis, instead, the result of careful deliberation and negotiation that hopefully achieves a consensus among allstakeholders.

A final note: Many in the profession still use the notion of triple constraint – scope, schedule, and budget.When this is the case, quality is a subset of the scope. If your colleagues, and especially your managers,insist on using the triple constraint, our advice is that you try to educate them on the benefits of parsingquality into a separate attribute. However, we don’t advise engaging in any hard-headed arguments. Ifthey persist in the use of triple constraint, and it would benefit the overall environment to go that way, gowith the flow.

Exercise• Complete the Project Priorities section in the

Project Charter by identifying functionalgroups that represent Key Stakeholders andtheir relative priorities.


Only the Project Sponsor is carried over to Project Priorities from the High Level ProjectOrg. as the other roles are part of the project team, not internal and external stakeholders.

VERIFY

ASSUMPTIO

NS!

Assumptions & Risks• Assumptions

• Constraints

• Procurement Assumptions

• Known Risks

• Runaway Trigger

• Shutdown Conditions

Exercise• Complete the Known Risks subsection of the

Assumptions & Risks section in the ProjectCharter


Organizational/Functional Stakeholders• Identify all stakeholders

• Vested Interest

• Assess their level of support

• Readiness

• Tolerance for change

• Training needs

• Other needs

The definition of a stakeholder in this course may be broader than you have encountered in the past.Application of this definition may require you to think beyond your normal definition.

• First, anyone who is actively involved in the project is considered a stakeholder. Activeinvolvement means that the stakeholder has an assigned responsibility for completing projectwork.

• Second, anyone whose interests may be affected by either the execution of the project or itsoutcome is considered a stakeholder. Certainly the customer is a stakeholder, but what about thedepartment that is going to work overtime for several weeks to help you meet your projectschedule? That department is also a stakeholder.

• Finally, anyone who may exert influence over the project’s objectives or outcomes is alsoconsidered a stakeholder. The sponsor and the customer are examples of this category ofstakeholder because they are the owners of the project’s objectives.

“Proactive” or “aggressive” management of project stakeholders is a winning approach.

• Identify the stakeholders: Take time and use a systematic approach to identify all projectstakeholders. Often this is not easy.

• Determine their requirements and expectations: Again, use a systematic approach to determinetheir requirements and what their expectations are for the project.

• Determine their communications requirements: For each stakeholder, determine what they need toknow about the project, when they need it, in what form they need it, and assign action for thecommunication to be made according to the stakeholder’s needs.

• Manage their influence in relation to requirements: Continue to meet with stakeholders regularlythroughout the project. In doing so, you will better understand their needs and you may be able toavoid unnecessary scope or other change requests that they might initiate.

Org/Functional SH Template

Mark Scott Owner In Favor Ready HighDemo of

website andconference

presentationNone

Training Services Future TrainingDelivery In Favor Ready Medium Demo of

website None

Consulting ServicesFuture

ConsultingServices

Neutral Ready Medium Demo ofwebsite None

Sales and Marketing Future Revenue In Favor Ready High Demo ofwebsite None

Customer Services Fewer calls dueto website issuesUncertain Ready Low Participation in

UAT None

Stakeholder Interest Support Readiness Tolerance ForChange

TrainingNeeds Other Needs

The stakeholder is identified in the first column. In the example, it is Mike Jones, the sponsor, and theTraining Managers.

The HR managers have a clear interest in the project, as it will provide new tools that they requested toimprove efficiencies. There is another interest/impact, in that they will have to undergo some training andpractice in order to use the new tools. In other words, they will have some work to get ready.

• They are clearly in favor of the new tools project.

• They are not ready and need training or other support.

• Their training needs are stated.

• Another need that was identified is to upgrade the memory of their computers.

Exercise• Complete the Organizational/Functional

Stakeholders section in the Project Charter


Issue Log“A point or matter in question or in dispute, orpoint or matter that is not settled and is underdiscussion or over which there are opposingviews or disagreements.” –PMBOK 4th Edition

We define an issue as an unanswered question or a difference of opinion. Issues are akin to the potholeson a road – the more the issues, the more difficult it becomes to navigate the project.

Accordingly, issues must be managed conscientiously and in a timely manner. Once an issue has beenanalyzed and recorded, it is important to assign a specific person as owner of the issue resolution. Theowner’s responsibility is to facilitate, rather than dictate, the resolution process.

Best results occur when the non-agreeing people jointly determine the issue resolution.

Further, as work on a project continues and as issues are resolved, it is equally important to document andbroadly communicate the resolution to appropriate stakeholders and team members. This practice not onlykeeps those affected by the resolution informed, but also discourages “second thoughts” that mightdevelop later in the project.

Planning

The Charter and Preliminary Scope Statement for your project are complete. As the project manager, youare authorized to move the project to the next stage.

It’s now time to prepare detailed plans for managing scope, schedule, cost, and other key projectmanagement activities.

Planning

5. Project Management Plan6. Organizational Change Management Plan7. Maintenance and Operations Plan

Project Management Plan

Planning Purpose“Those processes performed to establish thetotal scope of the effort, define and refine theobjectives, and develop the course of actionrequired to attain those objectives.” –PMBOK 4th Edition

The diagram above is the Planning Stage of the CA-PMM Diagram.

Project Management Plan Sub-Plans• Scope Management Plan• Configuration/Change Control Plan• Human Resources Management Plan• Communication Management Plan• Risk Management Plan• Cost Management Plan• Quality Management Plan• Schedule (Time) Management Plan• Procurement Management Plan• Contract Management Plan

These are the sub-plans that are called for in the CA-PMM.

These sub-plans align with the Knowledge Areas from the Project Management Institute’s ProjectManagement Body of Knowledge (PMBOK). There are two exceptions:

• Project Procurement Management has been broken into two sub-plans, Procurement andContract, so as to align with the State’s business needs.

• Project Integration Management has been renamed to Configuration/Change Control because“integration” has a specific meaning for State IT projects.

The next portion of the course will step through each of the sub-plans.

Scope Management Plan“The document that describes how the projectscope will be defined, developed, and verifiedand how the work breakdown structure will becreated and defined, and that providesguidance on how the project scope will bemanaged and controlled by the project team.”–PMBOK 4th Edition

We now turn to the centrally important topic of Scope Management. Three Scope Management elementsare created during Planning:

• The Scope Management Plan

• The approach to producing the detailed Project Scope Statement

• The project WBS

The Scope Management Plan details how all Scope Management processes will be performed.

• It includes plans for the two other Planning processes: preparation of the Project Scope Statementand preparation of the project WBS.

• It also includes plans for two processes that will be carried out during Execution.

Scope Control: The process by which scope will be controlled, including all elements of aChange Control process.

Scope Verification: The process by which deliverables will be formally accepted during eachphase of a project.

In the slides that follow (the scope section of this chapter), we will discuss:

• Preparing a detailed Project Scope Statement

• Scope Change Control

Scope Change Request• Scope Change Request #• Description• Category

– Must Have– Should Have– Nice to Have

• Benefits• Impact• Risk (associated with the change)• Approval

This is a simple template that you might find useful for scope change requests.

Change Request #: Each change request must have unique number so that it can be tracked

Description: Describe the change to be made and the reason for the change.

Category: Identify the change as must-have, should-have, or nice-to-have. Explain the reason for placingthe change in the category you choose.

Benefits: Quantify, to the degree possible, the monetary value of the change, if implemented.

Impact: Quantify, to the degree possible, the cost of the change, if implemented.

Risk: Identify the risks associated with the change and the actions that can be taken to manage the risk.

Approval: The appropriate set of signature blocks, consistent with the approval authorities set forth inyour scope management plan.

The “Scope Change Request” is an excerpt in SIMM 17.

Configuration/Change Control Plan*• To manage change to the project’s baselines

for scope, schedule, cost, and quality

• To manage change across the variousplanning documents to ensure that direct andindirect impacts are addressed

• To manage the storage, handling, anddisposition of project media (both automatedand paper)

*CA-PMM modification to PMBOK

In the last section, Scope Management, the discussion of change control was included to highlight howchange control is applied to a specific project management knowledge area. A similar approach is appliedto the other knowledge areas, such as schedule, cost,quality, and contracts.

The “Integration Management” processes from PMBOK have been renamed to “Configuration/ChangeControl” for the CA-PMM.

An integrated approach to handling project changes ensures that:

• Project changes are handled in a consistent manner using a standard set of rules

• Project stakeholders understand and become familiar with the project change process

• Change analysis is accomplished with regard to the impact a project change may have on otherareas of the project

• Better stakeholder communication occurs, due to centralized approach

Human Resource Management Plan“A document describing how roles andresponsibilities, reporting relationships, andstaffing management will be addressed andstructured for the project.” –PMBOK 4th Edition

In this segment of Planning, we will discuss preparation of the Human Resource Plan. The plan is mostlyconcerned with project roles, responsibilities, and reporting relationships. It has these three primaryoutputs:

• Staffing management plan

• Project organization charts

• Roles and responsibilities

Skill Level RequiredRequired

Skills

Source:Role:

Novice4

When Needed:Resource Name:

LearnerCompetentProficient321

Required Skills and Skill Level

X

X

XFacilitation

PresentationSkills

Knowledgeof Subject

Instructor

ActualSkillLevel

SkillGapPlan

Training Dept.

Aug 1 – Nov 30

2

3

1

Mentor

Coachingsessions

N/A

Dennis

This simple template can help you zero in on the skill sets and levels of proficiency you need to completeyour project.

During Planning, the resource requirements are specified on the template, including competency levels.Skills should include both subject matter skills and interpersonal skills such as communication. InExecution, when team members are acquired, the balance of the table is completed.

In the example, we have shown that an instructor is needed for the Bank Merger Project. The instructor isexpected to be fully proficient in facilitation, have basic competency with presentation skills, and basiccompetency in regard to his or her knowledge of the subject matter.

When a person is identified to fill the position during Executing, their competencies can be compared tothe desired competencies. Decisions can then be made regarding the acceptability of the resource and anytraining that might be required.

The “Required Skills and Skills Gap Plan” is an excerpt in SIMM 17.

Exercise• Using the Project Organization Chart, identify

the key roles needed

• Choose two of the roles you have identifiedand complete the Staffing Management PlanSection of the Human Resources Planworksheet


Use job descriptions, not names.

Release criteria examples, “end of phase,” “end of contract.”

Due to DPA rules and regulations, this is completed by the functional manager.

Communication Management Plan“The document that describes: thecommunications needs and expectations forthe project; how and in what format informationwill be communicated; when and where eachcommunication will be made; and who isresponsible for providing each type ofcommunication.” –PMBOK 4th Edition

Risk Management Plan“The document describing how project riskmanagement will be structured and performedon the project.” –PMBOK 4th Edition

Simple Probability and Impact ScalesScale: 1(low) – 5 (high)

Impact Scale

25% change to schedule, scope,budget, or quality

5

16 – 24% change to schedule, scope,budget, or quality

4


3


2

Less than 5% change to schedule,scope, budget, or quality

1Probability Scale

>80% chance5

61 – 80% chance4

41 – 60% chance3

20 – 40% chance2

< 20% chance1

Note: Risk probability of 85+ percent is considered fact(constraint) and should be included in planning!!!

In this approach, we do a simple 1 to 5 rating of both probability and impact. The words and the percentprobability shown on the slide will help build consistency in rankings made by different people.

You can adjust the scales to accommodate the realities of your project.

Timing Scale1 = within the next six months

.66 = from six months to a year from now

.33 = over a year from now

The Timing Scale is designed to factor in the “urgency” of the risk in terms of how soon action to managethe risk must be taken. Use the Timing Scale to select the appropriate Timing factor.

Risk Register

*

*

=

=

.33

1

*

*

555CustomerSophistication

1243Budget

* =Timing*RiskLevel(1-25)

Impact(1-5)

Prob.(1-5)

Risk

* =.66* 1053Audit & ControlNeeds

Note that the Customer Sophistication risk is judged to have both a high probability of occurrence and thehighest impact, if it occurs.

Risk Threshold1-9 = Low-level risk (green)

10-15 = Medium-level risk (yellow)

16-25 = High-level risk (red)

The next step in the process is to categorize the risks to the project as high, medium, or low. Again, thereare many methods for doing this.

In our approach, we set simple thresholds to sort the risks into high, medium, or low-level bins.

Looking back to the example, we see that:

• The audit and control needs category is a medium-level risk (10)

• Budget is a medium-level risk (12)

• Customer Sophistication is a low-level risk (5)

Exercise• Working as a team, use the Risk Register to

identify and rate the potential risks to yourproject:– Complete the “Probability” column

– Complete the “Potential Impact” column

– Review the Risk Level


Risks are populated from the Project Charter.

The Risk Register is not an excerpt, yet.

Risk Response Planning• Develop options and determine actions to

manage risks– Avoidance

– Mitigation

– Transference

– Acceptance

– Contingency

You have identified the risks to your project and have qualitatively assessed the risk level.

Now it’s time to make plans to deal with them based on the thresholds determined in the RiskManagement Plan.

Again, we advocate a proactive approach. Once you develop a plan for managing a risk, it is integratedinto the Project Plan. Some risk management plans will be executed to eliminate or reduce the level ofrisk. Others might only be executed if the risk actually occurs.

It is critical to assign an “owner” to each risk response. The owner will keep close track of the risk and, insome cases, might have the authority to approve the execution of a “contingency” risk response plan.

Exercise• Working as a team, choose two risks that

you have identified

• Use the Risk Register template to developRisk Management Plans (Cause throughOwner columns)


Cost Management Plan“The document that sets out the format andestablishes the activities and criteria forplanning, structuring, and controlling projectcosts.” –PMBOK 4th Edition

Project cost management includes the processes involved in planning, estimating, budgeting, andcontrolling costs so that the project can be completed within the approved budget.

Project cost management is primarily concerned with the cost of the resources needed to complete thescheduled activities. However, cost management should also consider the effect of project decisions onthe cost of using, maintaining, and supporting the product, service, or result of the project. This broaderview is often referred to as “lifecycle costing.”

Quality Management Plan“The quality management plan describes howthe project management team will implementthe performing organization’s quality policy.”–PMBOK 4th Edition

The Quality Management processes implement the quality management system through the proceduresand processes of quality planning, quality assurance, and quality control. Quality Management facilitatescontinuous process improvement activities conducted throughout the project lifecycle.

Schedule Management Plan“The document that establishes criteria and theactivities for developing and controlling theproject schedule.” –PMBOK 4th Edition

It’s now time to take the work we have completed and begin to build the schedule for the project.

We will discuss these processes:

• Activity Sequencing: Arranging all of the project activities in the order in which they will beperformed, primarily by establishing the dependencies between them. The result is called a“Network Diagram.”

• Activity Resource Estimating: Estimating the types and quantity of resources (persons,equipment, material) needed to complete each activity.

• Activity Duration Estimating: Determining the number of work days that will be required tocomplete each activity.

• Schedule Development: The process by which a schedule is created. It involves bringing togetherthe network diagram and estimates, analyzing the results, iterating the process, and, finally,gaining approval for a schedule that will be executed (the schedule baseline).

Activity Resource Estimating Includes…Estimating the types and quantities of theresources needed to complete each activity

– Human resources

– Material

– Equipment

– Consultants

As we progressively elaborate what we know about theproject, the ranges of our estimates get smaller!

Activity Resource Estimating is an important step along the way to creating a schedule for the project. Itis here that you estimate how many of each type of resource will be needed to complete each projectactivity. You need these estimates before you can determine the durations of each activity.

The accuracy of project estimates depends on the degree of detail used in preparing the estimate.

Estimates made early in the project are subject to considerable uncertainties. Rough-order-of-magnitude(ROM) estimates made during Initiating have an uncertainty range of -50 percent to +100 percent.

Other estimating techniques can be used to reduce uncertainty, but estimating is limited at that point.That’s because you have only developed a top-level view of the project. Initiating estimates are oftenbased on historical comparisons of top-level figures for similar projects, or on key project deliverables.Because you are working at the top level of a WBS, these are often called “top-down” estimates.

In Planning you will have gained detailed knowledge of the project, including the activities that must becompleted. Estimates can be made at the activity level and combined to produce much more accurateestimates. This is often referred to as “bottom-up” estimating.

In Executing, as actual schedule information is gained, estimates may be refined further.

Estimates made later in the project could narrow to an uncertainty range of -10% to +15%.

Note that the estimating process continues through the life of the project.

Estimating FundamentalEffort represents the amount of workexpressed in hours

– Effort-driven activities will require a longer orshorter duration as the effort increases ordecreases.

Duration represents the number of work days,weeks, or months to complete the effort

– Duration-driven tasks do not expand or contractregardless of the number of resourcesparticipating.

Effort and Duration: An estimate of the effort required to perform an activity is the foundation for anestimate of the duration of that activity.

• An effort estimate is the amount of work, usually measured in hours, that will be required tocomplete an activity. The effort estimate is made without reference to how those hours will bedistributed in a calendar.

• A duration estimate is the number of work periods (days, weeks, months) it will take to completethe activity.

It is important to understand the difference between effort-driven activities and duration-driven activities.

The duration of an effort-driven activity will become shorter if we add more resources to it. For example:

• An activity that requires 100 hours of effort, done by one resource working four hours per dayresults in a duration of 25 days

• Split that activity into five pieces

• Assign one resource to each piece

• Each resource can work four hours per day

• Duration is 5 days

If we change the number of resources to 10 (assuming that the nature of the work allows us to do so), andthe new resources can also work four hours per day, the duration becomes 2.5 days.

A duration-driven activity is one in which the duration of the activity is fixed, such as a meeting, or aclass, or possibly a fixed period of time for responses to be submitted.

Obtaining Estimates Includes…• Ask the person to whom the task is assigned

• Project manager estimates

• Gather a representative group

• Historical data

Person Assigned Activity: A best practice estimating technique is to get an estimate for an activity fromthe person who is going to do the activity. An advantage of this approach is that it helps to buildcommitment from the person performing that task to complete it within a time-frame they specified. Ifyou have uncertainties about the estimates that someone is providing, you may want to cross-check themusing other estimating methods.

Project Manager: Unless the PM has all the necessary experience and information to do projectestimates, this is not a good idea.

Representative Group: This can be a useful technique, particularly for new activities for whichexperience is limited. This technique is called the Delphi Technique. The Delphi Technique is a tool usedto build consensus among experts in a group setting. It is used for both estimating and risk management.The downside of this approach is that it is time consuming.

Historical Data: History is a great teacher. If you have reliable historical data that is relevant to yourproject it can be a big asset when estimating.

6 Steps To Activity Duration EstimatingStep 1 – WBS Review

Step 2 – Network Diagram Review

Step 3 – Baseline Effort Estimate

Step 4 – Resource Profile

Step 5 – Effort Estimate

Step 6 – Activity Duration Estimate

WBS Review: Making sure your WBS is complete and accurate.

Network Diagram Review: Making sure the dependencies shown in your network diagram are accurateand realistic.

Baseline Effort Estimate (BE): Making an estimate of how many hours it will take to complete eachproject activity under “ideal” conditions.

Resource Profile: Developing a baseline estimate “multiplier” based on the proficiency and other factorsaffecting the performance of the person performing the activity. We call this multiplier the EffortVariance Factor (EVF).

Effort Estimate (EE): The amount of effort required for that identified resource to complete the activity.The EE is calculated by multiplying the baseline effort estimate (BE) by the Effort Variance Factor(EVF).

Activity Duration Estimate: The number of work days required by the identified resource to completethe activity. Calculated by dividing the effort estimate by the number of hours the person works on theactivity each workday.

Steps 1 and 2• WBS Review

– Review the most recent WBS and revise asnecessary

– Be sure to include a detailed activity list for eachdeliverable

• Network Diagram Review– Depicts the relationships among activities and

milestones

– Shows the order in which various activities canbe undertaken

Step 1 in the process is to make sure that the WBS for the project is complete and accurate.

Review the associated activity list to be sure that all necessary activities are included. Remove anyunnecessary activities.

SF (Skill Factor) is not used to produce estimates that utilize vendor resources.

Step 2 is to review your network diagram for completeness and to ensure that the dependencies are asintended. Also be sure that the the logical relationships shown in the diagram are completed accurately.

Step 3: Baseline Effort Estimate• Proficient

• No interruptions

• Full-time assignment to the project

• Optimal work environment

Using this detailed estimating technique, you must gear up your estimating effort to collect baseline effortestimates rather than individual effort or duration estimates.

The baseline effort estimate (BE) represents the number of effort-hours it will take to complete an activityunder “ideal” circumstances. If you were doing nothing else in the entire world, how long would it take todo the task (raw effort)?

The ideal circumstances are:

• Proficient: The resource performing the activity is fully proficient and has no learning curve incompleting the task.

• No Interruptions: The resource performing the activity is never interrupted while completing thework.

• Full-Time Assignment to the Project: The resource does not have the inefficiencies associatedwith juggling multiple projects; he or she is devoting full time to completing the activity.

• Environmental Factors: The performance of the resource is not compromised by any less-than-ideal environmental conditions (e.g., reliability of the IT system).

Some things to keep in mind:

• Lags have no effort and therefore Baseline Effort Estimates are not required.

• Meetings that have a specified time limit will not require Baseline Effort Estimates because youwill be “fixing” the duration. The cost of the meeting goes up as more participants attend, but theduration of the meeting should stay the same.

• Activities that require two or more people should be split into discrete activities because it is verylikely that the skill factors of the individuals will vary.

Exercise• Identify two tasks that will be required for

your project

• Estimate the baseline effort (BE) for eachtask listed and enter each in the ActivityDuration Estimate Worksheet in theSchedule Management Plan section of theProject Management Plan


The Activity Duration Worksheet facilitates duration estimating. All estimates and computations areincluded on the worksheet.

This is an overview of the Activity Duration Estimate Worksheet with a completed example of an activityduration estimate.

This is NOT necessarily at the task level.

Legend:BE: Baseline Effort Estimate

SF: Skill Factor

WIF: Work Interruption Factor

MPF: Multi-project Factor

PPIF: Project Productivity Influencing Factor

EVF: Effort Variance Factor

EE: Effort Estimate

DE: Duration Estimate

Step 4: Resource ProfileThe Effort Variance Factor consists of:

– Skill Level

– Work Interruption

– Multi Project Assignment

– Project ProductivityEnvironment

Next we determine the Effort Variance Factor (EVF) for the person assigned to perform the activity. Wewill compute four factors about the person and aspects of their work setting. Then we will multiply thosefactors to determine the EVF for performing the activity.

We will describe each of the four factors in the discussion ahead. In short, they are:

• Skill Factor (SF): A factor that relates their skill level to that of a fully proficient resource for thatspecific activity.

• Work Interruption Factor (WIF): A factor that represents the impact of work interruption ontheir effort to complete the activity.

• Multi-Project Factor (MPF): A factor that represents the impact on a resource’s ability tocomplete an activity when assigned multiple projects.

• Project Productivity Influencing Factor (PPIF): A factor that represents the impact of a less-than-perfect work environment on the resource’s effort to complete the activity.

Skill Factor (SF)

1.4Competent in all task-related skills, solid knowledge ofsubject, good experience

Competent:Level 1

1.2Extensive subject matter knowledge, some learningcurve required

Proficient:Level 3

1.1Fully experienced, extensive subject matter knowledgeProficient:Level 2

1.5Competent at similar tasks, solid subject knowledge,some learning curve required

Competent:Level 2

2Possesses basic competencies for the task, somesubject knowledge, little experience

Learner:Level 1

1.75Competent at basic skills for the task, mid-range subjectknowledge, some experience

Competent:Level 3

1Fully experienced, subject matter expertProficient:Level 1

SFDescriptionSkillLevel

This slide shows a portion of the Skill Factor (SF) look-up table.

The first of the four factors, SF, is determined by assessing the skill level of the person assigned to do aparticular activity. It’s just common sense that an inexperienced person will require more effort-hours tocomplete a specific activity than a person who has had extensive experience with the activity.

• Proficient – Fully experienced, subject matter expert

• Competent – Competent in skills, solid knowledge of subject, good experience

• Learner – Basic competencies, some subject knowledge, little experience

• Novice – Some subject knowledge, extensive training needed, good work habits

The table starts with Proficient Level 1 Skill with a factor of 1 and continues to a SF of 4.0 for Novice,Level 3.

You will note that as the skill level decreases the skill factor increases. Notice that a Proficient Level 2skill will require 10 percent more effort-hours to complete the activity, hence a skill factor of 1.1

The table is used by looking for the description that best describes the skill level of the resource inperforming the assigned activity. Note that this factor will vary as the resource is assigned activities forwhich they have greater or lesser proficiency.

When a determination of SF has been made, the value is entered in the “SF” column of the ActivityDuration Estimating Worksheet.

Work Interruption Factor (WIF)• Time lost due to interruptions

• Interview team member

• Interview team member manager

• Historical data

WIF = 100100 - % of Time Lost Due to Interruptions

The WIF accounts for the interruptions we all face when we’re trying to complete our assigned projectwork. The reality is that when we have to repeatedly stop and start our work on an activity, it requiresmore overall effort to complete the activity than if we were able to do the work uninterrupted.

Once you come up with this number, you may find it useful to consult with the resource performing theactivity and their manager.

The Work Interruption Factor (WIF) is calculated based on the percentage of time you believe will be lostto interruption.

Let’s assume that you believe interruptions will cause a 20-percent loss in your work-time for theassigned activity.

The WIF is calculated using the formula shown on the slide, based on your estimate of time lost tointerruptions.

For a 20-percent loss:

WIF = 100 ÷ (100 - 20) = 100 ÷ 80 = 1.25

The result tells us that it will require 25 percent more effort-hours than the baseline estimate to completethe activity, based only on work interruptions.

In the example, the eight-hour task with a WIF of 25% will actually require 10 hours of effort. Thisincrease is due to the extra effort that is required to gear up after an interruption.

WIF

1.33251.25201.18151.1110

475250

1.82451.5435

1.055WIF

Percentage Lost Dueto Interruption

To make things easy, the table above shows WIF for commonly encountered work interruption rates.

Multi Project Factor

Work TimeAvailable

Work Day

Time lost tointerruptions

Time lost tomulti-projectassignment

Time lost tomulti-projectassignment

Project B

Project A

WI

MPF is perhaps the most subjective of the four factors. It’s very real, but tough to evaluate. The MultipleProject Factor accounts for the effort that is required to switch back and forth between tasks. It is based onthe level of assignment that a resource has to the project being estimated.

The Multiple Project Factor recognizes that there is some mental (and sometimes physical) gear shiftingrequired when you switch from working on one project to another project. This shifting is required, but itis essentially unproductive time.

For instance if it requires 20 minutes to mentally shift from project A to project B, and you spend 4 hoursworking on project B, then the 20-minute shifting time is reflected as a percentage relative to the 240 totalminutes of committed project B time. This equals roughly 10 percent.

However, if you are working on four projects a day, only two hours on each project per day, then thesame 20-minute shifting time represents a larger percentage of the committed project time, in this caseroughly 15 percent. So, the more projects you work on each day, the fewer hours per day you spend oneach project. Thus, the percentage of “mental shift time” will be a higher percentage of the time spent onany one project. If you only work on a project for one hour, the 20 minutes of shifting represents a 33percent loss of productivity, and therefore an increase in the number of effort-hours required to performthe activity.

Like the WIF, this means that more effort hours are required to achieve the productivity level. At 15percent (or a MPF of 1.18) you have to work 4.75 hours to achieve the four hours of productivitynecessary for the activity identified in the Baseline Effort Estimate.

Calculating MPF

1.2520%

1.1815%1.1110%MPF

% Lost Due to Multi-Project Assignment

MPF = 100100 - % of Time Lost Due to Switching Between Projects

2 projects3 projects4 projects

Research has led to the following estimates of the additional effort-hours required when working onmultiple projects. It’s not an exact science. We recommend that you start with the guidelines we offer andadjust them to the realities of your experience.

Assigned to one project:

• Additional effort hours = 0%

• MPF = 1.0

Assigned to two projects:


• MPF = 1.11

Assigned to three projects:


• MPF = 1.18

Assigned to four projects:


• MPF = 1.25

Project Productivity Influencing Factor• Team size

• Team location

• Tool stability

• Vendor support

1.0 1.5

No impact Max impact

The last factor is the Project Productivity Influencing Factor (PPIF). This is determined by evaluating anumber of environmental conditions that might diminish the team’s performance. The PPIF is simply theaverage of the ratings of the environmental conditions that apply to your project. For each environmentalcondition evaluated, you must make a subjective rating on a scale of 1.0 (no impact) to 1.5 (the maximumimpact). If an environmental condition has no impact on your project, just mark it N/A. You should onlyrate those that apply. To assist in this assessment, we offer some ideas about what represents no impactand maximum (max) impact in each environmental condition.

Team Size: Team communication channels go up exponentially as team size grows, and thereforeeffective communication becomes more challenging and time consuming.

• No impact (1.0): < 6-7 Team members• Max impact (1.5): 20+ Team members

Team Location: Travel, telephone tag, and other disruptions arise as the team becomes more dispersed.• No impact (1.0): Same location• Max impact (1.5): Multiple locations, multiple time zones

Tool Stability: Has a tool been stable and in place for several months? Is it unstable or new in service?• No impact (1.0): Stable• Max impact (1.5): Unstable

Vendor Support: Does your vendor respond to your requests in a quick and knowledgeable manner?• No impact (1.0): Quick and knowledgeable• Max impact (1.5): Slow and ineffective

PPIF

• Project duration

• Number of high issue stakeholders

• Turnover rate

• Team synergy

• Team-client synergy

1.0 1.5

No impact Max impact

Project Duration: Is the project of manageable duration, or are you running a marathon?• No impact: < 6 months• Max impact : >18 months

Number of Nemeses: A good PM can handle one or two nemeses. More than that can get challenging.• No impact: 1-2• Max impact : 3+

Turnover Rate: A high turnover rate can result in skills gaps, learning curve issues, and other challenges.• No impact: < 10%• Max impact : 30%+

Team Synergy: Are the team’s interpersonal relationships good, or is there considerable disharmony.• No impact: Works well together• Max impact : Chaotic

Team-Customer Synergy: Do you have a strong or weak relationship with your customer?• No impact: Strong• Max impact : Weak

PPIFProject ProductivityInfluencing Factors Range: 1 to 1.5

Team Size 1.00Team Location 1.00Tool Stability 1.25Vendor Support 1.00Project Duration 1.00Number of High IssueStakeholders 1.00

Turnover Rate 1.00Team Synergy 1.00Team-Client Synergy 1.50

PPIF = 1.08

The template shown on this slide is used to calculate the average value of the factors that apply to yourproject.

Simply add up all of the factors you rated and divide by the number of rated factors.

In the example shown, the sum of all of the factors is 7.2. Six factors were rated as applicable to theproject, so the average is 7.2 ÷ 6 = 1.2

You may now use the value of PPIF = 1.2 in further calculations.

NOTE: Unlike the other three factors in EVF, PPIF is related more to the environment than to the personperforming the activity. As such, you may be able to calculate PPIF once and apply the value in thecalculation of EVF’s for all project activities. Check to be sure that this is a valid approach in your case,particularly when team members are in different locations.

Effort Variance Factor Consists of…Skill Factor (SF)

X Work Interruption Factor (WIF)

X Multi-Project Factor (MPF)

X Project Productivity Influencing Factor(PPIF)

Effort Variance Factor (EVF)

You have now learned about the four factors listed on the slide. The next step is to combine them toobtain the EVF. The EVF is calculated by multiplying the four individual factors together.

Exercise• Assign each task for which you have a

Baseline Effort Estimate to someone on theteam

• Develop the Effort Variance Factor for eachteam member by assessing the following:– Skill Factor

– Work Interruption Factor

– Multi Project Factors


Effort Estimate

17 hrs*=2.8*6 hrs

EffortEstimate=EVF*Baseline

*Round up to the nearest whole number

Now that you have the EVF for the activity, you can calculate the Effort Estimate (EE) for the activity.

Remember, the EVF is nothing more than a “multiplier” of the baseline estimate that represents howmuch more effort will be required for the person assigned to complete the activity.

In the example, the baseline estimate is six hours. The EVF tells us that the resource assigned will require2.8 times more effort-hours than the baseline estimate to complete the activity.

EE = BE (6 hrs) x EVF (2.8) = 17 hours (round up)

The Activity Duration Worksheet calculates the EE.

Activity Duration Estimate

8=4÷31=5.1*Bill6EnterData

1.5=8÷12=2.9*Sue4WriteReport

DE=

ActivityHrs/WorkDay÷EE=EVF*ResourceBEActivity

Last, but not least, we finally arrive at the duration estimate.

For the “Enter Data” activity, the effort estimate is 31 hours and Bill is assigned to work on the activityfor four hrs/work day.

DE = 31 hrs ÷ 4 hrs/work day = 8 days (approximately)

Remember that effort is expressed in hours and duration is expressed in workdays. We recommend thatyou round up to half and full days when calculating duration estimates.

Exercise• Complete the Activity Duration Estimate

Template by including the Activity Hrs/WorkDay


Procurement Management Plan“The document that describes howprocurement progresses from developingprocurement documentation through contractclosure will be managed.” –PMBOK 4th Edition

Procurement Management begins by identifying project needs that may require the purchase oracquisition of products, services, or results outside of the organization. Procurement management endswhen a signed contract is received and the project negotiates a start date with the contractor or supplier.

SLP: Software Licensing Program

CSSI: California Strategic Sourcing Initiative

CCSI Exemption Request

Future OCIO plans include merging the IT Procurement Plan (ITPP) into the Procurement Planworksheet.

Contract Management Plan*To ensure that contractors and suppliers areadhering to the terms and conditions of thecontracts and providing the requiredservices/products that meet the expectations ofthe project.

*CA-PMM modification to PMBOK

Contract Management planning overlaps with the Procurement Management process.

The Contract Management Plan will guide the negotiations process with the selected Contractor orVendor.

Monitoring and Controlling begins when a signed contract is received and the project manager negotiatesa start date with the contractor or supplier.

Contract Management ends when the all contracted services/products have been delivered, accepted, andpaid for, and when all associated contract paperwork and files have been archived.

Organizational Change Management• To transition the people and processes

impacted by the project from their currentsituation to the new situation

• To ensure that a new situation has beenachieved and that it aligns with the strategicobjectives of the organization and the projectobjectives

Most projects will have an impact on business processes. They will directly impact the day-to-day jobs ofindividual employees. As a result, technology changes will require attention to the impacts that they haveon both process and people. Organizational Change Management focuses on ensuring that the changesaffecting people are addressed appropriately. Change inevitably results in an initial performance andmotivation decline, but effective Organizational Change Management helps minimize this drop.

Organizational Change Management is the process of aligning the organization's people and culture withproject changes in the business strategy, organizational structure, technology, and business processes.

Change has a tendency to elicit emotional responses. Therefore, any large-scale change initiative willlikely transfer the employees' focus from the business to transition-related issues. This shift in focus willlikely disrupt productivity.

However, an organization that implements a technology/business process transformation with integratedOrganizational Change Management will experience:

• The realization of the business transformation objectives

• Higher return on technology investments

• Retention of high performers

• Maintained and improved productivity

• Improved employee satisfaction and morale

M & O Transition Plan• To ensure that maintenance and operations

infrastructure is in place prior to the hand-offof the system, service, or product

• To facilitate the transfer of knowledge fromthe project team to the M&O team

The M&O infrastructure includes the procedures and policies, staffing, equipment, materials, training, andinformation needs.

It is important that the knowledge gained during the planning and development of the system, product, orservice be transferred to the team that takes over maintenance and operations. This can be via one-on-onetraining, classroom training, coaching, mentoring, operations manuals, and lessons learned.

Executing

The Project Management Plan is now completed and approved and you are authorized to begin the workon the project.

Executing

8. Deliverable Acceptance9. Status Report*10. Project Management Plan Update11. Benefit Validation12. Customer Acceptance13. Product Implementation

Deliverables & Performance Data

Executing Purpose“Those processes performed to complete thework defined in the project management planto satisfy the project objectives.” –PMBOK 4th Edition

*The “PM to Sponsor” and “Sponsor to Steering Committee” status reports are providedto the OCIO with the same frequency as the Independent Project Oversight Report.

The diagram above is the Executing Stage of the CA-PMM Diagram.

The primary purpose of Executing is to complete the work detailed in the Project Plan.

• This is accomplished by coordinating the activities of people assigned to do the work and theusage of other resources.

• The completed work should lead to a successful product that meets customer requirements.

The outputs of Executing are:

• Completed project and product deliverables

• Performance information for Monitoring and Control

• Project information for stakeholders

Deliverable Acceptance Criteria• Number

• Deliverables

• Acceptance Criteria

• Sign-off Authority

• Meets Yes/No

• Action Required

• Sign-off Date

Scope Verification criteria ensure that the completed work incorporates the scope of the work promised tothe customer.

Studies have shown that IT projects don’t usually deliver what was promised to the customer. Therefore itbehooves a PM to diligently review the latest scope statement in conjunction with the delivered scope andnote any discrepancies. It is important to discuss any shortcomings with the sponsor and key customersand then provide them with the best and most plausible reasons for the shortfall, along with solutions.

Depending on the timing, this list of missing functionality (deliverables and features) must becommunicated to the group responsible for ongoing maintenance and support of the system because theymay need to build emergency workarounds for any key missing functionalities.

Status Reports• Team to Project Manager

• Project Manager to Sponsor

• Sponsor to Executive/Steering Committee

• Monitoring Vital Signs

In Execution phase, the focus is on this area—required to be submitted to the OCIO for reporting on thepublic website. To accurately assess the status of a project, the project manager must focus on twoimportant sets of information:

1. The current status (where is the project now)

2. The future (look to the near future to see whether the team will complete upcoming tasks andmilestones as planned)

The excerpt for “Status Reports” are a little different; the reports are by menu item.

The level of detail in the status report depends on its intended audience. The PM wants to know the detailsabout all current and upcoming milestones and tasks. The sponsor will want to know the status withoutall the details. And the executive or steering committee will only want a very high-level and less-frequentreport.

Everybody reads vital signs – doctors, auto mechanics, and pilots. When a baby is born, the doctormonitors the infant’s pulse, reflexes, temperature, and general disposition. During a medical examination,the physician checks the patient’s vital signs – temperature, weight, blood pressure, and reflex. Automechanics monitor a car’s performance during a service, and airline traffic managers study the airplane’stake-off and landing performance. Every industry has its methods of checks and counter checks to assureefficient performance and to secure the safety and health of its customers. Every industry, that is, exceptfor IT. Ironically, the profession whose fundamental tenet is to produce precise information lacks the mostbasic information about its own projects.

• Vital signs offer a way to evaluate the overall health of a project. In fact, they are the metrics thatwe will use to measure project performance.

• Depending on the size of the project, The OCIO Project Management Lifecycle employs betweenseven and fifteen vital signs that indicate the health of a project. These vitals signs will be reportedmonthly as part of the Status Reporting Process.

Monitoring Vital Signs Scorecard• Aggregate indicators of the overall health of a

project

• 15 vital signs– Strategic

Strategy alignment, sponsorship, customer buy-in,technology viability, value-to-business, vendor viability

– Tactical Status of the critical path, milestone hit rate,

deliverable hit rate, unresolved issues, cost-to-date,actual resources vs. planned resources

– Environmental High probability-high impact risks, overtime utilization,

team disposition (effectiveness)

By the time sponsors realize that their projects are in trouble, often it is too late to take corrective actions.Project managers must monitor the vital signs of their projects, enabling prompt interventions and mid-course corrections. Project vital signs are aggregate indicators of the overall health of the project, verymuch like a hospital’s nursing station monitors patients’ heart and respiration rates. Vital signs can begrouped into three key categories:

Strategic: These vital signs focus on why we are doing the project and whether it is the right project.Abnormal variance in any of these vital signs should cause a serious re-evaluation of the project.

Tactical: These vital signs focus on how well we are accomplishing the goals of the project. Althoughabnormal variances in this area can also have a high degree of negative impact on the project, it is mucheasier to recover from the resulting problems.

Environmental: These vital signs relate to the work environment. These factors are difficult to instituteand measure as they relate to the management style of a particular organization, but nevertheless areimportant to everyone involved.

This information is provided to the public on the OCIO’s website under “Approved State IT Projects”

http://ocio.ca.gov/Business/projects.html

http://ocio.ca.gov/Government/IT_Policy/IT_Projects/

Called “Score Card” on the OCIO website.

Vital Signs

8. Strategy alignment

7. Sponsorship Commitment

6. Unresolved issues

5. High probability, highimpact risks

4. Cost-to-date

3. Status of the critical path

2. Technology viability

1. Customer buy-in

15. Team Effectiveness

14. Overtime utilization

13. Actual resources vs.planned resources

12. Deliverable hit rate

11. Milestone hit rate

10. Vendor viability

9. Value-to-business

Should be discussed with vendorIf “medium” or “weak” rating

Vital signs are a set of metrics designed to indicate different aspects of project health. The vital signsthat are checked on the slide are required for all projects regardless of size. Medium sized projectsmay measure additional vital signs if it is deemed appropriate for the project, and large and mega sizedprojects are required to measure all of the vital signs on a monthly basis.

• Green light– All is well

– Variance is acceptable

• Yellow light– Caution, trouble ahead

– The vital sign has reached a level at which it will begin to have anegative impact on the project

• Red light– Danger, measurable impact on the project– May be beyond project manager’s ability to recover

Vital Signs Indicators

The project manager monitors selected vital signs, each of which can have the following status:

• Green – All is well

• Yellow – Caution, trouble ahead

• Red – Danger, measurable negative impact on the project

Green: For a given vital sign, a green flag means the variance between planned and actual, if any, iswithin an acceptable range. For example, in the case of the critical path, a variance (delay) of up to 10percent may be defined as being normal and acceptable, as the team members have the ability to close thegap between planned and actual.

Yellow: For a given vital sign, a yellow flag indicates the point at which a breach in the performance ofthat vital sign will begin to negatively impact the project progress; it is usually beyond the team’s ownability to recover from the problem. For example, in the case of the critical path of a project, a variance(delay) between 10 to 20 percent should be defined as a Yellow condition. If a vital sign reaches this state,the project manager needs to meet with the appropriate team members, and at times with their functionalmanagers, and put a plan into action to bring the vital sign back into the Green status.

Red: For a given vital sign, a red flag indicates the point at which a breach in the performance of that vitalsign is beyond the project manager’s ability to recover from the problem and the project’s success is injeopardy. For example, in the case of the critical path, a variance (delay) of greater than 20 percent shouldbe defined as a Red condition. Once a given vital sign reaches the Red condition, the project managerneeds to meet with the functional managers of the appropriate team members and devise a plan ofrecovery.

Benefit Validation• Reality check

• If benefits are no longer valid, the projectmust be re-evaluated

• Refer to benefits stated in business case

• Explain assessment

• Describe action required

It is common, but not desirable, for organizations to continue investing in a project even though theexpected benefits have been deemed unrealistic.

During the Execution Stage of the project, we must determine if the stated benefits of the project arepossible to achieve. If and when we can see that the stated benefits are not possible, we must report this toour sponsor and work with him/her to determine the future of the project.

Benefit Validation

Analyze impact tooverall projectvalue; decidewhether tocontinue to pursuethis goal, or dropfrom Scope

Unable to eliminate allmanual spreadsheets;unable to createinterface betweenXYS system andfinance; best case is a25% reduction

validated

probable

possible

not possible

Reduce manualeffort in process by50%

NoneCost reduction basedon reducingdependence oncontractors; we haveincorporatedcontractor jobresponsibilities intoexisting stateemployee jobdescriptions

validated

probable

possible

not possible

3% reduction inoperating cost

Action RequiredExplanationAchievementStated Benefit

In the above example, the project manager is assessing a tangible benefit and an intangible benefit.

The tangible benefit of a 3% reduction in operating cost looks to be in good shape. The PM is successfullycompleting the work that will result in the cost reduction.

However, the intangible benefit of a 50% reduction in the manual effort involved in the work process isnot going to occur. The PM’s next task is to re-evaluate the overall value of the project in light of theinability to reduce the manual effort by 50% and then to make a recommendation to the sponsor abouthow to proceed.

Closing

Closing

14. Formal Product Acceptance15. Operations Metrics16. Transition to M&O17. Contract(s) Closure18. Administrative Closure19. Closing Checklist20. Post Implementation Evaluation Report*21. Lessons Learned

Contract/Administrative Closure

Closing Purpose“Those processes performed to finalize allactivities across all project managementprocess groups to formally close the project orphase.” –PMBOK 4th Edition

*The PIER is filed with the OCIO 6 to 18 months after implementation for reportable projects.

The diagram shows the Closing Stage of the CA-PMM. Closing executes the Maintenance and OperationsTransition plan.

Purpose:

• Formally terminate project activities

• Hand off completed products or close cancelled project

• Formally close project contracts

Outputs:

• Final product acceptance

• Contract closure

• Administrative closure

Formal Product Acceptance• Executing

– Deliverable acceptance

– Product implementation

• Closing– Product operating through pre determined cycles

– Final/formal overall product acceptance

Operations Metrics• Product performance measurements

• Established in the requirements

• Communicated to operations group

• Verified as part of the project closing process

Sample Operations Metrics:

The average time a connection spends communicatingwith they system.

AverageConnection Time

Number of connections that have failed to completesuccessfully.

ConnectionsFailed

Number of connections currently waiting in the queue tobe processed.

Connections inQueue

A count of the currently active connections that are openand sending information.

Active ReceivingConnections

Count of commands sent.Commands Sent

Total number of bytes sent out to connections.Bytes Sent

Total number of messages received by the system.MessagesReceived

Total number of bytes received since the system started.Bytes Received

Count of connections that successfully completed theirtransfer and confirmation.

ConnectionsCompleted

Contract(s) Closure• Process

– Check if final work products received/done

– Follow contractor evaluation process

– Verify final invoices received and processed

– Archive contract records

• Contract Tracking Database– What contract details will be

tracked?

Process

• What are the final work products required from the contractor?

• What is the process for evaluating the contractors’ performance?

• How are final invoices to be received and processed?

• How are contract records to be archived?

Contract Tracking Database

• What are the details for contract-tracking?

Administrative Closure• Collect, record, document and/or archive all project

information needed to formalize and finalize thatthe project (or phase) is closed

• Closure actions include:– Human resources: evaluate and release from the project– Contracts: follow all closure procedures– Assessment: analyze project success or failure and

capture lessons learned– Product/process: finalize transfer of ownership/authority

of product or operations to the customer– Organizational process assets: archive project data and

lessons learned

The PMBOK Guide describes Administrative Closure as follows: This procedure details all the activities,interactions, and related roles and responsibilities of the project team members and other stakeholdersinvolved in executing the administrative procedure for the project. Performing the administrative closureprocess also includes integrated activities needed to:

• Collect project records

• Analyze project success or failure

• Gather lessons learned

• Archive project information for future use by the organization

The OCIO Project Management Lifecycle separates the analysis of project success or failure into a PostImplementation Evaluation Report.

Post Implementation Evaluation• Post implementation and customer

acceptance

• Observation of how people are using theproduct

• Part of benefits measurement

• Results may require action

Taking a look at how people are really using the product of the project is a critical component of benefitsmeasurement.

The point is that how the system was actually being used had a major impact on the benefits derived. Thisstep won’t be necessary with all projects. What must be considered is the degree of misuse or non-use thatis possible with the product being implemented—before it’s implemented!

Product/System Use Review

See above;and meet withdirectors togainadditionalsupport

Unable to doreliabledemandplanning

No trust in datayes no

10/15//07B. SmithResourceAllocationReport

Reviewprocedures w/resourcemanagers

Resourcesappear to beover allocatedbut actually arenot

Not adjustingbase assignment% when projectcommitments aremade

yes no

10/15//07B. SmithBaseServiceSchedule

yes no

10/15//07B. SmithGlobalTemplate

ActionRequired

andDue Date

ImpactIf not, why notUsed asdesigned

DateObservedObserverProduct

The example above is from a Enterprise Project Management software installation in an IT departmentthat employs about 500 people domestically and 200 people internationally.

• The first product reviewed was the global template used to build project schedules. The reviewwas to determine if people were making modifications to the template and if so what type ofmodifications were being made. It was found that while some individuals were makingmodifications - adding views, columns, etc. – the modifications were reasonable and unique to theproject being scheduled.

• The second product reviewed was the schedule used to account for each individual’s non-projectwork. That was called the base service schedule, and each resource manager had a base serviceschedule for the individual’s reporting to him/her. What was found was that the resource managerswere not adjusting the base service schedules when assigning their individual resources to projectwork. If the original base service assignment was 55% of the individual’s time, and the resourcemanager had committed the resource to three projects – each at 25%, the resource manager wasnot reducing the base assignment to 25% thereby creating a 130% assignment. In some cases, thetime required was greater than 100% of the time, however, it was difficult to pick those outbecause so many over allocated resource assignments were a result of not making the properadjustments to the schedule as opposed to actual demand.

• The third product was the resource allocation report that was generated from all project schedulesand all base service schedules. A stated benefit of the implementation was to do effective demandplanning. Unless and until people were using the system properly, that benefit would nevermaterialize.

A thorough system use review led to some adjustments and additional training, and the organization wasable to do a much better job of managing the demand from the rest of the company.

PIER Costs• Last approved alternative costs

• Actual project costs

• Cost comparison

Final Lessons Learned• Conduct lessons learned sessions for all projects

with key internal and external stakeholders• Focus on technical or developmental processes

– aided– hindered

• Specific results from lessons learned include:– Update of the lessons learned database– Input to the knowledge management system– Updated corporate policies, procedures and processes– Improved business skills– Overall product and service improvements– Updates to the risk management plan

The focus of lessons learned meetings can vary, e.g.:

• Strong focus on technical or developmental processes

• Focus on processes that aided or hindered performance of the work

Project managers have a professional obligation to conduct lessons learned sessions for all projects withkey internal and external stakeholders, particularly if the project yielded less than desirable results.

Some specific results from lessons learned include:

• Update of the lessons learned database

• Input to the knowledge management system

• Updated corporate policies, procedures and processes

• Improved business skills

• Overall product and service improvements

• Updates to the risk management plan

Maintenance &Operations

Projects enter Maintenance and Operations and close when benefits have been measured.