Project Management Slide 1 Objectives Become familiar with

Project Management Slide 1

Objectives Become familiar with estimation. Be able to create a project work plan. Understand why project teams use timeboxing. Become familiar with how to staff a project. Understand how computer-aided software engineering (CASE), standards, and documentation improve the efficiency of a project. • Understand how to reduce risk on a project. • • • Slide 2

Project Management Concerns Slide 3

Project Management • The discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives • Cost • Schedule • Performance Slide 4

PM Activities evolve over Phases • • Inception Elaboration Construction Transition Slide 5

PM Artifacts in UP • • Software development plan Business case Detailed plan for each iteration Assessment of each iteration Periodic status assessment Work schedule Project measurement database Slide 6

PM in Inception Phase 1. Conceive new project • • Preliminary business case Identify some risk, begin assessment 2. Evaluate project scope and risk • More detailed development of business case and risk assessment Slide 7

IDENTIFYING PROJECT SIZE Slide 8

Cost Schedule Performance Trade-offs Cost Project cheaper sooner Schedule Project management involves balancing tradeoffs among the three key project parameters better Quality/Performance Slide 9

Estimating Project Timeframes Slide 10

Function Point Approach Estimate System Size (function points and lines of code) Estimate Effort Required (person-months) Estimate Time Required (months) Slide 11

Getting the Right Numbers for Estimation • Prior projects • Past experience • Industry standards • Detailed analysis Slide 12

Estimation Guidelines • • • Estimate using at least two techniques Get estimates from independent sources Avoid over-optimism; assume difficulties When you have arrived at an estimate, sleep on it Adjust for the people who'll be doing the job -they have the highest impact Slide 13

Estimation Trade-offs • Size • Function (or use-case) points • Lines of code • Effort • Person-months • People available • Time • Months Slide 14

Calculate Function Points • List major elements of system • Determine total number of each element • Specify complexity index of each component (low, med. , high) • Total index multiplied by number of components (TUFP) Slide 15

Function Point Estimation : Step One Complexity Description Low Medium High Total Inputs __x 3 __x 4 __x 6 ____ Outputs __x 4 __x 5 __x 7 ____ Queries __x 3 __x 4 __x 6 ____ Files __x 7 __x 10 __x 15 ____ Program Interfaces __x 5 __x 7 __x 10 ____ TOTAL UNADJUSTED FUNCTION POINTS Slide 16

TUPF Example Slide 17

Adjusted Processing Complexity -- Step 2 Slide 18

Function Points Estimation : Step Four Adjusted Project Complexity = . 065 + (0. 01 * Project Complexity) Total Adjusted Function Points = Adjusted Project Complexity * TUFP Slide 19

Function Point Estimation Processing Complexity (PC): __7______ (From Step 2) Adjusted Processing Complexity (PCA) = 0. 65 + (0. 001 * __7_ ) Total Adjusted Function Points: _0. 72 * _338_ = 243 (TUFP -- From Step 1) Slide 20

Converting Function Points to Lines of Code Language LOC/Function Code Point C COBOL JAVA C++ Turbo Pascal Visual Basic Power. Builder HTML Packages (e. g. , Access, Excel) 130 110 55 50 50 30 15 15 1040 Source: Capers Jones, Software Productivity Research Slide 21

Final Step • Multiply function points by LOC/FP • Approximate lines of code per function point in the chosen language • If you chose C, then 243 function points x 130 lines of code/FP = 31, 590 total lines of code Slide 22

Estimating Effort • Function of size and production rate • COCOMO model • Converts a lines-of-code estimate into a personmonth estimate • For moderate-size projects multiply thousands of lines of code by 1. 4 to get the number of people to assign to the project Slide 23

COCOMO Estimation Calculation Effort (in Person. Months) = 1. 4 * thousands-oflines-of-code Example: If LOC = 2000 Then. . . Effort = (1. 4 * 2000) = 28 Person. Months Slide 24

Estimating Schedule Time • Rule of thumb for estimation Schedule Time (months) = 3. 0 * person-months 1/3 Slide 25

Estimation Guidelines • • • Estimate using at least two techniques Get estimates from independent sources Avoid over-optimism; assume difficulties When you have arrived at an estimate, sleep on it Adjust for the people who will be doing the job; they have the highest impact Slide 26

Reconsider Buy/Build Decision Slide 27

CREATING AND MANAGING THE WORK PLAN Slide 28

Developing Work Plans • A work plan, is a dynamic schedule that records and keeps track of all tasks to be accomplished over the course of the project • Created after a project manager has a general idea of the project’s size and rough schedule • The work plan is usually the main item in a project management software application Slide 29

Developing a Work. Plan • • • Identify tasks in the project Estimate task length Determine task dependencies Specify to whom task will be assigned List deliverables Slide 30

A Workplan Example Work Plan Information Example Name of task Start date Completion date Person assigned Deliverable(s) Completion status Priority Resources needed Estimated time Actual time Perform economic feasibility Jan 05, 2001 Jan 19, 2001 Mary Smith, sponsor Cost-benefit analysis Open High Spreadsheet 16 hours 14. 5 hours ` Slide 31

Identifying Tasks • Top-down approach • Identify highest level tasks • Break them into increasingly smaller units • Methodology • Using standard list of tasks Slide 32

Work Breakdown Structure • Specify high level tasks • Break down each step into smaller tasks and number them in a hierarchical fashion • WBS can be done in two ways • SDLC phase • Product Slide 33

Top Down Task Identification Phases with high level steps Phases Work Plan Deliverables Estimated hours Assigned To * * Slide 34

Work Breakdown Structure Slide 35

WBS Problems • They tend to be specific to the design of the information system being developed • Too many levels of detail too early on in the SDLC for large projects or too few for small projects. • Since they are project specific, they are very difficult to compare across projects. Slide 36

Applying Iteration to Planning • Develop a high level long range plan, with allocation of time and resources to phases • Develop a more detailed plan for the earliest phase(s), including allocation of work, time and resources to interations • Develop a still more detailed plan for the current iteration, including work breakdown into tasks • Revise the plan iteratively, at least weekly Slide 37

Gantt Charts • Good for identifying time and order dependencies • Show slack (ahead) and over-runs (past) • Good for identifying critical paths • Good for small projects, and overview of large ones • Attempt to combine work breakdown with activities, deliverables not shown • Do not show task difficulty or cost • Do not scale well for details of large projects Slide 38

Gantt Chart Slide 39

Gantt Chart Slide 40

Another Style of Gant Chart Slide 41

Slide 42

Slide 43

Slide 44

PERT • Project Evaluation and Review Technique (PERT) • US Navy, 1957 • Systematic method of estimating project length, and monitoring progress • Uses systematic serialization algorithm based on • Dependences • Resource availability • Adds administrative oversight to critical paths • Critical path = sequence of tasks such that if any case on the CP is delayed so is the whole project Slide 45

PERT Estimation • PERT uses three time estimates: • Optimistic, O • Most likely, M • Pessimistic, P • Time Estimate = (O + 4 * M + P) / 6 Slide 46

Pert Chart • Used to communicate task dependencies • Allows easier visualization of tasks on a critical path Slide 47

Slide 48

Slide 49

Slide 50

Slide 51

Slide 52

PERT vs. Gantt Slide 53

CONTROLLING AND DIRECTING THE PROJECT Slide 54

Typical Margins of Error for Well-done Estimates Phase Deliverable Cost (%) time (%) Planning System Request 400 60 Project Plan 100 25 Analysis System Proposal 50 15 Design System Specification 25 10 Source: Boehm et al. (1995) Slide 55

The Hurricane Model Time Project Stage Slide 56

Slide 57

Evolutionary WBS • Organize in a standard manner across all projects • Create in an incremental and iterative manner • First evolutionary WBS done with initial aspects of the project • Later on more details are added to the WBS. • Comparable to earlier projects based on cost and schedule estimation Slide 58

Managing Scope • Scope creep -- a major cause of development problems • JAD and prototyping • Formal change approval • Charging for changes Slide 59

Scope Management • Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen. ” Slide 60

Timeboxing Steps 1. Set the date for system delivery 2. Prioritize the functionality that needs to be included in the system 3. Build the core of the system (the functionality ranked as most important) 4. Postpone functionality that cannot be provided within the time frame 5. Deliver the system with core functionality 6. Repeat steps 3 through 5 to add refinements and enhancements Slide 61

Project Risk Analysis • A risk comprises three elements: • an undesirable event, • an estimate of the severity of the consequences of the event • a likelihood that the event will occur • The amount of risk a project is exposed to is a good measure of the viability of the project Slide 62

Managing Risk Slide 63

Classes of Risk • Direct risk that the manager can control to some extent • Indirect risk that the manager cannot influence In managing a project the aim is to control risk so we try to avoid indirect risk where possible. Slide 64

Risk Control Three strategies: • Risk avoidance - reorganize the project so you are not exposed to the risk • Risk transfer -find other stakeholders to share the risk • Risk acceptance - decide to live with the risk and to take the occurrence of the risk as a possible contingency to be taken account of in the planning process Slide 65

Risk Acceptance Risk mitigation • Try to reduce the likelihood or the impact of a risk. • e. g. if we decide to choose a particular supplier for a component we can identify an alternative supplier with a similar product that could be used if the original supplier fails to deliver. Contingency planning • Construct “what if” plans on the basis of the risk occurring Slide 66

Risk Assessment - Overview • Do risk assessment • Take/plan actions to reduce risk • Revise assessment Slide 67

Classic Mistakes • • • Overly optimistic schedule Failing to monitor schedule Failing to update schedule Adding people to a late project Allowing requirements creep Slide 68

STAFFING THE PROJECT Slide 69

Staffing Attributes • Staffing levels will change over a project’s lifetime • Adding staff may add more overhead than additional labor • Using teams of 8 -10 reporting in a hierarchical structure can reduce complexity Slide 70

Increasing Complexity with Larger Teams Slide 71

Staffing the Project • Determine average number of people needed • Divide total person-months of effort by the optimal schedule • Adding more people will not reduce schedule • Create a staffing plan • Roles required for the project • Reporting structure Slide 72

Example Reporting Structures Project Manager Functional Lead Analyst Technical Lead Analyst Programmer Slide 73

Key Definitions • The staffing plan describes the kinds of people working on the project • The project charter describes the project’s objectives and rules • A functional lead manages a group of analysts • A technical lead oversees progress of programmers and technical staff members Slide 74

Motivation • Use monetary rewards cautiously • Use intrinsic rewards • Recognition • Achievement • The work itself • Responsibility • Advancement • Chance to learn new skills Slide 75

Motivational Don’ts Assign unrealistic deadlines Ignore good efforts Create a low-quality product Give everyone on the project a raise Make an important decision without the team’s input • Maintain poor working conditions • • • Slide 76

Conflict Avoidance Strategies • Clearly define roles and project plans • Make sure the team understands how the project is important to the organization • Develop detailed operating procedures and communicate these to the team members • Develop a project charter • Develop schedule commitments ahead of time • Forecast other priorities and their possible impact on project Slide 77

COORDINATING PROJECT ACTIVITIES Slide 78

CASE Tools • Computer-Aided Software Engineering (CASE) tools automate some or all of the development process • Not a silver bullet, but advantages include: – Reduced maintenance costs – Improve software quality – Enforce discipline – Some project teams even use CASE to assess the magnitude of changes to the project Slide 79

Standards • Examples • Formal rules for naming files • Forms indicating goals reached • Programming guidelines • Can you think of more examples? Slide 80

Standards Types of Standards Example Documentation standards The date and project name should appear as a header on all documentation. Coding standards All modules of code should include a header that lists the programmer, last date of update, and a short description of the purpose of the code. Procedural standards Report to project update meeting on Fridays at 3: 30 PM. All changes to a requirements document must be approved by the project manager. Specification requirement standards Name of program to be created Description of the program’s purpose User interface design standards The tab order of the screen will move from top left to bottom right. Accelerator keys will be provided for all updatable fields. Slide 81

Documentation • Good documentation happens up front – Documentation that occurs only at the tail end of a project/phase is not very useful • Project binder(s) are best practices containing – All internal communications (e. g. minutes from status meetings) – Written standards – Letters to and from the business users – Deliverables from each task Slide 82

Summary • • • Project Management Identifying Project Size Creating And Managing the Workplan Staffing the Project Coordinating Project Activities Slide 83