Project and Change Management

1
Project and Change Management

• Time Management

2
Project Time Management

• Establishes and maintains the appropriate
  allocation of time
• By planning, estimating, scheduling, trending and
  schedule control
• Through the successive stages of the projects
  natural life-span
• i.e. definition, concept, execution and finishing

3
Some Time Management Technologies

• Gantt charts
• Critical path analysis (CPM)
• Pert charts
• Monte Carlo simulation
• GERT analysis
• Line of balance techniques
• Critical Chain approach
• S-curves

4
Time Management Processes

• Activity definition identifying the specific
  activities that must be preformed to produce the
  various project deliverables
• Activity Duration Estimating estimating the
  number of work periods which will be needed to
  complete individual activities
• Activity Sequencing identifying and documenting
  interactivity dependencies
• Schedule development analysing activity
  sequences, activity durations and resource
  requirements to create the project schedule
• Schedule Control controlling changes to the
  project

5
Activity Definition

• Activity definition is the process that involves
  the identification and the documentation of the
  specific activities required to produce the
  project deliverable and sub-deliverables
  identified in the WBS
• In this process the main goal is to define the
  activities that are required to produce the
  desired project objectives

6
Activity definition- inputs

• WBS
• Scope Statement
• Historical Information
• Constraints
• Assumptions

7
Methods used

• Decomposition Involves subdividing project
  elements into smaller, more manageable
  components. Differs from scope definition in that
  the Output are activities (action steps) rather
  than deliverables
• Templates Activity lists or portions of activity
  lists from previous projects.

8
Activity Definition - Outputs

• A detailed activity list
• Supporting detail
• Refined work breakdown structure

9
Activity definition Issues

• 80-20 rule
• Choose deliverables as boundary points
• Activities should be S.M.A.R.T (specific,
  measurable, achievable, realistic, time-based)
• Avoid premature use of schedules that are too
  detailed

10
Activity Duration Estimating - Inputs

• Activity List
• Constraints
• Assumptions
• Resource Requirements
• Resources Capabilities
• Historical Information

11
Techniques for Activity Duration Estimating

• Expert judgement
• Analogous estimating
• Simulation

12
Outputs of Activity Duration Estimating

• Activity duration estimates
• Basis of estimates

13
Estimations

• Very difficult to do, but needed often
• Created, used or refined during
• Strategic planning
• Feasibility study and/or SOW
• Proposals
• Vendor and sub-contractor evaluation
• Project planning (iteratively)
• Basic process
• Estimate the size of the product
• Estimate the effort (man-months)
• Estimate the schedule
• NOTE Not all of these steps are always
  explicitly performed

14
Estimations

• Remember, an exact estimate is an oxymoron
• Estimate how long will it take you to get home
  from class tonight
• On what basis did you do that?
• Experience right?
• Likely as an average probability
• For most software projects there is no such
  average
• Most software estimations are off by 25-100

15
Estimation

• Target vs. Committed Dates
• Target Proposed by business or marketing
• Do not commit to this too soon!
• Committed Team agrees to this
• After youve developed a schedule

16
Estimation

• Size
• Small projects (10-99 FPs), variance of 7 from
  post-requirements estimates
• Medium (100-999 FPs), 22 variance
• Large (1000-9999 FPs) 38 variance
• Very large (gt 10K FPs) 51 variance

17
Estimation Methodologies

• Top-down
• Bottom-up
• Analogy
• Expert Judgment
• Priced to Win
• Parkinsons law
• Parametric or Algorithmic Method
• Using formulas and equations

18
Top-down Estimation

• Based on overall characteristics of project
• Some of the others can be types of top-down
  (Analogy, Expert Judgment, and Algorithmic
  methods)
• Advantages
• Easy to calculate
• Effective early on (like initial cost estimates)
• Disadvantages
• Some models are questionable or may not fit
• Less accurate because it doesnt look at details

19
Bottom-up Estimation

• Create WBS
• Add from the bottom-up
• Advantages
• Works well if activities well understood
• Disadvantages
• Specific activities not always known
• More time consuming

20
Expert Judgment

• Use somebody who has recent experience on a
  similar project
• You get a guesstimate
• Accuracy depends on their real expertise
• Comparable application(s) must be accurately
  chosen
• Systematic
• Can use a weighted-average of opinions

21
Estimation by Analogy

• Use past project
• Must be sufficiently similar (technology, type,
  organization)
• Find comparable attributes (ex of
  inputs/outputs)
• Can create a function
• Advantages
• Based on actual historical data
• Disadvantages
• Difficulty matching project types
• Prior data may have been mis-measured
• How to measure differences no two exactly same

22
Priced to Win

• The project costs whatever the customer has to
  spend on it
• Advantages You get the contract
• Disadvantages The probability that the customer
  gets the system he or she wants is small. Costs
  do not accurately reflect the work required

23
Parkinson's Law

• The project costs whatever resources are
  available
• Advantages No overspend
• Disadvantages System is usually unfinished

24
Algorithmic Measures

• Lines of Code (LOC)
• Function points
• Feature points or object points
• Other possible
• Number of bubbles on a DFD
• Number of of ERD entities
• Number of processes on a structure chart
• LOC and function points most common
• (of the algorithmic approaches)
• Majority of projects use none of the above

25
Code-based Estimates

• LOC Advantages
• Commonly understood metric
• Permits specific comparison
• Actuals easily measured
• LOC Disadvantages
• Difficult to estimate early in cycle
• Counts vary by language
• Many costs not considered (ex requirements)
• Programmers may be rewarded based on this
• Can use defects/ LOC
• Code generators produce excess code

26
LOC Estimate Issues

• How do you know how many in advance?
• What about different languages?
• What about programmer style?
• Stat avg. programmer productivity 3,000 LOC/yr
• Most algorithmic approaches are more effective
  after requirements (or have to be after)
• What's a line of code?
• What programs should be counted as part of the
  system?
• Assumes linear relationship between system size
  and volume of documentation

27
Function Points

• Based on a combination of program characteristics
  
• external inputs and outputs
• user interactions
• external interfaces
• files used by the system
• A weight is associated with each of these
• The function point count is computed by
  multiplying each raw count by the weight and
  summing all values

28
Function Point

• Function point count modified by complexity of
  the project
• FPs can be used to estimate LOC depending on the
  average number of LOC per FP for a given language
  
• FPs are very subjective -- depend on the
  estimator. They cannot be counted automatically
• FPs are language-independent

29
Wideband Delphi

• Group consensus approach
• Rand corp. used orig. Delphi approach to predict
  future technologies
• Present experts with a problem and response form
• Conduct group discussion, collect anonymous
  opinions, then feedback
• Conduct another discussion iterate until
  consensus
• Advantages
• Easy, inexpensive, utilizes expertise of several
  people
• Does not require historical data
• Disadvantages
• Difficult to repeat
• May fail to reach consensus, reach wrong one, or
  all may have same bias

30
Productivity estimates  

• Real-time embedded systems, 40-160 LOC/P-month
• Systems programs , 150-400 LOC/P-month
• Commercial applications, 200-800 LOC/P-month

31
Factors affecting productivity  

• Studies have indicated that the best programmers
  are over 10 more productive than their peers.
• Application domain experience
• Process quality
• Project size
• Technology support
• Working environment

32
Quality and productivity  

• All metrics based on volume/unit time are flawed
  because they do not take quality into account
• Productivity may generally be increased at the
  cost of quality
• It is not clear how productivity/quality metrics
  are related

33
Effort Estimation

• Now that you know the size, determine the
  effort needed to build it
• Various models empirical, mathematical,
  subjective
• Expressed in units of duration
• Man-months (or staff-months now)

34
Estimation Issues

• Quality estimations needed early but information
  is limited
• Precise estimation data available at end but not
  needed
• Or is it? What about the next project?
• Best estimates are based on past experience
• Politics of estimation
• You may anticipate a cut by upper management
• For many software projects there is little or
  none
• Technologies change
• Historical data unavailable
• Wide variance in project experiences/types
• Subjective nature of software estimation

35
Over and Under Estimation

• Over estimation issues
• The project will not be funded
• Conservative estimates guaranteeing 100 success
  may mean funding probability of zero.
• Parkinsons Law Work expands to take the time
  allowed
• Danger of feature and scope creep
• Be aware of double-padding team member
  manager
• Under estimation issues
• Quality issues (short changing key phases like
  testing)
• Inability to meet deadlines
• Morale and other team motivation issues

36
Estimation Guidelines

• Estimate iteratively!
• Process of gradual refinement
• Make your best estimates at each planning stage
• Refine estimates and adjust plans iteratively
• Plans and decisions can be refined in response
• Balance too many revisions vs. too few

37
Estimation Presentation

• How you present the estimation can have huge
  impact
• Techniques
• Plus-or-minus qualifiers
• 6 months /-1 month
• Ranges
• 6-8 months
• Risk Quantification
• /- with added information
• 1 month of new tools not working as expected
• -2 weeks for less delay in hiring new developers
• Cases
• Best / Planned / Current / Worst cases
• Coarse Dates
• Q3 02
• Confidence Factors
• April 1 10 probability, July 1 50, etc.

38
Other Estimation Factors

• Account for resource experience or skill
• Up to a point
• Often needed more on the low end, such as for a
  new or junior person
• Allow for non-project time common tasks
• Meetings, phone calls, web surfing, sick days
• There are commercial estimation tools available
• They typically require configuration based on
  past data

39
Other Estimation Notes

• Remember manage expectations
• Parkinsons Law
• Work expands to fill the time available
• The Student Syndrome
• Procrastination until the last minute (cram)

40
Activity Sequencing

• Activity sequencing involves reviewing the
  activities in the detailed WBS, detailed product
  descriptions, assumptions and constraints to
  determine the relationship between activities it
  also involves the evaluation of dependencies
• A dependency or relationship shows the way in
  which activities or sequenced to other activities
• Certain activities can be done in parallel others
  rely on the completion of others first
• It is important to determine these in a project

41
Activity Sequencing

• Mandatory Dependencies
• Hard logic dependencies
• Nature of the work dictates an ordering
• Ex Coding has to precede testing
• Ex UI design precedes UI implementation
• Discretionary Dependencies
• Soft logic dependencies
• Determined by the project management team
• Process-driven
• Ex Discretionary order of creating certain
  modules

42
Terminology

• Precedence
• A task that must occur before another is said to
  have precedence of the other
• Concurrence
• Concurrent tasks are those that can occur at the
  same time (in parallel)
• Leads Lag Time
• Delays between activities
• Time required before or after a given task

43
Terminology

• Slack Float
• Float Slack synonymous terms
• Free Slack
• Slack an activity has before it delays next task
• Total Slack
• Slack an activity has before delaying whole
  project
• Slack Time TS TL TE
• TE earliest time an event can take place
• TL latest date it can occur w/o extending
  projects completion date

44
Activity Sequencing

• The precedence diagramming method is a network
  diagramming technique in which boxes represent
  activities. It is useful for visualising types of
  time relationships.
• Boxes or rectangles (nodes) represent the
  activities and are connected with arrows to show
  dependencies

Activity A
Activity B
Dependencies
45
Task Dependency Relationships

• Finish-to-Start (FS)
• B cannot start till A finishes
• A Construct fence B Paint Fence
• Start-to-Start (SS)
• B cannot start till A starts
• A Pour foundation B Level concrete
• Finish-to-Finish (FF)
• B cannot finish till A finishes
• A Add wiring B Inspect electrical
• Start-to-Finish (SF)
• B cannot finish till A starts (rare)

46
Sample Logic diagram
Design Brochure
Set Date
Set Location
Mail Brochure
Receive Regs.
START
Obtain lists
END
Prepare kits
Obtain Materials
Set theme
Obtain speakers
47
Predecessors and Successors
48
Schedule development

• The goal of schedule development is
• To create a realistic project schedule that
  provides a basis for monitoring project processes
• To determine realistic start and finish dates for
  project activities

49
Schedule Development

• Project schedule development is based on the
  results of the preceding time management
  processes
• Activity definition
• Activity Duration estimating
• Activity sequencing

50
Schedule Development

• Inputs to the schedule development process
• Project network diagram
• Activity duration estimation
• Resource requirements
• Resource pool description
• Project and resource calendars
• Project constraints and assumptions

51
Project milestones

• Milestones
• Have a duration of zero
• Identify critical points in your schedule
• Shown as inverted triangle or a diamond
• Often used at review or delivery times
• Or at end or beginning of phases
• Ex Software Requirements Review (SRR)
• Ex User Sign-off
• Can be tied to contract terms

52
Outputs from Schedule Development

• Project schedule
• Supporting Detail
• Schedule Management plan

53
Essence of a good project schedule

• Logical
• Simple and easy to work with
• Easy to monitor
• Flexible i.e. easy to revise
• Specific and timely
• Help you to anticipate problems
• Promote effective communication

54
Supporting Detail

• Supporting detail for the project schedule
  includes at least documentation of all identified
  assumptions and constraints
• Information supplied as supporting detail
  includes
• Resource requirement by time period, often in the
  form of a histogram
• Schedule reserves or schedule risk assessment

55
Schedule Management Plan

• Defines how changes to the schedule will be
  managed
• May be formal or informal
• Highly detailed or broadly framed
• Is a subsidiary element of the overall project
  plan

56
Network Diagrams

• Developed in the 1950s
• A graphical representation of the tasks necessary
  to complete a project
• Visualizes the flow of tasks relationships

57
Mathematical Analysis

• PERT
• Program Evaluation and Review Technique
• CPM
• Critical Path Method
• Sometimes treated synonymously
• All are models using network diagrams

58
Network Diagrams

• Two classic formats
• AOA Activity on Arrow
• AON Activity on Node
• Each task labeled with
• Identifier (usually a letter/code)
• Duration (in std. unit like days)
• There are other variations of labeling
• There is 1 start 1 end event
• Time goes from left to right

59
Node Formats
60
Network Diagrams

• AOA consists of
• Circles representing Events
• Such as start or end of a given task
• Lines representing Tasks
• Thing being done Build UI
• a.k.a. Arrow Diagramming Method (ADM)
• AON
• Tasks on Nodes
• Nodes can be circles or rectangles (usually
  latter)
• Task information written on node
• Arrows are dependencies between tasks
• a.k.a. Precedence Diagramming Method (PDM)

61
Critical Path

• The specific set of sequential tasks upon which
  the project completion date depends
• or the longest full path
• All projects have a Critical Path
• Accelerating non-critical tasks do not directly
  shorten the schedule
• Slack or float is the amount of time an activity
  can be delayed without delaying a succeeding
  activity or the project finish date

62
Importance of CPM

• Helps identify what needs to be done when tasks
  must start and by what time they must be
  completed
• Easy to compare actual progress with plan
• Allows on-going re-scheduling
• Reduces project risk by identifying critical
  activities
• Provides a powerful basis for managerial action
• Helps clarify understanding of how the work must
  be done and how activities relate to one another
• Excellent communication tool

63
CPM

• Critical Path Method
• The process for determining and optimizing the
  critical path
• Non-CP tasks can start earlier or later w/o
  impacting completion date
• Note Critical Path may change to another as you
  shorten the current
• Should be done in conjunction with the you the
  functional manager

64
Example Step 1
65
Forward Pass

• To determine early start (ES) and early finish
  (EF) times for each task
• Work from left to right
• Adding times in each path
• Rule when several tasks converge, the ES for the
  next task is the largest of preceding EF times

66
Example Step 2
67
Backward Pass

• To determine the last finish (LF) and last start
  (LS) times
• Start at the end node
• Compute the bottom pair of numbers
• Subtract duration from connecting nodes earliest
  start time

68
Example Step 3
69
Example Step 4
70
Slack Reserve

• How can slack be negative?
• What does that mean?
• How can you address that situation?

71
Slack Reserve
72
Network Diagrams

• Advantages
• Show precedence well
• Reveal interdependencies not shown in other
  techniques
• Ability to calculate critical path
• Ability to perform what if exercises
• Disadvantages
• Default model assumes resources are unlimited
• You need to incorporate this yourself (Resource
  Dependencies) when determining the real
  Critical Path
• Difficult to follow on large projects

73
PERT

• Program Evaluation and Review Technique
• Based on idea that estimates are uncertain
• Therefore uses duration ranges
• And the probability of falling to a given range
• Uses an expected value (or weighted average) to
  determine durations
• Use the following methods to calculate the
  expected durations, then use as input to your
  network diagram

74
PERT

• Start with 3 estimates
• Optimistic
• Would likely occur 1 time in 20
• Most likely
• Modal value of the distribution
• Pessimistic
• Would be exceeded only one time in 20

75
PERT Formula

• Combined to estimate a task duration

76
PERT Formula

• Confidence Interval can be determined
• Based on a standard deviation of the expected
  time
• Using a bell curve (normal distribution)
• For the whole critical path use

77
PERT

• Advantages
• Accounts for uncertainty
• Disadvantages
• Time and labor intensive
• Assumption of unlimited resources is big issue
• Lack of functional ownership of estimates
• Mostly only used on large, complex project
• Get PERT software to calculate it for you

78
CPM vs. PERT

• Both use Network Diagrams
• CPM deterministic
• PERT probabilistic
• CPM one estimate, PERT, three estimates
• PERT is infrequently used

79
Milestone Chart

• Sometimes called a bar charts
• Simple Gantt chart
• Either showing just highest summary bars
• Or milestones only

80
Bar Chart
81
Gantt Chart
82
Gantt Chart

• Disadvantages
• Does not show interdependencies well
• Does not factor in uncertainty of a given
  activity (as does PERT)
• Advantages
• Easily understood
• Easily created and maintained
• Note Software now shows dependencies among tasks
  in Gantt charts
• In the old days Gantt charts did not show these
  dependencies, bar charts typically do not

83
Critical Chain Scheduling

• Technique that addresses the challenge of meeting
  or beating project finish dates and an
  application of the Theory of Constraints (TOC)
• Developed by Eliyahu Goldratt in his books The
  Goal and Critical Chain
• Critical chain scheduling is a method of
  scheduling that takes limited resources into
  account when creating a project schedule and
  includes buffers to protect the project
  completion date
• Critical chain scheduling assumes resources do
  not multitask because it often delays task
  completions and increases total durations

84
Buffers and Critical Chain

• A buffer is additional time to complete a task
• Murphys Law states that if something can go
  wrong, it will, and Parkinsons Law states that
  work expands to fill the time allowed. In
  traditional estimates, people often add a buffer
  and use it if its needed or not
• Critical chain schedule removes buffers from
  individual tasks and instead creates
• A project buffer, which is additional time added
  before the projects due date
• Feeding buffers, which are addition time added
  before tasks on the critical path

85
Example of Critical Chain Scheduling
86
Reducing Project Duration

• How can you shorten the schedule?
• Via
• Reducing scope (or quality)
• Adding resources
• Concurrency (perform tasks in parallel)
• Substitution of activities

87
Compression Techniques

• Shorten the overall duration of the project
• Crashing
• Looks at cost and schedule tradeoffs
• Gain greatest compression with least cost
• Add resources to critical path tasks
• Limit or reduce requirements (scope)
• Changing the sequence of tasks
• Fast Tracking
• Overlapping of phases, activities or tasks that
  would otherwise be sequential
• Involves some risk
• May cause rework

88
Crashing and Fast Tracking
89
Schedule Control

• Schedule control is concerned with
• Influencing the factors that create schedule
  changes
• Determining that the schedule has changed
• Managing changes as they occur
• It is not about simply reporting changes that
  have happened

90
Schedule Control

• Have effective procedures for monitoring and
  reporting actual progress against schedule
• And for highlighting problems
• Find problems early
• Take necessary steps to avoid schedule delays
• Hence minimise slippage
• By prompt and aggressive action

91
Inputs to schedule control

• Project schedule
• Performance reports
• Change Requests
• Schedule Management Plan

92
Tools and techniques for schedule

• Schedule change control system
• Performance measurement
• Additional Planning
• Project Management software

93
Outputs from schedule control

• Schedule updates
• Revisions
• Corrective actions
• Lessons learned