Lecture 2: Project Management, Part 1: Requirements, WBS, Scheduling, and Risk Management. Prof. Shervin Shirmohammadi SITE, University of Ottawa

Transcription

1 Lecture 2: Project Management, Part 1: Requirements, WBS, Scheduling, and Risk Management Prof. Shervin Shirmohammadi SITE, University of Ottawa Prof. Shervin Shirmohammadi ELG

2 Goal of Project Management TIME To finish the project: on budget Dilemma on time feature-complete COST with high quality Project Management is the planning, scheduling and controlling of project activities to achieve project objectives. Suggested readings: Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects. SCOPE Prof. Shervin Shirmohammadi ELG

3 On Budget Software projects being over budget is a major problem (we saw the numbers). Project Management helps us estimate the budget needed to complete a project before it starts monitor the progress and, at any given time, find out how much a project has cost and how much more it will cost until completion. Prof. Shervin Shirmohammadi ELG

4 On Time Software projects are often delayed (as we saw). Project Management helps us: estimate the time needed to complete a project before it starts monitor the progress and find out how much time remains to completion. Prof. Shervin Shirmohammadi ELG

5 Scope Software delivered at the end must provide all the features specified in its requirements (feature complete). Project Management helps us: estimate what features can be developed in the given time and cost frame monitor the progress and find out what features have been completed, and which ones will be completed before the end of the project: enables manager to re-negotiation features Prof. Shervin Shirmohammadi ELG

6 Management Tasks Development Process (both hardware and software) Waterfall, spiral, iterative and incremental, Project Charter Requirements Work Breakdown Structure Estimation Scheduling Organization Risk Management Configuration Management Verification and Validation (V & V) Project Tracking At any point in time, a PM must be able to tell you two sets of things: 1. So far: how much work (features or functionalities) has been done, how much effort (man-hours) it took, and how much budget (cost) did it take? 2. Also, according to the current plan: how much work (features or functionalities) is left, how much effort (man-hours) it needs, and how much budget (cost) has been estimated? Post Performance Analysis (PPA) Feedback for future projects Prof. Shervin Shirmohammadi ELG

7 Project Goal, Objective, and Scope Goal: must be defined crisply and clearly e.g., build a timesheet data entry system, build and successfully deploy a Web-based timesheet data application entry system for the department s internal use before the next major external software project Objectives: for a specific target e.g., benchmark two other companies timesheet data entry systems before the opening bid. S.M.A.R.T.: Specific, Measurable, Achievable, Realistic, and Time-bound. Scope: boundaries of the project: does and does not list Not to be confused with features or requirements Prof. Shervin Shirmohammadi ELG

8 Project Charter A document that formally recognizes the existence of a project. Provides the PM with the authority to apply organizational resources to the project: what the PM can and cannot do. e.g.; Right to reset Plan when requirements are changed Defines the project goal, scope and objectives. Details the level of quality to be expected. Validates the business justification. Highlights risk. Prof. Shervin Shirmohammadi ELG

9 Project Charter ( ) It s the contract: if anything needs resolution, this should specify it When in doubt, read the Charter! Also specifies: what to do if there is conflict Management reconciliation Scope change management Knowledge transfer Training approach Anything else Prof. Shervin Shirmohammadi ELG

10 Requirements Gathering Gather all stakeholders: an individual or group of individuals with a common interest in the software there may be conflicting interests among stakeholders! can be customers, consumers, owners, partners, funders, subcontractors, internals, society, Achieve sufficient requirements. Avoid design details Avoid implementation details Cover only the functions that the software must provide. At this stage, don t be concerned with how the functions are provided Use Notations to capture requirements (e.g., UML) Don t just talk about the product, but capture things on paper. Prof. Shervin Shirmohammadi ELG

11 Use Case Diagram In this example, Use Cases are prioritized. Priority 1 leads to the first version of the software and should cover architecturallysignificant features. Prof. Shervin Shirmohammadi ELG

12 Use Case Scenarios One or more user scenarios are written down for each Use Case. A lot of ambiguities are resolves at this stage. Still lots of details remain and are avoided. Example: Use case: show profile 1. START: users activates the show profile feature 2. software asks user to specify profile parameters 3. software retrieves parameters for database and displays them to the user 4. FINISH: user cancels the feature Prof. Shervin Shirmohammadi ELG

13 Non-Functional Requirements Captured as part of requirements gathering stage. Example: The software should run on a Pentium 4 PC with 250 Megabytes of RAM. The software should answer queries within 3 seconds. Prof. Shervin Shirmohammadi ELG

14 Work Breakdown Structure A hierarchical list of work activities needed to complete the project; a description of the work to be performed broken down to its key components, down to the lowest level. Divide and Conquer mentality. WBS identifies activities at a level useful for selecting the team with the proper skills. Based on staff number and estimates for the WBS, schedule cost and duration can be estimated. Prof. Shervin Shirmohammadi ELG

15 WBS Example Prof. Shervin Shirmohammadi ELG

16 WBS Architecture The WBS must cover all activities. It is crucial to capture all disciplines or stages (requirements, design, implementation, testing, ). PM must ensure everything is covered. Prof. Shervin Shirmohammadi ELG

17 Building WBS When to apply each method? Prof. Shervin Shirmohammadi ELG

18 Milestones A milestone is a significant event. Usually associated with an interim deliverable. Can be associated with the completion of a number of work items. There can be a milestone at the end of each iteration. Important to get the numbers right: Too few: big-bang effect, progress will be hard to track Too many: slows down project It is achieved as the result of the completion of a number of activities. Prof. Shervin Shirmohammadi ELG

19 Creating the WBS Who should do the WBS? Go through existing documents: Requirements Design documents Customer conversations Synchronize the WBS with the process framework: keep in mind the life cycle when doing the WBS. PM: sanity check the WBS to ensure: Everything is covered Granularity is appropriate Prof. Shervin Shirmohammadi ELG

20 Tools There are many tools to visualize WBS. WBS Chart Pro from Critical Tools Prof. Shervin Shirmohammadi ELG

21 Scheduling We have the activities and the tasks, now we need to schedule them. Obviously all activities cannot be done at the same time, because some depend on others. Two types of dependency: Activity Dependency Building should be done after Design Resource Dependency There is only 2 test machines, for 4 tests Engineer X is on vacation for 1 week Prof. Shervin Shirmohammadi ELG

22 Dependency Relations Finish-to-Start Start-to-Finish A B A B Start-to-Start Finish-to-Finish A A B B Prof. Shervin Shirmohammadi ELG

23 Lag and Lead E.g.: A +10 B B starts with a 10-day lag after A finishes. A has a 10 day finish-to-start lead. Prof. Shervin Shirmohammadi ELG

24 Assigning Tasks and Scheduling By now, we should know who is going to work on which tasks. Ideally, the people who were going to do the activities have given us estimates. There might be a need to break down activities into tasks before assignment can take place. Scheduling: assigns actual values to activities start and finish times, leading to milestones and deliverables being determined. Use of automated tools is strongly recommended! What values should we assign to each activity? The raw estimate, or the psyched estimate? Prof. Shervin Shirmohammadi ELG

25 Estimation Psychology Estimator: ideally it takes 3 weeks, but there are some uncertainties so let s say 6 weeks to be on the safe side. But, I have to work on two projects so there is a multitasking overhead, so say 8 weeks. Then there s the other stuff in between the projects. I d say 10 weeks. Causes the Student Syndrome Prof. Shervin Shirmohammadi ELG

26 Use Raw Estimates! Instead, use raw estimates and add uncertainty buffers at the appropriate positions in the plan. Prof. Shervin Shirmohammadi ELG

27 Gantt Chart Assigns activity bars to each task, proportional in length to the duration of the task. Dependency need not be supported by a Gantt Chart, but modern tools overlay dependency on the chart as well. A good visualization tool to see the big picture. How to handle very large projects with Gantt charts? Prof. Shervin Shirmohammadi ELG

28 Network Diagram A diagram that represents an ordered list of activities. Prof. Shervin Shirmohammadi ELG

29 CPM CPM: Critical Path Method Uses activity duration to find out the flexibility of each activity. It identifies a Critical Path (CP) which determines the duration of the whole project. Uses Two-pass analysis: Forward pass: finds the earliest start/finish Backward pass: finds the latest start/finish CP = the path with no flexibility Prof. Shervin Shirmohammadi ELG

30 Example (0,10) A 10 (0,0) (5,15) St (0,0) (0,15) B 15 (0,15) (15,35) C 20 (15,35) (70,70) (35,70) D 35 (35,70) End (70,70) What is the main disadvantage of CPM? Prof. Shervin Shirmohammadi ELG

31 Resource Leveling Distributes the work load based on resource constraints. Prof. Shervin Shirmohammadi ELG

32 Things to Consider On the average, staff spend 60% to 70% of their time on the activities. Where is the rest? Vacation Illness Talking on the phone Choose the uncertainty buffer based on estimation accuracy: 50% probability estimates: add 50% buffer 95% probability estimates: add 5% buffer Prof. Shervin Shirmohammadi ELG

33 Risk Management Risk is the possibility of suffering loss Loss could be: increased cost, delay, low-quality product, Risk Management is the understanding of the risks and taking them into account for project planning purposes. Risk is associated with the lack of complete knowledge of how the future will turn out; i.e., uncertainty. Prof. Shervin Shirmohammadi ELG

34 PMI model Risk Models Project Risk Management Risk Identification Risk Analysis Response Planning Monitoring & Control Qualitative Quantitative SEI s model Analyze Plan Identify Control Track Prof. Shervin Shirmohammadi ELG

35 Boehm s model Risk Models ( ) Project Risk Management Risk Assessment Risk Control Risk Identification Risk Analysis Risk Prioritization Risk Planning Risk Resolution Risk Monitoring Prof. Shervin Shirmohammadi ELG

36 Risk Identification The team and customer brainstorm Historical data: look at previous projects risk management plans Examine all assumptions, specially the optimistic ones Look for bottlenecks in the WBS and the network diagram Activities that hold up many others Activities that depend on many others Types of risks: Technical, legal, political, marketing, operational, Prof. Shervin Shirmohammadi ELG

37 Brainstorming Risk Analysis Delphi method: to reach consensus on how to handle risks. Impact Analysis: Impact = Probability Loss; e.g.: Unproven architecture: = 100 Fire burning the company down: =10 Sort risks based on impact and address the high-impact ones Prof. Shervin Shirmohammadi ELG

38 Decision Trees Assume $100,000 bonus for being early with an aggressive schedule (20% confidence), and $250,000 penalty for being late with a conservative schedule (90% confidence) Prof. Shervin Shirmohammadi ELG

39 Mitigating Risk Once you get all risks listed in priority, develop a plan for handling them: Risk Resolution Plan E.g.: Risk: unproven architecture Resolution: have proven architectures standby and ready Prof. Shervin Shirmohammadi ELG

40 Controlling Risk Update the Risks table on a weekly basis. Not always possible for all projects Typically done as one component of tracking (more about tracking in future lectures) Prof. Shervin Shirmohammadi ELG