有效的项目管理在传统项目管理中如何界定范围课件.ppt

Effective Project Management: Traditional, Agile, Extreme,Presented by(facilitator name),Managing Complexity in the Face of Uncertainty,Ch04: How to Scope a TPM Project,Tools, templates, and processes to scope a projectManaging client expectationsConditions of satisfactionThe project scoping meetingThe Requirements Breakdown StructureBusiness process diagrammingPrototyping your solutionBusiness validationChoosing a PMLC ModelWriting the Project Overview Statement,Summary of Chapter 4,Ch04: How to Scope a TPM Project,Conditions of SatisfactionProject Scoping MetingRequirements GatheringDiagramming Business ProcessesPrototypingValidating Business CasesProject Overview StatementApproval to Plan the Project,Tools, Templates, & Processes used to Scope a Project,Ch04: How to Scope a TPM Project,Client Wants vs. Client Needs Dilemma,What your client wants may not be what your client needs. Your job is to make sure that what they want is what they need and that you will deliver what they need.,Ch04: How to Scope a TPM Project,Make sure you understand what your client wants/needs/expectsMake sure the client understands what you will doAssure yourself that what your client wants is what your client needsActively include your client in scoping the projectPut yourself in the shoes of your clientMeaningfully involve your client wherever possibleKeep your client informed of project status,Tips to Managing Client Expectations During Scoping,Ch04: How to Scope a TPM Project,Project Scoping Process,Figure04-01,Ch04: How to Scope a TPM Project,Establishing Conditions of Satisfaction,Figure04-02,Ch04: How to Scope a TPM Project,PurposeDocument requirementsProject Overview StatementAttendeesProject ManagerClient GroupCore Team MembersThe Facilitator & Technographer,Planning and Conducting the Project Scoping Meeting,Ch04: How to Scope a TPM Project,AgendaIntroductionsPurpose of the Meeting (led by Facilitator)COS (conduct or review if done earlier)Description of current state (led by client representative)Description of problem or business opportunity (led by client representative)Description of end state (led by client representative)Requirements definition and documentation (led by facilitator)Discussion of the gap between current and end state (led by project manager)Choose best-fit project management approach to close the gap (led by project manager)Draft and approve the POS (whole scope planning group)Adjourn,Planning and Conducting the Project Scoping Meeting,Ch04: How to Scope a TPM Project,DeliverablesCOSRequirements DocumentBest-fit project management life cycle (PMLC)POS,Planning and Conducting the Project Scoping Meeting,Ch04: How to Scope a TPM Project,A requirement is something the product/project shoulddo/produce or a quality that it must have.,What Are Requirements?,Ch04: How to Scope a TPM Project,Facilitated Group SessionInterviewObservationRequirements ReuseBusiness Process DiagrammingPrototypingUse Cases,Approaches to Requirements Gathering,Ch04: How to Scope a TPM Project,StrengthsExcellent for cross-functional processesDetailed requirements are documented and verified immediatelyResolves issues with an impartial facilitator,Facilitated Group Session Method,RisksUntrained facilitators can lead to negative responsesTime and cost of planning and executing can be high,Table04-01,Ch04: How to Scope a TPM Project,StrengthsEnd-user participationHigh-level description of functions and processes provided,Interview Method,RisksDescriptions may differ from actual detailed activitiesWithout structure, stakeholders may not know what information to provideReal needs ignored if analyst is prejudiced,Table04-01,Ch04: How to Scope a TPM Project,StrengthsSpecific/complete descriptions of actions providedEffective when routine activities are difficult to describe,Observation Method,RisksDocumenting and videotaping may be time-consuming, expensive, and have legal overtonesConfusing/conflicting information must be clarifiedMisinterpretation of what is observed,Table04-01,Ch04: How to Scope a TPM Project,StrengthsRequirements quickly generated/refinedRedundant efforts reducedClient satisfaction enhanced by previous proofQuality increaseReinventing the wheel minimized,Requirements Reuse Method,RisksSignificant investment to develop archives, maintenance, and library functionsMay violate intellectual rights of previous ownerSimilarity may be misunderstood,Table04-01,Ch04: How to Scope a TPM Project,StrengthsExcellent for cross-functional processesVisual communicationsVerification of “what is/what is not”,Business Process Diagramming,RisksImplementation of improvement is dependent on an organization open to changeGood facilitation, data gathering, and interpretation requiredTime-consuming,Table04-01,Ch04: How to Scope a TPM Project,StrengthsInnovative ideas can be generatedUsers clarify what they want Users identify requirements that may be missedClient-focusedEarly proof of conceptStimulates thought process,Prototyping,RisksClient may want to implement prototypeDifficult to know when to stopSpecialized skills requiredAbsence of documentation,Table04-01,Ch04: How to Scope a TPM Project,StrengthsState of system described before entering the systemCompleted scenarios used to describe state of systemNormal flow of event/exceptions revealedImproved client satisfaction and design.,User Case Scenarios,RisksNewness has resulted in some inconsistenciesInformation may still be missing from scenario descriptionLong interaction requiredTraining expensive,Table04-01,Ch04: How to Scope a TPM Project,Building the Requirements Breakdown Structure,Figure04-03,Ch04: How to Scope a TPM Project,RBS The Reality,Ch04: How to Scope a TPM Project,The RBS is intuitive and most meaningful to the client The RBS is a deliverables-based approachThe RBS is consistent with the PMI PMBOKThe RBS remains client-facing as long as possible into the planning exercise,Characteristics of the RBS,Ch04: How to Scope a TPM Project,Does not require a trained facilitatorDoes not require learning one of the contemporary approaches to requirements gatheringPresents an intuitive approach to gathering requirementsAllows the client to work with the project team in an environment familiar to them, i.e., to stay in their own comfort zonePaints a clear picture of the degree to which the solution is clearly definedProvides the input needed to choose the best fit PMLC model,Advantages of using the RBS,Ch04: How to Scope a TPM Project,Completeness Are the requirements essentially complete or are some missing?Clarity Are the requirements clear? Are they ambiguous or imprecise?Validity Do the requirements reflect client intentions?Measurability Does the requirement have a fit criterion (measurement)?Testability Can the criterion be used to test whether the requirement provides the solution?,Verifying Attributes,Ch04: How to Scope a TPM Project,Maintainability Will the implementation be difficult or easy to understand or maintain?Reliability Can the reliability and availability requirements be met?Look and Feel Have all human factors been met (GUI, ergonomics, etc.)?Feasibility Can the requirements be implemented?Precedent Has a requirement similar to this been implemented before?,Verifying Attributes (continued),Ch04: How to Scope a TPM Project,Scale Are the requirements large and/or complex?Stability How often and to what degree might the requirements change?Performance Can the performance be met on a consistent basis?Safety Can the safety requirements be fully demonstrated?Specifications Is the documentation adequate to design, implement, and test the system?,Verifying Attributes (continued),Ch04: How to Scope a TPM Project,Not always obviousCome from many sourcesNot always easy to express clearly in wordsMany different types of requirements at different levels of detailNumber of requirements can become unmanageable if not controlledRequirements are not independent and may create conflict situationsMany interested and responsible parties Change as a result of changing business conditionsCan be time-sensitive,The Challenge of Requirements Management,Ch04: How to Scope a TPM Project,What to do to get requirements gathering started,Diagramming business processes Prototyping Business validation,Sometimes the client has trouble envisioning a solution or senior management is not convinced that this project makes business sense.If so, then consider:,Ch04: How to Scope a TPM Project,A business process is a collection of activities that takeone or more inputs from one or more different sourcesand produces a change of state that delivers businessvalue.,What is a Business Process?,Changeof state,Business Process,Input B,Input C,Input A,Figure04-04,Ch04: How to Scope a TPM Project,What is a Business Process?,Figure04-05,Ch04: How to Scope a TPM Project,The Top-Down, Left-to-Right Format,Figure04-06,Ch04: How to Scope a TPM Project,The Swim-Lane Format,Figure04-07,Ch04: How to Scope a TPM Project,Context Diagramming Process,Figure04-08,Ch04: How to Scope a TPM Project,What is a Business Process?,Figure04-09,Ch04: How to Scope a TPM Project,What is a Business Process?,Figure04-10,Ch04: How to Scope a TPM Project,FunctionalNon-functionalGlobalProduct/project constraints,Categories of Requirements,Ch04: How to Scope a TPM Project,Functional requirements specify what the product orservice must do.,Definition: Functional Requirement,Give an example of a functional requirement.,Ch04: How to Scope a TPM Project,Non-functional requirements demonstrate properties that the product or service should have in order to dowhat must be done.,Definition: Non-Functional Requirement,Give an example of a non-functional requirement.,Ch04: How to Scope a TPM Project,Global requirements describe the highest level of requirements within the system or product. They can bethought of as general requirements.,Definition: Global Requirement,Give an example of a global requirement.,Ch04: How to Scope a TPM Project,Product/project constraints are those requirements that,on the surface, resemble design constraints or projectconstraints.,Definition: Product/Project Constraints,Give an example of a product/project constraint.,Ch04: How to Scope a TPM Project,Hints on deciding which PMLC Model to use,The degree to which the RBS is complete is the major factor in deciding which PMLC model to use. Consider using the highest level of decomposition in the Objective section of the POS and leaving creation of the RBS and WBS for the Planning Phase. The highest level requirements could be those that deliver business value. Senior managers might prefer this.,Ch04: How to Scope a TPM Project,When to use each PMLC Model,Table04-02,Ch04: How to Scope a TPM Project,A general statement of the projectA reference for the planning teamA decision aid for the projectTo get management approval to plan the project,Purpose of the Project Overview Statement,POSs,A one-page description that is:,Ch04: How to Scope a TPM Project,Contents of the Project Overview Statement,Ch04: How to Scope a TPM Project,Example POS,Figure04-11,Ch04: How to Scope a TPM Project,POS Problem/Opportunity,A problem needing resolution or an untapped business opportunity. A statement of fact that everyone would agree to. It stands on its own.This is the foundation on which the proposed project will be based.,Ch04: How to Scope a TPM Project,POS Project Goal,A one or two sentence statement of how you intend to address the statedproblem/opportunity.A scoping statement that bounds the project you are proposing.,Ch04: How to Scope a TPM Project,POS Project Objectives,5 or 6 brief statements that further bound your project goal statement. From these statements it is clear what is in and not in the proposed project. These statements might identify major project deliverables. These statements form a necessary and sufficient set of objectives.,Ch04: How to Scope a TPM Project,POS Project Success Criteria,IRACISIRIncrease RevenueACAvoid CostsISImprove Service,Use quantitative metrics only!How much and by when?,Ch04: How to Scope a TPM Project,TechnologicalNew to the companyObsolescenceEnvironmentalManagement changeStaff turnoverInterpersonalWorking relationshipsCulturalFit to the companyCausal RelationshipsWill the solution solve the problem,POS Assumptions, Risks, and Obstacles,Ch04: How to Scope a TPM Project,Risk AnalysisFinancial AnalysesFeasibility studiesCost/benefit analysisBreakeven analysisReturn on inverstment,POS Attachments,Ch04: How to Scope a TPM Project,Expected Review Questions from ManagementHow important is the problem or opportunity to the organization?How is the project related to our CSFs?Does the goal statement related directly to the problem or opportunity?Are the objectives clear representations of the goal statement?Is there sufficient business value as measured by the success criteria to warrant further expenditures on this project?Is the relationship between the project objectives and the success criteria clearly established?Are the risks too high and the business value too low?Can senior management mitigate the identified risks?,Gaining Approval to Plan the Project,Ch04: How to Scope a TPM Project,Core project teamProject teamProject managerResource managersFunction/process managersClientSenior management,Participants in the Approval Process,Ch04: How to Scope a TPM Project,