1 / 69

P roject Management

P roject Management. Project Management. ANF DATA introduction Project Management Definition & Context Project Management Activities Effort Estimation Planning, Scheduling & Controlling Managing People Risk Management Some Special Project Types Distributed Projects Death March Projects.

pattiv
Télécharger la présentation

P roject Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project Management

  2. Project Management • ANF DATA introduction • Project Management Definition & Context • Project Management Activities • Effort Estimation • Planning, Scheduling & Controlling • Managing People • Risk Management • Some Special Project Types • Distributed Projects • Death March Projects Contents

  3. Introduction • Ivan Bradáč, ANF DATA KB • In ANF DATA since 2002 • Most of the time as Project Manager • Involved also in • Architecture • Implementation (Java) • Requirements Specifications • Before ANF DATA employed in Sun Microsystems, AIS Software • Masaryk University, Faculty of Science (Mathematical Analysis) • Ivan.Bradac@siemens.com My Introduction

  4. PM Definition & Context • What is a Project? • A project is a temporary endeavor to create a unique product, service, or result. • Project vs. Operational Work : Operations are ongoing and repetitive • What is Project Management? • Application of knowledge, skills, tools and techniques to project activities to meet project requirements • What is special on software Project Management? • Intangible product • Processes not standardised • Uniqueness of software projects What is Project Management

  5. PM Definition & Context • Project Manager & Project Team • Performing Organization • Owner (Sponsor) – person/organization who accepts and pays for the project result. • Customer (User) – person(s)/organization who will use the project result. • Other stakeholders (Influencers) • Individuals and organizations involved in the project or affected by the project‘s outcome • Stakeholders can have positive or negative influence on the project • Don‘t forget to identify the players, don‘t forget about the political influences! Project Players (Stakeholders)

  6. PM Definition & Context • Organizational systems can be project-based or non-project based • Organizational structures • Functional : No Project Managers • Projectized : Project manager = Functional Manager • Matrix : Project are performed throughout the functional lines. • The organizational structure has an influence on the Project‘s Manager authority Organizational Influences

  7. Chief Executive Project Coordination Functional Manager Functional Manager Functional Manager Staff Staff Staff Staff Staff Staff Staff Staff Staff PM Definition & Context Functional Organization (Gray boxes represent staff engaged in project activities.)

  8. Chief Executive Project Coordination Project Manager Project Manager Project Manager Staff Staff Staff Staff Staff Staff Staff Staff Staff PM Definition & Context Projectized Organization (Gray boxes represent staff engaged in project activities.)

  9. Chief Executive Functional Manager Functional Manager Functional Manager Staff Staff Staff Staff Staff Staff Project Manager Staff Staff Project Coordination PM Definition & Context Matrix Organization (Gray boxes represent staff engaged in project activities)

  10. PM Definition & Context • In general, the following phases are always present: • Initial Phase • Intermediate Phase • Final Phase • According to SEM: Project Lifecycle

  11. PM Definition & Context Project Lifecycle – Staffing

  12. PM Definition & Context • Scope Management (Requirements engineering) • Time Management (Planning, scheduling, controlling) • Cost Management (Effort estimation, controlling) • Quality Management • Human Resource Management • Risk Management • Integration Management (communication, putting everything together) Project Management Activities

  13. Integration Management • Coordination and integration of all project management activities and processes in accordance with the proper development method (e.g. stdSEM) • Includes e.g. the following activities • Scheduling meetings with customers and other stakeholders • Making choices where to concentrate resources in the moment • Anticipating potential issues • Making trade-offs among competing objectives • The central project document: Project Plan Integration Management

  14. Integration Management • Project Plan is the fundamental project document dedicated to team members and the management. • It sets out the available resources, work breakdown and schedule • It may reference more detailed documents pertaining to specific parts, e.g. Test Plan • Project Plan consists at least of • Key project data • Project organization • Deliverables (software, documentation, everything to be delivered) • Project volume planning (efforts and costs) • Work breakdown and schedule • Risk Analysis • Monitoring and reporting Project Plan

  15. Integration Management • The following parts are either included in the Project Plan directly or in a separate document: • QM Plan • CM Plan • Test Plan • Effort Estimation and scheduling are typically done outside of the Project Plan (but the PP must reference them. • Keep the Project Plan up to date • Each team member must know where is the valid Project Plan Project Plan - Continued

  16. Integration Management • The typical project roles include: • Project Manager • Technical Leader/ Architect • Quality Assurance Manager • Test Leader • Testers • Developers • Further project roles: Requirements Manager, Subproject manager, Team Leader, Documentation Writer, Configuration Engineer/Manager, ... • The project organization chart is a hierarchical diagram depicting the roles. Project Roles

  17. Effort Estimation • Cost management : Planning, estimating, budgeting, and controlling costs • Goal: Project should be completed within the approved budget • Project Costs consist of • Hardware and SW costs • Travel and training costs • Effort costs (paying of the SW engineers) • Cost Estimation  Effort Estimation • As effort cost is dominant in SW projects, effort estimation is the dominant part of cost estimation Effort Estimation – Dominant part of Cost Management

  18. Effort Estimation • Effort Estimation is a „black art“! • “Industry surveys from organizations such as the Standish Group, as well as statistical data [...] suggest that the average [software] project is likely to be 6-12 months behind schedule and 50-100 percent over budget.”Yourdon, E., Death March, Second Edition, Prentice-Hall, 2004. • What is special about SW effort estimation? • Intangible product • Rapidly emerging new technologies • Insufficient statistical data Effort Estimation – Known Issues

  19. Effort Estimation • The effort estimation is often disinterpreted as the minimum possible time to complete the project (see next slide for explanation): Effort Estimation - Interpretation

  20. Effort Estimation Explanation of the picture before: • The x-axis is the time (person-hours) necessary to complete the project. • The curve is a „probability distribution“: • Start (theoretically) the same project P many times independently. • For distinct points x[i] on the x-axis, set the y-value to be the nr. of projects, whose real duration was closest to x[i] • Create the curve by interpolating  you get a „skewed“ Gaussian curve • (For math freaks, integral of the curve over R equals 1; integral from a to b is the probability that the project will take more person-hours than a but less person-hours than b) Effort Estimation - Interpretation

  21. Effort Estimation • The result of an effort estimation is a figure, which predicts the project duration/necessary completion time with some probability • The best effort estimation is in the middle of the skewed Gaussian curve: • The probability that the project will be completed earlier is 50% • The probability that the project will be completed later is 50% • As there is some minimal time necessary, the Gaussian curve does not start at 0. • As there is no certainty that the project wil be finished in a finite time, the Gaussian curve is not limited Effort Estimation – Interpretation

  22. Effort Estimation • Standard techniques: • Expert judgement • Algorithmic • Analogy • Bottom-up approach • Some other techniques: • Parkinson‘s law (Work expands to fill the time available) • Price to win (Estimate to whatever the customer has available) Effort Estimation – Techniques Overview

  23. Effort Estimation • Experts on the domain or/and used technology are consulted and they provide an estimate based on their experience. • Theory: The expert‘s estimates are compared; the estimation process iterates untill an agreed estimation is reached • Practice – the project manager alone makes the effort estimation and is responsible for it. At least, a review is critically needed! • Another practice : As there is no time for iterations of estimation, an average is taken from the available estimations. Effort Estimation – Expert Judgement

  24. Effort Estimation • Uses a mathematical mode to compute the effort • Input parameters: Unique Project characteristics like • Project size • Project complexity • Result is computed. • Most general form: Effort = A * Size^B * M • A ... Constant for organizational influences • B ... Magic constant , 1 < B < 1.5 • M ... Combines process, product, development attributes • Example : COCOMO model • Problems: How to define the Size? • Lines of codes • Function points Effort Estimation - Algorithmic cost modelling

  25. Effort Estimation Linear X Exponential dependence Size/Effort

  26. Effort Estimation Perfectly Partitionable Task (50 person-months)

  27. Effort Estimation Unpartitionable Task

  28. Effort Estimation • The dependence between size and effort is an exponential one • For small projects and partitionable tasks, the dependence of effort/size is close to a linear one (exponent ~ 1) • For bigger projects, complex (less partitionable) task, the dependence is a exponential one (exponent ~ 1.5) • Persons and months are not interchangable: To accelerate the work in a factor of two, duplicating the number of persons is not sufficient. Message from previous slides

  29. Effort Estimation • Compare the system to be developed to completed projects, system or components • Analyse similarities and differences • Derive the estimate based on the known price/effort of the systems used for the comparison • Recommendations • Combine with other techniques • Use more on lower level, not suitable for whole projects • Provide an order-of-magnitude assessment Effort Estimation by Analogy

  30. Effort Estimation • The „not scientific“ approach but most widely used • Typical steps: • Decompose the work to subpackages • Assess the subpackages • Add contingency allowance for subpackages • Sum the results • Add contingency allowance for the whole result • For a set of similar tasks, a „base task“ can be identified and thoroughly estimated; the other tasks are compared to the base task. Effort Estimation – Bottom-up Approach

  31. Effort Estimation • Bottom-up approach has got its pitfalls: • Dividing the whole work into work packages might be more difficult than estimating the single packages • Some tasks are easily forgotten: • Development tools – installation, support, training • Code not directly attributable to as functionality like logging, system start-up/shut down, backup, archiving • Performance and stress testing • Meetings, communication • Technical documentation • ... And many others Effort Estimation – Bottom-up Approach - Traps

  32. Effort Estimation • Function Point Analysis is a widely adopted and used estimation method • Divide the software into modules from the user point of view • For each module, • Compute the Unadjusted Function Points • According to complexity factors, compute the Adjusted Function Points • Summarize the Function Points of the modules • Transform the Function Points count to the expected effort. Effort Estimation – Function Point Analysis - Overview

  33. Effort Estimation • The number of Unadjusted Function Points of a module is derived from • External Inputs – File types, data elements that are input as parameters to the module • External Outputs – output parameters of the module (as above) • External Enquiries – Nr. of transactions withim the module where an input causes an immediate output • Internal Logical Files – Records and their elements internal within the module • External Interface Files – Records and their elements to be used by other modules • Each factor is assigned a value according to a table; results are summed. Effort Estimation – Function Point Analysis – Unadjusted Function Points

  34. Effort Estimation • Once the Unadjusted Function Points are computed, complexity factors are taken into account • Data Communication • Distributed data processing • Performance • Heavily used configuration • Transaction rate • Online data entry • End user efficiency • Online update • Complex processing • Reusability • Installation ease • Operational ease • Multiple sites • Facilitate change • Result  Adjusted Function Points Effort Estimation – Function Point Analysis – Adjusted Function Points

  35. Effort Estimation • Well – known rule of thumb : Estimate the effort to the best of your abilities and multiply it by two (and add something...) • Avoid political estimation (political price is however acceptable) • Always introduce a contingency factor • Contingency of standalone tasks • Contingency for the whole project • Acceleration penalty – if the project is to be accelerated by some factor, the size of the team must be increased at least by a square of the factor (acc. 2 increase team by 4!) – but the reasonable team size is limited: • The length of the project in months should not exceed the average number of the team • Example: 180 months project  at most 13 people working for 14 months Effort Estimation – Tips & Tricks

  36. Effort Estimation • Overestimation is not the solution – why? • Effort is overestimated  Price is too high  project does not start or the competing company starts it • „Bindingly Obvious Rule of Estimation“: There is no method that works Paul Coombs, IT Project Estimation – a Practical Guide to the Costing of Software, Cambridge University Press  Combine the techniques Effort Estimation – Tips & Tricks II

  37. Planning, Scheduling & Controlling • Project planning is an iterative process • The following activities are done at the beginning: • Establish project constraints • Define milestones and deliverables • Schedule the work packages • The following activities are iterated (untill project is completed or cancelled): • Review project progress • Revise estimates of project parameters • Assess and renegotiate (if possible) project constraints • Reschedule the project • Continue with updated schedule Overview

  38. Planning, Scheduling & Controlling • Divide the work into subpackages • (Estimate needed effort) • Identify activity dependencies • Allocate people to work packages • Schedule the work packages • Identify the critical path – the longest sequence of dependent tasks • Identify the critical chain – the longest sequence of tasks taking the resource dependencies into acount • Introduce project-wide contingency. Two options • Mutliply each taks by some factor • Add buffers into the plan • Typically, bar charts and activity networks are used for the scheduling • Note: The following pictures depict just an abtract example, the real meaning of tasks is not significant. Scheduling

  39. Planning, Scheduling & Controlling Divide the work to subpackages (Identify Tasks)

  40. Planning, Scheduling & Controlling Identify Activity Dependencies

  41. Planning, Scheduling & Controlling Find the critical path

  42. Planning, Scheduling & Controlling Identify Resource Conflicts

  43. Planning, Scheduling & Controlling Resolve Resource Conflicts

  44. Planning, Scheduling & Controlling Identify Critical Chain

  45. Planning, Scheduling & Controlling • There is a vast number of PM Tools, but the tools of the Microsoft world prevail ... • Excel (or the like) – in pratice, the most used tool • MS Project (2003) • Desktop application, part of MS Office suite • Mostly used features include Gantt charts, resource sheets, network activity diagrams • MS Project Server (also reffered to as EPM – Enterprise Project Management) • Web solution • The plan can be accessed from MS Project 2003 (advanced work, mostly for the PM) or via web (simpler interface, for team members) • Can be customized and extended for the company‘s needs Planning & Controlling Tools

  46. Managing People • People working in a software organization are its greatest assets! • Treat all people in a project in a comparable way • Take in account different technical and communication skills and experience • Let all people contribute and listen to them • Inform honestly about project status • Communication – Support proper communication channels • Most important activities include • Selecting the staff • Team building and development • Motivating people Managing People – General

  47. Managing People • Information about people to be appointed to the project comes mostly from the following sources: • Information provided by the candidates (CVs) – provides the first hints whether a candidate is likely to be suitable (Education, practise, certificates, ...) • Interviews – provides more information about the communication and social skills - but avoid rapid subjective judgements • Recommendations for people who have worked with the people – very effective if you know and trust the people making the recommendations • Beware: Social & communication skills are as important as the technical ones - a conflicting person can destroy the project regardless of their technical skills! Selecting the Staff

  48. Managing People • In an ideal world, the project manager has the option to select the complete staff for the project – in the real world, this is mostly not the case: • The best experts are typically not available as they work on other projects or they are too expensive • Pressures to employ less experienced, less talented or even problematic people in the project may appear •  You can‘t mostly involve exactly the people you want but insist on rejecting unacceptable persons Selecting the Staff - Limitations

  49. Managing People • Stages of team development include • Forming – Team members define goals, roles, and direction of the team. Kick-off meeting! • Storming – The team sets rules and decision-making processes, often renegotiates (argues) over team roles and responsibilities • Norming – Procedures, standards, and criteria are agreed on • Performing – The team begins to function as a system • Adjourning – Termination of tasks, disengagement of relationships Team Building

  50. Managing People • Maslow‘s human needs hierarchy Motivating people – Hierarchy of Needs

More Related