EP 704 Unit 4

1
EP 704Unit 4

• Project Integration Management

Dr. J. Michael Bennett, P. Eng., PMP UNENE,
McMaster University, The University of Western
Ontario Version 2K4-XI-01
2
Revisions

• 2K4-XI-01 Initial Creation
• 2K4-XI-24 addition of 3rd edition slide

3
EP 704 Road Map

• Unit 1 Introduction to Project Management
• Unit 2 The Project Management Context
• Unit 3 Project Management Processes
• Unit 4 Project Integration Management
• Unit 5 Project Scope Management
• Unit 6 Project Cost Management
• Unit 7 Project Time Management
• Unit 8 Project Quality Management
• Unit 9 Project Human Resource Management
• Unit 10 Project Communications Management
• Unit 11 Project Risk Management
• Unit 12 Project Procurement Management

4
1 The IEEE PMP

• Purpose of the PMP
• PMP Outline (adapted from IEEE1058-99)
• Writing an PMP

5
Purpose of the PMP

• History
• Need
• Siting it

6
1998 PMP TOC

• 0 General
• 1 Overview
• 2 References
• 3 Definitions
• 4 Project Organization
• 5 Managerial Process Plans

• 6 Technical Process Plans
• 7 Supporting Process Plans
• 8 Additional Plans
• Annexes
• Index

7
Definitions

• Acquirer
• Baseline
• Milestone
• Work Activity- a collection of work tasks
  spanning a fixed duration within the schedule of
  a software project
• Work Task the smallest amount subject to
  management accountability

8
More definitions

• Work Package a specification of the work that
  must be accomplished to complete a work task
• Work Product any tangible item produced during
  the project

9
0 General Prefaces

• Title page
• Signature page
• Change history
• Preface
• TOC
• List of Figures
• List of Tables

10
1 Overview

• 1.1 Project Summary
• 1.1.1 Purpose, scope and objectives
• 1.1.2 Assumptions and constraints
• 1.1.3 Project deliverables
• 1.1.4 Schedule and budget summary
• 1.2 Evolution of the plan

11
1.1.1 Purpose, Scope and Objectives

• 1. concise summary of objectives2. product to
  be delivered3. major work activities4. major
  milestones5. required resources6. master
  budget and schedule

12
1.1.2 Assumptions and Constraints

• Assumptions on which the project is based
• Constraints (time, budget, resources, software to
  be reused, technology to be employed)
• Interfaces to other products

13
1.1.3 Project Deliverables

• 1. list of all deliverables2. including dates,
  locations and quantities3. is NOT the official
  Requirements document4. should have a pointer to
  it

14
1.1.4 Schedule and Budget Summary

• Summary of both
• Only the major work activities and supporting
  processes

15
1.2 Evolution of the Plan

• Specifies plans to do scheduled and unscheduled
  updates to the PMP
• Includes the dissemination plan
• Tells how to place the PMP under CM for the first
  time
• And subsequent updates

16
1.3 Project Charter

• Is the initial project plan document
• formally recognizes the existence of a project
• is issued by a manager external to the project
• provides the PM with the authority to apply
  organizational resources to the project

17
2 References

• Complete list of all documents referenced in the
  PMP
• All properly identified by title, report , date,
  author, path/name for electronic access,
  publishing organization

18
3 Definitions

• Define or refer to documents containing the
  definition of all terms and acronyms used in the
  PMP
• IEEE Std. 610.12-1990 Standard Glossary of
  Software Engineering Terminology (should be
  boiler-plate)

19
4 Project Organization

• Identifies
• Interfaces to organizational entities external to
  the project
• Project's internal organization
• Roles and responsibilities for the project

20
4 Project Organization

• 4.1 External Interfaces
• 4.2 Internal Structure
• 4.3 Roles and Responsibilities

21
4.1 External Interfaces

• Parent organization
• Customer
• Subcontractors
• Other organizational entities that interact with
  the project
• Org charts can be useful here

22
4.2 Internal Structure

• Describes Interfaces among/between
• the units of the Project Team
• configuration management
• quality assurance
• IVV
• etc etc etc
• Use graphical devices (org charts)

23
4.3 Roles and Responsibilities

• Identifies and states the nature of each major
  work activity and supporting process
• IDs the org units responsible for these processes
  and activities
• Matrixing of WAs and Supporting Processes vs
  OrgUnits good here

24
5 Managerial Process Plans

• Specifies the PM processes for the project
• Includes at least
• Start-up plan
• RMP
• PMP
• Project close-out plan

25
5 Managerial Process Plans

• 5.1 Start-up Plan
• 5.2 Work Plan
• 5.3 Control Plan
• 5.4 Risk Management Plan
• 5.5 Closeout Plan

26
5.1 Start-up Plan

• 5.1.1 Estimation Plan
• 5.1.2 Staffing Plan
• 5.1.3 Resource Allocation Plan
• 5.1.4 Project Staff Training Plan

27
5.1.1 Estimation Plan

• Specifies
• the cost and schedule for executing the plan
• methods. Tools, techniques for estimating , T,
  resource requirements
• confidence levels for above
• Basis of estimation
• How to re-estimate on a periodic/episodic basis

28
5.1.2 Staffing Plan

• Specifies number of folks on a
• skill level
• phase level
• types of skills needed
• duration
• source
• Use MSP/Artemis for charts to show

29
5.1.3 Resource Allocation Plan

• Specifies how to acquire non-human resources
• What, how, who, when
• Includes
• Equipment
• Hardware/software
• Janitorial
• Transportation
• Training
• Facilities
• Administration

30
5.1.4 Project Staff Training Plan

• Types of training needed
• Number of people
• Entry and exit criteria
• Training method

31
5.2 Work Plan

• Specifies work activities, schedule, resources,
  budget details for the entire project

32
5.2 Work Plan

• 5.2.1 Work Activities
• 5.2.2 Schedule Allocation
• 5.2.3 Resource Allocation
• 5.2.4 Budget Allocation

33
5.2.1 Work Activities

• Specify the WAs
• Use a WBS
• Decompose so that all risk factors are exposed,
  accurate estimates can be given
• WAs specify resources, costs, times, acceptance
  criteria, predecessor and successor WAs

34
5.2.2 Schedule Allocation

• Specs schedule relationships between WAs to show
  time-sequencing constraints
• Show opportunities for concurrency
• Show constraints (esp. externals)
• State frequent milestones
• Use visual devices such as PERTs, Gantts,
  activity networks, CPMs

35
5.2.3 Resource Allocation

• Detailed itemization of resources allocated to
  each major WA
• Numbers and skills of folks needed

36
5.2.4 Budget Allocation

• Detail necessary resource budget for each WA
• Include also travel costs, meeting costs,
  computing costs, software tools, special
  testing/simulation facilities, administrative
  support
• Use a spreadsheet

37
5.3 Control Plan

• Specifies metrics, reporting mechanisms, control
  procedures to measure, report, control
• Requirements
• Project schedule, budget, resources
• Quality
• Must be aligned with Org's policy

38
5.3 Control Plan

• 5.3.1 Requirements Control Plan
• 5.3.2 Schedule Control Plan
• 5.3.3 Budget Control Plan
• 5.3.4 Quality Control Plan
• 5.3.5 Reporting Plan
• 5.3.6 Metrics Collection Plan

39
5.3.1 Requirements Control Plan

• How to measure, report, control changes to
  requirements
• Mechanism to assess impact of RC on scope,
  quality, project schedule, budget, resources,
  risk factors
• Traceability too

40
5.3.2 Schedule Control Plan

• How to measure progress at major and minor
  milestones
• Compare actual to planned
• Implement corrective action
• Specify tools and methods to do this

41
5.3.3 Budget Control Plan

• Mechanism used to measure cost of work completed,
  compared to planned cost
• Implement corrective action
• Specify measurement intervals

42
5.3.4 Quality Control Plan

• How is quality to be measured
• Detail the process including reports

43
5.3.5 Reporting Plan

• Reporting mechanisms, format
• Frequency and detail of reporting
• Specify interfaces to be reported to

44
5.3.6 Metrics Collection Plan

• Methods, tools , techniques to collect And report
  project metrics
• Specify actual metrics, frequency, methods to
  validate, analyze and report metrics

45
5.4 Risk Management Plan

• IDs, analyzes, ranks RFs (risk factors)
• Describes procs for contingency planning
• Describes methods for
• Tracking RFs
• Evaluating changes in levels of RFs and responses
  to those changes
• Specifies plans for assessing initial RFs,
  ongoing IDing, assessment and mitigation of RFs
  for the length of the project

46
Riskin IT

• RM Plan describes (at least)
• RM work activities
• Procedures and schedules for performing WAs
• Documentation and reporting requirements
• Organizations and people responsible for specific
  activities
• Communication procedures to all (including
  acquirer, supplier, subs

47
Types of Risks

• Acquirer-supplier relationship
• Contractual risks
• Technological risks
• Size risks
• Development and environment risks
• Personnel acquisition risks
• Skill levels and retention risks
• Schedule and budget risks
• Risks in achieving acquirer acceptance

48
5.5 Project Closeout Plan

• Plans to ensure an orderly closeout of the
  project
• Should include plans for
• Staff reassignment
• Archiving project materials
• Post mortem debriefing
• Preparation of final report and Lessons Learned

49
6 Technical Process Plans

• Specifies
• The developmental process model
• MTT to develop the various work products
• Plans for specifying and maintaining the project
  infrastructure
• The product acceptance plan

50
6 Technical Process Plans

• 6.1.1.1 Process Model
• 6.1.1.2 Methods, Tools and Techniques
• 6.1.1.3 Infrastructure Plan
• 6.1.1.4 Product Acceptance Plan

51
6.1.1.1 Process Model

• Defines the relationships among major project
  work activities and supporting processes by
  specifying
• Flow of information and work products among
  activities and functions
• The timing of work products to be generated
• Reviews to be conducted
• Major milestones
• Baselines
• Project deliverables
• Required approvals

52
Cont.

• Can use graphical methods plus text
• Any change from the corporate model must be noted

53
6.1.1.2 Methods, Tools, Techniques

• Specifies developmental methodologies, tools and
  techniques
• Specify
• Design
• Build
• Test
• Integrate
• Document
• Deliver
• Modify and maintain the project's Ds and non-Ds

54
MTT Cont.

• Any technical standards, policies and procedures
  governing this must be mentioned
• This is dependent on the specific life cycle of
  the product we are developing. Software,
  Engineering product, bridge, etc

55
4.1.1.3 Infrastructure Plan

• Plan for establishing and maintaining the
  project-specific development environment
  including
• Hardware
• Networks
• Software
• environment
• Plus policies, procedures, standards, facilities

56
6.1.1.4 Product Acceptance Plan

• ID sign-offers and the (objective) conditions
  under which they MUST sign-off

57
7 Supporting Process Plans

• These are the supporting processes that last the
  duration of the project
• Specified to the same level as the PP
• Also must ID folks. time, costs to do this
• These may vary but MUST include CM, VV, QA,
  Problem Resolution, Client Review
• Can boiler-plate pointers here

58
7 Supporting Process Plans

• 7.1 Configuration Management Plan
• 7.2 Verification Validation Plan
• 7.3 Documentation Plan
• 7.4 Quality Assurance Plan
• 7.5 Reviews and Audits
• 7.6 Problem Resolution Plan
• 7.7 Subcontractor Management Plan
• 7.8 Process Improvement Plan

59
7.1 Configuration Management Plan

• CM plan for project including
• CI
• Control
• Status accounting
• Evaluation
• Release management

60
CM cont.

• Procedures for
• Initial baselining of WPs
• Logging and analysis of CRs
• CCB procedures
• Tracking of changes in progress
• Communication of results
• Automatic tools nice here

61
7.2 Verification Validation Plan

• VV plan includes
• Scope
• Tools
• Techniques
• Responsibilities
• Spec too the organization relationships and
  levels of independence

62
VV cont

• Verification Specifies
• Traceability
• Milestone reviews
• Progress reviews
• Peer reviews
• Prototyping
• Simulation
• Modeling

63
VV cont.

• Validation specifies
• Testing
• Demonstration
• Analysis
• Inspection

64
7.3 Documentation Plan

• Note that there are at least 3 modes of
  documentation
• (user, administrator, maintainer)
• Also non-deliverable and deliverable WPs
• This is the Plan to do this

65
DocPlan cont.

• Specifies OEs responsible for input information,
  doc generation, reviewing products
• NDs include requirements, design documentation,
  traceability matrices, test plans, meeting
  minutes, review sessions
• Ds include source code, object code, regression
  test suite, configuration library, user's manual,
  on-line help system, maintenance guide, etc

66
DocPlan cont.

• Includes
• List of documents to be prepared
• Template or standard
• Who will do it
• Who will review it
• Due dates
• Distribution list for reviews, baselines

67
7.4 Quality Assurance Plan

• Will point to a QAP

68
7.5 Reviews and Audits

• Specifies reviews and audits
• Schedule
• Resources
• Audits
• Assessments
• External agencies that approve/regulate

69
7.6 Problem Resolution Plan

• Specs the resources, TT, procedures to
• Report
• Analyze
• Prioritize
• Process SPRs during the project
• PRP states roles of development, CM, CCB, VV

70
7.7 Subcontractor Management Plan

• States how we manage any outsourcing
• See seminar series with the Institute

71
7.8 Process Improvement Plan

• Necessary for Quality organizations
• States results of tracking defects back to source
  and how the process is to be change-managed to
  prevent future occurrences

72
8 Additional Plans

• Are there any other plans
• Could involve
• Safety
• Privacy
• Security
• Installation/rollout
• Maintenance
• Etc etc etc

73
Annexes

• Anything else of use that might clutter up the
  clarity of the PMP

74
Index

• For acks and terms used in the plan

75
The Project Plan Process cont

• Tools and Techniques
• 1 Project planning methodology
• 2 Stakeholder skills and knowledge
• 3 Project management information
• system (PMIS)
• 4 Earned value management

76
2 Stakeholder Skills and Knowledge

• Stakeholders must be identified
• Each has skills, knowledge that may be useful in
  developing the PP
• PM must set up an environment in which the
  stakeholders can contribute in an appropriate
  manner

77
Examples

• A construction project with a lump-sum contract.
  The Cost Engineer will make a major contribution
  concerning profitability when the contract is
  being drawn up
• Project team members with special expertise will
  quality duration and effort estimates
• The Quality Manager can clarify quality objectives

78
3 PMIS

• The set of tools and techniques used to gather,
  integrate and disseminate outputs of the PM
  processes
• May be informal (excel spreadsheets and emails)
• May be formal. Artemis for example
• May be some hybrid of the two

79
Finishing the Plan Process

• Tools and Techniques
• 1 Project planning methodology
• 2 Stakeholder skills and knowledge
• 3 Project management information
• system (PMIS)
• 4 Earned value management

80
4 Earned Value Management

• Why it is mandatory
• What it is
• How we calculate it

81
Earned Value

• varianceany deviation from de plaaan, boss
• cost variance
• schedule variance
• PV Planned Value (old BCWS Budgeted Cost of
  Work Scheduled)
• EV Earned Value (old BCWP - Budgeted Cost of
  Work Performed)
• AC Actual Cost (old ACWP - Actual Cost of Work
  Performed)
• Performance IndicesSPI EV Schedule
  Performance Index
• PV
• CPI EV Cost Performance Index AC
• Critical Ratio (CR)CR SPI x CPI

82
EV Starts with the S-Curve
83
Hows the Project Today? EVA IT!
TODAY
Cumu l at i ve
Time in Months
84
Estimating the Final Time/

• Track at regular intervals (2 weeks)
• Green-light it if within .9-1.1
• Yellow-light it if .85 to .9 or 1.1 to 1.15
• Red-flag if below 0.8 or above 1.2

85
QAD Estimates

• Just invert the fractions
• If SPI 0.5, twice as long
• If CPI0.25, 4 times the cost and these are your
  most optimistic estimates!

86
EV Example Using Spending Curves
AC
PV
EV
70,000
Cumu l a t e i v e
60,000
50,000
40,000
30,000
20,000
10,000
0
1
2
3
4
5
6
7
8
9
10
Time in Months
TODAY
87
4 Project Plan Execution
Tools and Techniques 1 General management
skills 2 Product skills and knowledge 3
Work authorization system 4 Status review
meetings 5 Project management information
system 6 Organizational procedures
Inputs 1 Project plan 2 Supporting
detail 3 Organizational policies 4
Preventive action 5 Corrective action
Output 1 Work results 2 Change
requests
88
EVA Using Spending Curves
Cumu l ate i ve
Time in Months
TODAY
89
Typical Performance Report
90
3 Outputs from the Project Plan Development

• 1 The Project Plan
• 2 Supporting detail

91
4 Project Plan Execution

• general management skills
• product skills and knowledge
• work authorization system
• status review meetings
• project management information system

92
1 Inputs to the Project Plan Execution

• 1 Project Plan
• 2 Supporting detail
• 3 Organizational policies
• 4 Preventive action
• 5 Corrective action

93
1 Project Plan

• As we have seen in previous section
• Must have at least
• Scope management plan
• Risk management plan
• Contract management plan
• Performance measurement plan
• Quality plan

94
2 Supporting Detail

• As fleshed out in the PP

95
3 Organizational Policies

• Any policies that the organization wants followed
  in the execution of the plan, such as formal
  reporting of the EV and Risk Indices

96
4 Preventive Action

• Will flow from the Risk Management Plan

97
5 Corrective Action

• Anything done to bring expected future project
  performance in line with the plan

98
Tools and Techniques for Project Plan Execution

• 1 General management skills
• 2 Product skills and knowledge
• 3 Work authorization system
• 4 Status review meetings
• 5 PMIS
• 6 Organizational procedures

99
1 General Management Skills

• The PM must exhibit skills such as
• Leadership
• Communication
• Negotiating

100
2 Product Skills and Knowledge

• The team must understand the characteristics of
  the projects product
• These skills would be defined in resource
  planning of the PMP

101
3 Work Authorization System

• This is a formal release mechanism of funds to
  ensure the timely execution of the right work at
  the right time
• Typically it is a written authorization to
  proceed with the work
• Should be balanced with the amount of work to be
  done (verbal is fine for small WPs)

102
4 Status Review Meetings

• The frequency and attendance of each is specified
• Typically the team meets once a week
• The format should be boiler-plated
• Other meetings are scheduled too
• Customers
• Management
• Some may be event-driven!

103
5 PMIS

• Updated regularly as the work progresses

104
6 Organizational Procedures

• Anything formal or informal that the organization
  requires of work

105
3 Outputs from the Project Plan Execution

• 1 Work results
• 2 Change requests

106
1 Work Results

• These are the project progress reports from EVM
  and standard accounting
• Normally are tangible builds such as buildings,
  roads
• But may be training

107
2 Change Requests

• These will be generated as the work progresses

108
General Principles of Project Control

• Premises of Project Control
• Characteristics of a Project control System
• Components of a Project Control System
• Project Audits
• Project Control using EV

109
Premises of Project Control

• Control work, not workers
• Based on completed work
• Build metrics of control data into work process
• Send control data to the worker
• Control systems is designed for the ordinary
• Controls are hierarchical

110
Characteristics of a Project Control System

• Planning performance
• Observing performance
• Comparing actualize and planned
• Adjusting as required

111
Components of a Project Control System

• Is a feedback system
• Can be first order
• Or third

112
First-Order FBS
Inputs
Process
Outputs
Feedback
113
Third-Order FBS
Specifications Money People Authorization Data
Design Test Code Test Install
Plans Prototype System Document - -l
ADJUST
PLAN
COMPARE
MONITOR
114
Project Audits

• should contain at least1. current project status
• 2. EVM results and completion
  projections3. status of critical tasks4. risk
  assessment5. information relevant to other
  projects6. limitations of the audit

115
Statistical Process Control

• Useful for tracking the mature project
• Plot the EV stats as we proceed
• Normally done in the unit, over several projects
  running at the same time

116
Control Charts for PMs

• Control charts X, R and S

117
Control Chart Basics
In-control
UCLR
Range
CLr
118
Control Chart Basics
UCL
X-bar
CLx
LCL
Out-of-control
UCLR
Range
CLr
119
Shewart Control Charts
UCL CL3?
Centreline
X-bar
LCL CL-3?
120
OOC Rules

• 1 a single point is outside 3 sigma
• 2 at least 2 out of 3 successive points are on
  the same side of the CL and beyond 2 sigma
• 3 at least 4 out of 5 fall on the same side of CL
  and are at least one sigma off
• 4 At least 8 successive values fall on the same
  side of CL

121
Examples of OOC Situations
1
UCL
ZoneC
2
ZoneB
ZoneA
CLx
4
ZoneA
ZoneB
3
LCL
ZoneC
122
The Stability Process
ID process chars that describe process perf
Select process
Select appropriate type of Control Chart
Measure process perf over a period of time
ID and remove assignable causes
Build Control Chart
Plot Data on CChart
Y
N
Process is Stable continue measuring
In control?
Process is Unstable
123
Building the Charts
for each subgroup of size n
Rk XMAX - XMIN
X1X2.. Xk
k
124
Chart Limits

• X-bar
• UCLX A2R
• CLX
• LCLX -A2R
• Range (R)
• UCLR D4R
• CLR R
• LCLR D3R

125
Magic Constants

• N d2 A2 D3 D4
• 2 1.128 1.880 ----- 3.268
• 3 1.693 1.023 ----- 2.574
• 4 2.059 0.729 ----- 2.282
• 5 2.326 0.577 ----- 2.114
• 6 2.534 0.483 ----- 2.004
• 7 2.704 0.719 0.070 1.924
• 8 2.847 0.373 0.136 1.864
• 9 2.970 0.337 0.184 1.816
• 10 3.078 0.308 0.223 1.777

126
X-BAR and S CHARTS

• Previous fails if ngt10
• Must use averages of standard deviations

127
Homogenix Example
128
Calcs

• X45.06
• R7.33
• N5
• A20.577
• D42.114

129
Homogenix Control Chart
X-bar
In-control
Range
130
S Values
n
? (Xi - X)2
S
i1
n-1
131
X, S Chart Limits

• X-bar
• UCLX A3S
• CX
• LCLX - A3S
• S Chart
• UCLS B4S
• CLS S
• LCLS B3S

132
Average Standard Deviation Constants

• n A3 B3 B4
• 2 2.659 ------- 3.267
• 3 1.954 ------- 2.568
• 4 1.628 ------- 2.226
• 5 1.427 ------- 2.089
• 6 1.287 0.030 1.970
• 7 1.182 0.118 1.882
• 8 1.099 0.185 1.815
• 9 1.032 0.239 1.761
• 10 0.975 0.284 1.716
• 11 0.927 0.322 1.678
• 12 0.886 0.354 1.646
• 13 0.850 0.382 1.619
• 14 0.817 0.407 1.593
• 15 0.789 0.428 1.572

133
Moving Range Charts

• Sometimes all we have is an individual
  measurement
• Use a moving average approach

134
Moving Range Charts (XmR)

• When measurements are spaced widely in time
• When each point is used BY ITSELF
• Use a moving average (we look at 2, but more can
  be used)

135
When to Use (Westinghouse)

• Accounting figures of all kinds such as
  efficiencies, shipments, absences, losses,
  inspection ratios, maintenance costs, accident
  reports, etc
• Production data such as temperatures, pressures,
  voltages, humidity, heat, conductivity etc

136
XmR Equations

• Have k sequential data points
• ith moving range mRi X i1 - Xi
• Individuals amr
• U/LNPLx X ? 2.660
• CLx X

mR
i1

d2
137
Range Data Table
138
XmR (not X, S) better detects

• Cycles
• Trends
• Mixtures
• Grouping
• Relations between grouping and specification

139
Example
140
Xm Charts for Daily Product Service
5554535251504948474645444342414039383736
UCL























45.1

















LCL
10 20
30 40
141
mR Chart for Daily Product Service
111009080706050403020100
UCL

















3.34























10 20
30 40
142
Moving Range Charts for Discrete Data

• The number of Unresolved problems (URP) is
  compared against the planned number. But the
  manager suspects that something happened during
  week 31. Did it? Here is the data.

URPs Planned Dev Avg Dev Avg Dev
from seen URPs planned 2now from
grand Q Qavg 28 19 47
20.1 39 20.5 36.6
143
History of Unresolved Problems
144
Calculations

• Xbar 20.4
• mRbar 4.35
• CL Xbar
• UNPLx Xbar 2.66mRbar 31.6
• UCL 14.2

145
Xm Charts for UPRs
3230282624222018161412100804
UNPLx 31.6















CL20.4
















LNPLx 9.2
10 20
30 40
146
mR Chart for UPRs
UCL 14.2
1413121110090807060504030201












mRbar 4.4


















10 20
30 40
147
Moving Average and Moving Range

• MAMRs
• Same as before except we calculate the Moving
  Average instead of the individual points
• mXk (Xk Xk-1 Xk-n1)/n
• mX S mXk/(N-n1), kn(N)1

148
Using MAs to Estimate

• The software project manager is tracking the
  progress of detailed design of modules for a
  large piece of software. Is she in control?

149
Estimating with MAs
Number of modules completed per month
150
MAs
40
UCL34.575
Moving Averages
20
CL18.125
LCL1.675
UCL28.55
MovingRange
CL8.75
10
151
Trend-Line Graph
125
100
75
Number of Units Completed
50
25
1 2 3 4 5 6 7 8 9 10
11 12
Elapsed Months of Design Activity
152
Problems to look out for

• Cycles
• Trends
• Rapid shift in level
• Unstable mixture
• Bunching
• Stratification

153
Cycles

• Series of similar highs and lows
• Find the assignable cause
• Look for process variables such as
• Effort
• Support systems
• Personnel rotation
• Schedule demands
• System-build cycles

154
Cycles in Control Charts
UCL CL3?
Centreline
X-bar
LCL CL-3?
155
Trends

• Gradual but clear change in level
• Could be good or bad

156
Trends in Control Charts
UCL CL3?
Centreline
X-bar
LCL CL-3?
157
Rapid Shift in Level

• Sudden, apparently lasting shift due to one
  assignable cause
• Some new thing has jumped in
• Could be
• New procedures
• Change of personnel
• New product characteristics
• Changes in tools
• Changes in suppliers

158
Rapid Shift in Control Charts
UCL CL3?
Centreline
X-bar
LCL CL-3?
159
Unstable Mixture

• 2 or more assignable causes are carping up
• May interact randomly or in a pattern
• Measurement of time to defect-fix
• Some are simple
• Some are hard
• Sometimes we do not have enough people to do them
  all
• Try to factor out freaks

160
Unstable Mixture in Control Charts
UCL CL3?
Centreline
X-bar
LCL CL-3?
161
Bunching (or grouping)

• Strange values in a clump
• Look at the things going on at that time to seek
  out assignable causes

162
Bunching in Control Charts
UCL CL3?
Centreline
X-bar
LCL CL-3?
163
Stratification

• Variations are too close to the CL
• Perhaps a mistake was made in the CLs
• Check the range charts

164
Stratification in Control Charts
UCL CL3?
Centreline
X-bar
LCL CL-3?
165
Assignable Causes

• Erroneous data
• Data organization and analysis issues
• Process noncompliance
• Flawed or inadequate process design
• Change in characteristics in 1 or more process
  elements or causes

166
Data Organization and Analysis

• Lack of rational sampling
• Irrational subgrouping
• Nonhomogeniety in subgroups
• Parallel streams, use of averages from
  out-of-control processes

167
Process Noncompliance

• People, skill mix, resources, support, management
• Careless or inconsistent process execution
• Work environment changes

168
Erroneous Data

• Data collection mishaps
• Poor or loose operational definitions of
  measures, causing misinterpretation and
  misunderstanding leading to incorrect data
  recording

169
Distributional Models

• Binomial (np, p, XmR charts )
• Poisson (c, u chart)
• No expected distribution (as we have seen)
• Good reasons to expect Poisson in SE

170
5 Integrated Change Control

• Is concerned with
• Influencing the factors that create changes to
  ensure that changes are agreed on by all
  relevant parties
• Determining that a change has occurred
• Managing the actual changes when and as they occur

171
Must Have

• Baselined objects
• Either rejecting new changes to the Baseline or
  approving them and integrating them into the new
  Baseline

172
Requirements for ICC

• Maintaining the integrity of the performance
  measurement baselines
• Ensuring that changes to the product scope are
  reflected in the project scope baseline
• Coordinating changes across knowledge areas

173
Coordinating Changes Across the Entire Project
Communications
Integration
Subsidiary Change Control
Scope Change Control Schedule Change
Control Cost Change Control
Quality Control Risk Change Control
Contract Administration
174
Integrated Change Control
Inputs 1 Project plan 2 Performance
reports 3 Change requests
Output 1 Project plan updates 2
Corrective action 3 Lessons learned
Tools and Techniques 1 Change control system
2 Configuration management 3 Performance
measurement 4 Additional planning 5 PMIS
175
Inputs to ICC

• 1 Project Plan
• 2 Performance Reports
• 3 Change Requests

176
1 Project Plan

• This the ultimate baseline against which all
  changes will be controlled
• Note the special self-referential case of
  changing the Plan

177
2 Performance Reports

• These can include at least
• Performance reviews
• Variance analyses
• Trend analyses
• EV analyses

178
3 Change Requests

• Normally will be submitted with a common
  template
• Could also be
• Oral
• Informally written
• Direct or indirect
• Externally or internally initiated
• Legally mandated

179
Tools and Techniques for ICC

• 1 Change control system
• 2 Configuration management
• 3 Performance management
• 4 Additional planning
• 5 PMIS

180
1 Change control system

• A collection of formal, documented procedures
  that defines how project performance will be
  monitored and evaluated
• Includes the precise steps by which baselined
  project documents can be changed

181
CCS Components

• Paperwork
• Tracking systems
• Processes
• Approval levels necessary for authorizing changes

182
Product Versioning

• Revisions
• Variations
• How to Name

183
Product Evolution Graph
1.3
1.4
1.0
1.1
1.2
2.0
2.1
1.1.1
1.1.2
184
Version Control

• a Version is a new collection of Configuration
  Items
• each node in the previous slide was a Version
• a variant is a subset of a version

1
2
3
4
5
Version Variants 1234 and 1235
185
Change Management Control

• Change Management Plan
• The CM Process
• CM Object Identification
• Version Control
• Change Control
• Configuration Audit
• Status Reporting
• CM Standards

186
Change Management Plan

• A CM plan has two key components
• Baselines
• Configuration Items CIs

187
Baselines

• A baseline is a fixed milestone deliverable
• Restaurant analogy
• Typical Baselines
• 1. system specification
• 2. product requirements specification
• 3. design specification
• 4. Build specification
• 5. test plans-procedures-data
• 6. operational system

188
Procedure

• Baseline is fixed
• Entered into Project database
• Must be locked if copies are taken
• Need Change Control Board to approve BL
  modifications

189
Configuration Items CIs

• An CI is a named controlled object
• Can be a single section of a specification
• Can be a component

190
Minimum CI List

• 1. System Specification
• 2. PMP
• 3. Requirements Specification
• (a) executable or paper prototype
• 4. Preliminary Users Manual
• 5. Design Specification
• (a) data design document
• (b) architectural design document
• (c) module design document
• (d) interface design document
• (e) object descriptions
• 6. Source Code Listing
• 7. Testing
• (a) procedures
• (b) test cases and recorded results

191
Minimum CI List cont.

• 8. Operational manuals
• 9. Executable Modules
• (a) modules of executable code
• (b) linked modules
• 10. Database Description
• (a) schema and file structure
• (b) initial content
• 11. As-Built User Manuals
• 12. Maintenance Documents
• (a) software problem reports
• (b) maintenance requests
• (c) ECOs
• 13. Standards and Procedures

192
The CM Process

• Any discussion of CM poses the following
• how can the CIs be change-managed?
• how are the CI changes controlled before and
  after customer-release?
• Who is responsible for the changes and their
  priorities?
• how do we know that the changes have been made
  appropriately?
• how do we tell others that the changes have been
  made?
• and how do we know that they know?

193
CM Object Identification

• objects must be classed
• basic vs. composite
• each object has a list of attributes
• 1. name
• 2. description
• 3. list of resources
• 4. a realization

194
Change Control

• This the algorithm for changing a baselined
  object
• Change Report (CR)
• Change Control Board (CCB)
• Engineering Change Order (ECO)
• May also have other titles such as
• Engineering Review Board
• Technical review Board
• Technical Assessment Board

195
The CI Checkout Process
configuration object (modified)
configuration object (baselined version)
Check In
unlock
audit info
Project Database
Access Control
ownership info
Engineer
lock
Check Out
configuration object (baselined version)
196
Configuration Audit

• Control mechanisms only track until ECO is
  issued.
• How do we make sure that the change has been
  properly implemented?
• formal technical review
• product configuration audit

197
Formal Technical Review

• assess CI with respect to its consistency with
  other CIs, omission, side-effects
• done for all changes
• must be formal

198
Configuration Audit

• has the ECO-specified change been made?
• have any additional modifications been made?
• has a formal review been done?
• have the Engineering standards been followed?
• has the change been highlighted in the CI? Is
  the date there, author? Do the attributes
  reflect the change?
• have CM procedures for noting change, recording
  it and reporting it, been followed?
• have all related CIs been properly updated?

199
2 Configuration management

• This is a subset of Change Management
• Typically it is a parts list
• Perhaps software code listing
• Same principles apply though

200
3 Performance management

• Performance measurement technique, as seen will
  assess whether variances from the plan require
  corrective action
• This should flow out of the CCB decision to
  accept the change

201
4 Additional planning

• If the change is accepted, it is highly likely
  that we will need new cost and schedule
  estimates. Perhaps activity sequences need to be
  modified or inserted.
• Are there Risk implications? In fact, was this a
  risk and if not, why not

202
5 PMIS

• Updated as per usual

203
Outputs from the ICC

• project plan updates
• corrective action
• lessons learned

204
Status Reporting

• CSR asks the following questions
• what happened?
• who did it?
• when did it happen?
• what else was affected?

205
Configuration Management Standards

• IEEE 828-1990 Standard for Software CM PlansA
  standard (actually format) for designing your CM
  plan
• IEEE 1042-1990 Guide for Software Configuration
  ManagementAn introduction to folks first
  entering the field
• MIL-973 Configuration ManagementA DoD
  codification necessary for USA DoD contracting.
  Heavy!

206
Project Configuration Management

• Very Important Core Competency
• PLAN to REPLAN
• Before PMP is SOed, all is fluid
• After PMP, solid
• Must establish a a change control board
• Items are submitted, given an number and then
  voted on
• When approved, an ECO to plan is issued
• Need a procedure for this

207
Summary

• CM is an umbrella activity covering all aspects
  of a project, process and product. To quote the
  IEEE 610 definition, it isa discipline applying
  technical and administrative direction and
  surveillance over the life cycle of items...ANY
  items that are of importance to us.

208
6 Wrap-up

• What have we learned today?
• Summary and Future Directions

209
Chapter Four PIM

• 2K Edition
• 4.1 Project Plan Development
• 4.2 Project Plan Execution
• 4.3 Integrated Change Control

• Third Edition
• 4.1 Develop Project Charter
• 4.2 Develop Preliminary Project Scope Statement
• 4.3 Develop Project Management Plan
• 4.4 Direct and Manage Project Execution
• 4.5 Monitor and Control Project Work
• 4.6 Integrated Change Control
• 4.7 Close Project