Software Engineering Practice - Project management

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

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

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”

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

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

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

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.”

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

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)

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

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

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

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

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

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
• ...

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

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

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

Schedule charts
Gantt
• Task bars
• Example on next slide
PERT
• “Program Evaluation and Review Technique”
• Task boxes
• Example on next slide

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

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

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

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

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

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)

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

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

Risk management
Risk management
• “Assessment”
Identification
Analysis
Prioritization
• “Control”
Resolution
Monitoring

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

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

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

Risk prioritization
Risk exposure
RE = probability * consequences
Risks are prioritized in decreasing order of exposure
Example: Jalote

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

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

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

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: ?

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

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

Data collection
Data collection considerations
• Support good decisions
• Support good estimates
• Hawthorne effect
• Avoid too much overhead
Both on producers and on consumers

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

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

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

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

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

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

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%

The Gaussian

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

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

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

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

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

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

Discussion
Thank you!
Any questions?

Software Engineering Practice - Project management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Engineering Practice - Project management

Similar to Software Engineering Practice - Project management (20)

More from Radu_Negulescu

More from Radu_Negulescu (15)

Recently uploaded

Recently uploaded (20)

Software Engineering Practice - Project management