Software Project
Management
Review
INFO 638
Glenn Booker
INFO 638
Lecture #10
1
Project Limits
 Projects are limited in scope, as
defined by one of these:





INFO 638
A functional specification
A Software Requirements Specification
Use cases and their documentation
A Statement of Work (SOW)
A Mission Needs Statement (MNS)
(government term)
Lecture #10
2
The Triangle
 Projects generally get stuck facing a
triangle
 Cost
 Time (schedule)
 Features and/or quality
 At most, two of these points can be
controlled
 Which one can you tolerate flexibility?
INFO 638
Lecture #10
3
TPM Life Cycle
 Wysocki has five major phases in
the TPM life cycle





INFO 638
Scope the project
Develop the project plan
Launch the plan
Monitor/control project progress
Close out the project
Lecture #10
4
Risk Management Guide
 Need to create a list of possible risks
 Describe each risk briefly
 Estimate the probability of the risk
happening
 Should be between 0 and 100%
 Estimate the loss if the risk occurs
 How much effort will it take to recover
from the risk?
INFO 638
Lecture #10
5
Risk Management Guide
 Multiply probability times loss to get
the impact of each risk
 Impact = probability * loss
 Sort risks in descending order of
impact; keep the top 10 (typically)
 This is prioritizing the risks
 For each significant risk, assign a risk
owner to look for the risk occurring
INFO 638
Lecture #10
6
Procurement Management
 Procurement has its own life cycle,
which runs parallel to part or all of
the project life cycle






INFO 638
Solicit RFI (optional; and not in text)
Solicit RFPs
Get responses
Select Vendors
Manage contracts
Close out contracts
Lecture #10
7
Role of the POS
 The POS is a communications tool
among the project manager, their
development team, the customer, and
the project manager’s boss (upper or
senior management)
 The POS is a concise statement of
the project, and a summary of its
justification to continue
INFO 638
Lecture #10
8
Parts of a POS
 The POS has five major sections





Problem/opportunity
Goal
Objectives
Success criteria
Assumptions, risks, obstacles
 Each is typically a few paragraphs
long
INFO 638
Lecture #10
9
Work Breakdown Structure (WBS)
 The WBS gives structure to the set of
activities in a project
 It expands on the POS by describing
activities in more and more detail,
until you get down to the smallest
level of task you need to define for
your project
 The WBS is a really big ‘to-do’ list
INFO 638
Lecture #10
10
WBS Approaches
 There are three major approaches
to structuring a WBS
 Noun-type approaches (subsystems)
 Verb-type approaches (life cycle phases)
 Organizational approaches (who or
where performs work)
INFO 638
Lecture #10
11
WBS Numbering
 Tasks and activities are often given
unique identification numbers to help
do cost accounting and generate
status summaries
 In Microsoft Project, you can add a
column called WBS which will
automatically follow this numbering
INFO 638
Lecture #10
12
After the WBS
 Once the rough scope of tasks has
been defined in the WBS, we need
to estimate each task in terms of
duration and effort
 From effort we’ll get the cost of each
task, and eventually the project
 After estimation, can start to organize
the project schedule
INFO 638
Lecture #10
13
Creating a Good Estimate
 There are six techniques for
estimating the duration and
effort of a task






INFO 638
Similar activities
Historical data
Expert advice
Delphi technique
Three-point technique
Wide-band Delphi technique
Lecture #10
14
Estimating Resources
 While ‘resources’ often refers to
people on a project, it may refer to





INFO 638
People
Facilities
Equipment
Money
Materials
Lecture #10
15
Organization Chart
 Since we need to define the types of
staff needed to perform each task,
this feeds into developing the
organization chart of the project
 The roles needed for performing tasks
should all appear on the org chart
 It’s called a Resource Breakdown
Structure in the text (p. 108)
INFO 638
Lecture #10
16
Project Network Diagram
 Can present the project schedule in
three major forms
 Gantt chart, showing bars for each task
under a timeline
 Pert chart, with activity on arrow (AOA)
notation
 CPM chart, with activity on node (AON)
notation
 The latter two can show critical path
INFO 638
Lecture #10
17
Critical Path
 A key output is the critical path,
which can be defined as
 The longest duration path in the network
diagram, or
 The series of tasks whose early and late
schedules are the same dates, or
 The set of activities with zero slack
INFO 638
Lecture #10
18
Management Reserve
 At the project level, try to keep a
little reserve of time (padding) to
allow for likely schedule slips
 Don’t do this on individual tasks – tends
to bloat the schedule
 5-10% is a good schedule reserve
 So a 6-month project might try to finish
6-13 work days early
 6 months = 26 weeks = 130 work days
INFO 638
Lecture #10
19
Leveling Resources
 Then need to add up the planned
resources and look for potential
problems
 Over committing people
 Resources inconsistent with project
priorities
 Lack of management to monitor the
project resources
 Lack of accounting for employee
turnover
INFO 638
Lecture #10
20
Work Packages
 Earlier we defined a project as having
activities, which are broken into tasks
 A way to describe and manage the
tasks within an activity are work
packages
 The work package describes the tasks
to be accomplished, relevant dates,
and who will do the work
INFO 638
Lecture #10
21
Critical chain vs. critical path
 The critical path is the longest
duration through the project
 Doesn’t consider the resources needed
for tasks along the critical path
 Critical chain is the longest path
through the project, considering both
task dependencies and resource
constraints
INFO 638
Lecture #10
22
Joint Project Planning
 Joint Project Planning (JPP) uses a
goldfish-bowl approach to conducting
early analysis of a project
 Its scope is typically to define the
POS and/or PDS
 For software, this might include
defining the system scope and key
requirements, and/or developing
high level system design
INFO 638
Lecture #10
23
JPP
 All significant stakeholders in a
project need to attend JPP
 JPP sessions are typically held off-site
to avoid distractions
 JPP follows a specific agenda to reach
specific goals for the session, e.g.
develop a POS, describe the WBS,
etc.
INFO 638
Lecture #10
24
Monitoring Progress
 By now you have been able to create
a detailed project plan, including task
definitions, estimates of duration, &
assignment and leveling of resources
 Then the project actually starts
 Now you need to monitor what really
happens, and control the future of
the project
INFO 638
Lecture #10
25
Control and Risk
 Controlling a project is closely linked
to risk management
 You want to minimize the risk that
the project won’t finish successfully
 Successfully generally means “on time
and within budget”
 To do so, you need measurements to
help decide if the project is on track
INFO 638
Lecture #10
26
Controls
 Without good controls, a project will
wander like a 6-year-old on summer
vacation
 Controls allow us to
 Track progress – what has been
accomplished?
 Detect variance – have we departed from
the plan?
 Take corrective action – fix it!
INFO 638
Lecture #10
27
Progress Reporting System
 Some form of progress reporting
system needs to be established
 Want timely, complete, clear, and
accurate status reported
 Avoid adding too much to overhead to
create the status reports
 Results are readily available
 Warns of problems with time to fix them
INFO 638
Lecture #10
28
Variances
 Variances are the difference between
actual events and the project plan
 Positive variances are often good
 They mean you are ahead of schedule or
under budget
 But could mean the schedule has
slipped, and little has been accomplished
INFO 638
Lecture #10
29
Displaying Status
 There are three major ways to display
the status of a project graphically
 Gantt chart
 Milestone trend chart
 Cost schedule control chart
INFO 638
Lecture #10
30
Cost Schedule Control
 Cost schedule control refers to the
system used by the many agencies
called earned value or C/SCSC
 We have already defined a project
plan with tasks and resources
 Each task therefore has some defined
dollar value (its resources times their
hourly rate)
INFO 638
Lecture #10
31
Cost Schedule Control
 To use Cost Schedule Control, we
need to define when we get ‘credit’
for accomplishing each task
 Only when the task is done
 Half at the task start, and half at finish
 Etc.
 The total planned value of work done
on the project typically forms a long S
curve over time
INFO 638
Lecture #10
32
Change Control
 A change control process is needed to
manage changes to the scope of a
project
 Describes the activities needed to
analyze a problem, estimate how much
work it is to resolve, determine its
priority, fix it, and incorporate it into a
system change with other problem fixes
 The names of the organizations which
perform each of the steps may vary
INFO 638
Lecture #10
33
Escalation
 Escalation here means how a problem
can be resolved
 Little problems might be resolved by the
project manager
 Bigger problems might be resolved by
getting additional resources from your
organization
 Huge problems might need cooperation
from your customer to resolve
INFO 638
Lecture #10
34
Motivation
 Key for a good manager to recognize
is that different things motivate
different people
 And what motivates one person might
change over time
 One person might be thrilled to get an
award for their contribution to a project,
another might prefer a check, and a third
might want an extra two days vacation
INFO 638
Lecture #10
35
Motivation
 The big motivational factors for most
people are:
 Opportunity for achievement
 Opportunity for advancement
 Might include technical supervision
 Recognition
 Increased responsibility
 The work itself
INFO 638
Lecture #10
36
Management and Motivation
 Many of the motivational factors can’t
be controlled by a first line manager
 Key for managers to focus on are
 Provide challenging work
 Recognize your people’s work
 Design their job to provide a variety of
skills needed, clearly identifiable and
significant tasks, allow autonomy, and
provide feedback
INFO 638
Lecture #10
37
Contract Issues
 Many management issues involve
contractual concerns
 A good resource with more detail is
 On Time Within Budget, E.M. Bennatan, 3rd
ed., ISBN 0-471-37644-2, Wiley, 2000.
 The key contractual vehicles are
RFI, RFP, and RFQ
 For zillions of examples, go to
www.firstgov.gov and search
on those acronyms
INFO 638
Lecture #10
38
Contract Terms
 The terms of payment are clearly
defined in any contract
 Often payments are based on meeting
specific milestones in the project
 Rules for handling contract early
termination, and normal closeout of
the contract are also defined
INFO 638
Lecture #10
39
Team Rules
 Any team needs some rules to
function effectively





How will decisions be made?
How do you solve problems?
How do you resolve conflicts?
How & when does the team meet?
How does the team interact
with other projects? The customer?
 Who defines the answers to these?
INFO 638
Lecture #10
40
Closeout
 Normal closeout of a project typically
involves six steps






INFO 638
Get client acceptance
Ensure system installed
Ensure documentation delivered
Get client signoff
Post-implementation Audit
Party!
Lecture #10
41
Adaptive Project Framework
 Adaptive Project Framework (APF)
uses selected portions of traditional
project management (TPM)
 Focus is on planning just-in-time, rather
than planning the entire project from the
start
 APF is client-focused, and expects
constant change
INFO 638
Lecture #10
42
APF Structure
 APF uses five phases





Version Scope
Cycle Plan
Cycle Build
Client Checkpoint
Post-Version Review
 Planning is based on functionality,
and is kept high level until each cycle
INFO 638
Lecture #10
43
APF Core Values
 APF is based on six core values,
which help define how APF thinks






INFO 638
Client-focused
Client-driven
Incremental results
Continuous questioning
Change is progress
Don’t speculate
Lecture #10
44
Version Scope
 This phase sets the stage for the
project
 Prepare the POS, much like done
in TPM
 Define the vision of what the product will
be
 Define the overall budget and schedule
(timebox) of the project
 Define the WBS to the 2nd or 3rd level
INFO 638
Lecture #10
45
Number of Cycles
 Once we have a handle on the project
objectives and scope, need to
establish the preliminary number of
time boxes, and how long they are
 Try fixed duration for all time boxes; may
tweak later
 Might use development time of the most
complex cycle to set the time box size
 Consider client attention span too
INFO 638
Lecture #10
46
Cycle Objectives
 Finally, prepare objective statements
for the first few cycles
 Tell customer what they should
expect from each cycle (deliverables)
 Keep focus on business functions and
value to the customer
INFO 638
Lecture #10
47
Cycle Planning
 Cycle planning is performed like in
traditional project management
(TPM), but there are key differences
 In APF, the planning is done in detail only
for the next cycle – not the entire project
at once
 APF planning may or may not use project
software; it could be done with more
informal tools
INFO 638
Lecture #10
48
Cycle Build
 It is assumed that Cycle Plan is done
by one person or part of the team
 Cycle Build requires the whole team’s
presence to refine the schedule if
needed
 Identify specific resources for each
task, and ensure conflicts are
resolved and workload is balanced
INFO 638
Lecture #10
49
Build Cycle Functionality
 Start building the functionality
promised for this cycle, following the
plan just developed
 During the cycle, daily stand-up
meetings are used for status
 Stand up so it doesn’t drag on forever
 Monitor the system scope & their
priorities, and issues identified
INFO 638
Lecture #10
50
Build Cycle
 Use a Scope Bank to keep track of
requirements, and an Issues Log to
record and track significant problems
INFO 638
Lecture #10
51
Client Checkpoint
 The Client Checkpoint focuses on
two major activities
 Review of the quality of work done
in the existing cycle
 Need planned and actual functionality
added to the system in this cycle
 Adjust schedule for the next cycle
accordingly
 Need the Scope Bank
INFO 638
Lecture #10
52
Go back to Cycle Plan phase
 After the client checkpoint, loop
back to the cycle plan phase, until
this version of the product has
been completed
 Notice that we didn’t do detailed
planning during the client checkpoint
for this reason – it’s followed by the
planning phase
 Stop loop when done with Version
INFO 638
Lecture #10
53
Post-Version Review
 There are three activities in the
Post-Version Review
 Determine if the project has met
its business objectives
 Review lessons learned
 Look for APF process improvements
INFO 638
Lecture #10
54
APF Variations
 APF can be used for quick proof-ofconcept projects
 Sometimes an APF project will reveal
major scope problems; have to adjust
severely, or kill the project
INFO 638
Lecture #10
55
Extreme Project Management
 Extreme Project Management (xPM)
is similar to APF, but is better suited
to projects with poorly defined goals
 You don’t know what the objective is
 It isn’t the same as Extreme
Programming (XP), which is part of
the Agile family of development
methods
INFO 638
Lecture #10
56
Extreme Projects
 Extreme projects are generally fast,
innovative, and ill defined
 High speed – must be developed quickly
 High change – must respond to fast
changes in the project requirements
 High uncertainty – must be able to
handle rapid and unexpected changes
in project direction and focus
INFO 638
Lecture #10
57
xPM vs. APF
 xPM and APF have a lot in common
 The main differences are
 xPM has unknown project goals
 xPM has more variability in project
scope, budget, and time
 xPM has more variability in cycle
duration and number of cycles
INFO 638
Lecture #10
58