1. Project management
McGill ECSE 428
Software Engineering Practice
Radu Negulescu
Winter 2004

2. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 2
About this module
A typical software project involves a great number of tasks and artifacts
handled by different people over an extended period of time. Keeping
this under control requires specific techniques and skills.
Here we discuss:
• The software project management plan
• Task scheduling
• Risk management
• Project monitoring and control
• Project closure
We defer for other lectures:
• Team structure / organization
• Team communication / status reporting
• Core workflows
• Configuration management

3. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 3
About this module
Recommended:
• Rapid development ch. 5
• Jalote 5.1.2, 5.2.1-5.2.3, 5.3.1, 5.3.2, 6.4, 9, 13.3.1, 13.3.2
• Survival guide ch. 7, 12, 18
Extras:
• Rapid development ch. 9 “Scheduling”
• Survival guide ch. 17 “Scheduling”
• Bruegge & Dutoit ch. 11 “Project management”

4. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 4
Some buzzwords
Do not confuse the following similar-sounding notions:
• Project = the set of tasks, resources, and artifacts used to produce a
product
• Product = valuable outcome of a project
• Process = sequence of steps to produce a product, execute a task,
perform an activity
• Project management = the activities of planning, budgeting,
monitoring, controlling, and closing projects
• Project management plan = a detailed account of the foreseen
evolution of the project
• Project management process = the generic steps taken to plan,
execute, close projects

5. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 5
Challenges
“Project management” is a technical job
As a project manager, you will need to:
• Estimate and schedule well
Do your homework
Defend and negotiate your schedule
• Foresee and prepare for all mishaps
The target is not reached
External risks
• Be informed on how things go and react on the fly
Project monitoring
Project control
• Draw lessons from your projects
Both successful and unsuccessful

6. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 6
Challenges
“Laws” of project management [Source: Bruegge & Dutoit]
• Projects progress quickly until they are 90% complete. Then they
remain at 90% complete forever.
• When things are going well, something will go wrong. When things
just can’t get worse, they will. When things appear to be going better,
you have overlooked something.
• If project content is allowed to change freely, the rate of change will
exceed the rate of progress.
• Project teams detest progress reporting because it manifests their
lack of progress.
A metaphor: managing a bull ride
• Plan the bull ride
• Execute the bull ride
• Assess the damage and learn some lessons

7. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 7
A metaphor
Roping – Australian rodeo events
“Success depends on roper and
horse working together...”
“While the experts make the
team roping look easy, nothing
is simple. The first roper, the
header, rides after the steer and
ropes the horns, takes the dally
(wraps the rope) around his
saddle horn and turns the horse
away, leading the steer. A
second roper, the heeler, rides
in, ropes the hind legs and takes
the dally. In an instant, the
horses face the steer, the rope
becomes snug, and the judge
signals time. But if one hind leg
is caught, a five second penalty
is added.”

8. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 8
Project management – what’s involved?
Project management involves three main groups of activities
• Project planning: major decisions, coordinate team and resources
Determine task breakdown & task definition
Schedule tasks
Support go/no-go decisions
• Risk management
Assess importance of each risk
Set a strategy to deal with the risk
• Project execution: carry out the plan
Monitor and control project parameters
Optimize efficiency
Resolve risks
Replan
• Closure: extract useful information from the project
Prepare project data for future use
Prompt process improvements

9. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 9
Project management – what’s involved?
Example: car trip from Montreal to Toronto.
• Planning:
Check car, road conditions
Go/no-go decision
Check fuel
Fill tank before leave, or fill tank at Cornwall
Drive
Stop at Kingston
Arrive safely 5-6 hours later
• Risk management:
Risk: Traffic jam. Contingency: Plan alternate route and carry a map.
Risk: System failure. Contingency: Carry CAA card and a cell phone.
Risk: Car crash. Prevention: Stop midway and get some refreshments.
• (Continued on next slide)

10. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 10
Project management – what’s involved?
Example: car trip from Montreal to Toronto (continued from last slide)
• Execution:
Steer on lane
Keep distance from car in front
Keep to highway speed or legal limit
If drowsy open window
• Closure:
Note actual arrival time
Note fuel consumption

11. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 11
Part 1: Planning
How the plan will be used
• Clarify to everyone what to do during the project; get consensus
Minimize the need for revisiting issues later on
• Determine and resolve in advance any conflicts
Demands on the resources, staff, etc.
• Optimize, explore options
Outcome, chances of success, cost-efficiency, long-term goals
• Provide basis for assessing progress on-the-fly
Visualize complex issues
How the plan can NOT be used / pitfalls of project planning
• Goad the team into working harder by artificial goals
This usually achieves the adverse effect
Goals should be realistic and supported by rational estimates
• Wishful thinking to get buy-in from management & stakeholders
Very short-term and iffy strategy
Will divert a lot efforts and project resources to bad purposes

12. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 12
The software project management plan
Aim
• Vision
• Goals
Tasks
• Breakdown
• Definition / focus
• Entry criteria (dependencies)
• Exit criteria (sign-off)
Schedule
• Task allocation
• Resource allocation
People
• Decision making authority
• Roles, responsibilities, competencies
• Escalation
Resources
• Tools, technology, training schedule
Risks
• Identification
• Exposure
• Mitigation
• Monitoring and resolution
Artifacts
• Deliverables
• Formats
• Change control
Publicizing and monitoring
• Timing and content of status reports
• Time accounting
Policies, workflows
• Requirements
• Faults
• Issues
• Whitepapers

13. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 13
Example software project plan
After [Jalote, 9.1]
• Contract-based development
• Example
Project summary
• High-level information about project setup
• “External” milestones
Project planning
• Assumptions
• Process & tailoring, estimates, schedule milestones, deviation limits
• Change control, quality plan, project infrastructure: technology, tools, training
• Risk management
Project tracking
• Monitoring, status reporting, responsibilities
• Policies for intervention
Team structure, responsibilities

14. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 14
Vision
What is the project vision statement?
• A short statement that defines the project
E.g. “create the first competitive power-aware handheld word processor”
E.g. “create the world’s most memory-efficient digital simulator”
• Motivate team – a prerequisite for efficiency
• Provide top-level guidance
Will resolve squabbling, avoid side trips, avoid side-issues
What is a good vision statement?
• Needs to be challenging, but achievable. Focus on positive aspects.
Example: create a handheld browser that will get 15% market share
Anti-example: create a third-best browser
• Define what is unimportant along with what is important
E.g.: a high-speed OS for low-capacity use

15. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 15
Goals
Resolve priority conflicts
Examples
• Sell on the market
• Develop for a contract
• Develop tools for internal use
• Advertise capabilities
• Train developers
• Assess capability maturity
• Improve the organizational process
• ...

16. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 16
Task definition
Task granularity
• One person-week
• One person-month (rarer)
• More recently, may go down to one person-day
Examples of tasks [Bruegge & Dutoit]
• Unit test class “Foo”
• Test subsystem “Bla”
• Write user manual
• Write meeting minutes and post them
• Write a memo on NT vs Unix
• Schedule a code review
• Develop the project plan

17. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 17
Exit and entry conditions
Exit conditions: define when the task is complete
• Tell staff to do it well, report accurately, but not overdo it
• Meet the needs of downstream tasks
Sample exit conditions
• Inspection/testing
• Statistical criteria
Example
• Bad task definition
Inspect this item to find as many defects as you can
• Good task definition
Find 100-200 defects in this item using this checklist
Sample entry conditions
• Task dependencies
• Resources/staff availability

18. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 18
Schedules
Work breakdown structure
• Expected task duration
• Constraints and task dependencies
Project milestones
• Stage release
• Completion of major artifacts
• QA steps
Allocation of time slots to tasks
• Start date
• End date

19. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 19
Schedule charts
Gantt
• Task bars
• Example on next slide
PERT
• “Program Evaluation and Review Technique”
• Task boxes
• Example on next slide

20. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 20
Schedule charts
Storage subsystem
system analysis
1
Nov 13
5d
Nov 19
Storage subsystem
object design
2
Nov 20
5d
Nov 26
Storage subsystem
test plan
5
Nov 27
10d
Dec 10
Storage subsystem
implementation
3
Nov 27
15d
Dec 17

21. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 21
Scheduling strategies
Directed acyclic graph of task dependencies
Critical path method (CPM)
• Critical path
Defined by highest duration from start to finish
• Slack time
= latest start time – earliest start time

22. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 22
Scheduling strategies
Scheduling non-critical activities
• ASAP
Lower probability of schedule overruns
Almost ASAP: Whenever resources become available
• ALAP (JIT)
Better use of resources
Almost ALAP: Build in some slack time
• Value-based prioritization
• Risk-based prioritization

23. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 23
Team build-up
Recall rules of thumb
• Peak team size
• Effort vs. schedule
Evolution of staff involved in the project
• Approach 1: Rayleigh distribution
Matches the work needs during the project
Start project with a few senior staff [Survival guide]
Some junior staff can review documents, investigate tools, etc.
Appropriate for a larger project
• Approach 2: assign all staff together at the beginning
Use the initial work gap for training, getting up to speed
Use the slack in the end for documentation and closure
Applicable for small projects [Jalote]
Big no-no in [Survival guide], after [NASA SEL]
• Staged delivery helps smooth out the staff curve
Pipeline principle

24. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 24
Stage planning
Iterative and incremental model, evolutionary model, XP, etc.
• Turn one large project into several sub-projects
• Deliver in stages
Minimize risks and overheads
Maximize value to customer
Stage definition
• Stage themes
• High-risk first
• Low-priority last (if ever)
Stage plan
• Map out detailed activities
• Miniature milestones
Laborious activity
Help track progress and reduce risks

25. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 25
Stage planning
Activities [Survival guide p. 178]
• Requirements updates
Increasing at later stages – more change request accumulated
• Detailed design
May include revision of the architecture
• Construction
Goes with detailed design
Daily build and test
• Test case creation
In parallel with coding
Based on spec and UI prototype
• User documentation updates
• Technical reviews
Done by developers
• (continued on next slide)

26. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 26
Stage planning
Activities
• (continued from previous slide)
• Defect corrections
Done by developers
• Technical coordination
Brief team on designs, specifications, etc.
• Risk management
Reassess the risks on the list
The list itself might grow
• Project tracking
Track miniature milestones
• Integration and release
Fit & finish: install program, context-sensitive help, etc.
Ready to release depending on business decisions
• End-of-stage wrap-up

27. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 27
Miniature milestones
Binary: done/not done
Granularity: daily/weekly
Example:
• Fixing a set of reported failures
• Integration of several sources
• Cleaning up quick-and-dirty fixes
Two sets
• Get through to detailed design
• Get through to release-quality product

28. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 28
Risk management
Risk management
• “Assessment”
Identification
Analysis
Prioritization
• “Control”
Resolution
Monitoring

29. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 29
Risk identification
What is your greatest fear?
• Including those you don’t know about yet
Risk identification approaches
• Maintain a list of top-10 risks
• Brainstorming
• Surveying

30. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 30
Top risks
Top schedule risks, adapted from [McConnell, table 5-2]
• Feature creep
• Gold-plating
• Shortchanged early quality
• Overly optimistic schedules
• Inadequate design
• Silver-bullet syndrome (overoptimism on a technology or process)
• Research-oriented development
• Weak personnel
• Contractor failure
• Friction between developers and customers (business)
Other top risks
• Staff turnover / unavailability
• Low motivation
• Changes in business environment

31. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 31
Risk analysis
Risk: “unexpected loss”
Estimating consequences of loss
• Direct estimates: e.g. how long it takes to “fix” bad risk outcome
• Averaged estimates
• Combined estimates
• Scale estimates
Estimating probability of loss
• More subjective than the size estimate
• Aggregate estimates from different persons
• Delphi method
A panel of experts converge to group-consensus by eliciting and discussing
anonymous evaluations
• Mock betting
• Scale, adjective calibration

32. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 32
Risk prioritization
Risk exposure
RE = probability * consequences
Risks are prioritized in decreasing order of exposure
Example: Jalote

33. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 33
Risk resolution
Some specific strategies for dealing with a risk
• Assume the risk
• Avoid the risk
• Buy information about the risk
• Eliminate the root cause of the risk
• Publicize the risk
• Transfer the risk from one part of the system to another

34. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 34
Risk resolution
Levels of risk resolution
• Crisis
Do nothing to avoid or react to the risk
Address damage only after risk materializes
• Fix on failure
Identify risk
Plan and allocate resources only if risk materializes
• Mitigation
Plan resources ahead of time
Minimize risk consequences ahead of time
Execute contingency plan only if risk materializes
• Prevention
Resolve risks before undertaking a risky activity
• Elimination of root causes
Eradicate the conditions that made risks possible

35. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 35
Examples
Based on [Beck – XP]
• Schedule slips / project cancelled
Short release cycles (few months); 1-4 week iterations; 1-3 day tasks
Schedule high-risk features first
First release is the smallest release that makes most business sense
• System goes sour / defect rate
Regression tests
Refactoring – prime condition
Tests from programmer and customer perspective
• Business misunderstood / business changes
Continuous refinement of specification with customer involvement
Short release cycles
• False feature rich
Allow business to prioritize tasks; address only highest-priority tasks
• Staff turnover
Empowerment in estimation helps keep staff in project
Collective code ownership reduces exposure if one developer leaves
Explicit models for communication and inclusion of new staff

36. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 36
Examples
Source: adapted from [Bruegge & Dutoit]
• Risk: Members in key roles drop the course.
Contingency: Roles are assigned to somebody else. Functionality of the
system is renegotiated.
• Risk: The project is falling behind schedule.
Contingency: Extra project meetings are scheduled.
• Risk: One subsystem does not provide the functionality needed by
another subsystem.
Contingency: ?
• Risk: The latest version of JDK is not installed in the lab.
Mitigation: ?

37. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 37
Risk monitoring
Look for warning signs before damage occurs
• E.g. schedule slips instead of missing deadline
How to monitor warning signs?
• Continuous monitoring by everyone
Too much distraction, responsibility overlap
• Reassess risk exposure at discrete times
On milestones
On events such as completion of a task
• Continuous monitoring by risk officer

38. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 38
Project monitoring and control
Between projects
• Data collection
Capability baseline
Process baseline
• Interventions
Go/no-go decisions using baseline-aware estimates
Project planning (schedule, quality, etc)
Within a project
• Data collection
• Triggers
Milestones
SPC
• Interventions
Corrective action, preventive action
E.g. rescheduling, scope reallocation
E.g. review data interpretation from Jalote

39. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 39
Data collection
Data collection considerations
• Support good decisions
• Support good estimates
• Hawthorne effect
• Avoid too much overhead
Both on producers and on consumers

40. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 40
Data collection
What data to collect?
• Data for progress assessment
Key parameters
Scope
Effort
Schedule
Defects
Other parameters
Size
Classes, functions, dialogs
• Data for process improvement
Time accounting
Efficiency of various techniques
E.g. review outcomes vs. test outcomes

41. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 41
Data collection
Progress assessment
• Project indicators (include on status report)
List of tasks completed
Defect statistics
Top 10 risks list
Percent of schedule used
Percent of resources used
• Percents: to date, out of total planned
• All indicators (including percents): actual vs. planned
Publicizing project indicators
• Intranet web site
Example [Survival guide p. 93]
Can be based on revision control system
May include an “anonymous feedback” upload form
• Access: all staff, project manager, upper management

42. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 42
Data collection
Time accounting
• Track how teams spend their time
Why?
• Organization: basis for process improvements, better estimates
• Project: monitor progress, enable project control decisions
How?
• Time-accounting programs: enter time data from desks
• Time-accounting categories [Survival guide, pp. 108-109]
Management
Administration
Process
Requirements
UI prototyping
Architecture
Detailed design
Implementation
Component acquisition
Integration
System testing
Software release
Metrics

43. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 43
Interim post-mortems
A good time to reassess is between stages
Data from past iteration to be used for:
• Planning the next iteration
• Revising the project plan
• Enabling project decisions
Interim post-mortems
• Compare against baseline

44. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 44
Intervention triggers
Environment-dependent
• Examples
External factors, such as requirements change requests
Business context, such as subcontractor missing deadlines
Risk outcomes, such as technology incompatibility
Project-dependent
• Milestone-based
Milestone missed
Several milestones missed
• Statistics-based
Variation limits

45. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 45
Data interpretation
SPC charts
• X-bar chart:
Subgroup mean values
Control limits: LCL, UCL
3 sigma
• R-chart:
Subgroup ranges
• XMR chart:
Individual values
Moving ranges
Control limit: 2.66 moving range average

46. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 46
Data interpretation
Background
• Standard deviation
Measure of spread
σ = sqrt(Sum (x – µ)2)
• Normal distribution
A.k.a. bell curve, Gaussian
µ +/− σ : 68%
µ +/− 2σ : 95%
µ +/− 3σ : 99.7%

47. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 47
The Gaussian

48. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 48
Data interpretation
Reading trends
• Interpolation/regression
• Reconciling estimates
What to do about “bad” points
• None
• Eliminate and re-estimate
• Take corrective action: eliminate the cause of deviation
• Take preventive action: eliminate causes of other potential problems

49. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 49
Data interpretation
Examples
• Policies for out-of-control review parameters
• Policies for project indicators exceeding limit of variation
• Determine release quality on the basis of regression curve
QA week #
(normalized)1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Faults found
(log scale)
interpolated
101
102
103
100

50. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 50
Intervention
Project-level intervention
• Release product version
• Negotiate deadline
• Kill project
• Reduce scope
• Hire temporary staff
• Change policy for responding to events
E.g. freeze any further requirements changes
E.g. do overtime instead of recalibration
• Replan
E.g. add/remove risk mitigation steps

51. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 51
Intervention
Stage-level intervention: what to do when miniature milestones are not
met
• Recalibrate the developer’s schedule
Keep to optimal 8-hour days
• Trim down feature set
• Clear away some distractions
• Reassign parts of the project to other staff

52. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 52
Project closure
Extract useful information about the project
• Update all project plan information as it actually turned out
• Collect metrics, hard data from status reports
• Collect subjective impressions about what worked and what not
• Collect lessons learned: what worked, what not
About each activity in the project: planning, requirements, dev, testing
About new technology
About new techniques and processes
Update project-planning checklist and top 10 risk list
Why?
• Add to the baseline for future estimates
• Improve process
• Build foundation for future success

53. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 53
Debriefing team members
Project review meeting [Survival guide, ch. 18]
• Moderator: all sides of the issue are discussed, avoid getting mired in
a single issue
Questionnaire
• Generic rating questions
Change control policy: too restrictive, just right, too lax
• Targeted rating questions
“Active design reviews” compared to our usual technical reviews were:
effective, about the same, ineffective
• Open-ended questions
• Free-form comments

54. McGill University ECSE 428 © 2004 Radu Negulescu
Software Engineering Practice Project management—Slide 54
Discussion
Thank you!
Any questions?