Project Management
• All projects need to be “managed”
– Cost (people-effort, tools, education, etc.)
– schedule
– deliverables and “associated” characteristics
• Project management needs to be consciously
studied and understood by :
–
–
–
–
current project managers
current project leaders
current technical leaders
aspiring software engineers
4-Phases of Project Management
• Planning (P)
– gather and analyze information (e.g. requirements)
– develop a project plan
• Organize (O)
– recruit, train, and organize the personnel
– acquire and set up the resources, procedures, metrics, etc.
• Monitor (M)
– track the activities and risks according to the metrics
• Adjust
(A)
– fix those risk items that turned into real problems
– improve upon current activities
Planning: Project Plan(s)
• Quick Estimates:
– Brief Product/Project Description
– Schedule with deliverables and external delivery dates
– Cost of a single rolled up number
• More Comprehensive Plan:
– Product/Project Description: function list, scope of project (all the
deliverables), systems, training, consulting services & support
– Product/Project Attributes: performance, quality, scalability, any
special needs (i.e. translation, standards, etc.)
– Schedule: multiple delivery dates, multiple milestones and acceptance
dates
– Cost: by major functions, by systems, by support, by consulting
services, by training, etc.
– Resources : people, hardware, software, space, travel, special skills,
communication facilities, special tools, process and procedures, etc.
– Risks: “prioritized” list of risks and a risk mitigation outline
Planning: Estimation
• The more clear the requirements, the better is
the estimate(s)
• In reality, it is very difficult to modify the
numbers once the early estimates are given ;
make sure to buffer your estimates
• 2 most common estimates :
1. schedule
2. cost or effort (most of this is tied to people
resource as opposed to hardware or software or
facilities)
Work-Breakdown Structure (WBS)
(an estimation technique)
• Assuming that the requirements and the types of
deliverables are fairly well understood: (e.g.)
– code : source, executables, messages, screens, etc.
– documents: design spec., test plan, test cases, user manuals, etc.
– training: end user training, support personnel training, etc.
1. For each of the deliverables, consider the set of
activities that will be employed to develop the
deliverable (based on the process/procedure chosen)
2. Map the deliverable against the chosen activities, and
consider the sequencing of the activities, including any
inter-deliverable relationships.
A Simple Work-Breakdown Structure : Example
• Project is to provide a component that computes
the power function (given x and y, provide x**y
or xy).
• After some discussion with the user/customer, it
was determined that the deliverables are: a) user
reference sheet and b) actual source code and
object code on MS-Windows.
• The Work-Breakdown Structure of activities:
– “Power - code”: analysis, low level (code) design, code,
code test on MS Windows environment
– Reference sheet: analysis, design, write-up, test the
write-up
WBS: Simple POWER example (cont.)
Initial sequencing of the activities for the deliverables:
Code
Design
Code
Implementation
Code
Testing
Analysis of
Requirements
End
Ref. Sheet
Design
Ref. Sheet
Writing
Ref. Sheet
Testing
Note: the reference sheet activities are shifted a bit; also the code design
may provide input to reference sheet design.
From Work Breakdown to Volume of Work
• For POWER function code, the “volume” of work
may be in:
– Pages of Analysis and Design
– Lines of Code
– Number of Test Cases
• For POWER reference sheet, the volume may be in:
– Number of Pages of design/analysis
– Number of Text Sentences and Number of Diagrams
– Number of Test Cases
How do we Estimate Volume of Effort ?
•
•
•
•
Do we have comparable historic data ?
Can we use our personal experience ?
Can we ask others who have more experience ?
Can we buy data from professional
organizations ?
• Give the estimation work to the workers:
– code delivery estimation to the programmers
– reference sheet delivery estimation to the writers
Volume Estimate with
Personal Experience (for this example)
• POWER Code:
– 1 page of analysis and design
– 100 loc of C++ code (input check, error message,
power algorithm, return the result)
– 14 test cases for both variables x and y:
• 7 test cases for each of the variables x and y
– 2 outside the boundary, 2 at the boundary, 2 within the
boundary and 1 at zero
• Reference Sheet:
– 1 page of design
– 3 pages of user reference sheet (1 for functional
description, 1 usage directions, 1 error conditions and
messages
– 3 test cases (1 for normal usage, 2for error condition)
Convert Volume Estimates to Effort Estimates
• Power Code:
– 1 page of Analysis and Design
– 100 loc of C++ code
– 14 test cases and bug fix
- .5 person day
- 1 person day
- 1 person day
• Reference Sheet :
– 1 page of Design
- .5 person
– 3 pages of reference sheet
- .5 person day
– 3 test cases, review, and changes - .5 person day
Total Cost and Schedule Estimates for
POWER ?
• Total cost in person-days:
– 2.5(code) + 1.5 (ref.sheet) = 4 person days
• Schedule :
– if all sequential (with one person), it is 4 days
– if done in parallel (with 2 people), it is 2.5 days
• With Buffer (of approximately 20%)
– Cost = 5 person-days (multiply this by $/person-day)
– Schedule = 3 days (done in parallel)
A Few Things to Remember
1. Is our requirements well understood and double
checked with user?
2. Is the buffering enough and applicable to others who
may be less familiar/productive with C++ (or any
chosen tool) ?
– Some claim as much as a factor of 4 between actual
and estimate information
3. Is this approach scalable when the project is large and
complex (containing hundreds of these POWER
functions ) ?
4. Work Breakdown Structure can be more complex if
the inter-deliverables are related (code design may
affect reference sheet design).
5. How many people can be applied to each activity/task ?
Critical Path (CP) Scheduling
• Critical Path (CP) := Longest Path
1. We need to “break down” the activities into detailed,
discrete work units or tasks (with needed time-units).
2. Sequence the work units or tasks, showing what may be
performed independently and where are the
dependencies.
3. Estimate time required for each task.
Start
2
3
A
B
4
3
C
D
5
F
6
2
E
End
G
Note : END is gated by activity E which gated by D & G
Critical Path & Expected Project time
• The “expected” project time is the total time units
needed to complete all the tasks on the critical
path.
• In the previous slide: tasks A,B,F,G & E are on the
critical path and the total time needed is
2+3+5+6+2 = 18 time units = expected project time
• Any delay on the critical path elongates the
expected project time.
CP Scheduling (forward/backward paths)
• The CP Graph may be looked at in a tabular
form:
Tasks
Est. Time Early
Effort
Start
Early Late
End Start
Late Potential
End Slack
A
2
0
2
0
2
0
B
3
2
5
2
5
0
C
4
5
9
9
13
4
D
3
9
12
13
16
4
E
2
16
18
16
18
0
F
5
5
10
5
10
0
G
6
10
16
10
16
0
End
Note: the slack time
may be taken at C
or D, but not both
taking 4 units.
Slack time :=
(Late start – Early start)
Scheduling with CP
• Critical Path analysis of a project schedule tells us:
1. sequential ordering of tasks
2. potential parallelism of tasks
3. which activities are critical and must be completed on
time to avoid delay.
• It does not tell us :
1. how accurate the estimated task effort is
• Some people convert the estimate into a probability interval. (e.g.
Program Evaluation and Review Technique - PERT)
2. whether we can apply multiple resources to any of the
activity and reduce the time. (CPM, however, will allow
us to look at applying resources to reduce time.)