1. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 1 Chapter 5 Project Management “…a huge topic.” See Part 6, “Managing People”.

2. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 2 Project management l Organizing, planning and scheduling software projects

3. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 3 Objectives l To introduce software project management and to describe its distinctive characteristics. l To discuss project planning and the planning process. l To show how graphical schedule representations are used by project management. l To discuss the notion of risks and the risk management process.

4. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 4 Topics covered l Management activities l Project planning l Project scheduling l Risk management

5. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 5 Topics covered l Management activities l Project planning l Project scheduling l Risk management

6. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 6 l Concerned with activities involved in ensuring that software is delivered on time, within budget and in accordance with the requirements of the organizations developing and procuring the software. l Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software. Software project management

7. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 7 1.The product is intangible. In shipbuilding or civil engineering, managers can SEE the product being developed. 2.There are no standard software processes. Engineering disciplines with a long history have tried and tested processes. 3. Large software projects are often “one-off”. Lessons learned from previous projects may not be transferable to new projects. SE distinctions that make project management particularly difficult (one-of-a-kind)

8. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 8 l Proposal writing (to fund new projects) l Project planning and scheduling (focus of this Chap) l Project costing and preparing bids (Chap 26) l Project monitoring and reviews l Personnel selection and evaluation (Chap 25) l Report writing and presentations l Attending lots and lots of meetings! IBM Santa Teresa study, etc., … Management activities

9. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 9 l These activities are not peculiar to software management. l Many techniques of engineering project management are equally applicable to software project management. l Technically complex engineering systems tend to suffer from most of the same problems as software systems. Management commonalities

10. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 10 Project staffing l May not be possible to appoint the ideal people to work on a project… Project budget may not allow for use of highly-paid staff. Those with appropriate skills / experience may not be available. An organization may wish to develop employee skills by assigning inexperienced staff. l Managers have to work within these constraints especially when there is a shortage of skilled IT staff.

11. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 11 Topics covered l Management activities l Project planning l Project scheduling l Risk management

12. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 12 Project planning l Probably the most time-consuming project management activity (or at least it should be). l Continuous activity from initial concept to system delivery. Plans must be regularly revised as new information becomes available. l Different types of sub-plans may be developed to support a main software project plan concerned with overall schedule and budget.

13. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 13 Types of project sub-plans (QA)

14. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 14 Project planning “The plan is nothing – the planning is everything.” – Dwight Eisenhower, on the D-Day invasion plan (a bit of dramatic overstatement to make a point…)

15. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 15 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

16. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 16 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

17. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 17 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

18. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 18 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

19. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 19 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

20. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 20 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

21. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 21 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

22. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 22 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

23. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 23 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

24. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 24 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

25. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 25 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

26. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 26 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

27. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 27 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

28. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 28 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

29. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 29 Project planning process Establish the project constraints Make initial assessments of the project parameters (e.g., structure, size, etc.) Define project milestones and deliverables WHILE ( project has not been completed or cancelled ) DO Draw-up project schedule Initiate activities according to schedule Wait for a while (this is NOT idle time…) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables IF ( problems arise ) THEN Initiate technical review and possible revision END-IF END-WHILE-DO

30. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 30 The project plan l The project plan sets out: The resources available to the project; The work breakdown; A schedule for the work.

31. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 31 Project plan document structure l Introduction (goals, constraints, etc.) l Project organization l Risk analysis l Hardware and software resource requirements l Work breakdown l Project schedule l Monitoring and reporting mechanisms

32. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 32 Activity organization l Activities in a project should be associated with tangible outputs for management to judge progress (i.e., to provide process visibility) l Milestones are the unequivocal end-points of process activities. e.g., “DR1 complete” versus “90% of design complete”

33. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 33 Activity organization l (Customer) Deliverables are project results delivered to customers. (There are also internal “deliverables”.) l The waterfall model allows for the straightforward definition of milestones (“a deliverable oriented model”). l Deliverables are usually milestones, but milestones are not necessarily deliverables.

34. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 34 Milestones in the RE process

35. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 35 Topics covered l Management activities l Project planning l Project scheduling l Risk management

36. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 36 Project scheduling l Split project into tasks and estimate time and resources required to complete each. l Tasks should not be too small or too large – they should last on the order of weeks for projects lasting months. (“Models should be as simple as possible, but no simpler.”) (cont’d)

37. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 37 Project scheduling (cont’d) l Organize tasks as concurrent activities to make optimal use of workforce. l Minimize task dependencies to avoid potential delays. l Dependent on project managers’ intuition and experience. (Good management is not a science.)

38. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 38 The project scheduling process Review Progress

39. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 39 Scheduling problems l Estimating the difficulty of problems, and hence the cost of developing solutions, is hard. l The unexpected always happens. Always allow for different contingencies in planning. (a.k.a. “Murphy’s Law”) l Progress is generally not proportional to the number of people working on a task. Adding people to a late project can make it later (due to coordination overhead). (F. Brooks, The Mythical Man-Month)

40. TIMETIME PEOPLE fewmany less more The problem with "Man-Months"

41. TIMETIME PEOPLE fewmany less more What if time and people were perfectly interchangeable? The problem with "Man-Months"

42. TIMETIME PEOPLE fewmany less more What if time and people were perfectly interchangeable? 1 person/12 months 12 persons/1 month The problem with "Man-Months"

43. TIMETIME PEOPLE fewmany less more 1 person/12 months What if time and people were perfectly interchangeable? 12 persons/1 month The problem with "Man-Months"

44. TIMETIME PEOPLE fewmany less more K = time X people The problem with "Man-Months"

45. TIMETIME PEOPLE fewmany less more Can you think of an activity for which time and people are perfectly interchangeable? The problem with "Man-Months"

46. TIMETIME PEOPLE fewmany less more Stuffing Envelopes The problem with "Man-Months"

47. TIMETIME PEOPLE fewmany less more Stuffing Envelopes The problem with "Man-Months" Can you think of an activity for which time and people are not at all interchangeable?

48. TIMETIME PEOPLE fewmany less more Having a baby Stuffing Envelopes The problem with "Man-Months"

49. TIMETIME PEOPLE fewmany less more Having a baby Stuffing Envelopes The problem with "Man-Months" What would the curve for Software Development look like?

50. TIMETIME PEOPLE fewmany less more Software Development Having a baby Stuffing Envelopes The problem with "Man-Months"

51. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 51 Bar charts and activity networks l Graphical notations are often used to illustrate project schedules. l Activity charts (a.k.a. PERT* charts) show task dependencies, durations, and the critical path. l Bar charts (a.k.a. Gantt charts) generally show resource (e.g., people) assignments and calendar time. (Sommerville calls these “staff allocation vs. time” charts.) * Program Evaluation and Review Technique

52. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 52 Task durations and dependencies

53. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 53 Activity network |CP|=55

54. How much potential “slack time” is associated with Task J? If J is on the Critical Path, CP, then 0 Else |CP| - |JL| where JL is the longest path containing J

55. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 55 Consider Task T4… |CP|=55

56. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 56 Activity timeline duration potential slack time: 55-35 = 20 days

57. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 57 Staff allocation (Gantt) Chart

58. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 58 Topics covered l Management activities l Project planning l Project scheduling l Risk management

59. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 59 Risk management l Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project.

60. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 60 Risk management (cont’d) l A risk exists when there is a probability that some adverse circumstance will occur. Project risks affect schedule or resources. Product risks affect the quality or performance of the software being developed. Business risks affect the organization developing or procuring the software. (Taxonomy based on Effect)

61. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 61 Software risks

62. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 62 The risk management process l Risk identification – identify project, product and business risks l Risk analysis – assess the likelihood and consequences of these risks l Risk planning – draw up plans to avoid or minimise the effects of the risk l Risk monitoring – monitor the risks throughout the project We consider each of these activities in turn...

63. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 63 The risk management process

64. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 64 Risk identification l Types –Technology risks –People risks –Organizational risks –Tools risks –Requirements risks –Estimation risks (Taxonomy based on Source)

65. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 65 Risks and risk types

66. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 66 Risk analysis l Assess probability and seriousness of each risk. l Probability may be very low, low, moderate, high or very high. l Risk effects might be catastrophic, serious, tolerable or insignificant.

67. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 67 Risk analysis

68. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 68 Risk planning l Consider each risk and develop a strategy to manage that risk. l Avoidance strategies – the probability that the risk will arise is reduced. l Minimisation strategies – the impact of the risk on the project or product is reduced.  Contingency plans – if the risk arises, contingency plans are plans to deal with that risk. (to effect the minimisation strategy)

69. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 69 Risk management strategies

70. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 70 Risk monitoring l Assess each identified risk regularly to decide whether or not it is becoming less or more probable. l Also assess whether the effects of the risk have changed. l Each key risk should be discussed at management progress meetings.

71. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 71 Risk factors (  warning signs)

72. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 72 Key points l Good project management is essential for project success. (Necessary, but not sufficient…) l The intangible nature of software causes problems for management. l Managers have diverse roles, but their most significant activities are planning, estimating, and scheduling. l Planning and estimating are iterative processes which continue throughout the course of a project.

73. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 73 l A project milestone is a predictable state where some formal report of progress is presented to management. l Risks may be project risks, product risks or business risks. (and: technology, people, organisational, tools, requirements, or estimation risks) l Risk management is concerned with identifying risks which may affect the project, and planning to ensure that these risks do not develop into major threats. Key points (cont’d)

74. ©Ian Sommerville 2000Software Engineering. Chapter 5 Slide 74 Chapter 5 Project Management “…a huge topic.” See Part 6, “Managing People”.