Processes, Organization (2).PPT
- 1. Software Project Management Processes, Organization The information contained in this presentation was obtained from the public domain
- 2. Project Success Rates • The 2001 Standish Group Report Showed significant Improvement in IT Project Success Rates compared to 1995 stats: – Time overruns: decreased to 63% compared to 222% – Cost overruns were down to 45% compared to 189% – Required features were up to 67% compared to 61% – 78,000 U.S. projects were successful vs. to 28,000 – 28% of IT projects succeeded compared to 16% • Why the Improvements? • Better tools for monitoring and control • More skilled PM’s, more process, more user involvement • And “The fact that there are processes is significant in itself.“
- 3. Why Do Projects Succeed? • How to identify a projects success potential – What metrics could you look at? • Project size • Project duration • Project team size
- 4. Why Do Projects Succeed? – Executive support – User involvement – Experience project manager – Clear business objectives – Minimized scope – Standard software infrastructure – Firm basic requirements – Formal methodology – Reliable estimates
- 5. Why Executive Support? • Top management can help to: – Secure adequate resources – Get approval for unique project needs in a timely manner – Receive cooperation from people throughout the organization – Provide leadership guidance
- 6. • Define scope of project • Identify stakeholders, decision-makers, and escalation procedures • Develop detailed task list (work breakdown structures) • Estimate time requirements • Develop initial project management flow chart • Identify required resources and budget • Evaluate project requirements • Identify and evaluate risks Prepare contingency plan • Identify interdependencies • Identify and track critical milestones • Participate in project phase review • Secure needed resources • Manage the change control process • Report project status 15 PM Job Functions *Northwest Center for Emerging Technologies, "Building a Foundation for Tomorrow: Skills Standards for Information Technology,"Belleview, WA, 1999
- 7. PMI Framework Source: Project Management Institute
- 8. The 5 PMI Process Groups • 1. Initiating • 2. Planning • 3. Executing • 4. Controlling • 5. Closing • Note: these can be repeated for each phase • Each process is described by: • Inputs • Tools & Techniques • Outputs
- 9. PMI Process Groups Source: Project Management Institute
- 11. PMI Phase Interactions Initiating Processes Planning Processes Controlling Processes Executing Processes Closing Processes Design Phase Initiating Processes Planning Processes Controlling Processes Executing Processes Closing Processes Implementation Phase
- 12. PMI: Initiating Process • Inputs – Product Description – Strategic plan – Project Selection Criteria – Historical Information • Outputs – Project charter – Project Manager assigned – Constraints – Assumptions
- 13. • Scope Planning • Scope Definition • Activity Definition • Activity Sequencing • Activity Duration Estimating • Resource Planning • Cost Estimating • Cost Budgeting • Risk Planning • Schedule Development • Quality Planning • Communications Planning • Organization Planning • Staff Acquisition • Procurement Planning • Project Plan Development Devising and maintaining a workable scheme to accomplish the business need that the project was undertaken to address PMI: Planning Process
- 14. PMI: Executing Process • Project Plan Execution • Scope Verification • Quality Assurance • Team Development • Information Distribution • Source Selection • Contract Administration Coordinating people and other resources to carry out the plan
- 15. PMI: Controlling Process • Overall Change Control • Scope Change Control • Schedule Control • Cost Control • Quality Control • Performance Reporting • Risk Response Control Ensuring that project objectives are met by monitoring and measuring progress and taking corrective measures when necessary
- 16. PMI: Closing Process • Administrative Closure • Contract Close-out Formalizing acceptance of the project or phase and bringing it to an orderly end
- 18. Organizational Structures • Functional – Engineering, Marketing, Design, etc – P&L from production • Project – Project A, Project B – Income from projects – PM has P&L responsibility • Matrix – Functional and Project based – Program Mgmt. Model – Shorter cycles, need for rapid development process
- 19. Functional Organization • Pros – Clear definition of authority – Eliminates duplication – Encourages specialization – Clear career paths • Cons – “Walls”: can lack customer orientation – “Silos” create longer decisions cycles – Conflicts across functional areas – Project leaders have little power
- 20. • structure of an organization based on functional performance; organizational departments created to fulfill organizational functions such as marketing, finance, and personnel. This type of organization has characteristics of both line and staff functions.
- 21. • Over time, this approach changes an organization. The hierarchy and bureaucracy become weaker. Career success depends on the results of the projects on which you work, not just time on in a position or politics. The organization develops executives who manage projects. They are not necessarily technical experts, they are experts in running many different kinds of projects. Last, the organization becomes more agile, able to respond to changing customer needs.
- 22. Project Organization • Pros – Unity of command – Effective inter-project communication • Cons – Duplication of facilities – Career path • Examples: defense avionics, construction
- 23. Matrix Organization • Pros – Project integration across functional lines –Efficient use of resources –Retains functional teams • Cons – Two bosses for personnel – Complexity – Resource & priority conflicts
- 24. Matrix Forms • Weak, Strong, Balanced • Degree of relative power • Weak: functional-centric • Strong: project-centric
- 25. Organizational Structure Influences on Projects Matrix Organization Type Project Characteristics Functional Weak Matrix Balanced Matrix Strong Matrix Projectized Project Manager's Authority Little or None Limited Low to Moderate Moderate To High High to Almost Total Percent of Performing Organization's Personnel Assigned Full- time to Project Work Virtually None 0-25% 15-60% 50-95% 85-100% Project Manager's Role Part-time Part-time Full-time Full-time Full-time Common Title for Project Manager's Role Project Coordinator/ Project Leader Project Coordinator/ Project Leader Project Manager/ Project Officer Project Manager/ Program Manager Project Manager/ Program Manager Project Management Administrative Staff Part-time Part-time Part-time Full-time Full-time PMBOK Guide, 2000, p. 19
- 26. Quiz 1 • Why projects are broken down into smaller tasks? What is the ultimate objective. • To catch up the schedule, you can always add people in the project.
- 28. Isomorphic Team Structure • If project team closely reflects the physical structure of deliverables • Risk of project’s quality integration • PM functions as an integrator • Duplication, linking, styles etc to be standardized by the PM • It’s a simple structure • Best suited to independent modules
- 29. Isomorphic Team Structure Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Technical Report Team Member A Team Member B Team Member C Team Member D Team Member E Project Manager Structure of the Deliverable Structure of the Project Team
- 30. Specialty Team Structure • Team members apply their special expertise across a wide array of tasks • Emphasis towards their specialty and not deliverables • Responsibility is more diffused and problem diagnosis is difficult • Integration problems are greater than those of the isomorphic structure • It fits in nicely with matrix system
- 32. Egoless Team Structure • Egos may have ill-effects • Ego-less team structure is a truly collaborative effort that makes it hard to find who produced what portion of the product • No leader but consensus • Team members collaborate jointly and ego problem is minimized • Encourages interactivity and communication • Due to lack of leadership Ego-less team could drift • State of the art projects
- 33. Team Member A Team Member B Team Member C Chapter 1 Chapter 2 Chapter 4 Chapter 3 Chapter 5 Egoless Team Structure
- 34. Software Teams • Many organization structures … • Political and practical consequences of organizational change (is it within the PM scope of responsibility?)
- 35. Team Types
- 36. Democratic Decentralized –No team leader –Different task assigned to different task coordinators who are appointed for little time –Consensuses based problem solving –Horizontal communication
- 37. Controlled Decentralized –Team leader –Secondary leaders –Group based problem solving –Horizontal & vertical communication –Tasks and sub tasks
- 38. Controlled Centralized –Team leader –Top level problem solving –Vertical communication
- 39. Some Challenges
- 40. Because the project is, by definition, a temporary entity and must come to an end, the PM must be concerned with the future of the people who serve on the team. If the PM does not get involved in helping project workers with the transition back to their functional homes or to new projects, then as the project nears completion, project workers will pay more and more attention to protecting their own future careers and less to completing the project on time. (Shown by “S”Curve) Transition Challenge
- 41. Communication Challenge Two people, one channel Three people, three channels Four people, six channels Five people, ten channels
- 42. Key Differentiator: People • The cultivation of motivated, highly skilled software people has been discussed since 1960. In fact this factor is so important that in addition to process capability model the Software Institute has also developed a people management capability maturity model
- 43. Methods for Selecting Projects • There are usually (always?) more projects than available time and resources to implement them • Therefore: It is important to follow a logical process for selecting IT projects to work on • Methods include – Focusing on broad needs – Categorizing projects – Financial methods
- 44. Broad Organizational Needs • It is often difficult to provide strong justification for many IT projects, but everyone agrees they have a high value • “It is better to measure gold roughly than to count pennies precisely” • Three important criteria for projects: – There is a need for the project – There are funds available – There’s a strong will to make the project succeed
- 45. Categorizing IT Projects • One categorization: whether project addresses – a problem – an opportunity – a directive • Another: how long it will take & when it is needed • Another: overall priority of the project
- 46. Procurement Management • Procurement means acquiring goods and/or services from an outside source – a.k.a. purchasing or outsourcing • Know how your project fits-into this model – Are you building “in-house”? “for hire”? • Thus are you the ‘outside source’? – As a startup? (thus in-house but as basis for the business itself)
- 47. Why Outsource? • To reduce both fixed and recurrent costs • To allow the client organization to focus on its core business • To access skills and technologies • To provide flexibility • To increase accountability
- 48. Procurement Tools & Techniques • Make-or-buy analysis (build vs. buy) • Determining whether a particular product or service should be made or performed inside the organization or purchased from someone else. Often involves financial analysis • Experts • Both internal and external, can provide valuable inputs in procurement decisions