Software Engineering Practice - Project management

Project management

McGill ECSE 428Software 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 wellDo your homeworkDefend and negotiate your schedule

• Foresee and prepare for all mishapsThe target is not reachedExternal risks

• Be informed on how things go and react on the flyProject monitoringProject control

• Draw lessons from your projectsBoth successful and unsuccessful


Challenges

“Laws” of project management [Source: Bruegge & Dutoit]

• Projects progress quickly until they are 90% complete. Then theyremain at 90% complete forever.

• When things are going well, something will go wrong. When thingsjust 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 resourcesDetermine task breakdown & task definitionSchedule tasksSupport go/no-go decisions

• Risk managementAssess importance of each riskSet a strategy to deal with the risk

• Project execution: carry out the planMonitor and control project parametersOptimize efficiencyResolve risksReplan

• Closure: extract useful information from the projectPrepare project data for future usePrompt process improvements



Example: car trip from Montreal to Toronto.

• Planning:Check car, road conditionsGo/no-go decisionCheck fuelFill tank before leave, or fill tank at CornwallDriveStop at KingstonArrive 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 laneKeep distance from car in frontKeep to highway speed or legal limitIf drowsy open window

• Closure:Note actual arrival timeNote fuel consumption


Part 1: Planning

How the plan will be used

• Clarify to everyone what to do during the project; get consensusMinimize the need for revisiting issues later on

• Determine and resolve in advance any conflictsDemands on the resources, staff, etc.

• Optimize, explore optionsOutcome, chances of success, cost-efficiency, long-term goals

• Provide basis for assessing progress on-the-flyVisualize complex issues

How the plan can NOT be used / pitfalls of project planning

• Goad the team into working harder by artificial goalsThis usually achieves the adverse effectGoals should be realistic and supported by rational estimates

• Wishful thinking to get buy-in from management & stakeholdersVery short-term and iffy strategyWill 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 projectE.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 guidanceWill 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 shareAnti-example: create a third-best browser

• Define what is unimportant along with what is importantE.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 definitionInspect this item to find as many defects as you can

• Good task definitionFind 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 subsystemsystem analysis1Nov 13

5dNov 19

Storage subsystemobject design2Nov 20

5dNov 26

Storage subsystemtest plan5Nov 27

10dDec 10

Storage subsystemimplementation3Nov 27

15dDec 17


Scheduling strategies

Directed acyclic graph of task dependencies

Critical path method (CPM)

• Critical pathDefined by highest duration from start to finish

• Slack time= latest start time – earliest start time


Scheduling strategies

Scheduling non-critical activities

• ASAPLower probability of schedule overrunsAlmost ASAP: Whenever resources become available

• ALAP (JIT)Better use of resourcesAlmost 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 distributionMatches the work needs during the projectStart 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 speedUse the slack in the end for documentation and closureApplicable for small projects [Jalote]Big no-no in [Survival guide], after [NASA SEL]

• Staged delivery helps smooth out the staff curvePipeline principle


Stage planning

Iterative and incremental model, evolutionary model, XP, etc.

• Turn one large project into several sub-projects

• Deliver in stagesMinimize risks and overheadsMaximize value to customer

Stage definition

• Stage themes

• High-risk first

• Low-priority last (if ever)

Stage plan

• Map out detailed activities

• Miniature milestonesLaborious activityHelp track progress and reduce risks


Stage planning

Activities [Survival guide p. 178]

• Requirements updatesIncreasing at later stages – more change request accumulated

• Detailed designMay include revision of the architecture

• ConstructionGoes with detailed designDaily build and test

• Test case creationIn parallel with codingBased on spec and UI prototype

• User documentation updates

• Technical reviewsDone by developers

• (continued on next slide)


Stage planning

Activities

• (continued from previous slide)

• Defect correctionsDone by developers

• Technical coordinationBrief team on designs, specifications, etc.

• Risk managementReassess the risks on the listThe list itself might grow

• Project trackingTrack miniature milestones

• Integration and releaseFit & 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”IdentificationAnalysisPrioritization

• “Control”ResolutionMonitoring


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 methodA panel of experts converge to group-consensus by eliciting and discussing anonymous evaluations

• Mock betting

• Scale, adjective calibration


Risk prioritization

Risk exposureRE = 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

• CrisisDo nothing to avoid or react to the riskAddress damage only after risk materializes

• Fix on failureIdentify riskPlan and allocate resources only if risk materializes

• MitigationPlan resources ahead of timeMinimize risk consequences ahead of timeExecute contingency plan only if risk materializes

• PreventionResolve risks before undertaking a risky activity

• Elimination of root causesEradicate the conditions that made risks possible


Examples

Based on [Beck – XP]

• Schedule slips / project cancelledShort release cycles (few months); 1-4 week iterations; 1-3 day tasksSchedule high-risk features firstFirst release is the smallest release that makes most business sense

• System goes sour / defect rateRegression testsRefactoring – prime conditionTests from programmer and customer perspective

• Business misunderstood / business changesContinuous refinement of specification with customer involvementShort release cycles

• False feature richAllow business to prioritize tasks; address only highest-priority tasks

• Staff turnoverEmpowerment in estimation helps keep staff in projectCollective code ownership reduces exposure if one developer leavesExplicit 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 everyoneToo much distraction, responsibility overlap

• Reassess risk exposure at discrete timesOn milestonesOn events such as completion of a task

• Continuous monitoring by risk officer


Project monitoring and control

Between projects

• Data collectionCapability baselineProcess baseline

• InterventionsGo/no-go decisions using baseline-aware estimatesProject planning (schedule, quality, etc)

Within a project

• Data collection

• TriggersMilestonesSPC

• InterventionsCorrective action, preventive actionE.g. rescheduling, scope reallocationE.g. review data interpretation from Jalote


Data collection

Data collection considerations

• Support good decisions

• Support good estimates

• Hawthorne effect

• Avoid too much overheadBoth on producers and on consumers


Data collection

What data to collect?

• Data for progress assessmentKey parameters

ScopeEffortScheduleDefects

Other parametersSizeClasses, functions, dialogs

• Data for process improvementTime accountingEfficiency of various techniques

E.g. review outcomes vs. test outcomes


Data collection

Progress assessment

• Project indicators (include on status report)List of tasks completedDefect statisticsTop 10 risks listPercent 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 siteExample [Survival guide p. 93]Can be based on revision control systemMay 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]

ManagementAdministrationProcessRequirementsUI prototypingArchitecture

Detailed designImplementationComponent acquisitionIntegrationSystem testingSoftware releaseMetrics


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

• ExamplesExternal factors, such as requirements change requestsBusiness context, such as subcontractor missing deadlinesRisk outcomes, such as technology incompatibility

Project-dependent

• Milestone-basedMilestone missedSeveral milestones missed

• Statistics-basedVariation limits


Data interpretation

SPC charts

• X-bar chart: Subgroup mean valuesControl limits: LCL, UCL

3 sigma

• R-chart: Subgroup ranges

• XMR chart: Individual valuesMoving rangesControl limit: 2.66 moving range average


Data interpretation

Background

• Standard deviationMeasure of spreadσ = sqrt(Sum (x – µ)2)

• Normal distributionA.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 eventsE.g. freeze any further requirements changesE.g. do overtime instead of recalibration

• ReplanE.g. add/remove risk mitigation steps


Intervention

Stage-level intervention: what to do when miniature milestones are not met

• Recalibrate the developer’s scheduleKeep 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 notAbout each activity in the project: planning, requirements, dev, testingAbout new technologyAbout new techniques and processesUpdate 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 questionsChange 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?