Project Management
Slide 1
Objectives
Become familiar with estimation.
Be able to create a project work plan.
Understand why project teams use timeboxing.
Become familiar with how to staff a project.
Understand how computer-aided software
engineering (CASE), standards, and
documentation improve the efficiency of a
project.
• Understand how to reduce risk on a project.
•
•
•
•
•
Slide 2
Project Management Concerns
Slide 3
Project Management
• The discipline of planning, organizing, and
managing resources to bring about the
successful completion of specific project goals
and objectives
• Cost
• Schedule
• Performance
Slide 4
PM Activities evolve over Phases
•
•
•
•
Inception
Elaboration
Construction
Transition
Slide 5
PM Artifacts in UP
•
•
•
•
•
•
•
Software development plan
Business case
Detailed plan for each iteration
Assessment of each iteration
Periodic status assessment
Work schedule
Project measurement database
Slide 6
PM in Inception Phase
1. Conceive new project
•
•
Preliminary business case
Identify some risk, begin assessment
2. Evaluate project scope and risk
•
More detailed development of business case and
risk assessment
Slide 7
IDENTIFYING PROJECT
SIZE
Slide 8
Cost Schedule Performance Trade-offs
Project management
involves balancing tradeoffs among the three
key project parameters
Cost
Project
cheaper
better
sooner
Schedule
Quality/Performance
Slide 9
Estimating Project Timeframes
Slide 10
Function Point Approach
Estimate System Size
(function points and lines of code)
Estimate Effort
Required
(person-months)
Estimate Time Required
(months)
Slide 11
Getting the Right Numbers for
Estimation
• Prior projects
• Past experience
• Industry standards
• Detailed analysis
Slide 12
Estimation Guidelines
Estimate using at least two techniques
Get estimates from independent sources
Avoid over-optimism; assume difficulties
When you have arrived at an estimate, sleep on
it
• Adjust for the people who'll be doing the job -they have the highest impact
•
•
•
•
Slide 13
Estimation Trade-offs
• Size
• Function (or use-case) points
• Lines of code
• Effort
• Person-months
• People available
• Time
• Months
Slide 14
Calculate Function Points
• List major elements of system
• Determine total number of each element
• Specify complexity index of each component
(low, med., high)
• Total index multiplied by number of components
(TUFP)
Slide 15
Function Point Estimation : Step One
Complexity
Description
Low
Medium
High
Total
Inputs
__x 3
__x 4
__x 6
____
Outputs
__x 4
__x 5
__x 7
____
Queries
__x 3
__x 4
__x 6
____
Files
__x 7
__x 10
__x 15
____
Program
Interfaces
__x 5
__x 7
__x 10
____
TOTAL UNADJUSTED FUNCTION POINTS
Slide 16
TUPF Example
Slide 17
Adjusted Processing Complexity -- Step 2
Slide 18
Function Points Estimation :
Step Four
Adjusted Project Complexity
=
.065 + (0.01 * Project Complexity)
Total Adjusted Function Points
=
Adjusted Project Complexity * TUFP
Slide 19
Function Point Estimation
Processing Complexity (PC): __7______
(From Step 2)
Adjusted Processing
Complexity (PCA) =
0.65 + (0.001 * __7_ )
Total Adjusted
Function Points: _0.72 * _338_ = 243
(TUFP -- From Step 1)
Slide 20
Converting Function Points to Lines of
Code
Language
LOC/Function Code
Point
C
130
COBOL
110
JAVA
55
C++
50
Turbo Pascal
50
Visual Basic
30
PowerBuilder
15
HTML
15
Packages
10(e.g., Access, Excel)
40
Source: Capers Jones, Software Productivity Research
Slide 21
Final Step
• Multiply function points by LOC/FP
• Approximate lines of code per function point in
the chosen language
• If you chose C, then
243 function points x 130 lines of code/FP
= 31,590 total lines of code
Slide 22
Estimating Effort
• Function of size and production rate
• COCOMO model
• Converts a lines-of-code estimate into a personmonth estimate
• For moderate-size projects multiply thousands of
lines of code by 1.4 to get the number of people to
assign to the project
Slide 23
COCOMO Estimation Calculation
Effort
(in PersonMonths)
=
1.4 * thousands-oflines-of-code
Example:
If LOC = 2000 Then...
Effort =
(1.4 * 2000) =
28 PersonMonths
Slide 24
Estimating Schedule Time
• Rule of thumb for estimation
Schedule Time (months)
=
3.0 * person-months1/3
Slide 25
Estimation Guidelines
Estimate using at least two techniques
Get estimates from independent sources
Avoid over-optimism; assume difficulties
When you have arrived at an estimate, sleep on
it
• Adjust for the people who will be doing the job;
they have the highest impact
•
•
•
•
Slide 26
Reconsider Buy/Build Decision
Slide 27
CREATING AND MANAGING
THE WORK PLAN
Slide 28
Developing Work Plans
• A work plan, is a dynamic schedule that records
and keeps track of all tasks to be accomplished
over the course of the project
• Created after a project manager has a general
idea of the project’s size and rough schedule
• The work plan is usually the main item in a
project management software application
Slide 29
Developing a WorkPlan
•
•
•
•
•
Identify tasks in the project
Estimate task length
Determine task dependencies
Specify to whom task will be assigned
List deliverables
Slide 30
A Workplan Example
Work Plan Information
Example
Name of task
Start date
Completion date
Person assigned
Deliverable(s)
Completion status
Priority
Resources needed
Estimated time
Actual time
Perform economic feasibility
Jan 05, 2001
Jan 19, 2001
Mary Smith, sponsor
Cost-benefit analysis
Open
High
Spreadsheet
16 hours
14.5 hours
`
Slide 31
Identifying Tasks
• Top-down approach
• Identify highest level tasks
• Break them into increasingly smaller units
• Methodology
• Using standard list of tasks
Slide 32
Work Breakdown Structure
• Specify high level tasks
• Break down each step into smaller tasks and
number them in a hierarchical fashion
• WBS can be done in two ways
• SDLC phase
• Product
Slide 33
Top Down Task
Identification
Phases
Work Plan Deliverables Estimated
hours
Phases with
high level steps
Assigned
To
*
*
*
*
Slide 34
Work Breakdown Structure
Slide 35
WBS Problems
• They tend to be specific to the design of the
information system being developed
• Too many levels of detail too early on in the
SDLC for large projects or too few for small
projects.
• Since they are project specific, they are very
difficult to compare across projects.
Slide 36
Applying Iteration to Planning
• Develop a high level long range plan, with
allocation of time and resources to phases
• Develop a more detailed plan for the earliest
phase(s), including allocation of work, time and
resources to interations
• Develop a still more detailed plan for the current
iteration, including work breakdown into tasks
• Revise the plan iteratively, at least weekly
Slide 37
Gantt Charts
• Good for identifying time and order
dependencies
• Show slack (ahead) and over-runs (past)
• Good for identifying critical paths
• Good for small projects, and overview of large
ones
• Attempt to combine work breakdown with
activities, deliverables not shown
• Do not show task difficulty or cost
• Do not scale well for details of large projects
Slide 38
Gantt Chart
Slide 39
Gantt Chart
Slide 40
Another Style of Gant Chart
Slide 41
Slide 42
Slide 43
Slide 44
PERT
• Project Evaluation and Review Technique (PERT)
• US Navy, 1957
• Systematic method of estimating project length,
and monitoring progress
• Uses systematic serialization algorithm based on
• Dependences
• Resource availability
• Adds administrative oversight to critical paths
• Critical path = sequence of tasks such that if any
case on the CP is delayed so is the whole project
Slide 45
PERT Estimation
• PERT uses three time estimates:
• Optimistic, O
• Most likely, M
• Pessimistic, P
• Time Estimate = (O + 4 * M + P) / 6
Slide 46
Pert Chart
• Used to communicate task dependencies
• Allows easier visualization of tasks on a critical
path
Slide 47
Slide 48
Slide 49
Slide 50
Slide 51
Slide 52
PERT vs. Gantt
Slide 53
CONTROLLING AND
DIRECTING THE PROJECT
Slide 54
Typical Margins of Error for Well-done
Estimates
Phase
Deliverable
Cost (%)
time (%)
Planning
System Request
400
60
Project Plan
100
25
Analysis
System Proposal
50
15
Design
System Specification 25
10
Source: Boehm et al. (1995)
Slide 55
The Hurricane Model
Time
Project Stage
Slide 56
Slide 57
Evolutionary WBS
• Organize in a standard manner across all
projects
• Create in an incremental and iterative manner
• First evolutionary WBS done with initial aspects of
the project
• Later on more details are added to the WBS.
• Comparable to earlier projects based on cost
and schedule estimation
Slide 58
Managing Scope
• Scope creep -- a major cause of
development problems
• JAD and prototyping
• Formal change approval
• Charging for changes
Slide 59
Scope Management
• Scope creep happens when new requirements are
added to the project after the original project
scope was defined and “frozen.”
Slide 60
Timeboxing Steps
1. Set the date for system delivery
2. Prioritize the functionality that needs to be
included in the system
3. Build the core of the system (the functionality
ranked as most important)
4. Postpone functionality that cannot be provided
within the time frame
5. Deliver the system with core functionality
6. Repeat steps 3 through 5 to add refinements
and enhancements
Slide 61
Project Risk Analysis
• A risk comprises three elements:
• an undesirable event,
• an estimate of the severity of the
consequences of the event
• a likelihood that the event will occur
• The amount of risk a project is exposed
to is a good measure of the viability of
the project
Slide 62
Managing Risk
Slide 63
Classes of Risk
• Direct risk that the manager can control to some
extent
• Indirect risk that the manager cannot influence
In managing a project the aim is to control risk so
we try to avoid indirect risk where possible.
Slide 64
Risk Control
Three strategies:
• Risk avoidance - reorganize the project so you
are not exposed to the risk
• Risk transfer -find other stakeholders to share
the risk
• Risk acceptance - decide to live with the risk and
to take the occurrence of the risk as a possible
contingency to be taken account of in the
planning process
Slide 65
Risk Acceptance
Risk mitigation
• Try to reduce the likelihood or the impact of a
risk.
• e.g. if we decide to choose a particular supplier for a
component we can identify an alternative supplier
with a similar product that could be used if the
original supplier fails to deliver.
Contingency planning
• Construct “what if” plans on the basis of the
risk occurring
Slide 66
Risk Assessment - Overview
• Do risk assessment
• Take/plan actions to reduce risk
• Revise assessment
Slide 67
Classic Mistakes
•
•
•
•
•
Overly optimistic schedule
Failing to monitor schedule
Failing to update schedule
Adding people to a late project
Allowing requirements creep
Slide 68
STAFFING THE PROJECT
Slide 69
Staffing Attributes
• Staffing levels will change over a project’s
lifetime
• Adding staff may add more overhead than
additional labor
• Using teams of 8-10 reporting in a hierarchical
structure can reduce complexity
Slide 70
Increasing Complexity with Larger Teams
Slide 71
Staffing the Project
• Determine average number of people needed
• Divide total person-months of effort by the optimal
schedule
• Adding more people will not reduce schedule
• Create a staffing plan
• Roles required for the project
• Reporting structure
Slide 72
Example Reporting Structures
Project
Manager
Functional
Lead
Analyst
Technical
Lead
Analyst
Programmer
Programmer
Slide 73
Key Definitions
• The staffing plan describes the kinds of
people working on the project
• The project charter describes the project’s
objectives and rules
• A functional lead manages a group of
analysts
• A technical lead oversees progress of
programmers and technical staff members
Slide 74
Motivation
• Use monetary rewards cautiously
• Use intrinsic rewards
• Recognition
• Achievement
• The work itself
• Responsibility
• Advancement
• Chance to learn new skills
Slide 75
Motivational Don’ts
Assign unrealistic deadlines
Ignore good efforts
Create a low-quality product
Give everyone on the project a raise
Make an important decision without the team’s
input
• Maintain poor working conditions
•
•
•
•
•
Slide 76
Conflict Avoidance Strategies
• Clearly define roles and project plans
• Make sure the team understands how the
project is important to the organization
• Develop detailed operating procedures and
communicate these to the team members
• Develop a project charter
• Develop schedule commitments ahead of time
• Forecast other priorities and their possible
impact on project
Slide 77
COORDINATING PROJECT
ACTIVITIES
Slide 78
CASE Tools
• Computer-Aided Software Engineering (CASE)
tools automate some or all of the development
process
• Not a silver bullet, but advantages include:
– Reduced maintenance costs
– Improve software quality
– Enforce discipline
– Some project teams even use CASE to assess the
magnitude of changes to the project
Slide 79
Standards
• Examples
• Formal rules for naming files
• Forms indicating goals reached
• Programming guidelines
• Can you think of more examples?
Slide 80
Standards
Types of Standards
Example
Documentation
standards
The date and project name should appear as a header on
all documentation.
Coding standards
All modules of code should include a header that lists the
programmer, last date of update, and a short description
of the purpose of the code.
Procedural standards
Report to project update meeting on Fridays at 3:30 PM.
All changes to a requirements document must be
approved by the project manager.
Specification
requirement standards
Name of program to be created
Description of the program’s purpose
User interface design
standards
The tab order of the screen will move from top left to
bottom right.
Accelerator keys will be provided for all updatable fields.
Slide 81
Documentation
• Good documentation happens up front
– Documentation that occurs only at the tail end of a
project/phase is not very useful
• Project binder(s) are best practices containing
– All internal communications (e.g. minutes from status
meetings)
– Written standards
– Letters to and from the business users
– Deliverables from each task
Slide 82
Summary
•
•
•
•
•
Project Management
Identifying Project Size
Creating And Managing the Workplan
Staffing the Project
Coordinating Project Activities
Slide 83