Knowledge Base

Project Managers
KnowledgeBase:
PMP Prep with Practice Exams
PMBOK Case Studies

Processes
Tools
Templates
Techniques
2nd Edition
By Dick Billows, PMP, GCA
The Project Managers KnowledgeBase
HOW TO USE THE PROJECT

MANAGERS KNOWLEDGEBASE
I've organized the material in the book so that you can adapt it to your individual learning
style. The book will not only help you prepare for the Project Management Institutes
PMI) certification examinations (PMP and CAPM) it is also a guide to applying the
PMBOK1 to your projects. Ill refer to the PMBOK throughout the book and rely on the
full citation at the bottom of this page to avoid cumbersome duplication.
The KnowledgeBase allows you to study in ways that fit your learning style. You can:
;
Read about concepts and use the flow charts to learn the details
Use the 10 practice exams with the explanations of the answers
;
Read real life examples and dialog between project managers and sponsors,
stakeholders and the team as they apply the PMBOK to different size projects. See their:
scope statements, project charter, benefit/cost analyses, Monte Carlo simulation results and
hundreds more examples.
The chapters in this book cover the nine knowledge areas in the PMBOK and a 10th
chapter on professionalism and ethics, which is on the exams but not in the PMBOK.
Each chapter is divided into four sections:
;
Discussions of PMBOK concepts with flow charts of all the PMBOK processes
and their tools and techniques to help you learn the sequence of inputs, processes and
outputs.
;
Practice examinations with answers and explanations.
;
Application of the PMBOK concepts to three different size projects where you see
project managers actually use the techniques and explain processes and results to the project
sponsor.
;
PMBOK toolset pages that explain each tool with examples.
Use these components to tailor your exam prep to your individual learning style.
Best regards,
Dick Billows, PMP, GCA
P.S. As always my thanks to my project consultants and nit-picking editorial staff: Sally
Mitsch, Leslie Schiefelbein CAPM, Elizabeth Graves CAPM and Juana Cortez. Their work
in finding flaws, from conceptual to grammatical was superb. Any remaining errors come
from problems I intentionally hid from them.
1 A Guide to the Project Management Body of Knowledge; PMBOK Guide 2000 Edition, The Project Management
Institute, Inc., 4 Campus Boulevard, Newton Square, PA 197003
Copyright 2004 Richard Billows All Rights Reserved

May not be reproduced in any form without written permission
Table of Contents
HOW TO USE THE PROJECT MANAGERS KNOWLEDGEBASE ...................3
SCOPE MANAGEMENT ....................................................................................22
Scope Initiation ........................................................................................................................................... 22
INPUTS TO SCOPE INITIATION ................................................................................................................... 22
TOOLS & TECHNIQUES OF INITIATION ...................................................................................................... 23
OUTPUTS FROM SCOPE INITIATION ............................................................................................................ 24
Scope Planning............................................................................................................................................ 24
INPUTS TO SCOPE PLANNING .................................................................................................................... 25
TOOLS AND TECHNIQUES OF SCOPE PLANNING ......................................................................................... 25
OUTPUTS FROM SCOPE PLANNING ............................................................................................................. 25
Scope Definition.......................................................................................................................................... 26
INPUTS FOR SCOPE DEFINITION ................................................................................................................. 26
TOOLS AND TECHNIQUES OF SCOPE DEFINITION ....................................................................................... 26
OUTPUTS OF SCOPE DEFINITION ............................................................................................................... 27
Scope Verification....................................................................................................................................... 27
INPUTS TO SCOPE VERIFICATION .............................................................................................................. 27
TOOLS AND TECHNIQUES OF SCOPE VERIFICATION ................................................................................... 27
OUTPUTS OF SCOPE VERIFICATION ............................................................................................................ 28
Scope Change Control................................................................................................................................ 28
INPUTS TO SCOPE CHANGE CONTROL ........................................................................................................ 28
TOOLS AND TECHNIQUES OF SCOPE CHANGE CONTROL ............................................................................. 28
OUTPUTS OF SCOPE CHANGE CONTROL ..................................................................................................... 29
APPLYING THE PMBOK SCOPE MANAGEMENT CONCEPTS: ..................30

Applying Project Initiation ........................................................................................................................ 32
PROJECT #1: IN-DEPARTMENT INITIATION ................................................................................................ 33
PROJECT #2: CROSS-FUNCTIONAL INITIATION .......................................................................................... 35
PROJECT #3: CONSULTING INITIATION ...................................................................................................... 40
Scope Planning............................................................................................................................................ 41
PROJECT #1: IN-DEPARTMENT SCOPE PLANNING ...................................................................................... 42
PROJECT #2: CROSS-FUNCTIONAL SCOPE PLANNING ............................................................................... 44
PROJECT #3: CONSULTING SCOPE PLANNING ........................................................................................... 46
Scope Definition.......................................................................................................................................... 49
PROJECT #1: IN-DEPARTMENT SCOPE DEFINITION .................................................................................... 49
PROJECT #2: CROSS-FUNCTIONAL SCOPE DEFINITION .............................................................................. 51
PROJECT #3: CONSULTING SCOPE DEFINITION ......................................................................................... 53


Scope Verification....................................................................................................................................... 55
PROJECT #1: IN-DEPARTMENT SCOPE VERIFICATION................................................................................ 56
PROJECT #2: CROSS-FUNCTIONAL SCOPE VERIFICATION .......................................................................... 57
PROJECT #3: CONSULTING SCOPE VERIFICATION ..................................................................................... 58
Scope Change Control................................................................................................................................ 58
Alternatives Identification: Brainstorming & Lateral Thinking ................................................................... 59
Scope Statement ........................................................................................................................................... 60
Project Selection Methods............................................................................................................................ 61
Project Charter.............................................................................................................................................. 62
Product Analysis........................................................................................................................................... 64
Benefit/Cost Analysis................................................................................................................................... 65
WBS templates ............................................................................................................................................. 66
Performance Measurement & Variance Analysis......................................................................................... 67
Constraints and Assumptions ....................................................................................................................... 68
Expert Judgment........................................................................................................................................... 69
Decomposition.............................................................................................................................................. 70
Inspections and Audits ................................................................................................................................. 71
Corrective Action ......................................................................................................................................... 72
Lessons Learned ........................................................................................................................................... 73
Work Breakdown Structure (WBS).............................................................................................................. 74
SCOPE PRACTICE EXAM.................................................................................76

PROJECT TIME MANAGEMENT ......................................................................83
Activity Definition ...................................................................................................................................... 83
INPUTS TO ACTIVITY DEFINITION ............................................................................................................. 83
TOOLS AND TECHNIQUES OF ACTIVITY DEFINITION ................................................................................. 84
OUTPUTS OF ACTIVITY DEFINITION .......................................................................................................... 84
Activity Sequencing .................................................................................................................................... 84
INPUTS TO ACTIVITY SEQUENCING ........................................................................................................... 84
TOOLS & TECHNIQUES OF ACTIVITY SEQUENCING .................................................................................. 85
OUTPUTS OF ACTIVITY SEQUENCING ........................................................................................................ 87
Activity Duration Estimating .................................................................................................................... 87
INPUTS TO ACTIVITY DURATION ESTIMATING .......................................................................................... 87
TOOLS AND TECHNIQUES OF ACTIVITY DURATION ESTIMATING ............................................................... 88
OUTPUTS OF ACTIVITY DURATION ESTIMATING ...................................................................................... 88
Schedule Development ............................................................................................................................... 89
INPUTS TO SCHEDULE DEVELOPMENT ...................................................................................................... 89
TOOLS AND TECHNIQUES OF SCHEDULE DEVELOPMENT .......................................................................... 89
RESOURCE LEVELING ............................................................................................................................... 93
OUTPUTS OF SCHEDULE DEVELOPMENT ................................................................................................... 93
Schedule Control ........................................................................................................................................ 93
INPUTS TO SCHEDULE CONTROL ............................................................................................................... 93
TOOLS AND TECHNIQUES OF SCHEDULE CONTROL .................................................................................. 94
OUTPUTS OF SCHEDULE CONTROL ............................................................................................................ 94
APPLYING THE PMBOK TIME MANAGEMENT CONCEPTS .......................95


Activity Definition ...................................................................................................................................... 97
PROJECT #1: IN-DEPARTMENT ACTIVITY DEFINITION............................................................................... 97
PROJECT #2: CROSS-FUNCTIONAL ACTIVITY DEFINITION ......................................................................... 99
PROJECT #3: CONSULTING ACTIVITY DEFINITION .................................................................................. 101
Activity Sequencing .................................................................................................................................. 102
PROJECT #1: IN-DEPARTMENT ACTIVITY SEQUENCING .......................................................................... 103
PROJECT #2: CROSS-FUNCTIONAL ACTIVITY SEQUENCING .................................................................... 105
PROJECT #3: CONSULTING ACTIVITY SEQUENCING ................................................................................ 106
Activity Duration Estimating .................................................................................................................. 107
PROJECT #1: IN-DEPARTMENT DURATION ESTIMATING .......................................................................... 107
PROJECT #2: CROSS-FUNCTIONAL DURATION ESTIMATING .................................................................... 110
PROJECT #3: CONSULTING ACTIVITY DURATION ESTIMATING ............................................................... 112
Schedule Development ............................................................................................................................. 113
PROJECT #1: IN-DEPARTMENT SCHEDULE DEVELOPMENT ...................................................................... 114
PROJECT #2: CROSS-FUNCTIONAL SCHEDULE DEVELOPMENT ................................................................ 117
PROJECT #3: CONSULTING SCHEDULE DEVELOPMENT ........................................................................... 120
Schedule Change Control ........................................................................................................................ 121
Decomposition............................................................................................................................................ 123
WBS templates ........................................................................................................................................... 124
Precedence Diagramming Method (AON Networks)................................................................................. 125
Arrow Diagramming Method ..................................................................................................................... 126
Conditional Diagramming Methods (GERT) ............................................................................................. 127
Performance Measurement & Variance Analysis....................................................................................... 128
Network Templates .................................................................................................................................... 129
Critical Path Method (CPM)....................................................................................................................... 130
Resource Capabilities ................................................................................................................................. 131
Quantitatively Based Durations.................................................................................................................. 131
Analogous Estimating ................................................................................................................................ 132
Reserve Time (Contingency)...................................................................................................................... 133
Program Evaluation and Review Technique (PERT) ................................................................................. 134
Duration Compression................................................................................................................................ 136
Resource Calendars .................................................................................................................................... 137
Bar (Gantt) Charts ...................................................................................................................................... 138
Milestone Charts......................................................................................................................................... 138
Network Diagrams...................................................................................................................................... 139
Simulations (Monte Carlo & Probabilistic Analysis) ................................................................................. 140
TIME PRACTICE EXAM...................................................................................141

PROJECT COST MANAGEMENT ...................................................................148
Cost tools Used in Many PMBOK Processes....................................................................................... 148
Time Value of Money ................................................................................................................................ 148
Net Present Value ....................................................................................................................................... 149
Payback Period, B/C Ratio & IRR ............................................................................................................. 149
Costs: Variable, Direct, Fixed, Sunk, Opportunity & Life Cycle............................................................... 149
Resource Planning .................................................................................................................................... 150
INPUTS TO RESOURCE PLANNING ........................................................................................................... 150
TOOLS AND TECHNIQUES FOR RESOURCE PLANNING ............................................................................. 151


OUTPUTS FROM RESOURCE PLANNING ................................................................................................... 151
Cost Estimating......................................................................................................................................... 151
INPUTS TO COST ESTIMATING................................................................................................................. 151
TOOLS AND TECHNIQUES FOR COST ESTIMATING .................................................................................. 152
Bottom-up Estimating ................................................................................................................................ 152
Parametric Estimating ................................................................................................................................ 153
OUTPUTS FROM COST ESTIMATING ........................................................................................................ 153
Order of Magnitude, Budget & Definitive Estimates ................................................................................. 153
Cost Budgeting.......................................................................................................................................... 154
INPUTS TO COST BUDGETING ................................................................................................................. 154
TOOLS AND TECHNIQUES OF COST BUDGETING ..................................................................................... 154
OUTPUTS FROM COST BUDGETING ......................................................................................................... 155
Earned Value .............................................................................................................................................. 155
Cost Control.............................................................................................................................................. 155
INPUTS TO COST CONTROL ..................................................................................................................... 155
TOOLS AND TECHNIQUES OF COST CONTROL ......................................................................................... 156
PERCENTAGE COMPLETE REPORTING ..................................................................................................... 158
OUTPUTS FROM COST CONTROL ............................................................................................................. 158
APPLYING THE PMBOK COST MANAGEMENT CONCEPTS....................159

Resource Planning .................................................................................................................................... 161
PROJECT #1: IN-DEPARTMENT RESOURCE PLANNING ............................................................................. 161
PROJECT #2: CROSS-FUNCTIONAL RESOURCE PLANNING ....................................................................... 163
PROJECT #3: CONSULTING RESOURCE PLANNING .................................................................................. 164
Cost Estimating......................................................................................................................................... 166
PROJECT #1: IN-DEPARTMENT COST ESTIMATING .................................................................................. 166
PROJECT #2: CROSS-FUNCTIONAL COST ESTIMATING ............................................................................ 168
PROJECT #3: CONSULTING COST ESTIMATING........................................................................................ 170
Cost Budgeting.......................................................................................................................................... 171
PROJECT #1: IN-DEPARTMENT COST BUDGETING ................................................................................... 171
PROJECT #2: CROSS-FUNCTIONAL COST BUDGETING ............................................................................. 172
PROJECT #3: CONSULTING COST BUDGETING ........................................................................................ 174
Cost Monitoring and Control .................................................................................................................. 175
Expert Judgment......................................................................................................................................... 177
Performance measurement & Variance Analysis ....................................................................................... 178
Alternatives Identification: Brainstorming & Lateral Thinking ................................................................. 179
Project Management Software & Computerized Tools .............................................................................. 180
Parametric Estimating ................................................................................................................................ 182
Bottom-up Estimating ................................................................................................................................ 183
Earned Value Management (EVM) ............................................................................................................ 184
Net Present Value, Payback period, Benefit/Cost Ratio, IRR .................................................................... 186
Cost Estimating .......................................................................................................................................... 187
COST PRACTICE EXAM .................................................................................188


QUALITY MANAGEMENT ...............................................................................195
Quality Planning....................................................................................................................................... 195
INPUTS TO QUALITY PLANNING .............................................................................................................. 195
TOOLS AND TECHNIQUES FOR QUALITY PLANNING................................................................................ 196
OUTPUTS FROM QUALITY PLANNING ..................................................................................................... 197
Quality Assurance .................................................................................................................................... 198
INPUTS TO QUALITY ASSURANCE ........................................................................................................... 198
TOOLS AND TECHNIQUES FOR QUALITY ASSURANCE ............................................................................. 198
OUTPUTS FROM QUALITY ASSURANCE ................................................................................................... 199
Quality Control......................................................................................................................................... 199
INPUTS TO QUALITY CONTROL ............................................................................................................... 199
TOOLS AND TECHNIQUES FOR QUALITY CONTROL ................................................................................. 199
OUTPUTS FROM QUALITY CONTROL....................................................................................................... 202
APPLYING THE PMBOK QUALITY MANAGEMENT CONCEPTS ..............203

Quality Planning....................................................................................................................................... 205
PROJECT #1: IN-DEPARTMENT QUALITY PLANNING ............................................................................... 205
PROJECT #2: CROSS-FUNCTIONAL QUALITY PLANNING ......................................................................... 208
PROJECT #3: CONSULTING QUALITY PLANNING ..................................................................................... 210
Quality assurance ..................................................................................................................................... 212
PROJECT #1: IN-DEPARTMENT QUALITY ASSURANCE............................................................................. 212
PROJECT #2: CROSS-FUNCTIONAL QUALITY ASSURANCE ....................................................................... 213
PROJECT #3: CONSULTING QUALITY ASSURANCE .................................................................................. 215
Quality Control......................................................................................................................................... 216
PROJECT #1: IN-DEPARTMENT QUALITY CONTROL ................................................................................ 216
PROJECT #2: CROSS-FUNCTIONAL QUALITY CONTROL........................................................................... 217
PROJECT #3: CONSULTING QUALITY CONTROL ...................................................................................... 218
Quality Management Plan .......................................................................................................................... 221
Operational Definitions .............................................................................................................................. 222
Benefit/Cost Analysis................................................................................................................................. 223
Benchmarking ............................................................................................................................................ 224
Process Flow Charts & Process Adjustments ............................................................................................. 225
Cause and Effect Diagram (Fishbone or Ishikawa) .................................................................................... 226
Design of Experiments ............................................................................................................................... 227
Cost of Quality ........................................................................................................................................... 228
Checklists and Quality Audits .................................................................................................................... 229
Control Charts ............................................................................................................................................ 230
Statistical Sampling & Sample Sizes.......................................................................................................... 231
Pareto Diagrams ......................................................................................................................................... 232
Rework ....................................................................................................................................................... 233
QUALITY PRACTICE EXAM............................................................................234

PROJECT HUMAN RESOURCE MANAGEMENT ..........................................241
Organizational Planning .......................................................................................................................... 241
INPUTS TO ORGANIZATIONAL PLANNING ............................................................................................... 241


TOOLS AND TECHNIQUES OF ORGANIZATIONAL PLANNING ................................................................... 242
OUTPUTS FROM ORGANIZATIONAL PLANNING ....................................................................................... 243
Staff Acquisition ....................................................................................................................................... 245
INPUTS TO STAFF ACQUISITION .............................................................................................................. 245
TOOLS AND TECHNIQUES FOR STAFF ACQUISITION ................................................................................ 245
OUTPUTS FROM STAFF ACQUISITION ...................................................................................................... 246
Team Development................................................................................................................................... 246
INPUTS TO TEAM DEVELOPMENT............................................................................................................ 247
TOOLS AND TECHNIQUES FOR TEAM DEVELOPMENT ............................................................................. 247
OUTPUTS FROM TEAM DEVELOPMENT ................................................................................................... 249
APPLYING THE PMBOK HUMAN RESOURCE CONCEPTS ......................250

Organizational Planning .......................................................................................................................... 252
PROJECT #1: IN-DEPARTMENT ORGANIZATIONAL PLANNING ................................................................. 252
PROJECT #2: CROSS-FUNCTIONAL ORGANIZATIONAL PLANNING ........................................................... 254
PROJECT #3: CONSULTING ORGANIZATIONAL PLANNING....................................................................... 256
STAFF ACQUISITION ............................................................................................................................... 257
PROJECT #1: IN-DEPARTMENT STAFF ACQUISITION ................................................................................ 257
PROJECT #2: CROSS-FUNCTIONAL STAFF ACQUISITION .......................................................................... 258
PROJECT #3: CONSULTING STAFF ACQUISITION ..................................................................................... 260
Team Development................................................................................................................................... 261
PROJECT #1: IN-DEPARTMENT TEAM DEVELOPMENT ............................................................................. 261
PROJECT #2: CROSS-FUNCTIONAL TEAM DEVELOPMENT ....................................................................... 262
PROJECT #3: CONSULTING TEAM DEVELOPMENT ................................................................................... 263
Project Team Directory .............................................................................................................................. 265
Stakeholder Analysis .................................................................................................................................. 266
Staffing Management Plan ......................................................................................................................... 267
Negotiations................................................................................................................................................ 268
Team Building............................................................................................................................................ 269
Resource Availability ................................................................................................................................. 270
Role and Responsibility Matrix.................................................................................................................. 271
Resource Histogram ................................................................................................................................... 271
Input to Performance Appraisals ................................................................................................................ 272
HUMAN RESOURCES PRACTICE EXAM ......................................................273

PROJECT COMMUNICATIONS MANAGEMENT ...........................................280
Communications Planning....................................................................................................................... 280
INPUTS TO COMMUNICATIONS PLANNING .............................................................................................. 280
TOOLS AND TECHNIQUES FOR COMMUNICATIONS PLANNING ................................................................ 281
OUTPUTS FROM COMMUNICATIONS PLANNING ...................................................................................... 281
Information Distribution ......................................................................................................................... 281
INPUTS TO INFORMATION DISTRIBUTION ................................................................................................ 282
TOOLS AND TECHNIQUES FOR INFORMATION DISTRIBUTION.................................................................. 282
OUTPUTS FROM INFORMATION DISTRIBUTION........................................................................................ 283
Performance Reporting............................................................................................................................ 283

INPUTS TO PERFORMANCE REPORTING ................................................................................................... 284
TOOLS AND TECHNIQUES FOR PERFORMANCE REPORTING ..................................................................... 284
OUTPUTS FROM PERFORMANCE REPORTING........................................................................................... 284
Administrative Closure ............................................................................................................................ 284
INPUTS TO ADMINISTRATIVE CLOSURE .................................................................................................. 285
TOOLS AND TECHNIQUES FOR ADMINISTRATIVE CLOSURE .................................................................... 285
OUTPUTS FROM ADMINISTRATIVE CLOSURE .......................................................................................... 285
APPLYING THE PMBOK COMMUNICATIONS MANAGEMENT CONCEPTS

..........................................................................................................................286
Communications Planning....................................................................................................................... 288
PROJECT #1: IN-DEPARTMENT COMMUNICATIONS PLANNING ................................................................ 288
PROJECT #2: CROSS-FUNCTIONAL COMMUNICATIONS PLANNING .......................................................... 289
PROJECT #3: CONSULTING COMMUNICATIONS PLANNING ..................................................................... 290
Information Distribution ......................................................................................................................... 290
PROJECT #1: IN-DEPARTMENT INFORMATION DISTRIBUTION ................................................................. 290
PROJECT #2: CROSS-FUNCTIONAL INFORMATION DISTRIBUTION ........................................................... 292
PROJECT #3: CONSULTING INFORMATION DISTRIBUTION ....................................................................... 293
Performance Reporting............................................................................................................................ 294
PROJECT #1: IN-DEPARTMENT PERFORMANCE REPORTING .................................................................... 294
PROJECT #2: CROSS-FUNCTIONAL PERFORMANCE REPORTING............................................................... 294
PROJECT #3: CONSULTING PERFORMANCE REPORTING .......................................................................... 295
Administrative Closure ............................................................................................................................ 296
PROJECT #1: IN-DEPARTMENT ADMINISTRATIVE CLOSURE .................................................................... 296
PROJECT #2: CROSS-FUNCTIONAL ADMINISTRATIVE CLOSURE .............................................................. 297
PROJECT #3: CONSULTING ADMINISTRATIVE CLOSURE ......................................................................... 298
Communications Management Plan........................................................................................................... 299
Communications Network.......................................................................................................................... 300
Stakeholder Analysis .................................................................................................................................. 301
Information Retrieval Systems ................................................................................................................... 302
Performance Reviews and Project Reports................................................................................................. 302
Lessons Learned ......................................................................................................................................... 304
COMMUNICATION PRACTICE EXAM ............................................................308

PROJECT RISK MANAGEMENT ....................................................................315
Risk Management Planning..................................................................................................................... 315
INPUTS TO RISK MANAGEMENT PLANNING ............................................................................................ 315
TOOLS AND TECHNIQUES FOR RISK MANAGEMENT PLANNING .............................................................. 316
OUTPUTS FROM RISK MANAGEMENT PLANNING .................................................................................... 316
Risk Identification .................................................................................................................................... 316
INPUTS TO RISK IDENTIFICATION ............................................................................................................ 317
TOOLS AND TECHNIQUES FOR RISK IDENTIFICATION ............................................................................. 318
OUTPUTS FROM RISK IDENTIFICATION ................................................................................................... 318
10


Qualitative Risk Analysis......................................................................................................................... 319
INPUTS TO QUALITATIVE RISK ANALYSIS ............................................................................................... 319
TOOLS AND TECHNIQUES FOR QUALITATIVE RISK ANALYSIS ................................................................ 320
OUTPUTS FROM QUALITATIVE RISK ANALYSIS ....................................................................................... 321
Quantitative Risk Analysis ...................................................................................................................... 321
INPUTS TO QUANTITATIVE RISK ANALYSIS ............................................................................................ 321
TOOLS AND TECHNIQUES FOR QUANTITATIVE RISK ANALYSIS .............................................................. 322
OUTPUTS FROM QUANTITATIVE RISK ANALYSIS .................................................................................... 323
Risk Response Planning ........................................................................................................................... 323
INPUTS TO RISK RESPONSE PLANNING ................................................................................................... 324
TOOLS AND TECHNIQUES FOR RISK RESPONSE PLANNING ..................................................................... 324
OUTPUTS FROM RISK RESPONSE PLANNING ........................................................................................... 325
Risk Monitoring and Control .................................................................................................................. 325
INPUTS TO RISK MONITORING AND CONTROL ........................................................................................ 326
TOOLS AND TECHNIQUES FOR RISK MONITORING AND CONTROL .......................................................... 326
OUTPUTS FROM RISK MONITORING AND CONTROL ................................................................................ 326
APPLYING THE PMBOK RISK MANAGEMENT CONCEPTS .....................328

Risk Management Planning..................................................................................................................... 330
PROJECT #1: IN-DEPARTMENT RISK MANAGEMENT PLANNING .............................................................. 330
PROJECT #2: CROSS-FUNCTIONAL RISK MANAGEMENT PLANNING ........................................................ 332
PROJECT #3: CONSULTING RISK MANAGEMENT PLANNING ................................................................... 333
Risk Identification .................................................................................................................................... 334
PROJECT #1: IN-DEPARTMENT RISK IDENTIFICATION ............................................................................. 334
PROJECT #2: CROSS-FUNCTIONAL RISK IDENTIFICATION ....................................................................... 336
PROJECT # 3: CONSULTING RISK IDENTIFICATION .................................................................................. 338
Qualitative Risk Analysis......................................................................................................................... 341
PROJECT #1: IN-DEPARTMENT QUALITATIVE RISK ANALYSIS ................................................................ 342
PROJECT #2: CROSS-FUNCTIONAL QUALITATIVE RISK ANALYSIS........................................................... 343
PROJECT # 3: CONSULTING QUALITATIVE RISK ANALYSIS ..................................................................... 345
Quantitative Risk Analysis ...................................................................................................................... 346
PROJECT #1: IN-DEPARTMENT QUANTITATIVE RISK ANALYSIS .............................................................. 347
PROJECT #2: CROSS-FUNCTIONAL QUANTITATIVE RISK ANALYSIS ........................................................ 348
PROJECT #3: CONSULTING QUANTITATIVE RISK ANALYSIS ................................................................... 350
Risk Response Planning ........................................................................................................................... 352
PROJECT #1: IN-DEPARTMENT RISK RESPONSE PLANNING ..................................................................... 352
PROJECT #2: CROSS-FUNCTIONAL RISK RESPONSE PLANNING ............................................................... 353
PROJECT #3: CONSULTING RISK RESPONSE PLAN .................................................................................. 355
Risk Monitoring and Control .................................................................................................................. 356
Risk Management Plan............................................................................................................................... 357
Planning Meetings...................................................................................................................................... 358
Risk Categories & Checklists ..................................................................................................................... 359
Delphi Technique ....................................................................................................................................... 360
Cause and Effect Diagram (Fishbone or Ishikawa) .................................................................................... 361
Influence Diagram ...................................................................................................................................... 362
Pareto Diagram........................................................................................................................................... 363
11

Risk Triggers .............................................................................................................................................. 364
Data Precision Ranking .............................................................................................................................. 365
Scales of Probability & Impact & P/I Matrix ............................................................................................. 366
Assumptions Testing .................................................................................................................................. 367
Overall Risk Ranking ................................................................................................................................. 368
Interviewing................................................................................................................................................ 368
Sensitivity Analysis .................................................................................................................................... 369
Decision Tree Analysis............................................................................................................................... 370
Simulations (Monte Carlo & Probabilistic Analysis) ................................................................................. 371
Trends in Risk Analysis Results................................................................................................................. 372
Risk Responses (Avoid, Transfer, Mitigate, Accept) ................................................................................. 373
Residual Risks and Secondary Risks.......................................................................................................... 373
Contingency Reserve.................................................................................................................................. 374
Risk Response Audits & Risk Reviews...................................................................................................... 375
RISK PRACTICE EXAM...................................................................................376

PROCUREMENT MANAGEMENT...................................................................383
Procurement Planning ............................................................................................................................. 384
INPUTS TO PROCUREMENT PLANNING .................................................................................................... 384
Availability of Procurement Resources ...................................................................................................... 384
TOOLS & TECHNIQUES OF PROCUREMENT PLANNING ............................................................................ 385
Make-or-Buy Decisions.............................................................................................................................. 385
Selecting the Contract Type ....................................................................................................................... 385
OUTPUTS OF PROCUREMENT PLANNING ................................................................................................. 386
Statement of Work (SOW) ......................................................................................................................... 386
Procurement Management Plan.................................................................................................................. 387
Solicitation Planning ................................................................................................................................ 387
INPUTS TO SOLICITATION PLANNING ...................................................................................................... 387
TOOLS AND TECHNIQUES OF SOLICITATION PLANNING .......................................................................... 387
Standard Forms........................................................................................................................................... 387
OUTPUTS OF SOLICITATION PLANNING................................................................................................... 388
Procurement Documents ............................................................................................................................ 388
Evaluation Criteria ..................................................................................................................................... 389
Solicitation................................................................................................................................................. 389
INPUTS TO SOLICITATION ....................................................................................................................... 389
TOOLS & TECHNIQUES OF SOLICITATION ............................................................................................... 389
Advertising ................................................................................................................................................. 389
Bidder Conferences .................................................................................................................................... 390
OUTPUTS OF SOLICITATION .................................................................................................................... 390
Source Selection........................................................................................................................................ 390
INPUTS TO SOURCE SELECTION ............................................................................................................... 390
TOOLS AND TECHNIQUES OF SOURCE SELECTION .................................................................................. 390
Screening System ....................................................................................................................................... 391
Weighting System ...................................................................................................................................... 391
Contract Negotiation .................................................................................................................................. 391
OUTPUTS OF SOURCE SELECTION ........................................................................................................... 391
Contract Administration.......................................................................................................................... 392
INPUTS TO CONTRACT ADMINISTRATION ................................................................................................ 392
12


TOOLS & TECHNIQUES OF CONTRACT ADMINISTRATION ....................................................................... 392
OUTPUTS OF CONTRACT ADMINISTRATION ............................................................................................ 392
Contract Closeout..................................................................................................................................... 393
INPUTS TO CONTRACT CLOSEOUT ........................................................................................................... 393
TOOLS & TECHNIQUES OF CONTRACT CLOSEOUT .................................................................................. 393
OUTPUTS OF CONTRACT CLOSEOUT ....................................................................................................... 393
APPLYING THE PMBOK PROCUREMENT MANAGEMENT CONCEPTS..394

Procurement Planning ............................................................................................................................. 395
PROJECT#1: IN-DEPARTMENT PROCUREMENT PLANNING ....................................................................... 396
Types of Contract & Procurement Documents........................................................................................... 397
PROJECT #2: CROSS-FUNCTIONAL PROCUREMENT PLANNING ................................................................ 400
PROJECT #3: CONSULTING PROCUREMENT PLANNING ........................................................................... 403
Solicitation Planning ................................................................................................................................ 404
PROJECT #1: IN-DEPARTMENT SOLICITATION PLANNING........................................................................ 404
PROJECT #2: CROSS-FUNCTIONAL SOLICITATION PLANNING .................................................................. 406
PROJECT #3: CONSULTING SOLICITATION PLANNING ............................................................................. 407
Solicitation................................................................................................................................................. 408
PROJECT #1: IN-DEPARTMENT SOLICITATION ......................................................................................... 408
PROJECT #2: CROSS-FUNCTIONAL SOLICITATION ................................................................................... 409
PROJECT #3: CONSULTING SOLICITATION .............................................................................................. 410
Source Selection........................................................................................................................................ 411
PROJECT #1: IN-DEPARTMENT SOURCE SELECTION ................................................................................ 411
PROJECT #2: CROSS-FUNCTIONAL SOURCE SELECTION .......................................................................... 413
PROJECT #3: CONSULTING SOURCE SELECTION ..................................................................................... 414
Contract Administration.......................................................................................................................... 414
PROJECT #1: IN-DEPARTMENT CONTRACT ADMINISTRATION ................................................................. 415
PROJECT #2: CROSS-FUNCTIONAL CONTRACT ADMINISTRATION ........................................................... 416
PROJECT #3: CONSULTING CONTRACT ADMINISTRATION ...................................................................... 416
Contract Closeout..................................................................................................................................... 417
PROJECT #1: IN-DEPARTMENT CONTRACT CLOSEOUT ............................................................................ 417
PROJECT #2: CROSS-FUNCTIONAL CONTRACT CLOSEOUT ...................................................................... 417
PROJECT #3: CONSULTING CONTRACT CLOSEOUT ................................................................................. 418
Bidder Conference...................................................................................................................................... 419
Negotiation ................................................................................................................................................. 421
Advertising ................................................................................................................................................. 422
Contracts..................................................................................................................................................... 423
FIXED PRICE CONTRACT......................................................................................................................... 423
COST-REIMBURSABLE CONTRACT.......................................................................................................... 424
TIME AND MATERIAL CONTRACT ........................................................................................................... 424
ANATOMY OF A CONTRACT .................................................................................................................... 424
Request for Proposal (RFP)/Request for Quotation (RFQ)/Request for Information (RFI)....................... 426
REQUEST FOR PROPOSAL (RFP) .............................................................................................................. 426
REQUEST FOR QUOTATION (RFQ) .......................................................................................................... 427
REQUEST FOR INFORMATION (RFI) ........................................................................................................ 427
Evaluation Criteria ..................................................................................................................................... 428
Statement of Work (SOW) ......................................................................................................................... 429
13

Procurement Management Plan.................................................................................................................. 430
Make/Buy Analysis .................................................................................................................................... 431
PROCUREMENT PRACTICE EXAM ...............................................................433

INTEGRATION & CONTEXT ...........................................................................441
Project Plan Development ....................................................................................................................... 445
INPUTS TO PROJECT PLAN DEVELOPMENT .............................................................................................. 446
TOOLS AND TECHNIQUES FOR PROJECT PLAN DEVELOPMENT ............................................................... 446
OUTPUTS FROM PROJECT PLAN DEVELOPMENT ..................................................................................... 447
Project Plan Execution............................................................................................................................. 447
INPUTS TO PROJECT PLAN EXECUTION ................................................................................................... 447
TOOLS AND TECHNIQUES FOR PROJECT PLAN EXECUTION ..................................................................... 448
OUTPUTS FROM PROJECT PLAN EXECUTION ........................................................................................... 448
Integrated Change Control...................................................................................................................... 448
INPUTS TO INTEGRATED CHANGE CONTROL ........................................................................................... 450
TOOLS AND TECHNIQUES FOR INTEGRATED CHANGE CONTROL ............................................................ 450
OUTPUTS FROM INTEGRATED CHANGE CONTROL .................................................................................. 450
APPLYING THE PMBOK INTEGRATION MANAGEMENT CONCEPTS .....451

Project Plan Development ....................................................................................................................... 453
PROJECT #1: IN-DEPARTMENT PLAN DEVELOPMENT .............................................................................. 456
PROJECT #2: CROSS-FUNCTIONAL PLAN DEVELOPMENT ........................................................................ 459
PROJECT #3: CONSULTING PLAN DEVELOPMENT ................................................................................... 461
Project Plan Execution............................................................................................................................. 462
PROJECT #1: IN-DEPARTMENT EXECUTION ............................................................................................. 463
PROJECT #2: CROSS-FUNCTIONAL PLAN EXECUTION ............................................................................. 464
PROJECT #3: CONSULTING PLAN EXECUTION ......................................................................................... 465
Integrated Change Control...................................................................................................................... 466
PROJECT #1: IN-DEPARTMENT INTEGRATED CHANGE CONTROL ............................................................ 467
PROJECT #2: CROSS-FUNCTIONAL INTEGRATED CHANGE CONTROL ...................................................... 471
PROJECT #3 CONSULTING INTEGRATED CHANGE CONTROL ................................................................... 473
Project Planning Methodology ................................................................................................................... 475
Project Management Information System (PMIS) ..................................................................................... 475
General Management Skills & Product Skills ............................................................................................ 478
Work Authorization System ....................................................................................................................... 478
Change Control System and Configuration Management .......................................................................... 479
Performance Measurements ....................................................................................................................... 479
Corrective Action ....................................................................................................................................... 480
Change Requests ........................................................................................................................................ 481
INTEGRATION PRACTICE EXAM...................................................................482

PROFESSIONALISM & ETHICS......................................................................488
14


Ensure Integrity and Professionalism..................................................................................................... 488
ADHERING TO THE PMBOK PROCESS ................................................................................................. 489
CONFLICTS AND THE APPEARANCE OF CONFLICTS ................................................................................. 489
PROFESSIONAL CONDUCT ....................................................................................................................... 489
CONFIDENTIAL INFORMATION ................................................................................................................ 489
Contribute to the Project Management Knowledge Base ..................................................................... 490
Enhance Individual Competence ............................................................................................................ 490
Balancing Stakeholder Interests.............................................................................................................. 490
Interact With Team Members and Stakeholders .................................................................................. 491
Bias Toward Early and Aggressive Problem-Solving............................................................................ 491
Cultural Diversity..................................................................................................................................... 491
OBLIGATIONS TO PROJECT TEAM MEMBERS AND STAKEHOLDERS ........................................................ 493
CONFLICTS OF INTEREST ........................................................................................................................ 494
PROFESSIONALISM & ETHICS PRACTICE EXAM .......................................497

ABOUT THE AUTHOR.....................................................................................504
INDEX...............................................................................................................505

15
Table of Figures
FIGURE 1 CHARTER COMPONENTS ....................................................................................24
FIGURE 2 SCOPE STATEMENT ELEMENTS ......................................................................26
FIGURE 3 IN-DEPARTMENT ORGANIZATION CHART ...............................................31
FIGURE 4 CROSS-FUNCTIONAL ORGANIZATION CHART ........................................31
FIGURE 5 CONSULTING PROJECT ORGANIZATION CHART...................................32
FIGURE 6 IN-DEPARTMENT PROJECT CHARTER..........................................................35
FIGURE 7 PROJECT EVALUATION RESULTS....................................................................39
FIGURE 8 NET PRESENT VALUE OF THE CASH FLOWS (000S) ...............................41
FIGURE 9 PRODUCT ANALYSIS BY TIME BREAKDOWN............................................42
FIGURE 10 SCOPE STATEMENT E-MAIL ............................................................................44
FIGURE 11 EVENTS-DRIVEN PRODUCT ANALYSIS......................................................46
FIGURE 12 MAJOR DELIVERABLES ......................................................................................49
FIGURE 13 - COMPLETED WBS FOR IN-DEPARTMENT PROJECT ..........................51
FIGURE 14 STANDARD WBS TEMPLATES FROM FUNCTIONAL DEPARTMENTS
.....................................................................................................................................................53
FIGURE 15 BUILDING DEPARTMENT TEMPLATE ........................................................53
FIGURE 16 WORK BREAKDOWN STRUCTURE................................................................55
FIGURE 17 SCOPE VERIFICATION FORM..........................................................................57
FIGURE 18 CRITICAL PATH EARLY AND LATE START AND FINISH DATES.....91
FIGURE 19 WORK BREAKDOWN STRUCTURE................................................................97
FIGURE 20 SECTION OF WORK BREAKDOWN STRUCTURE....................................99
FIGURE 21 WORK PACKAGE (WBS DICTIONARY).......................................................100
FIGURE 22 DETAILED WBS ....................................................................................................101
FIGURE 23 SECTION OF WBS ................................................................................................103
FIGURE 24 ACTIVITY SEQUENCE IN GANTT CHART................................................104
FIGURE 25 ACTIVITY SEQUENCE IN NETWORK DIAGRAM FORM ....................104
FIGURE 26 AOA WITH DUMMY ............................................................................................104
FIGURE 27 LINKING TWO NETWORK TEMPLATES...................................................105
FIGURE 28 PROBABILISTIC BRANCHING........................................................................106
FIGURE 29 CPM DURATION ESTIMATES .........................................................................109
FIGURE 30 PERT DURATION ESTIMATES .......................................................................111
FIGURE 31 CRASHING THE PLAN.......................................................................................114
16


FIGURE 32 CRASHING THE PLAN REVISED SCHEDULE ......................................115
FIGURE 33 FAST TRACKING..................................................................................................116
FIGURE 34 FAST TRACKING..................................................................................................116
FIGURE 35 SCHEDULE MANAGEMENT PLAN ..............................................................117
FIGURE 36 RESOURCE CALENDAR ....................................................................................118
FIGURE 37 RESOURCE ATTRIBUTES .................................................................................118
FIGURE 38 OPTIMISTIC ESTIMATES ..................................................................................118
FIGURE 39 EXPECTED ESTIMATE......................................................................................119
FIGURE 40 PESSIMISTIC ESTIMATE ...................................................................................119
FIGURE 41 MONTE CARLO SIMULATION DURATION DATA.................................120
FIGURE 42 MONTE CARLO TORNADO SENSITIVITY GRAPH ...............................121
FIGURE 43 MONTE CARLO SIMULATION CUMULATIVE DISTRIBUTION........121
FIGURE 44 TIME VALUE OF MONEY.................................................................................148
FIGURE 45 EARNED VALUE ..................................................................................................157
FIGURE 46 SECTION OF RESOURCE REQUIREMENTS LISTING...........................162
FIGURE 47 WORK CONTOURS..............................................................................................164
FIGURE 48 RESOURCE REQUIREMENTS PEAK AND TOTAL .................................165
FIGURE 49 COST ESTIMATES PAGE #1.............................................................................167
FIGURE 50 COST MANAGEMENT PLAN...........................................................................167
FIGURE 51 COST ESTIMATES FOR EACH WBS ENTRY ..............................................167
FIGURE 52 FUNCTION POINT COUNT OF TRIP SYSTEM .........................................168
FIGURE 53 FUNCTION POINT ADJUSTMENTS.............................................................168
FIGURE 54 ANALOGOUS ESTIMATING............................................................................170
FIGURE 55 SECTION OF COST BASELINE .......................................................................171
FIGURE 56 COST BUDGET AND VARIANCES ................................................................171
FIGURE 57 COST BASELINE AND BENEFIT CASH FLOW.........................................172
FIGURE 58 PROJECT MANAGEMENT SOFTWARE.......................................................175
FIGURE 59 FISHBONE DIAGRAM ON CAUSES OF A PROBLEM ............................197
FIGURE 60 VARIABILITY OF DATA ....................................................................................200
FIGURE 61 CONTROL CHART ...............................................................................................201
FIGURE 62 PARETO DIAGRAM.............................................................................................202
FIGURE 63 CAUSE AND EFFECT DIAGRAM ...................................................................206
FIGURE 64 TRIP QUALITY MANAGEMENT PLAN .......................................................207
17

FIGURE 65 FLOW CHART OF TR PROCESS......................................................................208
FIGURE 66 PARETO DIAGRAM OF PROBLEM SOURCES ..........................................209
FIGURE 67 COST OF QUALITY ANALYSIS .......................................................................210
FIGURE 68 DESIGN OF EXPERIMENTS ............................................................................211
FIGURE 69 WEEKLY QC SAMPLE RESULTS & TRENDS .............................................213
FIGURE 70 DEPARTMENTAL CONTROL CHART..........................................................214
FIGURE 71 DEPARTMENTAL PERFORMANCE WEEKLY % COMPLIANCE WITH
STANDARD...........................................................................................................................215
FIGURE 72 CONTROL CHART ...............................................................................................217
FIGURE 73 RULE OF 7 ...............................................................................................................218
FIGURE 74 CONTROL CHART #3 WITH CUSTOMER SPECIFICATION................219
FIGURE 75 ROLES & RESPONSIBILITIES MATRIX .......................................................243
FIGURE 76 RESOURCE UTILIZATION ..............................................................................244
FIGURE 77 ROLES AND RESPONSIBILITIES ...................................................................253
FIGURE 78 STAFFING MANAGEMENT PLAN ................................................................254
FIGURE 79 RESOURCE AVAILABILITY..............................................................................259
FIGURE 80 INPUT TO PERFORMANCE APPRAISAL.....................................................262
FIGURE 81 COMMUNICATIONS MANAGEMENT PLAN ............................................289
FIGURE 82 TRACKING GANTT (LOWER BAR IS BASELINE UPPER BAR IS
ACTUAL) ................................................................................................................................291
FIGURE 83 RESOURCE USAGE STATUS ............................................................................292
FIGURE 84 SPECIAL INFORMATION REQUEST ............................................................293
FIGURE 85 EARNED VALUE ..................................................................................................295
FIGURE 86 CLOSEOUT REQUEST........................................................................................297
FIGURE 87 PROBABILITY AND IMPACT...........................................................................320
FIGURE 88 DECISION TREE...................................................................................................323
FIGURE 89 RISK MANAGEMENT PLAN MEMO.............................................................331
FIGURE 90 RISK MANAGEMENT PLAN TABLE OF CONTENTS ............................333
FIGURE 91 WORK BREAKDOWN STRUCTURE..............................................................335
FIGURE 92 IDENTIFIED RISKS AND THEIR TRIGGERS............................................335
FIGURE 93 RISK IDENTIFICATION CATEGORIES.......................................................337
FIGURE 94 CAUSE AND EFFECT DIAGRAM ...................................................................338
FIGURE 95 DELPHI TECHNIQUE ........................................................................................339
FIGURE 96 SWOT FOR ASSUMPTION ANALYSIS...........................................................340
18


FIGURE 97 INFLUENCE DIAGRAM.....................................................................................341
FIGURE 98 P/I ESTIMATING FORM....................................................................................342
FIGURE 99 P/I RESULTS...........................................................................................................343
FIGURE 100 P/I ESTIMATING FORM..................................................................................343
FIGURE 101 P/I RESULTS TABULATION ..........................................................................344
FIGURE 102 PROBABILITY AND IMPACT FOR FIVE RISKS ......................................345
FIGURE 103 LIST OF PRIORITIZED RISKS WITH P/I DATA AND DATA
PRECISION INFO ...............................................................................................................346
FIGURE 104 LIST OF PRIORITIZED RISKS .......................................................................347
FIGURE 105 DECISION TREE ANALYSIS ..........................................................................349
FIGURE 106 MONTE CARLO SIMULATION .....................................................................351
FIGURE 107 PROBABILITY DISTRIBUTION ON PROJECT DURATION ...............351
FIGURE 108 SENSITIVITY ANALYSIS .................................................................................352
FIGURE 109 SENSITIVITY ANALYSIS .................................................................................354
FIGURE 110 RISK RESPONSE PLAN ....................................................................................355
FIGURE 111 PROCUREMENT PLANNING ........................................................................384
FIGURE 112 CONTRACT FEE CALCULATION...............................................................386
FIGURE 113 SOLICITATION PLANNING ..........................................................................387
FIGURE 114 MAKE VS. BUY ANALYSIS..............................................................................398
FIGURE 115 PROCUREMENT MANAGEMENT PLAN ..................................................399
FIGURE 116 IN-DEPARTMENT SOW...................................................................................400
FIGURE 117 CROSS-FUNCTIONAL SOW OUTLINE .....................................................401
FIGURE 118 PROCUREMENT MANAGEMENT PLAN CONFIDENTIALITY
STANDARD...........................................................................................................................402
FIGURE 119 MAKE VS. BUY WITH LIFE CYCLE COSTS ..............................................403
FIGURE 120 EVALUATION CRITERIA................................................................................405
FIGURE 121 RFP OUTLINE.....................................................................................................406
FIGURE 122 SCREENING SYSTEM CRITERIA .................................................................407
FIGURE 123 SAMPLE EVALUATION FORM .....................................................................412
FIGURE 124 FUNCTIONAL ORGANIZATION .................................................................442
FIGURE 125 MATRIX ORGANIZATIONS: WEAK, BALANCED OR STRONG ALL
LOOK ALIKE........................................................................................................................443
FIGURE 126 PROJECTIZED ORGANIZATION ................................................................443
FIGURE 127 ORGANIZATIONAL CONTINUUM.............................................................444
19

FIGURE 128 PROCESSES IN PROJECT PLAN DEVELOPMENT................................453
FIGURE 129 FIRST "WAVE" OF PROJECT PLAN DEVELOPMENT PROCESSES458
FIGURE 130 SECOND WAVE OF PLANNING AFTER WBS ....................................459
FIGURE 131 EXECUTION PROCESSES...............................................................................462
FIGURE 132 INTEGRATED CHANGE CONTROL PROCESSES.................................467
FIGURE 133 STATUS REPORT DATA...................................................................................468
FIGURE 134 SAMPLE VARIANCE REPORT WITH PHYSICAL % COMPLETE
(EARNED VALUE %).........................................................................................................468
FIGURE 135 TRACKING GANTT CHART ..........................................................................469
FIGURE 136 CHANGE REQUEST ..........................................................................................470
FIGURE 137 EARNED VALUE ................................................................................................472
FIGURE 138 OLD AND NEW EARNED VALUE ABBREVIATIONS .........................472
20

Scope Management
Initiation
Project Planning
Project
Manager
Assigned
Scope
Scope Management Plan

Scope
Strategic Plan
Product Description
Historical Info
Project Selection Criteria
Project Selection Methods
Expert Judgment
Scope
Scope Planning
Initiation
Assumptions
Controlling
Product Description
Charter
Constraints
Assumptions
Product Analysis
Benefit/Cost Analysis
Alternatives ID
Expert Judgment
Scope Statement
-Project Justification
-Projects Product
-Project Deliverables
-Quantifiable Objectives
Scope Change Control

Scope Mgt Plan
Performance Reports
WBS
Change Requests
Scope Change System
Performance Measurement
Additional Planning
-Scope Changes
-Corrective Action
-Adjusted Baseline
-Lesson Learned
Constraints
- Limits On Teams Options
-Triple Constraint
Project Charter
-Business Need
-Product Description
-Project Managers Authority
Scope
Scope Definition
Other Planning
Outputs
Scope Statement
Historical Info
Constraints
Assumptions
WBS Templates
Decomposition
Work Breakdown Structure

-Deliverables
-Down To The Level Of Work Packages
-Unique Identifier
-WBS Dictionary
Scope
Scope Verification
Scope Statement
Work Results
WBS
Project Plan
Prod Documentation
Inspection
Copyright 2004 Richard Billows All Right Reserved

Formal
Acceptance
21
SCOPE MANAGEMENT
Scope management is a central concern for project managers because in the five processes
that comprise scope, we identify, elaborate and then control what is, and what is not,
included in the project. The PMBOK assumes that we start with a product description,
project selection criteria and insights into organizational strategy, all supplied by
management. This may not reflect how things happen in your organization but it is how
PMI says things should work.
From these inputs, we produce a number of major outputs within the first three scope
processes; these outputs are the charter, which is issued by senior management and the
scope statement. At this point, our processes in procurement and quality can begin. As well,
the next scope process, scope definition, can now start and we can produce the WBS. Then
our work on risk, time and cost can commence.
With the planning underway in all the other processes, our scope management work stops
until we reach the controlling process group. There, scope verification and scope control
commence. In scope verification, we confirm that what we have been developing is what we
described in the original scope statement. During scope control, we manage any changes to
the scope, using the change control processes documented in the scope planning.
SCOPE INITIATION
During scope initiation, senior management formally authorizes the project by issuing the
project charter. Prior to that authorization, the project has passed through the organizations
project selection criteria approval process and has been approved to use organizational
resources. The project manager is appointed and given authority to manage those resources
in the charter. We will also produce the project constraints and assumptions in this process.
Theyll form the boundaries within which all the other planning processes operate.
INPUTS TO SCOPE INITIATION

There are some very significant inputs to scope initiation. The first and most important input
is the product description. It describes the characteristics of the output or deliverable the
project is to create and it spells out the relationship between this product of the project and
the business need it fulfills.
Questions on the PMI certification exams about the product description are difficult for
many project managers because their work on a project usually does not start with such a
succinct description of what is to be achieved and the reasons for achieving it. But you must
put yourself in the PMBOK world to correctly answer the exam questions. The product
description is the first of many situations where your experience may differ from the ideal
world of the PMBOK. However, the exams are based on how organizations and project
managers should manage projects. To pass the exam you will have to adopt the PMBOK
mindset.
The strategic plan and the project selection criteria are also inputs to scope initiation. The
strategic plan is used to align the project with the organizations business goals. The project
selection criteria come from the organization and are standards that new projects must meet
in order to be approved.
22

Scope Management
Project
Manager
Assigned
Scope
Initiation
Strategic Plan
Product Description
Historical Info
Project Selection Methods
Expert Judgment
Assumptions
Constraints
- Limits On Teams Options
-Triple Constraint
Project Charter
-Business Need
-Product Description
-Project Managers Authority
The last input in scope initiation is historical data. Throughout initiation and many other
PMBOK processes, we use records of previous projects. Building an archive of project
data, including the work results, actual versus planned work, duration and project
performance, makes the planning of subsequent projects much easier and, as importantly,
more accurate.
TOOLS & TECHNIQUES OF INITIATION

Project selection methods utilize the criteria which the organization has established for
approving new projects. The point of that process is to ensure that organizational resources
are used effectively and that all approved projects yield an appropriate amount of value or
benefit in relation to their cost. The evaluation criteria are the financial and operational
standards that a project must meet to be approved.
The evaluation methods range from straightforward to complex. We may simply compare
the benefits to the costs. Calculating the payback period gives a measure of time that a
project takes to repay its cost. So a project that costs $35,000 and generates $10,000 of
benefit a year would have a 3.5 year payback period. Another measure for evaluation is the
benefit/cost ratio. Using that same example, if the project above has a 5 year life, it would
have a benefit/cost ratio of 1.42 (50,000/35,000). Projects with a benefit/cost ratio of less
than 1.0 return less value then their cost.
More complex evaluation methods may include mathematical models, often called
constrained optimization, with analysis of a project using linear or dynamic programming
models. Alternatively, we may use expert opinions to evaluate the worthiness of new projects
in combination with mathematical techniques.

23

OUTPUTS FROM SCOPE INITIATION
The outputs from scope initiation are the constraints and assumptions, the identification and
the assignment of the project manager and the project charter. During the scope initiation
process, we want to assemble information from as many people as possible. We will talk to
the stakeholders, sponsor, senior management and possibly experts and involve all of them
in elaborating the product description. The constraints may come from an executive who
puts a limit on the cost of the project or the resources that can be used for the project. We
also develop the assumptions, which are aspects of the project that we consider to be correct
or accurate, and we will test these later in risk management.
The output of these discussions with the stakeholders is the charter, which is the document
that formally authorizes the project. The charter is issued by a manager external to the
project who has sufficient authority to authorize the project manager to utilize the resources
the project requires. In the PMBOK the sponsor role does not include issuing the charter,
although in the real world the same individual may play both roles. The charter gives the PM
the authority to manage resources needed to produce the product of the project. It also
provides people with information about:
FIGURE 1 CHARTER COMPONENTS
The product that the project will produce
The business need the projects product will meet
The objectives
The justification for doing the project, such as:

o Market demand
o Business need
o Customer request
o Technology advance
o Legal requirement
o Social need
The last big issue in scope initiation is the identification of the project manager. Ideally,
during the scope initiation process, the project manager is appointed, although the
PMBOK says that the appointment of the PM can be delayed but must occur by the
beginning of execution.
SCOPE PLANNING
The second process in the scope management knowledge area is scope planning. During
scope planning, we expand our understanding of the deliverables needed to produce the
product of the project. We break the product of the project down into its component
deliverables and in the process, consider alternative ways to reach the end result. The scope
statement we produce is the driver behind the planning for time, cost, quality and
procurement. Those processes must wait for the scope statement as an input before they
can begin. It is also the document we will later use to confirm that the project has produced
the desired end results for the projects customer. A key point in the scope planning is the
24

Scope Management
involvement of as wide a community of stakeholders as possible. This can include sponsors,
senior management, functional managers, customers, employees, vendors and regulators.
Scope
Scope Planning
Product Description
Charter
Constraints
Assumptions
Product Analysis
Benefit/Cost Analysis
Alternatives ID
Expert Judgment
Scope Statement
-Project Justification
-Projects Product
-Project Deliverables
-Quantifiable Objectives
INPUTS TO SCOPE PLANNING

The inputs to scope planning are the product description, the project charter, assumptions
and constraints, which should be familiar as we developed them in the preceding process.
The product description, which is expanding as we move through this scope process, gives
us the target at which the project is aimed. The constraints are the restrictions imposed by
management or the outside world on the project budget, duration or resources. Last, we
consider the assumptions in which we describe a wide variety of potential impacts on the
project. Well treat them as true throughout planning and test them in risk analysis.
TOOLS AND TECHNIQUES OF SCOPE PLANNING

We use a broad range of tools to develop the scope statement. We use product analysis in
many different forms to break down the product of the project into its component
deliverables. We then use identification of alternatives as a way of considering options for
delivering those components. Next, we compare the alternatives with tools ranging from
benefit/cost analysis to return on investment, or payback period. Expert judgment comes
from the stakeholders, the sponsor, organizational managers and experts from outside the
organization.
OUTPUTS FROM SCOPE PLANNING

We produce the scope statement and the scope management plan from this process. Well
base all future planning on the scope statement. The scope management plan can be either
formal or informal but it details the processes and procedures we will follow to make
changes to scope, including the identification of the decision-makers who must approve
these changes.

25

FIGURE 2 SCOPE STATEMENT ELEMENTS
The scope statement should include:
Project Justification: the business need the project is to address
Projects Product: a description of the product of the project
Project Deliverables: a description of the deliverables that must be completed in order to sign off on
the project completion
Project Objectives: include quality measures, cost and schedule milestones that must be met for a
successful project
SCOPE DEFINITION
During the scope definition process, we further break down the project deliverables into the
work breakdown structure (WBS). The goal of this process is to increase the accuracy of our
estimates for duration and cost. The WBS gives us the framework for all our further
planning, control and performance measurements and the project team should play an active
role in its development. The team members involvement not only improves the
information but enhances their ownership of the plan.
Scope
Scope Definition
Other Planning Outputs
Scope Statement
Historical Info
Constraints
Assumptions
WBS Templates
Decomposition
Work Breakdown Structure

-Deliverables
-Down To The Level Of Work Packages
-Unique Identifier
-WBS Dictionary
Scope Statement Updates
INPUTS FOR SCOPE DEFINITION

We use the scope statement, constraints and assumptions, as well as inputs from the other
planning processes that are underway in procurement, communications and quality.
Information about previous projects and their work breakdown structures is also used and
can be a significant time saver.
TOOLS AND TECHNIQUES OF SCOPE DEFINITION

We develop the WBS by either borrowing information by using work breakdown structure
templates from previous projects or by decomposition. Often the final WBS will have a
combination of decomposed and template sections. The work breakdown structure
templates are essentially the work breakdown structures, or sections of them, used in
previous projects. They may also take the form of standard lifecycle steps used in a specific
technology, like the standard sequence of steps to build a structure or develop software.
These templates are useful because they reduce the amount of time or work spent on
developing a new work breakdown structure.
Decomposition is the process of subdividing the major deliverables of a project into their
components. This is usually performed by small groups who will be doing the work and is
often done by thinking through the sequence of components they will deliver.
26

Scope Management
Regardless of the techniques used, we only detail the WBS down to the point where we can
make adequate estimates of cost and duration.
OUTPUTS OF SCOPE DEFINITION

The first output of scope definition is the work breakdown structure (WBS). It is created
with the active involvement of the team and is a hierarchical pyramid of the project. The
highest level in a WBS is the product of the project which is then sub-divided into 4-8 major
deliverables to make up the second level. These major deliverables may be further subdivided into their major components. The subdivision, or decomposition, continues until
the deliverables are of a size suitable for scheduling and estimating, usually 2-10 days of
work.
The WBS is used to communicate the project deliverables, define the scope of the project
and give additional information for cost and duration estimating. Many other processes are
structured around the WBS, like risk identification and quality management. The PMBOK
recommends that each item in the WBS be given an individual identifier, called a code of
accounts. We can also develop a WBS dictionary and work package information which
consists of the details, staffing information and requirements for each WBS entry.
The other scope definition output is the scope statement update. These updates are used to
document any changes to the scope statement and we would follow the scope change
control process to change it. This information should be distributed to the appropriate
stakeholders.
With the development of the WBS and scope statement update document, we have
completed our scope efforts in the planning process group.
SCOPE VERIFICATION
Once we have begun to execute and control the project, we resume our scope management
processes. Scope verification is the process of formal acceptance of each major deliverable
from the project, as described in the scope statement, as well as the final product of the
project. This process is generally performed simultaneously with quality control to confirm
both acceptance and correctness of the product. In the case where the project is not
completed, the scope verification process should be used in order to document the extent of
the completion of the project.
INPUTS TO SCOPE VERIFICATION

We use several other inputs in addition to the scope statement, which is our principal
verification baseline. We also use the work results which document the progress we are
making on the deliverables. We will review product documentation (requirements,
specifications, drawings, etc.) as well as the WBS.
TOOLS AND TECHNIQUES OF SCOPE VERIFICATION

Inspection is the key technique in verification. The client, customer or sponsor must
examine and inspect the products of the project and sign a document attesting to the fact
that the product meets the specifications in the scope statement. The PMBOK notes that
these inspections may also be called reviews, audits or product reviews.

27

Scope
Scope Verification
Scope Statement
Work Results
WBS
Project Plan
Prod Documentation
Inspection
Formal
Acceptance
OUTPUTS OF SCOPE VERIFICATION

Scope verification has only one output, which is the formal acceptance document. The
formal acceptance document includes the sponsors signature and language indicating
acceptance of the projects deliverables and product. This acceptance can occur several
times, once for each major deliverable.
SCOPE CHANGE CONTROL

We invest a great deal of time in scope initiation, planning and development, building a solid
foundation that lets us determine what should or should not be included in the project.
During scope change control, we use this foundation to monitor the factors that create
change, determine whether changes have occurred and keep abreast of changes that do
occur.
Scope
Scope Change Control
Scope Mgt Plan
Performance Reports
WBS
Change Requests
Scope Change System
Performance Measurement
Additional Planning
-Scope Changes
-Corrective Action
-Adjusted Baseline
-Lesson Learned
INPUTS TO SCOPE CHANGE CONTROL

We use the WBS as our detailed map of what should happen in the project. Our
performance reports tell us what is happening as do the change requests that may be
submitted by the team or a stakeholder. The key issue in change control for the project
manager is careful assessment of any change request.
TOOLS AND TECHNIQUES OF SCOPE CHANGE CONTROL

We use our scope change control system and performance measurement as the principal
tools in this process. The scope change control system defines the process that must be used
in order to make changes to the project scope. It should outline the paperwork and level of
authority required to authorize changes to scope. Performance measurements assist in
evaluating any variations that do occur and in deciding what sort of corrective action, if any,
is necessary. Corrective action is the alternative to changing the scope and so it is the
project managers first option.
28

Scope Management
OUTPUTS OF SCOPE CHANGE CONTROL
Scope changes, corrective action, lessons learned and the adjustment of the baseline are the
outputs we produce in scope change control. Scope changes are considered if corrective
action that would bring future performance in line with the scope baseline is not possible.
The project manager conducts a thorough analysis of the proposed scope change to assess
its affect on all four of the triple constraints of time, cost, quality and scope (This is not a
typo. This PMI concept has evolved but the name has not changed). Adjustments to the
scope baseline are made if the authorized decision-maker approves the change.
The documentation we create for our lessons learned includes a record of all scope changes
and their causes. They are recorded for future PMs to use as a reference for their projects.
Lastly, we adjust the baseline to reflect the changes to scope made during scope change
control.

29
APPLYING THE PMBOK SCOPE

MANAGEMENT CONCEPTS:
To make the preceding concepts easier to understand, well apply them to:
;
Small company or in-department projects
Cross-functional projects
Consulting projects for clients
In the previous sections, we covered the scope concepts and definitions you need to know
for the PMI certification examinations. In this section, youll see how we apply those
concepts, tools and techniques to realistic projects of three different scales. Youll see the
techniques applied to real data and people which will help you understand the material for
the examinations and follow the PMBOK guidelines on your projects.
The three projects we will look at all address the same business problem/opportunity which
is the improvement in the effectiveness of their handing of customer trouble reports. The
business need comes from the customers the company is losing as a result of poor handling
of customer problems.
Each project also has the same product description and major deliverables. They differ only
in the scale of the effort. As a result, the project managers apply different PMBOK tools
and techniques as they move through the PMBOK processes. The point of this section is
to show you how to apply the best practices and select the appropriate techniques for a
particular project. The three projects are:
;
Project #1: In-department project this project takes place within a functional
department. All six of the project team members and project manager report to the same
boss, who fills the roles of project sponsor and functional manager as well as senior
management. The stakeholders are:
o All 15 employees in the department.
o The human resources department, which may be involved in some of the
staffing and training.
o The sales department, which has committed to a higher level of service with
a major customer.
The department is organized along functional lines and the project manager has just secured
a PMP certification.
30

Scope Management
FIGURE 3 IN-DEPARTMENT ORGANIZATION CHART
Metro
Trouble Ticket
Unit
Manager
Department
employee
Department
employee
Department
employee
Department
employee
Department
employee
Department
employee
Department
employee
Department
employee
Project Manager
Project Team
;
Project #2: Cross-functional Project this project addresses customers trouble
report processing in 15 different functional units and utilizes technical specialists from
information systems, training, the construction department and outside suppliers and
professional firms.
o The project manager is from a technical department with no authority over
any of the team members from other departments.
o There are more than 100 stakeholders for this project and the project will
include: systems development, construction, training of employees and
procurement of computer hardware and other equipment.
o The organization is a matrix organization and the project manager secured a
PMP five years ago.
FIGURE 4 CROSS-FUNCTIONAL ORGANIZATION CHART
President
Executive Vice President
Division VP
Sales
Division VP
Marketing
Metro
Operations
Division VP
Operations
Southern
Operations
Division VP
Accounting
Division VP
Research
Northeast
Operations
Division VP
Technical
Services
Department
employee
Project Manager
Project Team: 4 individuals from each division
Project #3: Consulting project this project is being managed by an external consultant
whose firm is also providing technical expertise on the project
o The consulting firm is a projectized organization.
o The consulting project manager is 10 years beyond earning a PMP.
31

o The client organization is a mix of matrix and functional departments.
o There are over 1500 stakeholders on this effort.
o Resources will be provided by 22 departments as well as other suppliers and
professional firms.
FIGURE 5 CONSULTING PROJECT ORGANIZATION CHART
President
Consulting
Firm
Executive Vice President
Division VP
Sales
Division VP
Marketing
Metro
Operations
Division VP
Operations
Southern
Operations
Division VP
Accounting
Consulting
Project
Manager
Division VP
Research
Division VP
Services
Northeast
Operations
Staff
Consultant
Staff
Consultant
Staff
Consultant
Project Team: 4 individuals from each division
As we proceed through the scope management processes, we will first look at how we can
apply scope management for the project being performed within a functional department.
Then we will look at how that process and its techniques differ when the scale grows to a
cross-functional effort and last, at how a consulting project manager might handle scope
management.
The PMBOK itself does not specify what scale of project requires what kind of scope
management techniques. It simply says that a process can be successfully completed with
very informal or very formal techniques and with a wide range of technical sophistication.
We've made judgments about what is appropriate for projects of each scale but that is not to
say that an advanced technique we describe for the consultants might not be applied to an
in-department project in certain circumstances. By the same token, very simple techniques
which we talk about at the in-department level may be used on cross-functional projects
when they are appropriate. Our purpose is to illustrate the practical applications of the
techniques and teach the PMBOK processes.
APPLYING PROJECT INITIATION

All projects need to be initiated, although far less than half of the projects performed in
most organizations actually complete initiation correctly. Let's remember that the key
purpose of initiation is to secure authorization from the organization to proceed with the
planning of the project. We also want to secure authority for the project manager to assign
work to members of the project team and evaluate their performance. Many organizations
avoid the issue of project manager authority due to the conflict that it often creates.
32

Scope Management
However by avoiding this conflict, we leave a project manager to deal with the authority
issue in the midst of trying to get the project going, which is rarely successful.
In the project charter, we want to communicate the projects purpose and justification,
designate the project manager and give the PM the individual authority to use resources. We
also tell the stakeholders what constraints management has placed on the project (i.e.,
resources, time, budget) and what assumptions we are making about the organization and
the projects product.
The absence of a description of the product of the project is where most people encounter
their first major disconnect between the ideal PMBOK world and their project
management world. Unfortunately, in very few organizations does the project sponsor or
senior management come to the project manager with a completed product description.
What project managers usually receive is a list of the activities that an executive wants done
and a vague reference to the problem or the business opportunity were tackling. Rarely does
the product description give a project manager the characteristics of the product or service
the project is to produce or how to define its success.
So as we apply the PMBOK, our first major challenge is to secure a product description
with information to support the charter development and later planning. Since that's a
required input for initiation, project managers usually have work to do before the PMBOK
processes can kick in. Let's begin with Project #1, our in-department project.
PROJECT #1: IN-DEPARTMENT INITIATION

Situation:
1. The project is initiated by a department manager, using team members and a project manager who
are the managers subordinates.
2. The project has no separate budget; purchases and the team's time will be paid for out of the
department budget.
3. Aside from the customers, the sales department is the only identified stakeholder outside the
department.
Your boss calls you into the corner office and says, "Id like you to start work on this project
immediately. We really need to improve how quickly we resolve customers trouble reports.
The sales people are getting all kinds of complaints. Use anybody in any department you
need. And I want you to find some device that will let us notify our people 24 hours a day
that a trouble report has come in. Well also need to have access to the company website to
get details of a customer's product and problem history."
The boss turned away to work on the papers on the desktop. Remembering your lessons
from the PMBOK, you knew that this is not the way to initiate a project. So you said to
the boss, "If this project is really important to our department, weve got to do it right."
The boss looked up and nodded somewhat impatiently. But you go on, "We need to issue a
project charter."
The boss frowned and said, "We don't have time for all that paperwork, lets just get started.
This project has to be done as soon as possible!"

33

You answered, "Oh, it doesn't have to be a lot of paperwork. You could just send an e-mail
to everybody who will be affected by the project telling them that Im the project manager
and that Ill be assigning them work. That will be a good start.
That seems reasonable, the boss agreed.
"The other thing we need to do is talk about the constraints on the project. Is there any limit
to how many people I can use? Or how much of their time I can use?"
The boss leaned back, thought and then said, "Well, I don't want this project to interfere
with the QGB-39 project that Karen and Mike are working on, or the development of our
new procedures which will take all of Elsie and Jims time. Both of those projects are
corporate mandates, so they have to come first.
"So then I can't use any of those four people on this project, can I?
"No, I guess not," the boss said.
"We should send that constraint out with the charter and also information on how much of
other peoples time I can use. Is there a budget limitation or a time frame you have in
mind?
"I don't want you to spend more than $5,000 for equipment and I would like to be finished
as soon as we can. But I see now that you're not going to be able to use as many people as I
thought and you are going to have to spend time on purchasing to stay within that $5,000
limit. So let's say 3-4 months. And I suppose youll put that in your charter e-mail.
Actually, it would be best if you issued the charter for this project because you're not only
the sponsor but senior management as well and the person with sufficient authority to give
me the authority to assign work to team members. There's one other element we need to
include and that's the product description. Exactly what is it that you want the project to
produce and how does it tie in to our department strategy?
"Well, the sales people say our department is causing too many complaints so I want faster
resolution of customer trouble reports than we are delivering now."
You smiled and asked, "How much faster?"
The boss thought for a moment and then said, "If we could resolve 90% of them in 20
minutes that would be fantastic."
You thought about the assumptions that had to hold true for a result like that and then
asked, Turnaround times are always affected by volume, are we assuming that the volume
of trouble reports will stay the same?
The boss thought for a minute and then said, Well, lets assume no more than a 10%
increase over the next year.
You stood and said, "Great, Ill draft all this as a project charter and bring the e-mail for your
review, then you can issue it. I have no idea whether that end result is feasible within the
constraints and assumptions but we will start the planning with them."
34

Scope Management
FIGURE 6 IN-DEPARTMENT PROJECT CHARTER
TO: TRIP Project team and stakeholders
FR: The department manager
RE; TRIP charter
Project Title: Trouble Report Improvement Project
Business Issue: We will undertake this project in order to get the response to our customers
trouble reports below twenty minutes for 90% of the reports that come in to us twenty- four hours
a day, seven days a week. These levels of service will more than double the quality of our service
in comparison to the nearest competitor in our industry.
Project Manager: Chris Pimbock
Authority: Chris will have the authority to directly assign work to the team members assigned to
this project. In addition, Chris will participate in the yearly review for any team member who
spends more than 200 hours or 10% of their working hours on this project. The participation of all
team members must be approved by the team members boss before any assignment or
negotiation of the assignment may take place.
Product of the Project: This project will enable us to answer 90% of our customers trouble
reports within twenty minutes, twenty-four hours a day, seven days a week.
Constraints:
1. All employees in the department can spend up to 8 hours a week on project work except
Karen, Mike, Elsie and Jim.
2. The purchases on this project will not exceed $5,000
3. The project will be completed within 3-4 months
Assumptions:
1. Turnover in the department will not increase
2. The volume of trouble tickets will not increase more than 10%
----------------------------------------That may have sounded pretty simple, but our project manager met all of the criteria for a
successful project initiation. Given the scale of the project, a manager with an appropriate
level of authority is issuing the charter; it designates the project manager and gives the
project manager authority to use organizational resources to deliver a clearly defined project
product. In the discussion, the project manager and sponsor surfaced constraints and
assumptions. They also considered the departments criteria for approving new projects;
which was that corporate mandates come first. Simple as that was, the project manager did
everything correctly.
PROJECT #2: CROSS-FUNCTIONAL INITIATION

Situation:
1. The sponsor is the Vice President of Sales who wants to address a company-wide problem; the
handling of customer trouble reports is causing a competitive disadvantage in the marketplace.
2. The project manager works in a technical department and is loaned to the Sales VP. Team
members will have to be borrowed as well.
3. The project will affect departments throughout the company. Fifteen different departments handle
trouble reports for specific products and/or market segments.
The project managers boss received a call from the Sales VP who explained that the
company's competition was, using our poor performance on handling customer trouble
reports to take business away from us. The project managers boss agreed to loan the
project manager to the Vice President of Sales for an extended assignment and agreed to the
first meeting.

35

The VP of Sales opened the meeting by saying, You don't come from the sales department
but the way we do projects here is action, overtime, weekends, working late and getting
things done fast. So I want you to start work on this project tomorrow. We have to improve
our responsiveness in every department in this organization when customers submit a
trouble report.
The Sales VP paused for a breath while pulling three sheets of paper out of the mahogany
desk. Here's a list of the things I think you can start doing tomorrow while we get the rest
of the team in place.
The project manager waited a moment and then said, "If you want me to do the work on
this project, I am certainly willing to do so. But if you want me to manage the project, then
you and I have quite a bit of planning to do.
I would like you to manage the project team and do some of the work, the VP of Sales
responded.
Fine, but the team will be large because we will need to change performance on trouble
reports in 15 different departments. So we have some planning to do before we start doing
tasks.
The Vice President of Sales nodded grudgingly and said, "I just dont want a lot of
paperwork. I want the project team to really hustle."
The project manager nodded and said, "Speaking of the project team, were going to need
people from all the departments that handle trouble reports. I don't believe any of those
departments are in your organization or under your control.
The Sales VP nodded in agreement, but with a puzzled look.
So the project manager continued, "I will need authority to assign tasks to the members of
the project team and none of them are my subordinates or yours."
The Vice President of Sales glanced over at the wall clock and said, We can work those
details out later. I'm sure all the departments will cooperate and if not, Ill talk to them.
The project manager responded, "Unfortunately it usually doesn't work like that. What
usually happens is that our required resources will vanish into the undergrowth. Every time
we need people to do a task, theyll be busy on something for their home department. Then
the project completion date will slip later and later and later.
I cant have that! the Sales VP quickly replied.
Then we need an executive with sufficient authority to grant me the authority to use
resources from all those departments. I think we need to go the Executive Vice President;
we need someone at that level to issue the charter."
The Sales Vice President frowned even more deeply, "The EVP has approved the idea, so
Ill ask him to issue this charter.
The project manager nodded and said, "There are just a couple more things we have to talk
about. First is the description of exactly what you want this project to produce. Second are
the constraints and assumptions under which we have to operate. Well want all of those
items to be in the charter.
----------------------------
36

Scope Management
Organizations often dodge the issue of project manager authority on cross-functional efforts
because it creates conflict situations with functional managers. But inadequate authority
makes it difficult or impossible for the project manager to get work done efficiently and on
time.
The authority issue has to be resolved at the beginning of initiation, which is why the
PMBOK makes a clear point about the rank required for the executive who issues the
project charter. That's also why the PMBOK distinguishes between the project sponsor
and the senior manager who issues the charter. Often the executive who pays for a crossfunctional project does not have the rank to grant the necessary authority to a project
manager.
The executive issuing the charter also has to be very clear about the authority of the project
manager to use organizational resources. A project manager really needs three things. First,
when borrowing resources from other departments, the project manager should "own" a
block of the borrowed persons time (e.g. half-time for the month of June, full-time
Mondays and Tuesdays, etc.). Second, during that block of time the project manager
owns, the PM should be able to assign work directly to the resource without having to go
through their functional manager. Third, the project manager should have the authority to
recognize outstanding performance with some reward, such as input into the borrowed
persons performance review. Having all three of those authorities is ideal and hopefully
illustrates why the charter needs to be issued by a person with sufficient rank to give the
project manager those authorities. Often we need to settle for less than the ideal authority,
but the key point is we can't let the authority issue slide until we start work on the project
because then it's too late.
The issue of project manager authority is the most difficult in a functional organization and
becomes somewhat easier in a matrix organization where the functional departments are
accustomed to lending their staff to projects. That doesn't mean that borrowing resources in
a matrix organization happens smoothly or without conflict. In fact, the matrix organization
places heavy communication burdens on project managers because they must negotiate with
the functional managers. Overall, they usually have no authority beyond what they gain in
the charter.
Another significant difference between in-department and cross-functional projects is in the
project selection methods. The Vice President of Sales asked our project manager to assist
in the preparation of the strategic information and payback period that the corporations
project management office (PMO) required for new projects. Our cross-functional project
manager was familiar with this process and knew the criteria that the project steering
committee and the PMO used. The steering committee was made up of executives who
evaluated projects, assisted by staff members from the project office (PO). There are many
different types or flavors of project offices. For our cross-functional project, the PMO
was a weather station; reporting results without controlling or trying to directly affect what
happens.
Together with the Vice President of Sales, the PM drafted a short document on the strategic
necessity and justification for the Trouble Report Improvement Project (TRIP). It was
focused on addressing the five criteria the evaluation committee would use to subjectively
evaluate projects:
;
Strategic Goals
37

;
Return on Investment
Payback Period
Quality/Service Objectives
Growth Targets
The committee also wanted a cost benefit analysis with a payback period calculation and
benefit/cost ratio. Developing the numbers for this financial analysis was as much art as it
was science; particularly for the benefit number, which often involved intangibles. For the
cost side, the project manager crafted analogous estimates from previous projects that were
somewhat similar. The Vice President of Sales would develop the benefit calculations
required for the analysis, but again this was largely a matter of drawing on expert opinion
and experience.
Our project manager shared the discomfort other PMs have at showing anyone cost and
duration estimates that were based on so little data. But producing them was the only way to
get the project approved. There is a need to provide numbers to decision-makers in order to
secure their authorization for the project to proceed. However, there is usually little detailed
data available to support those cost and duration estimates. In other words, the estimates
have a great deal of uncertainty. Unfortunately, project managers usually wind up having to
live with these first budget and duration estimates for the remainder of the project.
38

Scope Management
FIGURE 7 PROJECT EVALUATION RESULTS
Project Evaluation
TRIP Project
Member 1
Member 2
Member 3
Member 4
Member 5
Member 6
weight Raw Weighted Raw
Weighted Raw
Weighted Raw Weighted Raw Weighted Raw Weighted
Strategic Goals
25%
9
2.25
5
1.25
9
2.25
9
2.25
4
1
1
0.25
15%
8
1.2
9
1.35
8
1.2
3
0.45
6
0.9
9
1.35
Payback Period
5%
7
0.35
7
0.35
7
0.35
7
0.35
2
0.1
5
0.25
Quality/Svc Objectives
35%
6
2.1
9
3.15
9
3.15
8
2.8
7
2.45
9
3.15
Growth Targets
20%
5
1
8
1.6
8
1.6
6
1.2
8
1.6
9
1.8
Total
6.9 Total
7.7 Total
8.55 Total
7.05 Total
6.05 Total
6.8
Total Score for Project A
43.05
Product Launch Project

Member 1
Member 2
Member 3
Member 4
Member 5
Member 6
Weighted Raw
Strategic Goals
25%
9
2.25
6
1.5
3
0.75
9
2.25
6
1.5
6
1.5
15%
10
1.5
7
1.05
4
0.6
3
0.45
4
0.6
1
0.15
Payback Period
5%
10
0.5
7
0.35
4
0.2
7
0.35
7
0.35
9
0.45
35%
6
2.1
10
3.5
9
3.15
8
2.8
3
1.05
1
0.35
Growth Targets
20%
5
1
9
1.8
8
1.6
6
1.2
8
1.6
9
1.8
Total
7.35 Total
8.2 Total
6.3 Total
7.05 Total
5.1 Total
4.25
Total Score for Project B
38.25
Payroll System Project

Member 1
Member 2
Member 3
Member 4
Member 5
Member 6
Weighted Raw
Strategic Goals
25%
4
1
9
2.25
6
1.5
10
2.5
2
0.5
3
0.75
15%
8
1.2
5
0.75
7
1.05
10
1.5
6
0.9
7
1.05
Payback Period
5%
2
0.1
4
0.2
7
0.35
10
0.5
7
0.35
5
0.25
35%
4
1.4
3
1.05
4
1.4
2
0.7
3
1.05
9
3.15
Growth Targets
20%
3
0.6
6
1.2
9
1.8
7
1.4
4
0.8
3
0.6
Total
4.3 Total
5.45 Total
6.1 Total
6.6 Total
3.6 Total
5.8
Total Score for Project C
31.85
Financial Analysis (000s)

Year 1
Year 2 Year 3
Year 4
Year 5
TRIP Project
Benefit cash flow
Cost cash flow
Net
Cum
10%
Int
Payback Period
Benefit/cost ratio
$95.88
2.5 years
($29.92)
3.20
$65.96
NPV
$0
-$23
-$23
-$23
$12
-$10
$2
-$21
$45
-$1
$44
$23
$40
$0
$40
$63
$40
$0
$40
$103
$10
-$23
-$13
-$13
$10
-$15
-$5
-$18
$15
-$5
$10
-$8
$18
-$5
$13
$5
$22
-$5
$17
$22
$75.00
($43.58)
$31.42
3.2 years
1.72
$117
-$135
-$18
-$18
$178
-$135
$43
$25
$32
-$135
-$103
-$78
$76
$0
$76
-$2
$12
$0
$12
$10
$415.00
($335.73)
$79.27
4.1 years
1.24

Benefit cash flow
Cost cash flow
Net
Cum

Benefit cash flow
Cost cash flow
Net
Cum
The project steering committee, assisted by the project office staff, applied their 5 evaluation
criteria to the justification the sponsor had written. They also evaluated two other projects
that had been submitted. Only the TRIP project was approved. The sponsor came back
from a meeting with a customer and asked the PM why the other two projects had failed to
make the grade.
The PM said, The Product Launch Project had almost as high an evaluation on the criteria
as we did, but their payback period was almost a year longer and their benefits were only
1.72 times their costs, which is pretty low. The Payroll Project was a lot lower on the
business justification, but a 4 year payback and the low B/C ratio for all those dollars they
wanted to spend was the real killer.

39

PROJECT #3: CONSULTING INITIATION
Situation:
1. The product of the project is developed at the same time the consultants are working to sell their
services to the client, whether through face-to-face contact or a formal bid process.
2. While selling, consultants often ignore PM authority issues as well as constraints and assumptions
since they may adversely affect the likelihood of securing the engagement.
Our consulting project manager pulled into the prospective clients parking lot and began the
search for an empty parking spot. Beside the project manager sat a partner in the consulting
firm who was the account executive for this client. In the backseat sat a newly hired staff
consultant who had significant technical expertise from five years with another consulting
firm. The consulting project manager turned into another row looking for a vacant space in
the crowded lot, knowing they had plenty of time before the meeting with the client
companys executive VP to finalize the contract terms for the TRIP project.
The staff consultant in the backseat asked, "Exactly what do you want me to do in the
meeting; wow them with my technical expertise? I did a lot of that with my old firm."
The partner and project manager shared a look and then the partner said, "Well let the other
firms come in and talk about their technical credentials and all that geekie engineer stuff.
Very few senior executives are interested in or impressed by technical details or engineering
talk. As a result, top executives often stop meeting with consultants or their own internal
project managers who just talk technical details. As you'll see, we're going to talk about the
business value this project will produce in the client's business. That's why we can sell our
projects to senior executives rather than submitting RFP responses to their purchasing
departments. Most clients see our competitors as a commodity with no difference between
them. So the clients send out an RFP and buy the services from the cheapest bidder.
"But how do you know the business value the client wants to buy?" the staff consultant
asked.
The project manager laughed and said, "We ask them and then listen very carefully. We want
to pin down precisely what business benefit the project should produce and get the client's
agreement on how they will measure success."
Wow! We never defined the product of the project that way. Our salespeople always
thought it was easier to sell a vague description of what the product would produce."
The partner responded, "It may be easier to sell some people with vague descriptions of the
product of the project but it's almost impossible to deliver on those projects and have a
satisfied client as well as make a profit on them."
The staff consultant said, "My old firm did have a lot of write-offs. We were always
expanding the scope of the work, trying to keep the client happy. We always had arguments
with them about what was and what was not in the scope. As the arguments continued it
got harder and harder to get the clients people to do their part on the projects.
The project manager said, "It sounds like you also shied away from defining the project
managers authority in the project charter. But after all those write-offs, were the clients
happy at the end of the projects? Did they hire you for follow-on engagements?
40

Scope Management
The staff consultant said, "No, almost never. But what do you mean about the authority and
charter?"
The project manager answered, "When we are trying to produce business value from a
project rather than just a technical result, it always requires work by the client's people.
During the sales and project initiation process and in our contract, we have to make it clear
how our project manager will work with the clients people.
The staff consultant said, Oh, our project managers never got anywhere near a client until
after the contract was signed.
The partner added, "That makes it very difficult for the delivery team to know what business
benefit the client has actually bought. No wonder your old firm is out of business."
------------------Our consulting PM prepared the documentation for justifying the project to the clients
project selection committee as part of the sales effort. Their presentation of the information
justifying the project expense included ROI and net present value calculations as part of the
cost benefit analysis.
FIGURE 8 NET PRESENT VALUE OF THE CASH FLOWS (000S)
TRIP Project
Benefit Cash Flow
Cost Cash Flow
Net
Cum
Year 1
Year 2
$
$ 12.00
$ (23.00) $ (10.00)
$ (23.00) $ 2.00
$ (23.00) $ (21.00)
Year 3
$ 45.00
$ (1.00)
$ 44.00
$ 23.00
$
$
$
$
Year 4
40.00
40.00
63.00
Year 5
$ 40.00
$
$ 40.00
$ 103.00
NPV @ 10% interest

$
95.88
$
(29.92)
$
65.96
The approval of the consulting assignment may require very elaborate evaluation procedures,
particularly if the client company is considering proposals from a number of consulting
organizations. The proposals themselves may be subjected to sophisticated mathematical
analyses, such as decision trees and other mathematical models discussed in our tools and
techniques section.
SCOPE PLANNING
Scope planning involves a great deal more than writing a wordy narrative, even though thats
what it consists of in many organizations. Usually the scope statement is a vague narrative
that makes no concrete commitments about what the project will produce nor does it limit
what will be included in the project. Taking this scope statement mush approach,
however, does allow us to start work quickly. It also allows people to postpone the hard
choices and stakeholders conflicts about them until later in the project; when they are much
more expensive to resolve. Organizations often combine mushy scope statements with
scope planning that is done by very small groups. This approach makes the scope work go
even faster but excluding some stakeholders from scope planning limits our ability to
unearth all the requirements early in the planning process.
The PMBOK approach to scope planning is just the opposite. First, a project manager
engages in a search for stakeholders, seeking to involve as many of them as possible in scope
planning so that we unearth all the stakeholders requirements early in the process. Including
requirements during scope planning often costs 1/100th of what it costs to add them once
we are deep into executing. Second, the PMBOK focuses on a clear statement of the
projects product and its major deliverables as well as identifying the measures that define
41

project success in objectively verifiable form. A scope statement that meets these PMBOK
standards is not mushy at all; it's a robust, hard edged document filled with measurements
we can verify later.
As a result, scope planning should include the active participation of stakeholders so that we
"catch as many project requirements as possible in the beginning rather than have them
spring up after we start work. A sound scope planning effort should also include processes
for breaking the product of the project down into its major deliverables and specifying
quantifiable criteria that define project success. That's a whole lot different than the mission
statement mush that is cut and pasted from one project to another without anyone noticing.
Let's see how scope planning is done with our small project and then look at what
techniques we use as the scale of the effort increases.
PROJECT #1: IN-DEPARTMENT SCOPE PLANNING

Situation:
1. The PMs boss, who is the department manager, is playing all the management roles and there is no
outside executive or project office to enforce a project management discipline.
2. The number of stakeholders is relatively small.
You enter the scope planning meeting, a bit surprised that everyone you invited has come.
There are five members from your department, representatives from both marketing and
sales and even the boss. Additionally, the sales people grudgingly agreed to invite one person
from your organizations largest customer. Getting all these people together was difficult but
you knew that broad participation in scope planning was a key to avoiding surprises later.
You open the meeting by reminding everyone of the product of the project, to "Resolve
90% of customer trouble reports within 20 minutes." The customer representative was
immediately enthusiastic about the product, which confirmed the link between the projects
product and the customers need. That was the reason you wanted the customer present.
The scope planning process you used had three steps. You started with a product analysis to
break down the product into its major functions and the deliverables that were required to
deliver the product description. Then you would discuss alternatives for completing each of
the deliverables. Last, you would compare the benefits/costs of each alternative and agree
on the best option which would be included in the scope statement.
You began by offering the group your product analysis which was a breakdown of the
product description by process step or function. Basically, you broke down the target time
frame of 20 minutes into time limits for each of the processes that had to take place to
resolve a customer trouble report. The components you suggested were:
FIGURE 9 PRODUCT ANALYSIS BY TIME BREAKDOWN
1. Notification of the "on duty" employee from your department within one minute of
the customer's telephone trouble report.
2. Diagnosis of the customer's technical problem by minute 12.
3. Communication to the customer of the solution by minute 17.
4. Verifying the success of the solution by minute 20.
42

Scope Management
Then the stakeholder group discussed each of those component deliverables, with people
making suggestions for how each might be accomplished. For the first step, notification, the
alternatives you identified included using pagers, cell phones or wireless internet
connections. The group then examined the costs and benefits of various approaches using
rough estimates from published sources like trade magazines and communications product
reviews. As an example, for the notification equipment options, you considered the tradeoffs between speed and cost, operating within the budget constraint of $5,000.
The sales representative mentioned that their department would like to be notified whenever
a customer had a trouble report. You added this to your list of deliverables, thinking that this
was the kind of requirement that usually came up at the end of a project where it would cost
10 times more to accomplish than it would if youd surfaced it early, during the scope
planning.
An employee from your department suggested breaking the product of the project down by
the information systems that would be used. The conversation then explored alternatives for
the paging system, the company's website that stored customer service information and the
wireless network which employees might use to access it.
When the discussion was over, you had a much more detailed understanding of the product
of the project and the major deliverables that would be needed to produce it. As importantly,
you had a group of stakeholders who had been given an opportunity to participate in the
scope planning and who felt their ideas and requirements had been considered.
With the product description further elaborated and the major deliverables of the project
identified, you were ready to draft the scope statement from your outline of the key points it
should cover.

43

FIGURE 10 SCOPE STATEMENT E-MAIL
TO: All Stakeholders in the TRIP project
FR: Chris Pimbock, project manager
TRIP: Scope Statement
Project Justification
This project is necessary to address the customers complaints about the speed with which their trouble reports
are resolved. The poor response time is causing customer dissatisfaction and giving the competition the ability
to accurately point out flaws in our support. We are suffering problems in customer retention as a result of this
problem.
Project Product
Resolve 90% of the customer trouble reports within 20 minutes.
Major Deliverables
1.
95% of department staff pass training exam with score of >90%
2.
On duty staff member notified of customer trouble report within 2 minutes
3.
Staff accesses Customer Information System within 6 minutes
4.
Staff contacts customer with problem analysis and recommendations within 17 minutes
5.
90% of customers use new contact system for trouble reports.
Objectives
In addition to the above quantitative measures, we have a purchases budget of $5,000 and a duration target of 3
to 4 months.
A change to any of the measured deliverables constitutes a change in the scope of the project. All proposed
changes to the scope will be documented in a memo by the project manager with supporting information
quantifying the impact on cost, duration, scope and quality. The project manager will provide the project
sponsor with a written recommendation on the proposed change. Any change to the project scope as defined
above must be approved by the project sponsor/department manager.
Both the process our project manager followed in scope planning and the simple e-mail
above meet the PMBOK requirements without excessive meeting time or generation of
mountains of paperwork. By following the appropriate processes in scope planning, the
project manager significantly improve the odds of success because the scope reflects the
requirements of all the stakeholders. The scope statement provides useful information about
what is and what is not in the project and is a sound basis for the continuing planning effort.
PROJECT #2: CROSS-FUNCTIONAL SCOPE PLANNING

Situation:
1. With 15 different departments involved, the stakeholder group is very large.
2. The impact of requirements that are not discovered until work is underway is very significant.
3. The project is occurring in a project-dense environment where many people are assigned to more than
one project and functional departments are besieged with requests to get involved in a host of
initiatives.
Our cross-functional project manager turned the corner and literally ran into the vice
president of sales who was the project sponsor and who said, Just the person I was looking
for."
The project manager replied, "How can I help?"
44

Scope Management
"I'm getting a little concerned about the fact that we have not started work and that you
seem to be all over the organization talking to people about what they want. Why are you
wasting time doing that?"
The project manager answered, "I know how important this project is to the organization
and I understand that youd like us to start work immediately. But its exactly because of the
importance of this project that I need to take the time to properly define the scope. If we
don't come up with objective verifiable measures of the scope now, we're going to have time
consuming battles later on because we havent unearthed the requirements of all the
different departments that are affected by this project. The best way I know to finish quickly
is to have a complete scope planning process with quantifiable and verifiable outcomes.
That's another problem," the sales VP said, "I hear you're going around really pinning
people down on how we will measure what they want. People feel you're really putting the
pressure on them.
In a sense I am, the project manager answered. "Im taking the approach that you cant
add a vague requirement to this project. As an example, you can't just tell me that you want a
certain kind of trouble report processed faster. You have to tell me how much faster so Ill
know at the end whether we've met your requirements or not. That way you can also look at
the requirements and decide if you want to modify or remove them.
The vice president of sales thought for a moment and then nodded slowly saying, "Well, we
have had a lot of projects here where the scope is so vaguely defined that we have big
arguments trying to decide what is included or if we succeeded in delivering it.
"That's the other reason for focusing on measurable verifiable outcomes. It makes change
control much easier because everyone knows what is included in the project and what is not.
So I think this time I'm spending is well worthwhile."
The vice president nodded agreement and then said, "Well, maybe you could reduce the
number of people you talk to about requirements. That would make it go faster."
The project manager answered, "Yes it certainly would, but when the requirements of the
people I didn't talk to come up six months from now, it will cost 10 times as much to add
them to the project than doing so now.
----------------------------------------On a cross-functional scale, our project manager will follow the same three step process of
product analysis, followed by identifying alternatives and then benefit/cost analysis of the
alternatives. However, this PM is likely to use more sophisticated product analysis
techniques like the events-driven breakdown you see below. Our project manager will:
;
Identify the business events required by the deliverable
Develop their inputs, outputs and external interfaces
Build process model
Build logical data model
Prepare requirements
Prepare acceptance criteria.

45

The events and their responses for one of the project deliverables the team developed are
below. Note that this is just a listing of the events and their responses which we will use as
the basis for our product analysis.
FIGURE 11 EVENTS-DRIVEN PRODUCT ANALYSIS
Event #
Source
Trigger
Event Response
Major Output
External
Destination
Customer
Our product not

working, calls
hotline
Record customer
data and problem
data
New trouble
report
Copy to customer
stored in database
Company
problem-solver
Customer agrees
that problem is
solved
Record solution
codes in
customers
history
Updated trouble
report
Customer
database
Company
problem-solver
Is this a recurring
problem?
Provide problemsolver with last 18

months of history
on this
customers
trouble reports
Trouble ticket
history
Company
problem- solvers
remote device
Customer
Wants to know
status of open
trouble tickets
Select all open

trouble tickets
and status data
Listing of all
trouble tickets for
a customer
Customer
The team then wrote a business event scenario for each of the events above, describing
exactly what should happen at each step. That level of product analysis leads us to develop
alternatives for each event. Then we assess each event in terms of costs and benefits. The
benefit/cost analyses of those alternatives may be more elaborate with costs gathered from
interviewing experts and consideration of the lifecycle costs of the alternatives rather than
just the charges to the project budget.
From these processes, our cross-functional PM wants a stakeholder group that is engaged
with the project, who feels their ideas and requirements have been considered.
PROJECT #3: CONSULTING SCOPE PLANNING

Situation:
1. With 15 different departments involved, the stakeholder group was very large.
2. The impact of requirements that are not discovered until work is underway is very significant.
3. The project is occurring in a project-dense environment where many people are assigned to more than
one project and functional departments are besieged with requests to get involved in a host of
initiatives.
The consulting firm partner, project manager and newly hired staff consultant had adjourned
to a coffee shop after their third meeting with the prospective client about the TRIP project.
The partner had the signed contract in a briefcase under the small round table.
The staff consultant said, "Wow, you sure spend a lot of time on scope planning. Your
contract is full of numbers and metrics on each deliverable. My old firm had mainly words in
their scope statements like: world-class service, leading-edge technology and unequaled
performance.
46

Scope Management
The partner responded, "A good scope statement is the key to consistent success in the
consulting business. Profitable firms make money on change orders. Unprofitable firms lose
money or can't charge for change orders at all because they did not have a solid scope
statement."
The project manager added, "Because the outcomes are so clear and measured, we never
have arguments with the client about what is and what is not included in the project scope.
Instead of fighting, we spend our time quantifying the budget and the duration impact of the
changes the client wants.
"Remember," the partner continued, "good scope control is not preventing changes to the
project scope. Good scope control is setting a foundation for making changes to scope and
also making changes to budget and duration. People who don't know what they're doing
fight every change in scope because their process doesnt give them the basis for getting paid
for the changes.
------------------For consulting scope planning, our consulting project manager may facilitate brainstorming
sessions with client personnel. In these sessions, the consultant seeks to stimulate the
creative thinking of client decision-makers and facilitate an environment in which one idea
from an individual triggers many other ideas from the group. The idea in brainstorming, and
the challenge in facilitating these sessions, is to keep the end result in mind. We use
brainstorming to generate a lot of good ideas and we come back and evaluate them later on.
The facilitator does not try to limit the flow of ideas and suggestions from the group. It is
actually quite the contrary. The facilitator works only to stimulate the flow of ideas and
quickly brings to a halt any attempt to evaluate or criticize the ideas that have been
generated.
With the scope statement generated, this signifies the beginning of a lot more planning, as
you can see on the flow chart on the following page. With the scope statement released, we
can begin our work in procurement and quality. Those two processes in turn contribute
information to the scope definition process.

47

Procurement
Procurement Planning
Scope Statement
Product Description
Procurement Resources
Market Conditions
Constraints
Assumptions
Make Or Buy
Expert Judgment
Contract Type
Communications
Communications Planning
Communications Requirements
Communications Technology
Constraints
Assumptions
Stakeholder Analysis
Scope
Initiation
Strategic Plan
Product Description
Historical Info
Project Selection
Methods
Expert Judgment
Scope Planning
Scope
Scope Definition
Product Description
Charter
Constraints
Assumptions
Product Analysis
Benefit Cost Analysis
Alternatives ID
Expert Judgment
Other Planning
Outputs
Scope Statement
Historical Info
Constraints
Assumptions
WBS Templates
Decomposition
Scope
Quality
Quality Planning
Quality Policy
Scope St
Prod Des
Standards/Regs
Other Outputs
Benefit/Cost
Benchmarking
Flow-Charting
Design Of Exp
Cost Of Quality
48

Scope Management
SCOPE DEFINITION
To develop the work breakdown structure (WBS) we take all of the outputs of scope
planning and scope initiation plus historical data. Utilizing a combination of WBS templates
from previous projects and decomposition of the major project deliverables, we develop the
work breakdown structure. The WBS is a hierarchy of deliverables, sub- deliverables and
sub sub-deliverables. The lowest level of detail in the WBS is a task or work package that
will usually take between two and ten working days. This size is generally appropriate for
accurate scheduling and budgeting without delving into micromanagement of the project
team.
PROJECT #1: IN-DEPARTMENT SCOPE DEFINITION

Situation:
1. No WBS templates are available from previous similar projects.
The team is small enough that everyone can participate in the WBS development.
You joined the stakeholder from sales and all of the project team members for the scope
planning meeting in the small conference room. Just as you were about to get the meeting
started, the sponsor and the boss of the whole project team, came in.
Im getting a little tired of all this planning, the boss said to the group and then turned to
you and said, When is the work going to start? Im getting concerned about when well be
finished.
You answered, "The easiest thing we could do is make a to-do list very quickly and start
work. But we'd almost surely be doing the wrong things and we'd find missing pieces that
would be very time consuming to fix later on. The best approach and the way to get the
project done quickly is to do a careful job with planning and then when we do start work, we
will be very efficient."
The boss nodded in grudging agreement, waved to the group and left. You pulled out the list
of major deliverables you had developed in the scope planning meeting and reminded
everyone of them:
FIGURE 12 MAJOR DELIVERABLES
1. Notification of the on duty employee from your department within 1 minute of

the customers telephone trouble report.
2. Diagnosis of the customers technical problem by minute 12.
3. Communication to the customer of the solution by minute 17.
4. Verification of the success of the solution by minute 20.
I would like to suggest we work on one of those deliverables at a time and decompose it
into sub-deliverables. You paused and looked around and saw that everyone was engaged.
Unfortunately, you continued, we dont have any historic project plans to use as
templates, so well have to decompose the whole WBS.
Marty, a team member seated at the far end of the table, said, One of the important things
under that second deliverable is training, so a sub-deliverable is competency with the new
49

wireless devices. Were going to need some pretty serious training in order to get our people
to perform at this level. I dont know if we can handle this training with the company HR
department, so an outside contractor
Marty, you interrupted, you are addressing important points, and well revisit them when
we do our make/buy analysis in procurement planning. But right now we want to focus on
developing the sub-deliverables, not picking resources. So whats the deliverable from this
training? How will we know our people are trained?
The room was quiet for a few moments when Casey, one of the younger team members said,
We need the manager to approve the training curriculum after we or a vendor designs it.
Then we need 100% attendance at the sessions and the last deliverable might be that we pass
a test.
Do we really need a test? another team member asked.
A third added, A test at the end will make attendance better and keep people focused.
You said, A test will give us a verifiable outcome and well say that everyone has to pass.
Also, I think each of those tasks or sub-deliverables that Casey suggested fall in the 2-10 day
range we are looking for.
But it wont take the boss 2 days to approve the curriculum! Marty objected.
True but we have to develop the curriculum before the boss can review it, make
modifications and get it approved and that combination will take 2 days.
You made notes on the discussion and the sub-deliverables the team developed. Four hours
later, your WBS was complete, with each entry having a duration between 2-10 days, which
was appropriate for scheduling and budgeting.
50

Scope Management
FIGURE 13 - COMPLETED WBS FOR IN-DEPARTMENT PROJECT
Trouble Report Improvement Project (TRIP)
Start
Communication systems and wireless devices meet 98% of test criteria
installation passes city building dept inspection, CO issued
90% of customers use new contact system for trouble reports (TRs)
Mailings, brochures and inserts for new system approved by Marketing
Shipping receives 27,000 printed brochures, inserts and mailings
95% of customers receive notification in the mail of the new system for addressing TR
99% of all monthly statements have notice of new service
80% of customers that call customer service reminded of new service
35% of customers visit support website per month
Department staffing of certified problem-solvers at 90% of peak volume
Identify qualified applicants for 120% of openings
90% of attendees earn problem-solver certification
Problem-solvers pass a test of customer's top 20 TRs with a score of >90%
Notification of the correct problem-solver within 1 minute of customer's TR
Vendor's training video is approved by department management
98% of problem-solvers attend training
95% of problem-solvers who score less than 90% on first test pass with >90% on retest
Diagnosis of customer's problem by minute 12, 80% first diagnosis accuracy
Monthly on-call schedule is approved by management by the 28th of each month
Problem-solver equipment passes quarterly inspection
95% of reports we contact customer with problem analysis and recommendations within 17 minutes
Sample 5% of TRs for each problem-solver
Write-up for each variation from the procedure
Random sample of reports shows solution success 90% of reports at 5 days
Resolve 90% of customer's TR in 20 minutes
PROJECT #2: CROSS-FUNCTIONAL SCOPE DEFINITION

Situation:
1. We have templates; therefore, the scope development relies on a combination of decomposition and
templates to create the WBS.
2. We have a large team that is too big and specialized to have one meeting.
3. We have functional departments with templates to use for all project work and each will develop
their own pieces of the WBS.
Our cross-functional project manager must design a process for scope definition that reflects
the fact that there are 15 different operating departments involved and affected by the
project. So it would not be possible to have one small meeting with the team to develop the
WBS. Also, our cross-functional project manager has functional and technical specialists
who will be performing relatively limited tasks and having no further involvement with the
project. These functional departments, like Information Technology, Construction and
Facilities, also have templates which they utilize for all projects. Those templates include the
technical requirements that their work has to meet.
51

As a result, our cross-functional project manager has a number of separate scope
development meetings with small groups of people. In this way, the project manager still
gains the advantages of having the team participate in the work breakdown structure
development, although the participation is limited to the sections of the project on which
those team members will work. The project manager initiated this process by asking people
from certain functional units to be responsible for the scope development of each of the
project's major deliverables.
The project manager joined the systems analyst and three programmers from the
information technology department who were developing the WBS for their work on the
TRIP project. As the project manager listened to the discussion, the Director of Information
Technology came in and said, "I want to remind you that this system development work for
your project has to follow our developmental process and meet our quality assurance
standards."
The project manager answered, "I wouldn't have it any other way and we need to be certain
that the WBS that your people give me and the duration estimates we make later on include
the development of the required documentation and testing that your quality standards
require. What I don't want is to be surprised at the end with additional requirements that
were not in the work breakdown structure."
The IS director frowned and said, "You cant want us to put the entire procedure manual in
the WBS!"
"Oh no," the project manager responded, "but if your general systems design has to comply
with your departmental operating procedure #14-1, say that in the WBS without reprinting
procedure #14-1. I don't want any surprise requirements and the best way is clear, verifiable
outcomes. So don't tell me you're going to do a user test. Tell me in the WBS that you are
going to test 100 trouble reports and make adjustments until 100% process correctly. Then,
any change in the testing is a scope change."
The director agreed and our project manager stopped by two more scope development
sessions. In the facilities department, they had the work breakdown structure for a similar
remodeling project completed several years ago. While their portion of the TRIP project
involved more electrical work than the earlier effort, almost the entire WBS from that
project could be used with only minor modifications for the custom aspects of the TRIP
project.
Our cross-functional project manager was coping with the large size of the project team and
still allowing people to actively participate in conceiving the outcomes they would later be
held accountable for delivering. The project manager's principal role was to encourage the
groups and stimulate their creativity as well as restraining them from going into too much
detail in the WBS.
What the project manager wanted was the lowest level of detail in the WBS to be between 2
days and 10 days worth of work for the assigned individual. That would allow adequate
budgeting and scheduling without filling the WBS with endless entries for one hour
meetings.
52

Scope Management
FIGURE 14 STANDARD WBS TEMPLATES FROM FUNCTIONAL DEPARTMENTS

Management approves general design
Requirement specifications documented meeting SOP #45.4
High-level design approved by enterprise architecture
Management approves detail design
Process model meets SOP #55.8 standards
Data dictionary ok'd by Sr. DPA
Management approves system and device test criteria
Unit test criteria meets SOP#66
Integration and systems test meet SOP #71
Construction
Hardware installation meets manufacturer's test specifications
Software approved by QC as meeting development standards
FIGURE 15 BUILDING DEPARTMENT TEMPLATE
installation passes city building dept inspection CO issued
Department management approves construction design
Demolition/removal accepted by engineer
Rough framing meets specifications
Rough electrical meets specifications
Rough plumbing meets specifications
Interior finish
Finish electrical
Finish plumbing
City inspection
Engineering inspection shows construction meets specifications
PROJECT #3: CONSULTING SCOPE DEFINITION

Situation:
1. Consultants have several templates from previous engagements.
2. The project requires the active participation of more than 24 client employees, drawn from more than
15 functional units.
Our consulting project manager smiled at the executive vice president's assistant and was
motioned into the executive's office. The executive vice president was the sponsor for the
consulting engagement and had signed the consultant's contract.
The executive came right to the point and said, "If I remember the proposal you submitted
to us, you folks have done dozens of engagements similar to the one you're doing for us on
the TRIP project."
"Yes we have," the consulting project manager answered, "and I have managed a number of
them personally."

53

"Then why are you having dozens of our people spending all this time in the planning
meetings for the work breakdown structure when you already have dozens of them? On top
of that, I'm also paying for you and your staff to sit in on all the same meetings. I don't think
I'm getting my money's worth."
The consulting project manager answered, "It's absolutely true that we have several very
good work breakdown structures for projects that are very similar to the one we're doing for
your organization. The reason my associates and your people are working to develop the
work breakdown structure for this project is that I want your people to feel that this is their
project, not the consultant's project. You are spending several thousand dollars for our
contribution to the scope development process and an even larger amount for the time your
people are spending. But this project has a budget that is well into six figures and it's my firm
belief that we will be better off at the end if your people are active participants in the WBS. I
want a WBS that reflects their thinking as well as our thoughts from previous projects. As
importantly, when people actively participate in developing the work breakdown structure
and the tasks for which they will later be held accountable, the level of commitment is much
higher. I think that's worth the money you are spending.
The executive vice president thought for a moment, shrugged and said, "I agree that people
who feel some ownership for a plan are likely to do a better job implementing it."
54

Scope Management
FIGURE 16 WORK BREAKDOWN STRUCTURE
Start
Management approves general design
Requirement specifications documented meeting SOP #45.4
High level design approved by enterprise architecture
Management approves detail design
Process model meets SOP #55.8 standards
Data dictionary ok'd by Sr DPA
Management approves system and device test criteria
Unit test criteria meets SOP #66
Integration, and systems test meet SOP #71
Construction
Hardware installation meets manufacturer's test specification
Software approved by QC as meeting development standards
installation passes city building dept inspection, CO issued
SCOPE VERIFICATION
Scope verification occurs during the controlling phase and focuses on the formal acceptance
of each of the major deliverables and the final product of the project. The PMBOK
emphasizes the need for sponsors, clients and stakeholders to inspect and formally accept
that the deliverable or product of the project is meeting the specifications as defined in the
scope statement and detailed in the WBS.

55

PROJECT #1: IN-DEPARTMENT SCOPE VERIFICATION
Situation:
1. The department manager is senior management as well as the sponsor of the project and signed both
the charter and the scope statement.
Our in-department project manager knocked on the boss' window and mouthed the words,
"We're ready."
The boss nodded and rose from his chair to come out to the department work area where
the employees had their cubicles.
The project manager said, "We have the call routing all set up and the wireless devices are
charged and ready to go. So we're ready for you to inspect our first deliverable, which is
notification of an employee within one minute of a customer trouble report."
The boss nodded a bit impatiently and the project manager nodded to one of the project
team members who stood in front of the telecommunications closet. That team member
flipped the switch, activating the call routing system.
"It should take just a moment," the project manager said.
As the seconds went by with no trouble report phone calls coming in, a couple of the team
members laughed nervously. Suddenly, there was a ringing in the telecommunications
closet. The project manager started the stopwatch atop a clipboard on the desk. Seconds
later, one of the wireless devices rang. The team member promptly picked up the device and
initiated the conversation with a customer about a trouble report.
The project manager clicked the stopwatch again and recorded the time and the speed with
which a call had been routed to the wireless. In the next five minutes, six more trouble
reports came in and the project manager recorded the speed of the routing on each one.
The boss said, smiling at the assembled team, "I think this project is moving along very
nicely; you certainly passed the first test." With that, the boss turned to go back to his office
and the project manager said, "I would like to get your formal acceptance of this project
deliverable here on the sheet where I recorded the timeliness of the calls."
56

Scope Management
FIGURE 17 SCOPE VERIFICATION FORM
Scope Verification & Acceptance

Project:
Deliverables:
Date: / /
Inspection Results:
The above inspection fully met the deliverables specified in this project scope
statement.
Sponsor
approval_____________
Sr. Management approval_______________
Stakeholder approval
__________
Stakeholder approval__________
Stakeholder
approval__________
Stakeholder approval__________
The boss scribbled a signature at the bottom of the clipboard and went back to his office.
The project manager has completed all of the requirements of scope verification as detailed
in the PMBOK.
PROJECT #2: CROSS-FUNCTIONAL SCOPE VERIFICATION

Situation:
1. The project sponsor did not have sufficient authority to issue the charter.
2. The scope statement was approved by the executive vice president and the department heads or
directors of 15 different functional units affected by the project.
Our cross-functional project manager and the four project team members were all tired after
a long day. This would be their sixth inspection meeting for the TRIP project. The project
manager had been insisting that each of the department heads or directors from the affected
departments sign off on this deliverable of the wireless notification system.
The project manager contacted each of those stakeholders, to ask them to inspect the first
project deliverable. Whenever one of these decision-makers was already committed to a
meeting or business trip, the project manager had scheduled another inspection session at a
time that was convenient for them.
One of the team members asked the project manager, "Why is it so important that all of the
stakeholders sign off accepting this first deliverable?"
The project manager smiled and said, "We have had a lot of politics on this project and a
number of these department heads were not happy with the fact that we're even doing this
project."
57

The team member nodded in vigorous agreement.
The project manager continued, "I dont want to have anybody come up to us at the end of
this project and say that the results are not acceptable. That's why I'm going to ask each of
the stakeholders to inspect and then accept in writing each of our major deliverables as we
progress through this project. That kind of formal verification and sign off saves a lot of
problems at the end.
PROJECT #3: CONSULTING SCOPE VERIFICATION

Situation:
1. The project involves consolidation of operations from several different functional units.
The consulting project manager stood next to the executive vice president watching the
tabulation of the time required to route customer trouble reports to the company's problemsolvers. Beneath them in the computer operations room, 14 team members entered the
response time for each of the incoming trouble reports.
The executive vice president said, "A written report would have been more than enough for
my needs; there really was no need for me to come down here and inspect this process."
The consulting project manager nodded and said, "I appreciate you taking the time because
often inspecting the results can trigger thoughts about whether this is exactly what you want
and whether it's going to meet the organization's strategic needs now and in the immediate
future."
The executive vice president frowned for a moment and then stared up at the ceiling for an
even longer moment, finally saying, "You know were opening the distribution centers in
Japan next quarter and those customers are going to have trouble reports as well. We need
to hire Japanese speaking problem-solvers to adequately address those customers problems.
I know that's a scope change but it never dawned on me during the original planning."
The project manager said, I'll get on the analysis tonight because we may have to make
adjustments in both the space planning and furniture purchases for those additional
problem-solvers. Not to mention the fact that recruiting them may take a lot longer than the
other employees were hiring. It's certainly a good thing that this came up now rather than at
the end of the project when it would be a great deal more expensive to handle."

Scope change is a separate process in the PMBOK. When we study for the certification
exams we need to understand the inputs like the WBS, the scope management plan and the
scope change control system. We also need to know the techniques like performance
measurement. We also need to understand the difference between corrective action which
fixes future performance and change requests which, if approved after analysis, lead to
changes in the scope baseline.
However, as we go beyond the PMBOK, we need to realize that scope control is actually
done as part of our integrated change control. To give you a better idea about how that
would work on our three example projects, please look at the integrated change control
section which shows you how practicing project managers integrate all of their control
processes
58

Scope Management
ALTERNATIVES IDENTIFICATION: BRAINSTORMING & LATERAL

THINKING
USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
USED BY:
SCOPE PLANNING
SCOPE STATEMENT
PROJECT MANAGERS AND TEAM MEMBERS
RESOURCE PLANNING
SCOPE MANAGEMENT PLAN

RESOURCE REQUIREMENTS
We use alternatives identification processes at several places in project planning. Rather than
simply adopt the usual way of doing things, we assemble team members and/or stakeholders
to develop options or different ways of doing things. It is a method we use to stimulate new
ideas, options and solutions for the project. We perform alternatives identification for the
product of the project, but as we work through the project, we will also conduct alternatives
identification sessions for resource planning in the cost management knowledge area.
The most common types of alternatives identification are brainstorming and lateral thinking.
Brainstorming is the process of focusing on a specific problem or desired end result and
developing as many solutions as possible. Brainstorming is believed to be most effective
when it is executed in a rapid-fire succession of ideas. We want to encourage our team
members to express their most eccentric solutions which will stimulate thinking outside the
box from all of the team members.
Lateral thinking is a technique accredited to Edward DeBono. It is similar to brainstorming
in that the desired outcome is innovative solutions to a problem. When using the lateral
thinking technique, we identify the common solution and acknowledge that this is not
necessarily the best response. Then we use this information or discussion as a springboard
to generate novel solutions to the problem. The most realistic ideas are harvested at the end
of the session and those ideas are discussed in detail.
When we conduct the alternatives identification sessions, we need to establish rules for the
meeting before it begins. Because fears of criticism or humiliation are likely to stifle our team
members creativity, it is imperative that no evaluation or analysis of ideas occurs before the
identification of solutions is complete. We want to record the ideas as they are expressed and
a flip chart is often the best way to do this because it is easy to examine during the review
session. In order to conduct a successful meeting, we may want to establish rules such as:
Definition of the problem or the desired outcome must be clear to all participants in the
alternatives identification session.
All conversation and discussion must remain focused on the subject of the session.
1. Discussion of ideas should be held off until the end of the session
2. Welcome creative and even outlandish ideas
3. Interruptions are unacceptable
4. All participants must share at least two ideas
Input from as many people and points of view as possible is what makes this exercise
successful.
59
SCOPE STATEMENT
USED IN THESE PMBOK
PROCESSES:
SCOPE PLANNING
SUPPORTS THESE
OUTCOMES:
USED BY:
RESOURCES PLANNING
There are two key issues in the development of our project scope statement. First, the scope
statement should be developed with broad participation of the stakeholders, not by the
project manager alone or with the project sponsor. The reason for encouraging broad
participation is that it significantly increases our odds of unearthing requirements early.
Second, the scope statement should be focused on the product of the project, the major
deliverables necessary to yield that product and quantifiable criteria that define the project's
success. The scope statement should not be a "gee whiz" description of all the wonderful
techniques you are going to use in the project.
TO: All Stakeholders in the TRIP project
FR: Chris Pimbock, project manager
TRIP: Scope Statement
Project Justification
This project is necessary to address the customers complaints about the speed with which their trouble
reports are resolved. The poor response time is causing customer dissatisfaction and giving the competition
the ability to accurately point out flaws in our support. We are also suffering problems in customer
retention as a result of this problem.
Project Product
Resolve 90% of the customer trouble reports within 20 minutes.
Major Deliverables
1.
95% of department staff pass training exam with score of >90%
2.
On duty staff member notified of customer trouble report within 2 minutes
3.
Staff accesses Customer Information System within 6 minutes
4.
Staff contacts customer with problem analysis and recommendations within 17 minutes
5.
90% of customers use new contact system for trouble reports.
Objectives
In addition to the above quantitative measures, we have a budget of $5,000 and a duration target of 3 to 4
months.
The scope of the project is likely to be more detailed because the measures and levels of performance have
been confirmed with both the customer and our sales and marketing department stakeholders.
A change to any of the measured deliverables constitutes a change in the scope of the project. All proposed
changes to the scope will be documented in a memo by the project manager with supporting information
quantifying the impact on cost, duration, scope and quality. The project manager will provide the project
sponsor with a written recommendation on the proposed change. Any change to the project scope as
defined above must be approved by the project sponsor/department manager.
60

Scope Management
PROJECT SELECTION METHODS

USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
SCOPE PLANNING
SCOPE STATEMENT
RESOURCES PLANNING
USED BY:
Organizations use a wide variety of methods for evaluating projects to determine whether
resources should be allocated to them. In the example below, we see three projects which
are evaluated subjectively against five justification criteria in the upper half of the example.
In the lower half of the example we see benefit/cost analysis and comparison of payback
periods, cost-benefit ratios and net present value.
Project Evaluation
TRIP Project
Member 1
Member 2
Member 3
Member 4
Member 5
Member 6
Weighted Raw
Weighted Raw Weighted Raw Weighted
Raw Weighted
Strategic Goals
25%
9
2.25
5
1.25
9
2.25
9
2.25
4
1
1
0.25
15%
8
1.2
9
1.35
8
1.2
3
0.45
6
0.9
9
1.35
Payback Period
5%
7
0.35
7
0.35
7
0.35
7
0.35
2
0.1
5
0.25
35%
6
2.1
9
3.15
9
3.15
8
2.8
7
2.45
9
3.15
Growth Targets
20%
5
1
8
1.6
8
1.6
6
1.2
8
1.6
9
1.8
Total
6.9 Total
7.7 Total
8.55 Total
7.05 Total
6.05 Total
6.8
Total Score for Project A
43.05

Member 1
Member 2
Member 3
Member 4
Member 5
Member 6
Weighted Raw
Raw Weighted
Strategic Goals
25%
9
2.25
6
1.5
3
0.75
9
2.25
6
1.5
6
1.5
15%
10
1.5
7
1.05
4
0.6
3
0.45
4
0.6
1
0.15
Payback Period
5%
10
0.5
7
0.35
4
0.2
7
0.35
7
0.35
9
0.45
35%
6
2.1
10
3.5
9
3.15
8
2.8
3
1.05
1
0.35
Growth Targets
20%
5
1
9
1.8
8
1.6
6
1.2
8
1.6
9
1.8
Total
7.35 Total
8.2 Total
6.3 Total
7.05 Total
5.1 Total
4.25
Total Score for Project B
38.25

Member 1
Member 2
Member 3
Member 4
Member 5
Member 6
Weighted Raw
Raw Weighted
Strategic Goals
25%
4
1
9
2.25
6
1.5
10
2.5
2
0.5
3
0.75
15%
8
1.2
5
0.75
7
1.05
10
1.5
6
0.9
7
1.05
Payback Period
5%
2
0.1
4
0.2
7
0.35
10
0.5
7
0.35
5
0.25
35%
4
1.4
3
1.05
4
1.4
2
0.7
3
1.05
9
3.15
Growth Targets
20%
3
0.6
6
1.2
9
1.8
7
1.4
4
0.8
3
0.6
Total
4.3 Total
5.45 Total
6.1 Total
6.6 Total
3.6 Total
5.8
Total Score for Project C
31.85
Financial Analysis (000s)

Year 1
Year 2 Year 3
Year 4
Year 5
10%
Int
Payback Period
Benefit/cost ratio
$95.88
2.5 years
($29.92)
4.03
$65.96
NPV @10%
TRIP Project
Benefit cash flow
Cost cash flow
Net
Cum
$0
-$23
-$23
-$23
$12
-$10
$2
-$21
$45
-$1
$44
$23
$40
$0
$40
$63
$40
$0
$40
$103
$10
-$23
-$13
-$13
$10
-$15
-$5
-$18
$15
-$5
$10
-$8
$18
-$5
$13
$5
$22
-$5
$17
$22
$75.00
($43.58)
$31.42
3.2 years
1.42
$117
-$135
-$18
-$18
$178
-$135
$43
$25
$32
-$135
-$103
-$78
$76
$0
$76
-$2
$12
$0
$12
$10
$415.00
($335.73)
$79.27
4.1 years
1.02

Benefit cash flow
Cost cash flow
Net
Cum

Benefit cash flow
Cost cash flow
Net
Cum

61
PROJECT CHARTER
USED IN THESE PMBOK
PROCESSES:
SCOPE INITIATION
SUPPORTS THESE
OUTCOMES:
SCOPE STATEMENT
USED BY:
SENIOR MANAGEMENT, PROJECT MANAGERS,

STAKEHOLDERS AND TEAM MEMBERS
The project charter is the document that formally authorizes the project to begin and gives
the project manager authority to use resources to complete it. This document is issued by a
senior manager, external to the project. It details the business objective the project will
address as well as the description of the product the project will produce. The charter will
identify the project manager as well as the authority this person will have to manage the
project and the resources who will work on the project.
In the PMBOK world, the project charter is developed by senior management. But in real
life, the project manager often influences the information in the project charter or even
writes it. Because the charter is developed so early in the project, it provides a broad level of
detail, describing the end results, but not all the processes we will use to achieve those
results.
The project charter is always a written document but the level of formality will vary from
organization to organization and may even vary from project to project within an
organization. On smaller, interdepartmental projects where a minimal amount of resources
are used, we may find that the charter is a more informal document, such as an e-mail or a
memo distributed at the first meeting for the project.
TO: TRIP Project team and stakeholders
FR: The department manager
RE; TRIP charter
Project Title: Trouble Report Improvement Project
Business Issue: We will undertake this project in order to get the response to our customers
trouble reports below twenty minutes for 90% of the reports that come in to us twenty- four hours
a day, seven days a week. These levels of service will more than double the quality of our service
in comparison to the nearest competitor in our industry.
Project Manager: Chris Pimbock
Authority: Chris will have the authority to directly assign work to the team members assigned to
this project. In addition, Chris will participate in the yearly review for any team member who
spends more than 200 hours or 10% of their working hours on this project. The participation of all
team members must be approved by the team members boss before any assignment or
negotiation of the assignment may take place.
Product of the Project: This project will enable us to answer 90% of our customers trouble
reports within twenty minutes, twenty-four hours a day, seven days a week.
Constraints:
1. All employees in the department can spend up to 8 hours a week on project work except
Karen, Mike, Elsie and Jim.
2. The purchases on this project will not exceed $5,000
3. The project will be completed within 3-4 months
Assumptions:
1. Turnover in the department will not increase
2. The volume of trouble tickets will not increase more than 10%
On a large project, where it is common to have a review board and the evaluation of several
executives before the charter is signed and the project can begin, it is typical to submit a very
formal document. The charter should address the same issues as on smaller projects but we
include more detail, such as:
62

Scope Management
Organizational Overview we focus on the business issue this project will address, including
but not limited to, the relationship of the project to the organizational objectives and the
resources required for a successful completion.
Assignment and Authority of the Project Manager we ask that the PM have the authority
to give assignments directly to the resources of the project, as well as the influence to
comment on and reward any resources who spend more than a certain percentage of their
work hours on the project. If this section is done correctly, we can expect to have some
push-back from the executives. This is a tough point to compromise on, because we want
the PM to have as much authority as possible from the beginning, so that later, when the
enthusiasm of our resources wanes, we maintain the authority to enforce these assignments.
Description of the Product the Project will Produce this section differs from the
organizational overview in that it describes the final deliverables and business result which
the project will produce.
Benefit/Cost Analysis we use this analysis to determine whether the benefit of
implementing a project will compensate for the costs of the project. We are interested in
pursuing projects where the benefits our organization receives far outweigh the costs.
Return on Investment (ROI) return on investment is one of the popular benefit/cost
analysis techniques. The formula is:
(total benefit - total costs) = ____
X 100 = ROI
total costs
The most difficult aspect of this calculation is often the isolation of the costs and benefits.

63
PRODUCT ANALYSIS
USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
USED BY:
SCOPE PLANNING
SCOPE STATEMENT
Product analysis is the name given by the PMBOK to a broad range of techniques used to
carve up the product of the project into its components. It is the first of the techniques
we apply during scope planning when we are working toward formulating the projects
major deliverables. We may break the product up into its major functions or its engineering
structures or its system modules. Regardless of the technique, a sizeable amount of creative
thinking is required to look at the product of the project from these different perspectives.
As well, the expertise required for product analysis is significant and on larger efforts we may
use experts. Some examples of the alternative ways we might analyze the product of the
project are:
;
Office building complex product analysis alternatives

o By the requirements of each floor (first floor, second floor etc.)
o By the requirements of each engineering system (structural,
heating/ventilating/air-conditioning, plumbing, electrical)
o By marketing phase (phase one, phase two, phase three)
Information systems development product analysis alternatives

o By developmental step (general design, detailed design, construction, testing)
o By user process (data entry, editing, report generation, data retrieval)
64

Scope Management
BENEFIT/COST ANALYSIS
USED IN THESE PMBOK
PROCESSES:
SCOPE PLANNING, INITIATION
SUPPORTS THESE
OUTCOMES:
EVALUATING ALTERNATIVES
USED BY:
PROJECT MANAGERS & STAKEHOLDERS
Benefit/cost analysis is used in many of the PMBOK processes. We use it to evaluate a

given alternative and also to compare several alternatives. The benefit/cost analysis can be
as simple as the example below, where we have simply taken the benefits and costs, then
calculated the difference and we see the benefit/cost ratio is 290,000/272,000 = 1.06.
Benefits
Fewer repeat calls
50% reduction in lost customers
12% reduction in turnover
Sum of Benefits
Cost
trainer's time
training facility
Annual operating cost
Annual maintenance
total
units x rate
total
1,000
50
1,500
100
1
50,000
500
45
Sum of Costs
$75,000
$200,000
$15,000
$290,000
$50,000
$150,000
$50,000
$22,500
$272,500
We can also make the analysis more sophisticated by making comparisons over time and by
adding elements such as the net present value of the benefits or the cost of cash flow. The
benefit/cost analysis is also the foundation for return on investment calculations, internal
rate of return and net present value calculations.
It is usually a very simple process to come up with the costs of an alternative. We have list
prices for equipment and materials and labor rates for people's time. This is not to say we
never have disputes about the costs, but the data is usually readily available.
Whatever level of sophistication, the difficult part of a benefit/cost analysis is coming up
with quantified measures of the benefit of an alternative. When the benefits are cost savings,
the computation is simpler. But when we have benefits in the form of increased customer
satisfaction or employee satisfaction, it is much more difficult to put a dollar figure on the
benefits. In fact, it is almost always the benefit portion of a benefit/cost analysis that is the
source of conflict and disagreement.

65
WBS TEMPLATES
USED IN THESE PMBOK
PROCESSES:
SCOPE DEFINITION AND ACTIVITY
DEFINITION
SUPPORTS THESE
OUTCOMES:
CREATING THE WBS
USED BY:
During both the scope definition phase and the activity definition processes, having the
work breakdown structure from historical projects is exceedingly useful because it saves
significant amounts of time for the project manager and project team members. While many
organizations do not maintain this kind of historical data, those that do make project
planning more efficient and also avoid the mistakes that result when vital work breakdown
structure components are overlooked during planning.
When the organization does maintain an archive of project plans, we begin our work by
looking for projects similar to the effort we are now undertaking. If similar projects are not
available, we look for historical projects that had a major deliverable that is similar to one of
the major deliverables in our current project. When we find a suitable match, we can avoid
some or all of the decomposition effort and can often complete the WBS by simply
reviewing the historical work breakdown structure and making appropriate adjustments.
Other sources of work breakdown structure templates are technical and specialty
departments in the organization. These departments may have a standard WBS of their
activities. As an example, the construction department may have a template for remodeling
efforts and the human resources department may have a template for the development and
delivery of training classes. As well, most Information Systems departments also have
standard methodologies and work breakdown structure steps they follow which can be
inserted into a project plan.
installation passes city building dept inspection CO issued
Department management approves construction design
Demolition/removal accepted by engineer
Rough framing meets specifications
Rough electrical meets specifications
Rough plumbing meets specifications
Interior finish
Finish electrical
Finish plumbing
City inspection
Engineering inspection shows construction meets specifications
66

Scope Management
PERFORMANCE MEASUREMENT & VARIANCE ANALYSIS

USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
USED BY:
CHANGE CONTROL
The comparison of actual performance to the baselines in time, cost, scope, quality and
other processes is a regular project management task. Usually the process begins with status
reports submitted by the members of the project team. Manually or with the aid of an
automated Project Management Information System (PMIS), a project manager compares
where we are as of today to where we should be. The project manger then compares how
much we have achieved or delivered versus the baseline and how much it has cost compared
to the budget.
We may do these comparisons with variance analysis like you see below where we compare
the actual start to the baseline start and so on.
ID
Task Name
Act. Start
Start
$1 million in XJ-17 sales on website
Act. Finish
% Comp.
Phys. %
Comp
Act. Dur.
Rem. Dur.
Act. Cost
NA
NA
0%
0%
0 days
1 day
$0.00
T ue 12/20/05
NA
47%
0%
28.5 days
32.5 days
$59,701.00
40% of website visitors return withi T ue 12/20/05
NA
70%
0%
17.5 days
7.5 days
$28,000.00
Tue 12/20/05
NA
67%
0%
12.5 days
6.25 days
$20,000.00
Fri 1/13/06
NA
80%
0%
5 days
1.25 days
$8,000.00
Focus group of ten customers can e T hu 12/22/05
NA
47%
0%
22.69 days
25.81 days
$5,851.00
High level design spec 1-1 & test c Thu 12/22/05
NA
30%
0%
1.5 days
3.5 days
$630.00
Detailed design approved by Burlin
Thu 1/5/06
NA
25%
0%
2 days
6 days
10
IT-QC sign off that Construction m
Tue 1/17/06
NA
65%
0%
3.25 days
1.75 days
$845.00
11
IT-QC sign off that System test m
Tue 1/24/06
NA
95%
0%
7.6 days
0.4 days
$1,976.00
12
IT-QC sign off that Integration test
Fri 2/3/06
NA
30%
0%
3 days
7 days
$780.00
13
Burlingame & Wilson sign off on a
Fri 2/17/06
NA
40%
0%
3 days
4.5 days
$780.00
14
Website attracts 5,000 visitors per d
NA
NA
0%
0%
0 days
10 days
$0.00
15
Website has a top 5 position in the
NA
NA
0%
0%
0 days
10 days
16
20% of existing customers visit we
NA
NA
0%
0%
0 days
2.5 days
$0.00
17
90% of all new CSR s score 90% or bette
NA
NA
0%
0%
0 days
67.04 days
$0.00
18
Weekly call monitoring identifies any C
NA
NA
0%
0%
0 days
24.04 days
$0.00
19
100% of new CSRs attend training
NA
NA
0%
0%
0 days
4 days
$0.00
20
25 CSRs who meet hiring specs acce
NA
NA
0%
0%
0 days
7 days
$0.00
21
Director of CS approves HR's selectio
NA
NA
0%
0%
0 days
2 days
$0.00
P Burlingame & J W ilson s ign off
Produc t managers approve 124 X
$840.00
$0.00
Another alternative is to do our performance measurement and variance analysis with earned
value information.
Earned Value
PV
Week
Cost budget
Cost base line
1
12000
12000
2
13500
25500
3
14100
39600
4
13400
53000
5
12500
65500
6
16000
81500
7
18000
99500
8
9000
108500
9
8000
116500
10
7000
123500
AC
Actual cost
cum cost
11400
11400
13500
24900
13100
38000
15500
53500
14500
68000
17500
85500
19000
104500
11000
115500
7000
122500
7000
129500
% complete
8.40%
8.40%
12.00%
20.40%
11.00%
31.40%
10.00%
41.40%
12.00%
53.40%
15.00%
68.40%
8.00%
76.40%
6.00%
82.40%
5.60%
88.00%
12.00%
100.00%
EV
value created
10374
25194
38779
51129
65949
84474
94354
101764
108680
123500
CV
SV
CPI
SPI
Cost Variance
Schedule Variance
Cost performance Index
Schedule performance Index
-$1,026
-$1,626
0.91
0.86
$294
-$306
1.01
0.99
$779
-$821
1.02
0.98
-$2,371
-$1,871
0.96
0.96
-$2,051
$449
0.97
1.01
-$1,026
$2,974
0.99
1.04
-$10,146
-$5,146
0.90
0.95
-$13,736
-$6,736
0.88
0.94
-$13,820
-$7,820
0.89
0.93
-$6,000
$0
0.95
1.00
EAC
Estimate at completion
$135,714 $122,059 $121,019 $129,227 $127,341 $125,000 $136,780 $140,170 $139,205 $129,500

67
CONSTRAINTS AND ASSUMPTIONS

USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE OUTCOMES:
PROJECT PLAN DEVELOPMENT
PROJECT PLAN
SCOPE INITIATION
SCOPE STATEMENT
SCOPE PLANNING
SCOPE DEFINITION
WORK BREAKDOWN STRUCTURE
ACTIVITY DEFINITION
ACTIVITY LIST
ACTIVITY DURATION ESTIMATING
ACTIVITY DURATION ESTIMATES
SCHEDULE DEVELOPMENT
PROJECT SCHEDULE
ORGANIZATIONAL PLANNING
SCHEDULE MANAGEMENT PLAN
COMMUNICATIONS PLANNING
COMMUNICATIONS MANAGEMENT
PLAN
PROCUREMENT PLANNING
USED BY:
SENIOR MANAGEMENT, PROJECT

MANAGERS, STAKEHOLDERS AND TEAM
MEMBERS
PROCUREMENT MANAGEMENT PLAN

STATEMENT OF WORK
Constraints are restrictions that limit our projects duration, use of resources and budget
along with other issues. We develop our constraints during the initiation process and they
affect nearly every planning process. Often the constraints are the first words we hear from a
project sponsor, who is clear about how long we can take to finish the project and how
much we can spend. There are times when a combination of constraints makes a project
impossible or unfeasible. We first try to negotiate a loosening of the triple constraints to
make the project feasible. As an example, a tight budget constraint coupled with a short
duration may not be possible. But loosening one of those constraints may allow us to
succeed. If we cannot reach a compromise, a PMP is bound by both the PMBOK and
by PMIs professional ethics to notify the sponsor and the senior manager who issued the
charter that the project is not feasible with the current constraints.
Assumptions are aspects of the project that we consider to be true during the planning
phases. Assumptions are risks that we identify during scope initiation. When we come to
risk assessment, we always perform at least a qualitative risk analysis on all of the
assumptions to verify that we should still consider them to be true. As importantly, we
always measure qualitatively, and possibly quantitatively, the consequences to the project if
the assumptions are not true. In fact, we may find that the expected value of an assumption
is so large that we must plan a risk response to it. In sum, assumptions are not a list of
wishes and hopes that we attach to the charter. They are a set of risks that we identify early
and manage throughout the project.
68

Scope Management
EXPERT JUDGMENT
USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
SCOPE INITIATION
SCOPE STATEMENT
SCOPE PLANNING
USED BY:

ACTIVITY DEFINITION
ACTIVITY DURATION ESTIMATING
RESOURCE PLANNING
QUANTITATIVE RISK ANALYSIS
SOLICITATION PLANNING
The knowledge of experts is critical in the planning processes of our project. Consequently,
we use expert judgment in several processes throughout the project management life cycle.
We may pull our experts from our own organization, from relevant trade organizations, or
consultants trained in a particular area. In each case, we are talking with people who possess
a high level of knowledge regarding the project phase we are addressing.
When working on a small, interdepartmental project, our experts may be team members who
have worked on similar projects before or managers whose experience with projects of a
comparable size or scope can assist with the details of planning. We may need an assessment
of the validity of our resource availability assumptions or the probability of receiving any
procured items within a certain time frame.
To identify experts for a project, you may want to:
1. Look in trade magazines or in the membership directories of professional
associations.
2. Ask your sponsor or other senior managers for contact names.
3. Talk to your project team members about who they have worked with on previous
projects.
4. Contact local consulting firms.

69
DECOMPOSITION
USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
SCOPE DEFINITION
SCOPE STATEMENT
ACTIVITY DEFINITION
USED BY:

ACTIVITY LIST
WBS UPDATES
Decomposition is the process of breaking down the major deliverables of the project into
smaller component pieces. These pieces are organized to create the work breakdown
structure (WBS). We begin this process with the major deliverables of the project. We break
them down into smaller and smaller deliverables until we reach the point where the
resources assigned to these tasks can make accurate estimates on the duration of the task and
we can develop estimates on the cost of the task.
This graphic demonstrates a network, which is an effective tool for decomposition of major
deliverables into their component parts.
70

Scope Management
INSPECTIONS AND AUDITS

USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
SCOPE VERIFICATION
FORMAL ACCEPTANCE
QUALITY CONTROL
ACCEPTANCE DECISIONS
QUALITY ASSURANCE
QUALITY IMPROVEMENT
RISK MONITORING AND CONTROL
PROJECT CHANGE REQUESTS
USED BY:

CONTRACT CLOSEOUT
Frequent inspection of the product or the major deliverables of the project is performed to
ensure that we are performing the work that will lead to the accurate completion of our
scope. These inspections are often called audits, product verifications or reviews. They are
performed by the project manager, team members, the project sponsor, and people
independent of the project.
Inspections and audits are done for a variety of purposes, from verifying the scope to
comparing the deliverable to its specifications. The key issue in both of these activities is
that we are following a prescribed procedure or a checklist which has been developed in
advance. We're not just examining the deliverable, trying to find things that are wrong, were
comparing what has actually been produced versus what we were supposed to produce, in
terms of precise characteristics and specifications.
On smaller projects, we may use a checklist to audit or review the major deliverables. Larger
projects may undergo several different types of inspections in order to verify that we are
reaching the predefined acceptable level of quality.

71
CORRECTIVE ACTION
USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
CHANGE REQUESTS
USED BY:
SENIOR MANAGEMENT, PROJECT MANAGERS

AND TEAM MEMBERS
Corrective action is where the project manager and stakeholders avoid a change to the
project plan by creative problem solving or by taking advantage of opportunities. We take
corrective action after analyzing the factors which have caused a variance between actual
performance and the baseline. This analysis may utilize status reports from project team
members, earned value analysis or our project information system. We document the
problem and then we analyze the types of corrective action that will bring future
performance in line with the plan. Next, we take the corrective action and document the
impact. The final step in corrective action is to monitor actual performance to ensure that
our corrected action is having its desired effect.
Often it is the development of creative corrective action that allows a project to overcome
difficulties. Consistently successful project managers are good at crafting corrective action
solutions to problems. But as importantly, they also find out about problems early when
there is still time for corrective action. That early warning is a function of a good system for
information gathering and a project team culture that makes it safe for team members to
report problems early without fear of blame.
72

Scope Management
LESSONS LEARNED
USED IN THESE PMBOK
PROCESSES:
SUPPORTS THESE
OUTCOMES:
SCOPE, TIME, COST OR OTHER
CHANGES
USED BY:
SENIOR MANAGEMENT, CURRENT AND FUTURE

CHANGE REQUESTS
Lessons learned discussions and documentation should accompany all changes to the
baseline plan and situations where we take corrective action. The objective is documentation
of the issues that went according to plan, what led to their success, as well as the areas of the
project that needed modification. An outline might include:
Lessons Learned
Table of contents
1. Integration
1.1. Output of Integrated Change Control
1.2. Commentary on the reasons behind our change control decisions
2. Scope
2.1. Output of Scope Change Control
2.2. Assessment of the reasons behind scope changes and the means by which the
changes could have been avoided
3. Time
3.1. Output of Schedule Control
3.2. Assessment of the reasons behind schedule changes and the means by which the
4. Cost
4.1. Output of Cost Control
4.2. Assessment of the reasons behind cost changes and the means by which the
5. Quality
5.1. Component of the tool/technique Quality Audits
5.2. Assessment of the reasons behind quality changes and the means by which the
6. Communications
6.1. Output of Administrative Closure
7. Risk
7.1. Component of output Tracking as part of Risk Management Plan
7.2. Component of input Historical Information as part of Risk Identification
7.3. Component of output Risk Database in Risk Monitoring and Control
8. Leadership Style
9. Effectiveness of the project manager
10. Effectiveness of the organizations processes for project management
Lessons learned are an important output of all of our control processes. The discussion of
the project and its documentation are activities for both the project manager and the
stakeholders. There are two broad purposes of these activities.
First, the lessons learned process is a valuable source of improvement information for
project managers, stakeholders, team members and the organization. Project managers gain
information and insight on the effectiveness of their leadership and project management
approach. Stakeholders and team members can gain the same type of input on their
performance and they together with executives may see opportunities for the organization to
improve its project processes.
Second, lessons learned information is useful for future project managers so they can learn
from the mistakes made on historic projects and also from the things that went well.
Organizations without a lessons learned process make the same project mistakes over and
over again.

73
WORK BREAKDOWN STRUCTURE (WBS)

USED IN THESE PMBOK
PROCESSES:
SCOPE DEFINITION
SUPPORTS THESE
OUTCOMES:
FORMAL ACCEPTANCE
SCOPE CHANGES
USED BY:
SENIOR MANAGEMENT, PROJECT MANAGERS

AND TEAM MEMBERS
The work breakdown structure (WBS) is a hierarchical listing of the project deliverable and
sub-deliverables that we develop in a series of processes that take the product description
and progressively elaborate it as we move from initiation, to scope planning, scope definition
and activity definition. We can use decomposition or WBS templates or both to create a
WBS.
During the decomposition activities, we divide our project into smaller, more manageable
pieces which we can use to craft accurate resource and cost estimates. Breaking the project
down into these pieces also enables us to confirm that all of these pieces are tied to the
scope. These pieces are then arranged to construct a hierarchical list of the project that is
breakdown of the product.
In order to create this list, we begin with major deliverables and continue subdividing them
into smaller sub-deliverables and sub sub-deliverables. There are several rules project
managers use to determine when we stop subdividing. Generally, we want a duration
between 2 and 10 days of work because that is an appropriate size for scheduling and
budgeting.
Templates are sections or complete project plans from previous projects that act as guides.
We may use the same template repeatedly or modify it slightly for each project. These
templates can save us a lot of time because they eliminate the need to develop an entirely
new WBS each time we begin a project.
74

Scope Management
Start
Installation passes city building dept inspection, CO issued

75
SCOPE PRACTICE EXAM

1. After the completion of the scope statement, a key stakeholder informs you that they want
to add several major deliverables. How should you handle this situation? (027)
(A) refuse to make changes as that part of the planning is finished
(B) wait until the project plan is complete
(C) modify the scope statement as requested
(D) utilize the process specified in the scope management process
Answer: (D) All of the change management processes for scope, cost, procurement and so on should
be followed as soon as those plans and the project plan are approved.
2. An information systems (IT) project manager distributed a document to the stakeholders
which described the software to be developed, performance standards it would meet, the
users it would serve, their performance using it and the installation timeline and cost. The
document was an example of a: (014)
(A) charter
(B) WBS
(C) product description
(D) project scope
Answer: (D) The product description does not contain budget or schedule estimates. The charter
authorizes the project and gives the PM authority. The WBS is a listing of activities or work packages
so project scope is the best answer because it contains all these elements.
3. The project scope statement furnishes a basis for: (009)
(A) future project decisions including the criteria used in verification
(B) providing links to the clients functional management groups
(C) allowing the project to move to the next phase
(D) the project manager to assign project work to people
Answer: (A) The scope clearly communicates what is and what is not in the project and is, thus, used
for many decisions.
4. Having stakeholders and the client assist in the project planning: (037)
(A) enables better planning since they are familiar with project requirements
(B) is not recommended since those outsiders do not have an adequate knowledge of project
management
(C) usually confuses the situation
(D) provides only some understanding, but usually the client dealing with the project has
only limited authority
Answer: (A) Stakeholder and client involvement in project planning is the key to change control and
avoiding scope creep.
76


Knowledge Base

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Knowledge Base

Transféré par

Droits d'auteur :

Formats disponibles

Project Managers

PMBOK Case Studies

The Project Managers KnowledgeBase

HOW TO USE THE PROJECT

Use the 10 practice exams with the explanations of the answers

Practice examinations with answers and explanations.

PMBOK toolset pages that explain each tool with examples.

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

APPLYING THE PMBOK SCOPE MANAGEMENT CONCEPTS: ..................30

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

SCOPE PRACTICE EXAM.................................................................................76

APPLYING THE PMBOK TIME MANAGEMENT CONCEPTS .......................95

The Project Managers KnowledgeBase

TIME PRACTICE EXAM...................................................................................141

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

APPLYING THE PMBOK COST MANAGEMENT CONCEPTS....................159

COST PRACTICE EXAM .................................................................................188

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

APPLYING THE PMBOK QUALITY MANAGEMENT CONCEPTS ..............203

QUALITY PRACTICE EXAM............................................................................234

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

APPLYING THE PMBOK HUMAN RESOURCE CONCEPTS ......................250

HUMAN RESOURCES PRACTICE EXAM ......................................................273

The Project Managers KnowledgeBase

APPLYING THE PMBOK COMMUNICATIONS MANAGEMENT CONCEPTS

COMMUNICATION PRACTICE EXAM ............................................................308

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

APPLYING THE PMBOK RISK MANAGEMENT CONCEPTS .....................328

The Project Managers KnowledgeBase

RISK PRACTICE EXAM...................................................................................376

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

APPLYING THE PMBOK PROCUREMENT MANAGEMENT CONCEPTS..394

The Project Managers KnowledgeBase

PROCUREMENT PRACTICE EXAM ...............................................................433

APPLYING THE PMBOK INTEGRATION MANAGEMENT CONCEPTS .....451

INTEGRATION PRACTICE EXAM...................................................................482

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

PROFESSIONALISM & ETHICS PRACTICE EXAM .......................................497

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

The Project Managers KnowledgeBase

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

The Project Managers KnowledgeBase

Copyright 2004 Richard Billows All Rights Reserved

The Project Managers KnowledgeBase

Scope Management Plan

Scope Change Control

Work Breakdown Structure

Copyright 2004 Richard Billows All Right Reserved

The Project Managers KnowledgeBase

INPUTS TO SCOPE INITIATION

Copyright 2004 Richard Billows All Rights Reserved

TOOLS & TECHNIQUES OF INITIATION