Chapter 3:
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 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
• Approximate lines of code per function point in the
chosen language
• If you chose C, then 243 function Points times 130 lines
of code = 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 person-month
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) =
Months
28 Person
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
WORKPLAN
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
Gantt Chart
Slide 37
Gantt Chart
Slide 38
Another Style of Gant Chart
Slide 39
Slide 40
Slide 41
Slide 42
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 43
PERT Estimation
• PERT uses three time stimates:
• Optimistic, O
• Most likely, M
• Pessimistic, P
• Time Estimate = O + 4 * M + P
Slide 44
Pert Chart
• Used to communicate task dependencies
• Allows easier visualization of tasks on a critical path
Slide 45
Another kind of PERT Chart
Slide 46
Another Variation
Slide 47
And another
Slide 48
Slide 49
And another variant
Slide 50
PERT vs. Gantt
Slide 51
CONTROLLING AND DIRECTING THE
PROJECT
Slide 52
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 53
The Hurricane Model
Time
Project Stage
Slide 54
Slide 55
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 56
Managing Scope
• Scope creep -- a major cause of development problems
• JAD and prototyping
• Formal change approval
• Charging for changes
Slide 57
Scope Management
• Scope creep happens when new requirements are
added to the project after the original project scope was
defined and “frozen.”
Slide 58
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 59
Project Risk
• 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 60
Managing Risk
Slide 61
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 62
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 63
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 64
Risk Assessment - Overview
• Do risk assessment
• Take/plan actions to reduce risk
• Revise assessment
Slide 65
Classic Mistakes
•
•
•
•
•
Overly optimistic schedule
Failing to monitor schedule
Failing to update schedule
Adding people to a late project
Allowing requirements creep
Slide 66
STAFFING THE PROJECT
Slide 67
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 68
Increasing Complexity with Larger
Teams
Slide 69
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 70
Example Reporting Structures
Project
Manager
Functional
Lead
Analyst
Technical
Lead
Analyst
Programmer
Programmer
Slide 71
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 72
Motivation
• Use monetary rewards cautiously
• Use intrinsic rewards
• Recognition
• Achievement
• The work itself
• Responsibility
• Advancement
• Chance to learn new skills
Slide 73
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 74
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 75
COORDINATING PROJECT
ACTIVITIES
Slide 76
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 77
Standards
• Examples
• Formal rules for naming files
• Forms indicating goals reached
• Programming guidelines
• Can you think of more examples?
Slide 78
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 79
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 80
Summary
•
•
•
•
•
Project Management
Identifying Project Size
Creating And Managing the Workplan
Staffing the Project
Coordinating Project Activities
Slide 81