Your SlideShare is downloading. ×
Software Engineering Practice - Project management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software Engineering Practice - Project management

696
views

Published on

Published in: Business, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
696
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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