Chapter 4 Project Management Organizing planning and scheduling

Chapter 4 Project Management Organizing, planning, and scheduling software projects ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 0 of 40

Objectives l l To introduce software project management and to describe its distinctive characteristics To discuss project planning and the planning process To show graphical schedule representations are used by project management To discuss the notion of risks and the risk management ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 1 of 40

Topics covered l l Management activities Project planning Project scheduling Risk management ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 2 of 40

Software project management l l Concerned with activities involved in ensuring that software is produced on time and in accordance with the requirements of the software developer/procurer Project management is needed because software development is always subject to budget and time constraints that are set by the developer ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 3 of 40

Management activities l l l l Proposal writing Project planning and scheduling Project cost estimation Project monitoring and reviews Personnel selection and evaluation Report writing and presentations Decision making ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 4 of 40

Software management distinctions l l l The product is intangible. The product is uniquely flexible. Software engineering is not recognized as an engineering discipline with the same status as mechanical, electrical engineering, etc. The software development process is not standardized. Many software projects are 'one of a kind' projects, no example to follow. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 5 of 40

Management commonalities l l l These activities are not peculiar to software management. Many techniques of engineering project management are equally applicable to software project management. Technically complex engineering systems tend to suffer from the same problems as software systems. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 6 of 40

Project staffing l May not be possible to appoint the ideal people to work on a project • • • l Project budget may not allow for the use of highly-paid staff Staff with the appropriate experience may not be available An organization may wish to develop employee skills on a software project Managers have to work within these constraints especially when (as is currently the case) there is an international shortage of skilled IT staff. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 7 of 40

Project planning l l l Probably the most time-consuming project management activity. Continuous activity from initial conception to system delivery. Plans must be regularly revised as new information becomes available. Various types of plan may be developed to support the main software project plan with respect to the schedule and budget. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 8 of 40

Types of project plan Plan Description Quality plan prescribes the standards and procedures for quality assurance Validation plan describes the approach, resources, and schedule for system validation Configuration management plan Maintenance plan describes the structure and procedures for configuration management predicts the requirements, cost, and effort required for maintenance Staff development plan describes how the skills and experience of the project team are to be acquired ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 9 of 40

Project planning process Identify all project constraints; Assess initial project parameters; define project milestones and deliverables; while the project has not been cancelled or completed do begin set up project schedule; initial activities according to the schedule; wait for a prescribed period of time; review project progress; update estimates, parameters, and schedule; renegotiate project constraints if (problems arise) then initiate technical review and corrective actions; end; ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 10 of 40

Project plan structure l l l l Introduction Project organization Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 11 of 40

Activity organization l l Activities in a project should be organized to produce for management to judge progress. Milestones are the end-point of a process activity. Deliverables are project results delivered to customers. The waterfall process allows for the straightforward definition of progress milestones. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 12 of 40

Milestones in the RE process ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 13 of 40

Project scheduling l l Split project into tasks and estimate time and resources required to complete each task Organize tasks concurrently to make optimal use of the workforce Minimize task dependencies to avoid delays caused by one task waiting for another to complete Make good use of the project manager’s intuition and experience ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 14 of 40

The project scheduling process ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 15 of 40

Scheduling problems l l Estimating the difficulty of problems, and hence the cost of developing a solution, is hard. Productivity is not proportional to the number of people working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allow contingency in planning. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 16 of 40

Bar charts and activity networks l l Graphical notations used to illustrate the project schedule. Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two. Activity charts show task dependencies and the critical path. Bar charts show schedule against calendar time. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 17 of 40

Task durations and dependencies ©IS&JCH 050131 Task T 1 T 2 T 3 Duration (days) 8 15 15 T 4 T 5 T 6 T 7 T 8 T 9 T 10 T 11 T 12 10 10 5 20 25 15 15 7 10 Software Engineering, Chapter 4 Dependencies T 1 (M 1) T 2, T 4 (M 2) T 1, T 2 (M 3) T 1 (M 1) T 4 (M 5) T 3, T 6 (M 4) T 5, T 7 (M 7) T 9 (M 6) T 11 (M 8) Slide 18 of 40

Activity network ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 19 of 40

Activity timeline ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 20 of 40

Staff allocation ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 21 of 40

Risk management l l Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project. A risk 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 ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 22 of 40

Events that may put a software project at risk l l l l Staff turn-over Management change Unavailability of required hardware Requirements change Underestimation of time and resources Difficulty with CASE tools Technology change Business change ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 23 of 40

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 minimize the effects of the risk l Risk monitoring Monitor the risks throughout the project ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 24 of 40

The risk management process ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 25 of 40

Risk identification l l l Technology risks: database system, reuse parts People risks: staff illness, difficulty in recruiting Organizational risks: budget cut, restructuring Tools: unexpected problems with the CASE tools Requirements risks: changes that necessitate major rework Estimation risks: underestimation of time and resources required ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 26 of 40

Risk analysis l l l Assess probability and seriousness of each risk Probability may be very low, moderate, high or very high Risk effects might be catastrophic, serious, tolerable or insignificant ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 27 of 40

Risk planning Consider each risk and develop a strategy to manage that risk l Avoidance strategies Strategies that can be followed to minimize the probability of a risk l Minimization strategies Strategies that can be followed to minimize the impact of a risk l Contingency plans Plans to deal with a risk if that risk arises ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 28 of 40

Risk management planning Risk Organizational financial problems force reduction in the project budget Probability Low Consequence Catastrophic Strategy Be prepared to convince the upper management that the project is making important contribution to the goals of the business ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 29 of 40

Risk management planning (continued) Risk It becomes impossible to recruit staff with the skills required for the project Probability High Consequence Catastrophic Strategy Alert customer of potential difficulties and the possibility of delays, investigate buying-in components or subcontracting ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 30 of 40

Risk management planning (continued) Risk Key staff are ill at critical times in the project Probability Moderate Consequence Serious Strategy Reorganize team so that there is more overlap of work. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 31 of 40

Risk management planning (continued) Risk Software components which should be reused contain defects which limit their functionality Probability Moderate Consequence Serious Strategy Replace defective components with bought-in components of known reliability ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 32 of 40

Risk management planning (continued) Risk Changes to the requirements that requires major rework Probability Moderate Consequence Serious Strategy Make requirements traceable so that the impact of a change can be readily assessed, and enhance the changeability by practicing information hiding. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 33 of 40

Risk management planning (continued) Risk The organization is restructured so that different management is responsible for the project Probability High Consequence Serious Strategy Be prepared to convince the upper management that the project is making important contribution to the goals of the business ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 34 of 40

Risk management planning (continued) Risk The database used in the system is not fast enough Probability Moderate Consequence Serious Strategy Investigate the possibility of acquiring a highperformance database ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 35 of 40

Risk management planning (continued) Risk The time required to develop the software is underestimated Probability High Consequence Serious Strategy Investigate buying-in components, investigate the use of a program generator ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 36 of 40

Risk factors Risk type Technology People Potential indicators Late delivery of hardware or support software, many reported technical problems Low staff morale, poor relationships amongst team members, high job-availability Organizational gossip, lack of action by senior management Tools Reluctance to use tools, frequent complaints about CASE tools, demands for higher-powered workstations Requirements Numerous change requests or customer complaints Estimation Failure to meet schedule or to clear reported defects ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 37 of 40

Risk monitoring l l l Assess each identified risk 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. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 38 of 40

Key points l l Good project management is essential for project success. The intangible nature of software makes it difficult to manage. Managers have diverse roles but their most significant activities are planning, estimating and scheduling. Planning and estimating are iterative processes which continue throughout the course of a project. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 39 of 40

Key points (continued) l l l A project milestone is a predictable state where some formal report of progress is presented to management. Risks may be project risks, product risks or business risks. 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. ©IS&JCH 050131 Software Engineering, Chapter 4 Slide 40 of 40