Project Scope Management SEII - Lecture 4
Develop a good project selection process and insist that sponsors are from the user organization
Important roles in project teams
Regular meetings with defined agendas
Regular deliverables to users and sponsors
Don’t promise too much
Users and developers togather
24 trang |
Chia sẻ: dntpro1256 | Lượt xem: 665 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Project Scope Management SEII - Lecture 4, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Project Scope ManagementSEII-Lecture 4Dr. Muzafar KhanAssistant ProfessorDepartment of Computer ScienceCIIT, Islamabad.RecapRecent trends in IT projectsGlobalization, outsourcing, and virtual teamsProject management process groupsInitiating, planning, executing, monitoring and control, and closing processesProject integration managementKey processes and the relevant discussion2Project Scope ManagementScopeWork to be doneProductsProcessDeliverableProduct-relatedProcess-relatedStakeholders’ agreement3Main ProcessesProcesses to define, control, and decide workCollecting requirementsDefining scopeCreating the WBSVerifying scopeControlling scope4Collecting Requirements [1/4]Most difficultIf not properly defined; major reworkIEEE Standard [1990] definition“A condition or capability needed by a user to solve a problem or achieve an Objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. A documented representation of a condition or capability as in 1 or 2.”5Collecting Requirements [2/4]6Figure source: IT Project Management, K. Schwalbe, 6th ed., p. 180Collecting Requirements [3/4]Many TechniquesInterviewsFocus groupsWorkshopsSurveysObservationPrototypingEffort VS project size7Collecting Requirements [4/4]High level requirements from project charterA piece of paper to multi volume documentText, images, diagrams, and videos etc.Functional and non-functional requirementsRequirements management planAnalysis, documentation, managementRequirements traceability matrixRequirements, their attributes and status8Defining ScopeDefining the work required in detailGood scope definition – accurate estimate for time, cost, and other resourcesBaseline for performance measurement and project controlTechniques: expert judgment, product analysis, alternative identification, and facilitated workshopsMain output: project scope statement9Creating the WBS [1/2]Deliverable-oriented grouping of the workWBS – a foundation documentMain inputs: project scope statement, stakeholder requirements documentation, and organizational process assetsMain technique: decompositionMain outputs: WBS, WBS dictionary, scope baseline, and project document updates 10Creating the WBS [2/2]Task-oriented family tree of activitiesOrganized around project products, project phases, or process groupsWork package – task at the lowest levelDuration estimates for work packagesGood WBS needs good understanding11Sample WBS [1/3]12Figures source: IT Project Management, K. Schwalbe, 6th ed., p. 187-8Sample WBS [2/3]13Figure source: IT Project Management, K. Schwalbe, 6th ed., p. 188Sample WBS [3/3]14Figures source: IT Project Management, K. Schwalbe, 6th ed., p. 190Approaches for Developing WBS [1/4]Using guidelinesThe analogy approachThe top-down approachThe bottom-up approachThe mind-mapping approach15Approaches for Developing WBS [2/4]Using guidelinesIf guidelines exist then followFor example, US DODTemplates and past examplesAnalogy approachSimilar projectsRepository of WBSBetter understanding16Approaches for Developing WBS [3/4]Top-down approachConventional approachStart with the largest itemMust have vast technical insight and broad perspectiveBottom-up approachIdentify specific tasksAggregate these tasksVery time consumingNew systems/approaches17Approaches for Developing WBS [4/4]Mind-mapping approachLike brain stormingCore idea then branchesMore visual, less structuredIncreased creativity and participationUse of top-down and bottom-up approachesLater on any type of WBS i.e. chart or tabular form18Suggestions for Creating WBS [1/2]A unit of work at only one place The work content of a WBS item is the sum of the WBS items below itWBS item is the responsibility of only one individualWBS must be consistent with the work planned to be performedWBS should mainly serve the project team19Suggestions for Creating WBS [2/2]Project team members should be involved in developing the WBSEach WBS item must be documented in a WBS dictionary WBS must be a flexible tool to accommodate inevitable changes20Verifying ScopeDifficult to verify scope in IT projects and minimize scope changesScope creep – tendency for project scope to keep getting biggerFormal acceptanceMain inputs: project management plan, requirements documentation, validated deliverablesMain tool: inspectionMain outputs: accepted deliverables and change requests21Controlling ScopeControlling changes to the project scopeMain objective – to influence the factors that cause scope changesMain inputs: project management plan, work performance data, requirements documentationMain tool: variance analysisMain outputs: work performance measurements and change requests 22Suggestions to Improve User InputDevelop a good project selection process and insist that sponsors are from the user organizationImportant roles in project teamsRegular meetings with defined agendasRegular deliverables to users and sponsorsDon’t promise too muchUsers and developers togather23SummaryCollecting requirementsDifferent methodsDefining scopeEstimates for all resourcesCreating the WBSDifferent approachesVerifying scopeFormal acceptanceControlling scopeChange control24
Các file đính kèm theo tài liệu này:
- lecture_4_csc392_dr_muzafar_khan_8049_2027014.pptx