Project Management. Minsoo Ryu. Hanyang University.

Transcription

1 Project Management Minsoo Ryu Hanyang University

2 Contents Management Activities Project Planning and Scheduling Risk Management 2 2

3 Introduction Software project management is an essential part of software engineering Good management cannot guarantee project success However, bad management usually results in project failure Late delivery, costs more than originally estimated, failure of meeting requirements Software managers are responsible for planning and scheduling project development They supervise the work to ensure that it is carried out to the required standards and monitor progress to check if the development is on time and within budget 3 3

4 Management Activities It is impossible to write a standard job description for a software manager The job varies tremendously depending on the organization and the software product being developed However, most managers take responsibility at some stage for some or all of the following activities Proposal writing Personnel selection and evaluation Project planning and scheduling Project cost Project monitoring and reviews Report writing and presentations 4 4

5 Proposal Writing Write a proposal to win a contract to carry out the work The proposal includes The objectives of the project and how it will be carried out Cost and schedule estimates Justification of why The proposal writing is a skill that you acquire through practice and experience 5 5

6 *118-Second Elevator Pitch By Jeffrey Hayzlett, January 2, Summary 118 seconds is the length of the average elevator ride in New York City The first 8 seconds are "the hook, since the length of time the average human can concentrate on something and not lose some focus is as little as 8 seconds. The Good: "In less than two minutes, I will tell you how the use of me, my company, or my service will grow your development department 115%." The Bad: "My name is Sam Maybe-Somebody, and my company The Hopeful-Who Knows wants to work with your company using our We Think Super Service." The Ugly: "My name is Sam Nobody, and my company wants to work with your company because we think we can help you." Your 118 must: Grab the attention of your prospect (why) Convey who you are (who) Describe what your business offers (what) Explain the promises you will deliver on (how) 6 6

7 Personnel Selection May not be possible to appoint the ideal people to work on a project Project budget may not allow for the use of highly-paid staff Staff with the appropriate experience may not be available An organisation may wish to develop employee skills on a software project Managers have to work within these constraints especially when there are shortages of trained staff 7 7

8 *Seven Non-Negotiables to Prevent a Bad Hire by David K. Williams and Mary Michelle, May 31, negotiables_to_prevent_a.html?awid= Summary Of nearly 2,700 employers surveyed, 41% estimate a single bad hire cost $25,000; a quarter estimate a bad choice cost $50,000 or more not to mention the demoralizing effect The seven Non-Negotiables are Respect, Belief, Loyalty, Commitment, Trust, Courage and Gratitude. We ask potential candidates to tell us about situations where they have exemplified each of the non-negotiable traits. We also ask the same questions of the individual's references not the references they list on their resume, but of their former coworkers, associates and bosses that we identify independently, and who are in a position to speak open and candidly about the candidate's strengths (or weaknesses) in exhibiting these traits. 8 8

9 Project Planning and Scheduling Project planning is concerned with identifying the activities, milestones, and deliverables produced by a project A plan is drawn up to guide the development towards the project goals Cost estimation is a related activity that is concerned with estimating the resources required to accomplish the project plan 9 9

10 Project Monitoring Project monitoring is a continuing activity The manager must keep track of the progress of the project and compare actual and planned progress and costs Although most organizations have formal mechanisms for monitoring, a skilled manager can often form a clear picture of what is going on through informal discussions with project staff Informal monitoring can often predict potential problems by revealing difficulties as they occur For example, daily discussions with project staff might reveal a particular problem in finding some software fault 10 10

11 Contents Management Activities Project Planning and Scheduling Risk Management 11 11

12 Project Planning Probably the most time-consuming project management activity Continuous activity from initial concept through to system delivery Plans must be regularly revised as new information becomes available Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget 12 12

13 Types of Project Plan Plan Quality plan Validation plan Configuration management plan Maintenance plan Description Describes the quality procedures and standards that will be used in a project. See Chapter 27. Describes the approach, resources and schedule used for system validation. See Chapter 22. Describes the configuration management procedures and structures to be used. See Chapter 29. Predicts the maintenance requirements of the system, maintenance costs and effort required. See Chapter 21. Staff plan. development Describes how the skills and experience of the project team members will be developed. See Chapter

14 Project Plan Structure Most plans should include the following sections Introduction Project organization Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms 14 14

15 Minimum Project Plan The minimum plan sets out: The work breakdown A schedule for the work The resources available to the project 15 15

16 Work Breakdown: Milestones and Deliverables Milestones A recognizable end-point of a software process activity At each milestone, there should be a formal output, such as a report Milestone reports need not be large documents They may be a short report of what has been completed Deliverables A project result that is delivered to the customer It is usually delivered at the end of some major project phase such as specification or design Deliverables are usually milestones, but milestones need not be deliverables 16 16

17 Project scheduling Split project into tasks and estimate time and resources required to complete each task Organize tasks concurrently to make optimal use of workforce Minimize task dependencies to avoid delays caused by one task waiting for another to complete Dependent on project managers intuition and experience 17 17

18 Task Durations and Dependencies Activity Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) 18 18

19 Activity Network 19 19

20 Activity Bar Chart 20 20

21 Staff Allocation 21 21

22 PERT PERT (Program Evaluation and Review Technique) A model for project management designed to analyze and represent the tasks involved in completing a given project Optimistic time (minimum) Normal time Pessimistic time (maximum) Expected = (a + 4m + p)/

23 Gantt Chart Gantt chart from Microsoft Project critical path in red CPM (Critical Path Method) An algorithm for scheduling a set of project activities 23 23

24 WBS (Work Breakdown Structure) WBS is a tool used to define and group a project's discrete work elements (or tasks) in a way that helps organize and define the total work scope of the project The Work Breakdown Structure is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract Example: WBS of an aircraft 24 24

25 The 100% Rule WBS Principles The WBS includes 100% of the work defined by the project scope and captures all deliverables internal, external, interim in terms of the work to be completed, including project management Mutually exclusive elements There is no overlap in scope definition between two elements of a Work Breakdown Structure Planned outcomes, not planned actions The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants 25 25

26 WBS Principles Level of detail A question to be answered in determining the duration of activities necessary to produce a deliverable defined by the WBS is when to stop dividing work into smaller elements Rules of thumb The first is the "80 hour rule" which means that no single activity or group of activities to produce a single deliverable should be more than 80 hours of effort The second rule of thumb is that no activity or series of activities should be longer than a single reporting period Thus if the project team is reporting progress monthly, then no single activity or series of activities should be longer than one month long The last heuristic is the "if it makes sense" rule Applying this rule of thumb, one can apply "common sense" when creating the duration of a single activity or group of activities necessary to produce a deliverable defined by the WBS 26 26

27 WBS coding scheme WBS Principles It is common for Work Breakdown Structure elements to be numbered sequentially to reveal the hierarchical structure For example Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point 27 27

28 Contents Management Activities Project Planning and Scheduling Risk Management 28 28

29 Risk Management Risk management is increasingly seen as one of the main jobs of project management Risk management involves anticipating risks that might affect the project schedule of the quality of the software being developed and taking action to avoid these risks There are three related categories of risk Project risks affect the project schedule or resources Product risks affect the quality or performance of the software being developed Business risks affect the organisation developing or procuring the software 29 29

30 Software Risks Risk Affects Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Specification delays Size underestimate CASE tool underperformance Project and product Project and product Project and product Product There will be a larger number of changes to the requirements than anticipated. Specifications of essential interfaces are not available on schedule The size of the system has been underestimated. CASE tools which support the project do not perform as anticipated Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed

31 Risks and Risk Types Risk type Technology People Organisational Tools Requirements Estimation Possible risks The database used in the system cannot process as many transactions per second as expected. Software components that should be reused contain defects that limit their functionality. It is impossible to recruit staff with the skills required. Key staff are ill and unava ilable at critical times. Required training for staff is not available. The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget. The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Changes to requirements that require major design rework are proposed. Customers fail to understand the impact of requirements changes. The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated

32 The Risk Management Process Risk identification Identify project, product and business risks; Risk analysis Assess the likelihood and consequences of these risks; Risk planning Draw up plans to avoid or minimise the effects of the risk; Risk monitoring Monitor the risks throughout the project; 32 32

33 The Risk Management Process 33 33

34 Risk Analysis Assess probability and seriousness of each risk Probability may be very low, low, moderate, high or very high Risk effects might be catastrophic, serious, tolerable or insignificant 34 34

35 Risk Analysis (i) Risk Probability Effects Organisational financial problems force reductions in Low Catastrophic the project budge t. It is impossible to recruit staff with the skills required High Catastrophic for the project. Key staff are ill at critical times in the project. Moderate Serious Software components that should be reused contain defects which limit their functionality. Changes to requirements that require major design rework are proposed. The organisation is restructured so that different management are responsible for the project. Moderate Moderate High Serious Serious Serious 35 35

36 Risk Analysis (ii) Risk Probability Effects The database used in the system cannot process as Moderate Serious many transactions per second as expec ted. The time required to develop the software is High Serious underestimated. CASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of Moderate Tolerable requirements changes. Required training for staff is not available. Moderate Tolerable The rate of defect repair is underestimated. Moderate Tolerable The size of the software is underestimated. High Tolerable The code generated by CASE tools is inefficient. Moderate Insignificant 36 36

37 Risk Planning Consider each risk and develop a strategy to manage that risk Avoidance strategies The probability that the risk will arise is reduced Minimisation strategies The impact of the risk on the project or product will be reduced Contingency plans If the risk arises, contingency plans are plans to deal with that risk 37 37

38 Risk Management Strategies (i) Risk Organisational financial problems Recruitment problems Staff illness Defective components Strategy Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Alert customer of potential difficulties and the possibility of delays, investigate buying-in components. Reorganise team so that there is more overlap of work and people therefore understand each other?s jobs. Replace potentially defective components with boughtin components of known reliability

39 Risk Management Strategies (ii) Risk Requirements changes Organisational restructuring Database performance Underestimated development time Strategy Derive traceability information to assess requirements change impact, maximise information hiding in the design. Prepare a briefing document for senior management showing how th e project is making a very important contribution to the goals of the business. Investigate the possibility of buying a higherperformance database. Investigate buying in components, investigate use of a program generator 39 39

40 Risk Monitoring Assess each identified risks regularly to decide whether or not it is becoming less or more probable Also assess whether the effects of the risk have changed Each key risk should be discussed at management progress meetings 40 40

41 Risk Indicators Risk type Technology People Organisational Tools Requirements Estimation Potential indicators Late delivery of hardware or support software, many reported technology problems Poor staff morale, poor relationships amongst team member, job availability Organisational gossip, lack of action by senior management Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations Many requirements change requests, customer complaints Failure to meet agreed schedule, failure to clear reported defects 41 41

42 10 Jeopardy Signs Software people don t understand their customer s needs The product scope is poorly defined Changes are managed poorly The chosen technology changes Business needs change [or are ill-defined] Deadlines are unrealistic Users are resistant Sponsorship is lost [or was never properly obtained] The project team lacks people with appropriate skills Managers [and practitioners] avoid best practices and lessons learned 42 42

43 Common-Sense Approach to Avoid 10 Jeopardy Signs Start on the right foot This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations Maintain momentum The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team s way 43 43

44 Common-Sense Approach to Avoid 10 Jeopardy Signs Track progress For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity Make smart decisions In essence, the decisions of the project manager and the software team should be to keep it simple Conduct a postmortem analysis Establish a consistent mechanism for extracting lessons learned for each project 44 44