Project Management. Project Planning CE PROJECT MANAGEMENT L- 5

Transcription

1 Project Management Project Planning CE PROJECT MANAGEMENT 1 L- 5

2 Project Phases 1. Ini7a7on 2. Planning 3. Execu7on 4. Controlling 5. Closing

3 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

4 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

5 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Frequent, periodic s, video clips and Vendor selec7on other communica5ons to the sponsors is a minimum set of communica5ons Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

6 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Frequent, periodic s, video clips and Vendor selec7on other communica5ons to the project team is a minimum set of communica5ons Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

7 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) A project manager should think of himself as a director of a movie. He should regularly Vendor selec7on prepare and distribute media about the project Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

8 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) A project manager should think of himself as a director of a movie. He should regularly Vendor selec7on prepare and distribute media about the project Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

9 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

10 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

11 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

12 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

13 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

14 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

15 Planning Phase Communica7on plan Scope management plan Approval of plans Gap analysis Request for Proposal (RFP) Vendor selec7on Work breakdown & Schedule Budget and Resource assessment Iden7fy cri7cal path Kickoff end of plan

16 Elements of a Detailed Plan 1. Project team n Selec7on n Descrip7on 2. Work plan 3. Time and cost of ac7vi7es 4. Project risks 5. Communica7on plan 6. Other management plans

17 Elements of a Detailed Plan 1. Project team n Selec7on n Descrip7on 2. Work plan 3. Time and cost of ac7vi7es 4. Project risks 5. Communica7on plan 6. Other management plans

18 Elements of a Detailed Plan 1. Project team 2. Work plan n High level tasks listed n Ask for lower level tasks 3. Time and cost of ac7vi7es 4. Project risks 5. Communica7on plan 6. Other management plans

19 Elements of a Detailed Plan 1. Project team 2. Work plan 3. Time and cost of ac7vi7es Project schedule Project budget 4. Project risks 5. Communica7on plan 6. Other management plans

20 Elements of a Detailed Plan 1. Project team 2. Work plan 3. Time and cost of ac7vi7es Project schedule Project budget 4. Project risks 5. Communica7on plan 6. Other management plans

21 Elements of a Detailed Plan 1. Project team 2. Work plan 3. Time and cost of ac7vi7es 4. Project risks n Plans to reduce risk n Plans for disasters 5. Communica7on plan 6. Other management plans

22 Elements of a Detailed Plan 1. Project team 2. Work plan 3. Time and cost of ac7vi7es 4. Project risks n Plans to reduce risk n Plans for disasters 5. Communica7on plan 6. Other management plans

23 Elements of a Detailed Plan 1. Project team 2. Work plan 3. Time and cost of ac7vi7es 4. Project risks 5. Communica7on plan n Recipient, mode, frequency, responsibility 6. Other management plans

24 Elements of a Detailed Plan 1. Project team 2. Work plan Recipient 3. Time and cost What of ac7vi7es Frequency Mode Responsibility 4. Project risks Project Executive 5. committee Communica7on status plan Monthly Verbal report Sponsor n Recipient, Project mode, frequency, responsibility Written Sponsors status Weekly report Project manager 6. Other management plans Activity At start and Project manager status weekly Project team member

25 Elements of a Detailed Plan 1. Project team 2. Work plan 3. Time and cost of ac7vi7es 4. Project risks 5. Communica7on plan 6. Other management plans n Scope management n Resource management n Quality management

26 Project Concept The idea or the reason Problem statement It may contain the following Business cases Benefits Descrip7on of a problem or solu7ons to a problem Ini7al es7mate The project concept can be the result of a special mee7ng, an ini7al research, etc

27 Project Concept - - The initial cost estimation To reach a figure for the ini7al es7ma7on, you may have to consider the following Total number of hours and cost per hour The size of the team Cost of management and suppor7ng staff QA costs Consul7ng or contractor costs Deployment delivery, and manufacturing costs Adver7sing and marke7ng costs Cost of producing this es7ma7on Others (such as kick- off) mee7ng and final party

28 Project Proposal RFQ (request for quota7on) Request for an exact quote for a specific service RFI (Request for informa7on) To garner informa7on before sending a RFP Verify assump7ons and certain requirements Solicit resumes and team composi7ons (legal issues) Other basic communica7ons RFP (request for proposal) This is a big one

29 Request for Proposal (RFP) It consists of the following: Introduc)on Execu)ve Summary include a summary of the requesters company and market space. Purpose a descrip6on of the project, the problem and the proposed solu6on that the requester needs to achieve. Key Business and Technical Requirements include the key business and technical requirements. Proposed Project Phases and Milestones include a high level descrip6on of project phases (if applicable) and milestones. Quality Assurance Requirements include any and all quality assurance requirements including processes, procedures, and methodologies. Budget detail the budget that has been established to complete the project.. Schedule of Events include a schedule of events with 6melines for the proposal through awarding of contract to vendor Proposal Template indicate whether a proposal document template is included and any instruc6ons for comple6ng it.

30 The Proposal Introduc)on Execu)ve Summary include a brief history of the company together with some high level financial informa7on Corporate and Cultural Informa)on contain addi7onal informa7on about your company and the technical department(s) that will be involved in the project. It should include a corporate overview and some informa7on about the company culture Previous Projects and Clients contain descrip7ons of previous clients and projects that were similar to the project the client is proposing or that will demonstrate your organiza7on's exper7se and experience in project management and development Client References list some of your clients who have agreed to give references Development Methodologies and Process include an overview of the project lifecycle, and the documenta7on that is produced during each phase. It should also include informa7on about processes and procedures for such things as configura7on management, quality management, source control, security, and any other standard processes used during the development of projects

31 The Proposal Quality Assurance and Tes)ng Processes and Procedures Quality assurance processes, procedures and methodologies should be outlined together with an overview of the documenta6on produced at each step of the lifecycle. There may be tes6ng outside of the quality assurance team that also needs to be accomplished Development Environment include a brief descrip6on of the development environment such as opera6ng system, design packages, programming soaware, unit test soaware etc Assump)ons contain both organiza6onal assump6ons and technical assump6ons. Organiza6onal assump6ons include such things as, the expecta6ons the vendor has from the client as far as involvement in the project; client responsibili6es such as tes6ng or documenta6on; client representa6ves for the project (project manager, for example). Technical assump6ons will include items such as, client's exis6ng hardware, systems and soaware that will be used for the project; specific technology will be used in the development of the product; consultants will be engaged for specific areas of development requiring specialized knowledge or skill sets. The Problem This sec6on will include a brief descrip6on of the problem. This can be taken directly from the RFP or can be elicited from the client via phone conversa6ons or mee6ngs. Proposed Solu)on(s) This sec6on will include details of the proposed solu6on or solu6ons. There may be more than one way to solve the specified problem and, if this is the case, give the client some alterna6ves. Constraints, Limita)ons, and Risks Note any known constraints, limita6ons, or risks that are currently known. This can include things such as the 6meline for the star6ng the project. You may need to complete another project before you would be available to work on this one. Any limita6ons that you company has with regard to technology, knowledge and skill sets should be iden6fied together with a proposal for how you would manage them should you be awarded the project. Risks are things that are obvious to you based on the informa6on that the client has already furnished. Proposed Project Phases The project may need to be developed and delivered in phases either because the client has requested it in the RFP or because you feel that the size and/or complexity of the project warrants it. You may propose that the project be delivered in three phases with one of the products being delivered in each. Milestones and Deliverables This sec6on will include high level project milestones and deliverables. These would include the project phases, if relevant. At this early stage of the planning phase, the milestones may be confined to approximate dates for comple6on of specific documents for the planning phase and a high level 6meline for when each of the subsequent lifecycle phases will be concluded. The Proposed Project Team The proposed project team will include the specific roles/posi6ons needed together with some high level qualifica6ons and skill sets. Individuals do not need to be iden6fied at this point. Costs and Payment Details This sec6on will contain high level es6mates based on the ini6al es6mates that were created during the concept phase or the budget informa6on contained in the RFP. Terms and Condi)ons This will include some legal jargon that will most likely be supplied by your legal department. It will contain some disclaimers related the accuracy of the informa6on contained herein, together with contractual requirements for the approval to move forward with the project. Proposal Submission and Ques)ons This sec6on will include the contact informa6on of the proposal preparer, the date and 6me that the proposal was submiped, and the method of delivery. It will also include any ques6ons the preparer has about anything in the RFP that was not clear. Proposal Acceptance and Approval By signing this document, everyone involved is in agreement that the proposal document is accurate and complete and is approved to move forward.

32 The Proposal Proposed Solu)on(s) include details of the proposed solu6on or solu6ons, or alterna6ves Constraints, Limita)ons, and Risks Note any known constraints, limita6ons, or risks. This can include things such as the 6meline for the star6ng the project. You may need to complete another project before you would be available to work on this one. Any limita6ons that you company has with regard to technology, knowledge and skill sets should be iden6fied together with a proposal for how you would manage them should you be awarded the project. Risks are things that are obvious to you based on the informa6on that the client has already furnished Proposed Project Phases The project may need to be developed and delivered in phases either because the client has requested it in the RFP or because you feel that the size and/or complexity of the project warrants it. Milestones and Deliverables include high level project milestones and deliverables. At this early stage of the planning phase, the milestones may be confined to approximate dates for comple6on of specific documents and a high level 6meline for when each of the subsequent lifecycle phases will be concluded The Proposed Project Team The proposed project team will include the specific roles/posi6ons needed together with some high level qualifica6ons and skill sets. Individuals do not need to be iden6fied at this point. Costs and Payment Details This sec6on will contain high level es6mates based on the ini6al es6mates that were created during the concept phase or the budget informa6on contained in the RFP. Terms and Condi)ons This will include some legal jargon that will most likely be supplied by your legal department. It will contain some disclaimers related the accuracy of the informa6on contained herein, together with contractual requirements for the approval to move forward with the project. Proposal Submission and Ques)ons This sec6on will include the contact informa6on of the proposal preparer, the date and 6me that the proposal was submiped, and the method of delivery. It will also include any ques6ons the preparer has about anything in the RFP that was not clear. Proposal Acceptance and Approval By signing this document, everyone involved is in agreement that the proposal document is accurate and complete and is approved to move forward.

33 The Proposal The Proposed Project Team include the specific roles/posi6ons needed together with some high level qualifica6ons and skill sets. Individuals do not need to be iden6fied yet Costs and Payment Details contain high level es6mates based on the ini6al es6mates that were created during the concept phase or the budget informa6on contained in the RFP Terms and Condi)ons include some legal jargon that will most likely be supplied by your legal department. It will contain some disclaimers related the accuracy of the informa6on contained herein, together with contractual requirements for the approval to move forward with the project. Proposal Submission and Ques)ons include the contact informa6on of the proposal preparer, the date and 6me that the proposal was submiped, and the method of delivery. It will also include any ques6ons the preparer has about anything in the RFP that was not clear Proposal Acceptance and Approval By signing this document, everyone involved is in agreement that the proposal document is accurate and complete and is approved to move forward

34 Cost of proposal For large systems, the project proposal can cost a lot if details are required Some7me the client will pay certain amount

35 Green light The project can move to next stage The ini7al $ is in place However, we may start at different stages

36 Different Types of Project Stakeholders People/group/organiza7on who are involved, or have an interest in, the project or the outcome of the project End user/payer/payee/the marke7ng people/the support people Resources People/Equipment/Time/Money

37 Project Planning Project Activity and Risk Management Ø Ini7al Project Coordina5on and the Project Charter Ø Star7ng the Project Plan : the WBS Ø Human Resources : the RACI Matrix and Agile Projects Ø Interface Coordina7on through Integra5on Management Ø Project Risk Management CE PROJECT MANAGEMENT 37 L- 5

38 Project Management PMBOK Project Initiation

39 Project Management Processes (Initiation) Project Management Plan Ini7a7on Project Charter Project Scope Statement Scope (defini7on) WBS Cost (es7mates, ) Time (ac7vity diagrams, ) Human Resources (RACI matrix, ) Also to consider: Quality, Risk, Communication, Procurement, Integration (PMBOK knowledge areas)

40 Project Charter and Project Management Plan Terminology Terminology comes from the PMBOK but similar documents exist in any project. Other terms used: Project Charter: Project Initiation Document, Project Mandate, Project Brief, Letter of Agreement, Statement of Work Project Management Plan: Strategy Plan, Project Execution Plan, Project Plan

41 Project Charter and Project Management Plan The Main Concept Project Charter: Comes from outside the project and defines the project. Unchanged during the project. Project Management Plan: Owned by the project team. Constantly updated during the course of the project.

42 Two Processes in Project Initation Develop Project Charter Stakeholder Analysis

43 The Project Charter (Definition) The project charter is a document that formally recognizes the existence of a project. It describes the product to be delivered and addresses the business need of the project. The charter should be SMART: Specific Measurable Achievable Realistic Time-specific 43

44 The Project Charter (Definition) Typical contents: Project Title, Start & Finish Date Budget Informa5on Project Manager (contact address) Project Objec5ves Approach Roles and Responsibili5es (Sign off) Comments (from stakeholders) 44

45 Inputs to the PMBOK Process Develop Project Charter Project statement of work, Business Case and/or Contract Enterprise environmental factors Organizational process assets Reasons for projects: Business need Product scope description Strategic plan

46 Examples of Enterprise Environmental Factors Organizational or company culture and structure Infrastructure, for example, existing facilities and capital equipment Existing human resources Personnel administration (e.g. hiring and firing guidelines, employee performance reviews) Marketplace conditions

47 Organizational Process Assets Represents the organization s processes and procedures and the organization s learning and knowledge ( Lessons learned ), e.g. Organizational standard processes Standardized guidelines, templates, work instructions, evaluation criteria Project closure guidelines or requirements (e.g. audits) Financial control procedures Information about previous projects (and why they failed) Historical information (e.g. identified risk events)

48 Stakeholder Analysis Stakeholders are individuals, work groups and organizations that are actively involved in the project, or whose interests can be positively or negatively affected as the result of project execution or project completion. Stakeholder analysis serves two purposes: to determine the information needs of the various stakeholders. to devise a communication strategy that will best serve the project.

49 Typical Roles and Responsibilities of Stakeholders Project Sponsor the one with the money Senior Management e.g. priorities between projects, project charter Team Does Planning and Execution Functional Manager: owns resources (IT, marketing, etc.) Project Manager The individual responsible for the project Other Stakeholders Customer, external experts,

50 What is a project charter? Document issued by sponsor Authorizes existence of the project Provides project manager with authority Provides authority to apply resources to ac7vi7es Should provide ROI

51 The Charter and Organizational Strategy

52 Charters Tie Projects to Strategy Strategy seems lohy and out of reach for many project managers Whether to start a project or not is the most strategic decision in the project lifecycle Project managers best opportunity to engage in strategic choices is when wri7ng the charter

53 Tips to Tie Charter to Strategy Keep charter short and results- oriented Relate project to specific organiza7onal goals Specify methodologies and implementa7on in the plan, not the charter Read and reread organiza7on mission statements, and match them to your charters

54 The Moment of Opportunity Project manager can insist on charter at the moment of assignment Don t wait Don t give up the chance to say No Start your project as a professional, with a charter

55 Why Charters Appeal to Strategists Clear, simple statements of purpose First drahed before a penny has been spent Earliest opportunity to accelerate or halt the effort Breakthrough strategies ohen require projects for execu7on

56 Negotiating Using a Charter

57 How Do Project Managers Get Resources? Persuasion Boss Own staff and budget Sponsor The Charter

58 The Charter Answers Key Questions Who gave you the authority? How much authority did you get? Why is this so important? Any nego7ator, naysayer, or skep7c will ask these ques7ons

59 Negotiate Using the Charter Write the charter to be ac7on- oriented and specific Use the document as proof of authority See, the sponsor wants it done For the tough nego7a7ons, get as far as possible using persuasion and the charter, then pull in the sponsor

60 Processes, Policies, and Procedures for Charters

61 Charters Demonstrate Organizational Maturity Document decisions to authorize projects Clear star7ng point for planning processes Tie projects to organiza7onal strategy and plans Control authoriza7on of projects and alloca7on of resources to them

62 Sample Charter Process Idea Opportunity Document Chief Officer and other approvals Present to execu7ve commilee Approved opportuni7es are projects

63 BeneSits of a Formal Process Execu7ves decide early Start- up of new projects is controlled Authority is clear and well- documented Audit, financial, and governance controls are sa7sfied Pormolio of projects balanced and priori7zed

64 Project Scope Management

65 Learning Objectives Understand the elements that make good project scope management important. Explain the scope planning process and describe the contents of a scope management plan. Describe the process for developing a project scope statement using the project charter and preliminary scope statement. Discuss the scope defini7on process and work involved in construc7ng a work breakdown structure using the analogy, top- down, bolom- up, and mind- mapping approaches.

66 Learning Objectives Explain the importance of scope verifica7on and how it relates to scope defini7on and control. Understand the importance of scope control and approaches for preven7ng scope- related problems on informa7on technology projects. Describe how sohware can assist in project scope management.

67 What is Project Scope Management? Scope refers to all the work involved in crea7ng the products of the project and the processes used to create them. A deliverable is a product produced as part of a project, such as hardware or sohware, planning documents, or mee7ng minutes. Project scope management includes the processes involved in defining and controlling what is or is not included in a project.

68 Project Scope Management Processes Scope planning: Deciding how the scope will be defined, verified, and controlled. Scope defini5on: Reviewing the project charter and preliminary scope statement and adding more informa7on as requirements are developed and change requests are approved. Crea5ng the WBS: Subdividing the major project deliverables into smaller, more manageable components. Scope verifica5on: Formalizing acceptance of the project scope. Scope control: Controlling changes to project scope.

69 Scope Planning and the Scope Management Plan The scope management plan is a document that includes descrip7ons of how the team will prepare the project scope statement, create the WBS, verify comple7on of the project deliverables, and control requests for changes to the project scope. Key inputs include the project charter, preliminary scope statement, and project management plan.

70 Sample Project Charter

71 Sample Project Charter (cont d)

72 Scope DeSinition and the Project Scope Statement The preliminary scope statement, project charter, organiza7onal process assets, and approved change requests provide a basis for crea7ng the project scope statement. As 7me progresses, the scope of a project should become clearer and more specific.

73 Further DeSining Project Scope

74 Creating the Work Breakdown Structure (WBS) A WBS is a deliverable- oriented grouping of the work involved in a project that defines the total scope of the project. A WBS is a founda7on document that provides the basis for planning and managing project schedules, costs, resources, and changes. Decomposi5on is subdividing project deliverables into smaller pieces.

75 Sample Intranet WBS Organized by Product

76 Sample Intranet WBS Organized by Phase

77 Intranet WBS in Tabular Form 1.0 Concept 1.1 Evaluate current systems 1.2 Define requirements Define user requirements Define content requirements Define system requirements Define server owner requirements 1.3 Define specific functionality 1.4 Define risks and risk management approach 1.5 Develop project plan 1.6 Brief Web development team 2.0 Web Site Design 3.0 Web Site Development 4.0 Roll Out 5.0 Support

78 Intranet WBS and Gantt Chart in MS Project 2000

79 Intranet Gantt Chart Organized by Project Management Process Groups

80 Executing Tasks for JWD Consulting s WBS

81 Approaches to Developing WBSs Guidelines: Some organiza7ons provide guidelines for preparing WBSs. Analogy approach: Review WBSs of similar projects and tailor to your project. Top- down approach: Start with the largest items of the project and break them down. BoSom- up approach: Start with the specific tasks and roll them up. Mind- mapping approach: Write tasks in a non- linear, branching format and then create the WBS structure.

82 Sample Mind- Mapping Approach

83 Resulting WBS in Chart Form

84 The WBS Dictionary and Scope Baseline Many WBS tasks are vague and must be explained in more detail so people know what to do and can es7mate how long the work will take and what it will cost. A WBS dic5onary is a document that describes detailed informa7on about each WBS item. The approved project scope statement and its WBS and WBS dic7onary form the scope baseline, which is used to measure performance in mee7ng project scope goals.

85 Advice for Creating a WBS and WBS Dictionary* A unit of work should appear in only one place in the WBS. The work content of a WBS item is the sum of the WBS items below it. A WBS item is the responsibility of only one individual, even though many people may be working on it. The WBS must be consistent with the way in which work is actually going to be performed; it should serve the project team first, and other purposes only if prac7cal. *Cleland, David I., Project Management: Strategic Design and Implementation, 2 nd edition (New York: McGraw-Hill 1994).

86 Advice for Creating a WBS and WBS Dictionary (cont d)* Project team members should be involved in developing the WBS to ensure consistency and buy- in. Each WBS item must be documented in a WBS dic7onary to ensure accurate understanding of the scope of work that is included and not included in that item. The WBS must be a flexible tool to accommodate inevitable changes while properly maintaining control of the work content in the project according to the scope statement. *Cleland, David I., Project Management: Strategic Design and Implementation, 2 nd edition (New York: McGraw-Hill 1994).

87 Scope VeriSication It is very difficult to create a good scope statement and WBS for a project. It is even more difficult to verify project scope and minimize scope changes. Many projects suffer from scope creep and poor scope verifica7on (see What Went Wrong? ). FoxMeyer Drug filed for bankruptcy aher scope creep on a robo7c warehouse. Engineers at Grumman called a system Naziware and refused to use it. 21 st Century Insurance Group wasted a lot of 7me and money on a project that could have used off- the- shelf components.

88 Scope Control Scope control involves controlling changes to the project scope. Goals of scope control are to: Influence the factors that cause scope changes. Ensure changes are processed according to procedures developed as part of integrated change control. Manage changes when they occur. Variance is the difference between planned and actual performance.

89 Suggestions for Improving User Input Develop a good project selec7on process and insist that sponsors are from the user organiza7on. Place users on the project team in important roles. Hold regular mee7ngs with defined agendas, and have users sign off on key deliverables presented at mee7ngs. Deliver something to users and sponsors on a regular basis. Don t promise to deliver when you know you can t. Co- locate users with developers.

90 Suggestions for Reducing Incomplete and Changing Requirements Develop and follow a requirements management process. Use techniques such as prototyping, use case modeling to get more user involvement. Put requirements in wri7ng and keep them current. Create a requirements management database for documen7ng and controlling requirements.

91 Suggestions for Reducing Incomplete and Changing Requirements (cont d) Conduct adequate tes7ng throughout the project life cycle. Review changes from a systems perspec7ve. Emphasize comple7on dates to help focus on what s most important. Allocate resources specifically for handling change requests and enhancements

92 Using Software to Assist in Project Scope Management Word- processing sohware helps create scope- related documents. Spreadsheets help perform financial calcula7ons and weighed scoring models, and help develop charts and graphs. Communica7on sohware, such as e- mail and the Web, helps clarify and communicate scope informa7on. Project management sohware helps create a WBS, the basis for tasks on a Ganl chart. Specialized sohware is available to assist in project scope management.

93 Chapter Summary Project scope management includes the processes required to ensure that the project addresses all the work required and only the work required to complete the project successfully. Main processes include: Scope planning Scope defini7on WBS crea7on Scope verifica7on Scope control

94 Work Breakdown Structure (WBS) The WBS represents a logical decomposi7on of the work to be performed and focuses on how the product, service, or result is naturally subdivided. It is an outline of what work is to be performed. LEVEL ELEMENT DESCRIPTION 1 Project 2 Category 3 Subcategory 4 Sub-Subcategory 5 Work Package

95 Work Package

96 Deliverables and Milestones Deliverables Tangible, verifiable work products Reports, presenta7ons, prototypes, etc. Milestones Significant events or achievements Acceptance of deliverables or phase comple7on Cruxes (proof of concepts) Quality control Keeps team focused

97 Example of WBS: Holiday holiday passport travel documents tickets booking choose resort confirm household cat! Chapter 5 Planning insurance brochures 97

98 Developing the WBS

99 Example Work Breakdown Schedule

100 The WBS Should Follow the Work Package Concept

101 Developing the WBS The WBS Should Be Deliverable- Oriented The Level of Detail Should Support Planning and Control Developing the WBS Should Involve the People Who Will Be Doing the Work Learning Cycles and Lessons Learned Can Support the Development of a WBS

102 102

103 103

104 104

105 Responsibility Matrix Intersec7on of WBS and organiza7on structure Rows = persons or func7onal posi7ons Columns = work tasks or packages for which each personnel is responsible Useful for monitoring and control 105

106 106

107 107

108 108

109 Estimation Techniques - The Project Management Approach Guess7ma7ng Delphi Technique Time Boxing Top- Down Bolom Up Analogous Es7mates (Past experiences) Parametric Modeling (Sta7s7cal)

110 Project Es7ma7on Guess7ma7ng Based on feeling and not facts Not a good method for es7ma7ng but ohen used by inexperienced project managers Delphi Technique Involves mul7ple, anonymous experts Each expert makes an es7mate Es7mates compared If close, can be averaged Another itera7on un7l consensus is reached

111 Project Es7ma7on Time Boxing A box of 7me is allocated for a specific ac7vity, task, or deliverable Can focus a team if used effec7vely Can demoralize a team if used too ohen or ineffec7vely because of the increased stress or pressure on the project team to get things done

112 Project Es7ma7on Top- Down Es7ma7ng Top and middle managers determine overall project schedule and/or cost. Lower level managers are expected to breakdown schedule/budget es7mates into specific ac7vi7es (WBS). Ohen couched in terms of what a project should cost and how long it should take as decreed by a member of top management who thinks those parameters are appropriate. May be a response to the business environment. May lead to a death march project.

113 Project Es7ma7on Bolom- Up Es7ma7ng Most common form of project es7ma7on Schedules & budgets are constructed from the WBS Starts with people who will be doing the work Schedules & budgets are the aggregate of detailed ac7vi7es & costs

114 Project Es7ma7on Analogous es7ma7ng based on similarity between current projects and others Use informa7on from previous, similar projects as a basis for es7ma7on

115 Project Es7ma7on Parametric Modeling Use project characteris7cs (parameters) in a mathema7cal model to es7mate Example: $50/ LOC based on: Programming language Level of exper7se Size & complexity

116 Simple Work Breakdown Structure Project Task 1 Task 2 Task 3 Sub Task 1.1 Sub Task 1.2 Sub Task 1.3 Work Package Work Package Work Package 1.1.3

117 Simple Work Breakdown Structure Project Task 1 Task 2 Task 3 Sub Task 1.1 Sub Task 1.2 Sub Task 1.3 Work Package Work Package Work Package 1.1.3