Chapter 3: Project Management

1. Chapter 3:Project Management

2. Key Definitions Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality. A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated.

3. Introduction

4. Introduction Consider the planning that goes into a wedding Even use a Wedding Planner IT Projects are much more complicated

5. Introduction Overly optimistic timetables are the #1 problem in IT projects

6. Introduction Realistic assessments can be made by following three steps: Creating the work plan Staffing the project Controlling the project

7. CREATING THE WORK PLAN

8. The Work Plan Work Plan � A dynamic schedule that records and keeps track of all tasks Lists each task along with important information: Due date Responsible person List of deliverables

9. The Work Plan Two steps in creating the Work Plan Identify the tasks that need to be accomplished Estimate the time it will take for each task

10. A Work Plan Example

11. Identifying Tasks Top-down approach Identify highest level tasks (derived from the system request) Break them into increasingly smaller units Identify deliverables, hours required etc. for each task as it's identified

12. Top Down Task Identification

13. Identifying Tasks Methodology Using standard list of tasks Most businesses have templates This is the most common way to create work plans Incorporates past experience and company standards

14. Cost Schedule Performance Trade-offs

15. Estimation Trade-offs Size / Performance Function points Lines of code Cost Person-months Schedule Months

16. Time Estimation Once tasks are identified, need to give time and effort values Where do these values come from? Formal estimating procedures Provided with the methodology Taken from projects with similar tasks Provided by experienced developers Pulled out of thin air

17. Time Estimation The numbers used in estimation should be conservative Use the time spent for planning Along with industry standard percentages Estimate the overall time for the project

18. Estimating Project Timeframes

19. Time Estimation We are given thatso

20. Time Estimation We are also given thatso

21. Estimating a Project Based on Industry Information

22. Getting the Right Numbers for Estimation Prior projects Past experience Industry standards Detailed analysis

23. Function Point Approach

24. Function Point Estimation-- Step One

25. Function Points Estimation-- Step Two

26. Function Point Estimation -- Step 3

27. Converting Function Points to Lines of Code

28. Function Point Shortcut Choose standard Adjusted Project Complexity (PCA) from the range: 0.65 Simple systems 1.0 "Normal" systems 1.35 Complex systems

29. Estimating Effort Effort is a function of size and production rates (amount of work per a given time unit) COCOMO model Converts lines of code intoperson months

30. COCOMO Estimation Calculation

31. Estimating Schedule Time Rule of thumb for estimation

32. Staffing Attributes You can now determine the average number of staff needed 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

33. Increasing Complexity with Larger Teams

34. Timeboxing Fixed deadline Reduced functionality if necessary Fewer �finishing touches�

35. Timeboxing Steps Set delivery date Deadline should not be impossible Should be set by development group Prioritize features by importance Build the system core Postpone unfinished functionality Deliver the system with core functionality Repeat steps 3-5 to add refinements and enhancements

36. STAFFING THE PROJECT

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

38. Motivation Use monetary rewards cautiously Use intrinsic rewards Recognition Achievement The work itself Responsibility Advancement Chance to learn new skills

39. Conflict Avoidance Strategies Clearly define roles and project plans Hold individuals accountable Project charter listing norms and groundrules Develop schedule commitments ahead of time Forecast other priorities and their possible impact on the project

40. Reporting Structures

41. CONTROLLING AND DIRECTING THE PROJECT

42. The Hurricane Model

43. Margins of Error in Cost and Time Estimates

44. What happens when you overshoot an estimate? Adjust the schedule Allow milestones to move forward, but leave completion date unchanged

45. When Schedule is Missed

46. Gantt Chart

47. PERT Program Evaluation and Review Technique Uses Critical Path Method PERT is a network analyses Good when individual time estimates are uncertain

48. PERT Pert uses three estimates Optimistic Most Likely Pessimistic

49. PERT They are combined into a single weighted average

50. Pert Chart Used to communicate task dependencies Allows easier visualization of tasks on a critical path

51. PERT Chart with MS Project

52. CASE Tools

53. CASE Components

54. Standards Allows teams to work more efficiently Helps ensure quality Examples Formal rules for naming files Forms indicating goals reached Programming guidelines Can you think of more examples? The book lists a long set of examples on page 81. If you have a lot of students with their books open, you might pass up spending time having the students come up with examples. Otherwise, this is a valuable exercise. You might also ask whether there are times when it is better NOT to use standards.The book lists a long set of examples on page 81. If you have a lot of students with their books open, you might pass up spending time having the students come up with examples. Otherwise, this is a valuable exercise. You might also ask whether there are times when it is better NOT to use standards.

55. Standards

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

57. Documentation Project binder Table of contents Continual updating

58. Managing Scope Scope creep � a major cause of development problems To avoid scope creep: Identify requirements as well as possible RAD and prototyping Use formal change approval Discourages people from requesting changes Charging for changes Really discourages people from requesting changes! The smaller points here suggest some methods for limiting scope creep and are worth pointing out to the students. The last in the list allows users to make changes -- but adds to the costs that they must allocate to the project.The smaller points here suggest some methods for limiting scope creep and are worth pointing out to the students. The last in the list allows users to make changes -- but adds to the costs that they must allocate to the project.

59. Managing Risk Some causes of risks Weak personnel Scope creep Poor design Overly optimistic estimates

60. Managing Risk Create a risk assessment document that tracks: Potential risks Their likelihood Potential impact on the project Actions to reduce likelihood of the risk Deal with risks preemptively

61. Managing Risk

62. Classic Mistakes Overly optimistic schedule Failing to monitor schedule Failing to update schedule Adding people to a late project