Question? Leave a message!




Project Management

Project Management
Chapter 22 Project Management “…a huge topic.” See Part 4, “Software Management”. Chapter 22 Project Management Slide 1 Topics covered  Risk management  Managing people  Teamwork Chapter 22 Project Management Slide 2 Software project management  Concerned with ensuring that software is delivered on time, within budget and in accord- ance with the requirements of both the developing and procuring organizations.  Needed because software development is always subject to budget and schedule constraints. Chapter 22 Project Management Slide 3 Success criteria  Deliver the software to the customer on time.  Keep overall costs within budget.  Meet the customer’s needs/expectations.  Maintain a happy and well-functioning develop- ment team. Chapter 22 Project Management Slide 4 Software management distinctions  The product is intangible. • Software cannot be seen or touched. Software project managers cannot see progress by simply looking at the artefact that is being constructed. (one-of-a-kind)  Many software projects are “one-off”. • Large software projects are usually different in some ways from previous projects. Even managers who have lots of previous experience may find it difficult to anticipate problems. (cont’d) Chapter 22 Project Management Slide 5 Software management distinctions (cont’d)  Software processes are variable and organiza- tion specific. • We still cannot reliably predict when a particular software process is likely to lead to development problems. Chapter 22 Project Management Slide 6 Project Manager activities  Project planning • Planning, estimating, and scheduling project development and assigning people to tasks.  Reporting • Reporting on the progress of a project to customers and to the managers of the company developing the software. (cont’d) Chapter 22 Project Management Slide 7 Project Manager activities (cont’d)  Risk management • Assess and monitor risks; take action when problems arise.  People management • Select team members and establish ways of working that lead to effective team performance  Proposal writing • May be involved in writing a proposal describing the objectives of the project and how it will be carried out. Chapter 22 Project Management Slide 8 Topics covered  Risk management  Managing people  Teamwork Chapter 22 Project Management Slide 9 Risk management  Risk management is concerned with identifying risks and drawing up plans to minimize their effect. (cont’d) Chapter 22 Project Management Slide 10 Risk management (cont’d)  A risk exists when there is a probability that some adverse circumstance will occur. • Project risks affect schedule or resources. • Product risks affect software quality or performance. • Business risks affect the organization developing or procuring the software. (Taxonomy based on Effect) Chapter 22 Project Management Slide 11 Risk examples 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 organizational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and product There will be a larger number of changes to the requirements than anticipated. Specification delays Project and product Specifications of essential interfaces are not available on schedule. Size underestimate Project and product The size of the system has been underestimated. CASE tool Product CASE tools, which support the project, do not underperformance 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. Chapter 22 Project Management Slide 12 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 risks  Risk monitoring – monitor the risks throughout the project Risk Risk Risk analysis Risk planning identification monitoring Risk avoidance Risk List of potential Prioritised risk and contingency assessment risks list plans Chapter 22 Project Management Slide 13 Risk identification  May be a team activity or based on the individual project manager’s experience.  A checklist of common risks types may be used to identify risks in a project: • Technology risks • People risks Taxonomy based on • Organizational risks Source • Requirements risks • Estimation risks Chapter 22 Project Management Slide 14 Examples of risk types Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected. (1) Reusable software components contain defects that mean they cannot be reused as planned. (2) People It is impossible to recruit staff with the skills required. (3) Key staff are ill and unavailable at critical times. (4) Required training for staff is not available. (5) Organizational The organization is restructured so that different management is responsible for the project. (6) Organizational financial problems force reductions in the project budget. (7) Tools The code generated by software code generation tools is inefficient. (8) Software tools cannot work together in an integrated way. (9) Requirements Changes to requirements that require major design rework are proposed. (10) Customers fail to understand the impact of requirements changes. (11) Estimation The time required to develop the software is underestimated. (12) The rate of defect repair is underestimated. (13) The size of the software is underestimated. (14) Chapter 22 Project Management Slide 15 Risk analysis  Assess probability and seriousness of each risk.  Probability may be very low, low, moderate, high, or very high.  Risk consequences might be catastrophic, serious, tolerable, or insignificant. Chapter 22 Project Management Slide 16 Risk types and examples of analysis results Risk Probability Effects Organizational financial problems force reductions in the Low Catastrophic project budget (7). It is impossible to recruit staff with the skills required for the High Catastrophic project (3). Key staff are ill at critical times in the project (4). Moderate Serious Faults in reusable software components have to be repaired Moderate Serious before these components are reused. (2). Changes to requirements that require major design rework Moderate Serious are proposed (10). The organization is restructured so that different High Serious management is responsible for the project (6). The database used in the system cannot process as Moderate Serious many transactions per second as expected (1). Chapter 22 Project Management Slide 17 Risk planning  Develop a strategy to manage each risk... • Avoidance strategies – reduce the probability. • Minimization strategies – reduce the impact by developing contingency plans. Chapter 22 Project Management Slide 18 Risk management strategies Risk Strategy Organizational Prepare a briefing document for senior management financial problems showing how the project is making a very important contribution to the goals of the business and presenting reasons why cuts to the project budget would not be cost- effective. Recruitment Alert customer to potential difficulties and the possibility of problems delays; investigate buying-in components. Staff illness Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs. Defective Replace potentially defective components with bought-in components components of known reliability. Requirements Derive traceability information to assess requirements changes change impact; maximize information hiding in the design. Chapter 22 Project Management Slide 19 Risk monitoring  Regularly assess each identified risk to determine if it is becoming less or more probable.  Also assess whether the effects of the risk have changed.  Significant risks should be discussed at management progress meetings. Chapter 22 Project Management Slide 20 Risk indicators (warning signs) Risk type Potential indicators Technology Late delivery of hardware or support software; many reported technology problems. People Poor staff morale; poor relationships amongst team members; high staff turnover. Organizational Organizational gossip; lack of action by senior management. Tools Reluctance by team members to use tools; complaints about CASE tools; demands for higher-powered workstations. Requirements Many requirements change requests; customer complaints. Estimation Failure to meet agreed schedule; failure to clear reported defects. Chapter 22 Project Management Slide 21 Topics covered  Risk management  Managing people  Teamwork Chapter 22 Project Management Slide 22 Managing people  People are an organization’s most important assets.  The tasks of a manager are essentially people- oriented.  Successful management requires a good understanding of people.  Poor people-management is an important contributor to project failure. Chapter 22 Project Management Slide 23 People management factors  Consistency: treating all team members in an equitable way without favourites or discrimination.  Respect: recognizing that team members have different skills and respecting (indeed, capitalizing on) these differences.  Inclusion: developing an environment in which all views, even those of the most junior staff, are considered.  Honesty: being honest about what is going well and what is going badly in a project. Chapter 22 Project Management Slide 24 Motivating people  Involves organizing project tasks and the working environment to encourage people to work effectively.  Maslow (‘54) suggests that people are motivated by satisfying their needs... Maslow’s Needs Hierarchy Chapter 22 Project Management Slide 25 Needs satisfaction  In software development groups, basic physiological and safety needs are not (usually) an issue.  Social • Provide communal facilities • Allow informal communications (e.g., via social networking)  Esteem • Recognition of achievements • Appropriate rewards  Self-realization • Training - people want to learn more • Responsibility Chapter 22 Project Management Slide 26 Case study: Individual motivation Alice is a software project manager working in a company that develops alarm systems. This company wishes to enter the growing market of assistive technology to help elderly and disabled people live independently. Alice has been asked to lead a team of 6 developers than can develop new products based around the company’s alarm technology. Alice’s assistive technology project starts well. Good working relationships develop within the team and creative new ideas are developed. The team decides to develop a peer-to- peer messaging system using digital televisions linked to the alarm network for communications. However, some months into the project, Alice notices that Dorothy, a hardware design expert, starts coming into work late, the quality of her work deteriorates and, increasingly, that she does not appear to be communicating with other members of the team. Alice talks about the problem informally with other team members to try to find out if Dorothy’s personal circumstances have changed, and if this might be affecting her work. They don’t know of anything, so Alice decides to talk with Dorothy to try to understand the problem. (cont’d) Chapter 22 Project Management Slide 27 Case study: Individual motivation (cont’d) After some initial denials that there is a problem, Dorothy admits that she has lost interest in the job. She expected that she would be able to develop and use her hardware interfacing skills. However, because of the product direction that has been chosen, she has little opportunity for this. Basically, she is working as a C programmer with other team members. Although she admits that the work is challenging, she is concerned that she is not developing her interfacing skills. She is worried that finding a job that involves hardware interfacing will be difficult after this project. Because she does not want to upset the team by revealing that she is thinking about the next project, she has decided that it is best to minimize conversation with them. Chapter 22 Project Management Slide 28 Personality types  Maslow’s needs hierarchy is almost certainly an over-simplification of what drives motivation...  One should also take into account different personality types: • Task-oriented • Self-oriented • Interaction-oriented (cont’d) Chapter 22 Project Management Slide 29 Personality types (cont’d)  Task-oriented • The motivation for doing the work is the work itself.  Self-oriented • The work is a means to an end, which is the achieve- ment of individual goals - e.g., to get rich, to play tennis, to travel.  Interaction-oriented • The principal motivation is the presence and actions of co-workers. Chapter 22 Project Management Slide 30 Motivation balance  Most people have personalities that are a blend of these types, with one usually being dominant at any given time.  The balance can change depending on personal circumstances and external events.  Just being part of a cohesive group or team can be highly motivating to people... Chapter 22 Project Management Slide 31 Topics covered  Risk management  Managing people  Teamwork Chapter 22 Project Management Slide 32 Teamwork  Most software engineering is a group activity.  A good group is cohesive and has team spirit. The people involved are motivated by the success of the group as well as by their own personal goals.  Effective and efficient group communication is a key determinant of group performance.  Flexibility in composing groups is often limited – managers must do the best they can with the people available. Chapter 22 Project Management Slide 33 Advantages of group cohesiveness  Quality standards can be developed by the group members (and are therefore likely to be observed).  Team members learn from each other and get to know each other’s work.  Knowledge is shared, so continuity can be maintained if a group member leaves.  Refactoring and continual improvement is encouraged.  Members work collectively to deliver high quality results, regardless of who originally created the design or program. Chapter 22 Project Management Slide 34 Case study: Team spirit Alice, an experienced project manager, understands the importance of creating a cohesive group. As they are developing a new product, she takes the opportunity of involving all group members in the product specification and design by getting them to discuss possible technology with elderly members of their families. She also encourages them to bring these family members to meet other members of the development group. Alice also arranges monthly lunches for everyone in the group. These lunches are an opportunity for all team members to meet informally, talk around issues of concern, and get to know each other. At the lunch, Alice tells the group what she knows about organizational news, policies, strategies, and so forth. Each team member then briefly summarizes what they have been doing and the group discusses a general topic, such as new product ideas from elderly relatives. Every few months, Alice organizes an ‘away day’ for the group where the team spends two days on ‘technology updating’. Each team member prepares an update on a relevant technology and presents it to the group. This is an off-site meeting in a good hotel and plenty of time is scheduled for discussion and social interaction. Chapter 22 Project Management Slide 35 Team effectiveness factors  The people in the group: You need a mix of people in a project group as software development involves diverse activities such as negotiating with clients, programming, testing, documentation, etc.  The group organization: A group should be organized so that individuals can contribute to the best of their abilities and tasks can be completed as expected.  Technical and managerial communications: Good communications between group members, and between the software engineering team and other project stakeholders, is essential. Chapter 22 Project Management Slide 36 Assembling a team  It 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 organization may wish to develop employee skills (= train those who lack skills) on a software project.  Managers have to work within these constraints, especially when there are shortages of trained staff. Chapter 22 Project Management Slide 37 Group composition  Groups composed of members who all share the same motivation can be problematic... • Task-oriented - everyone wants to do their own thing; • Self-oriented - everyone wants to be the boss; • Interaction-oriented - too much chatting, not enough work.  An effective group has a balance of all types.  This can be difficult to achieve as software engineers are often task-oriented.  Interaction-oriented people are very important as they can detect and defuse tensions that arise. Chapter 22 Project Management Slide 38 Case study: Group composition In creating a group for assistive technology development, Alice is aware of the importance of selecting members with complementary personalities. When interviewing potential group members, she tried to assess whether they were task- oriented, self-oriented, or interaction-oriented. She felt that she was primarily a self- oriented type because she considered the project to be a way of getting noticed by senior management and possibly promoted. She therefore looked for one or perhaps two interaction-oriented personalities, with task-oriented individuals to complete the team. The final assessment that she arrived at was: Alice—self-oriented Brian—task-oriented Bob—task-oriented Carol—interaction-oriented Dorothy—self-oriented Ed—interaction-oriented Fred—task-oriented Chapter 22 Project Management Slide 39 Group organization  The way that a group is organized affects: • the decisions that are made, • the ways that information is exchanged, and • the interactions between the development group and stakeholders.  Key organizational questions to consider include: • Should the project manager be the technical leader of the group? • Who will be involved in making critical technical decisions, and how will these be made? (cont’d) Chapter 22 Project Management Slide 40 Group organization (cont’d)  Key questions (cont’d): • How will interactions with external stakeholders and senior company management be handled? • How can groups integrate people who are not co- located? • How can knowledge be shared across the group? (cont’d) Chapter 22 Project Management Slide 41 Group organization (cont’d)  Small software engineering groups are usually organized informally, without a rigid structure.  For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects.  Agile development is always based around an informal group on the principle that formal structure inhibits information exchange. Chapter 22 Project Management Slide 42 Informal groups  The group acts as a whole and comes to a consensus on decisions affecting the system.  The group leader serves as the external interface of the group but does not allocate specific work items.  Rather, work is discussed by the group as a whole and tasks are allocated (by mutual consent) according to ability and experience.  This approach is successful for groups where all members are experienced and competent. Chapter 22 Project Management Slide 43 Group communications  Good communications are essential for effective group working.  Information must be exchanged on the status of work, design decisions, and changes to previous decisions.  Good communications also strengthens group cohesion as it promotes understanding. (cont’d) Chapter 22 Project Management Slide 44 Group communications are influenced by:  Group size: The larger the group, the harder it is for people to communicate with other group members.  Group structure: Communication is better in informally structured groups than in hierarchically structured groups. (But size matters here...)  Group composition: Communication is better when there are different personality types in a group and when groups are mixed rather than single sex.  Physical work environment: The organization of the workplace can help encourage communications.  Available communication channels: Different forms of communication are supported by a range of technologies. Chapter 22 Project Management Slide 45 Communication/coordination over- head: The “Mythical Man-Month”  Unfortunately, the time required to complete a SE project is generally not inversely proportional to the number of people working on the project.  Adding people to a late project can make it later (due to communication/coordination overhead). (F. Brooks, The Mythical Man-Month) Chapter 22 Project Management Slide 46 The problem with "Man-Months" more T I M E less few many PEOPLE Key points  Good project management is essential if software engineering projects are to be developed on schedule and within budget.  Software management is distinct from other engineering management. • Software is intangible. • Projects may be novel or innovative with no body of experience to guide their management. • Software processes are not as mature as traditional engineering processes. (cont’d) Chapter 22 Project Management Slide 48 Key points (cont’d)  Risk management is now recognized as one of the most important project management tasks.  It involves identifying and assessing project risks to determine their probability and severity.  One should develop strategies to both avoid and reduce the impact of risks. (cont’d) Chapter 22 Project Management Slide 49 Key points (cont’d)  People are motivated by interaction with other people, the recognition of management and their peers, and by being given opportunities for personal development.  Ideally, software development groups should be small and cohesive.  Factors that influence group effectiveness are its mix of people, its organization and the quality of communication among its members. (cont’d) Chapter 22 Project Management Slide 50 Key points (cont’d)  Communication within a group is influenced by factors such as: • the status of group members, • the size of the group, • the gender composition of the group, • the personalities within the group, and • the available communication channels. Chapter 22 Project Management Slide 51 Chapter 22 Project Management Chapter 22 Project Management Slide 52
Website URL
Comment