1、Effective Project Management: Traditional, Agile, ExtremePresented by(facilitator name)Managing Complexity in the Face of UncertaintyCh04: How to Scope a TPM ProjectnTools, templates, and processes to scope a projectnManaging client expectationsnConditions of satisfactionnThe project scoping meeting
2、nThe Requirements Breakdown StructurenBusiness process diagrammingnPrototyping your solutionnBusiness validationnChoosing a PMLC ModelnWriting the Project Overview StatementSummary of Chapter 4 Ch04: How to Scope a TPM ProjectnConditions of SatisfactionnProject Scoping MetingnRequirements Gatheringn
3、Diagramming Business ProcessesnPrototypingnValidating Business CasesnProject Overview StatementnApproval to Plan the ProjectTools, Templates, & Processes used to Scope a Project Ch04: How to Scope a TPM ProjectClient Wants vs. Client Needs DilemmaWhat your client wants may not be what your client ne
4、eds. Your job is to make sure that what they want is what they need and that you will deliver what they need.WANTSNEEDS Ch04: How to Scope a TPM ProjectnMake sure you understand what your client wants/needs/expectsnMake sure the client understands what you will donAssure yourself that what your clie
5、nt wants is what your client needsnActively include your client in scoping the projectnPut yourself in the shoes of your clientnMeaningfully involve your client wherever possiblenKeep your client informed of project statusTips to Managing Client Expectations During Scoping Ch04: How to Scope a TPM P
6、rojectProject Scoping ProcessFigure04-01 Ch04: How to Scope a TPM ProjectEstablishing Conditions of Satisfaction Negotiate agreement andwrite Project Overview StatementRequestResponse ClarifyRequest Agree onResponseFigure04-02 Ch04: How to Scope a TPM ProjectnPurposenDocument requirementsnProject Ov
7、erview StatementnAttendeesnProject ManagernClient GroupnCore Team MembersnThe Facilitator & TechnographerPlanning and Conducting the Project Scoping Meeting Ch04: How to Scope a TPM ProjectnAgendanIntroductionsnPurpose of the Meeting (led by Facilitator)nCOS (conduct or review if done earlier)nDescr
8、iption of current state (led by client representative)nDescription of problem or business opportunity (led by client representative)nDescription of end state (led by client representative)nRequirements definition and documentation (led by facilitator)nDiscussion of the gap between current and end st
9、ate (led by project manager)nChoose best-fit project management approach to close the gap (led by project manager)nDraft and approve the POS (whole scope planning group)nAdjournPlanning and Conducting the Project Scoping Meeting Ch04: How to Scope a TPM ProjectnDeliverablesnCOSnRequirements Document
10、nBest-fit project management life cycle (PMLC)nPOSPlanning and Conducting the Project Scoping Meeting Ch04: How to Scope a TPM ProjectA requirement is something the product/project shoulddo/produce or a quality that it must have. What Are Requirements? Ch04: How to Scope a TPM ProjectnFacilitated Gr
11、oup SessionnInterviewnObservationnRequirements ReusenBusiness Process DiagrammingnPrototypingnUse CasesApproaches to Requirements Gathering Ch04: How to Scope a TPM ProjectStrengths1.Excellent for cross-functional processes2.Detailed requirements are documented and verified immediately3.Resolves iss
12、ues with an impartial facilitator Facilitated Group Session MethodRisks1.Untrained facilitators can lead to negative responses2.Time and cost of planning and executing can be high Table04-01 Ch04: How to Scope a TPM ProjectStrengths1.End-user participation2.High-level description of functions and pr
13、ocesses provided Interview MethodRisks1.Descriptions may differ from actual detailed activities2.Without structure, stakeholders may not know what information to provide3.Real needs ignored if analyst is prejudiced Table04-01 Ch04: How to Scope a TPM ProjectStrengths1.Specific/complete descriptions
14、of actions provided2.Effective when routine activities are difficult to describe Observation MethodRisks1.Documenting and videotaping may be time-consuming, expensive, and have legal overtones2.Confusing/conflicting information must be clarified3.Misinterpretation of what is observed Table04-01 Ch04
15、: How to Scope a TPM ProjectStrengths1.Requirements quickly generated/refined2.Redundant efforts reduced3.Client satisfaction enhanced by previous proof4.Quality increase5.Reinventing the wheel minimized Requirements Reuse MethodRisks1.Significant investment to develop archives, maintenance, and lib
16、rary functions2.May violate intellectual rights of previous owner3.Similarity may be misunderstood Table04-01 Ch04: How to Scope a TPM ProjectStrengths1.Excellent for cross-functional processes2.Visual communications3.Verification of “what is/what is not” Business Process DiagrammingRisks1.Implement
17、ation of improvement is dependent on an organization open to change2.Good facilitation, data gathering, and interpretation required3.Time-consuming Table04-01 Ch04: How to Scope a TPM ProjectStrengths1.Innovative ideas can be generated2.Users clarify what they want 3.Users identify requirements that
18、 may be missed4.Client-focused5.Early proof of concept6.Stimulates thought processPrototypingRisks1.Client may want to implement prototype2.Difficult to know when to stop3.Specialized skills required4.Absence of documentationTable04-01 Ch04: How to Scope a TPM ProjectStrengths1.State of system descr
19、ibed before entering the system2.Completed scenarios used to describe state of system3.Normal flow of event/exceptions revealed4.Improved client satisfaction and design.User Case ScenariosRisks1.Newness has resulted in some inconsistencies2.Information may still be missing from scenario description3
20、.Long interaction required4.Training expensiveTable04-01 Ch04: How to Scope a TPM ProjectBuilding the Requirements Breakdown Structure Figure04-03 Ch04: How to Scope a TPM ProjectProject goaland solution Requirement 1Function1.1Feature1.2.1.1Featuren.3.1Sub-function1.2.3Requirement nFunction1.2Funct
21、ion1.3Functionn.1Functionn.2Functionn.3Sub-function1.2.2Sub-function1.2.1Featuren.3.2Featuren.3.3Featuren.3.4Feature1.2.1.2Feature1.2.1.3Feature1.2.1.4RBS The Reality FunctionalRequirement n Ch04: How to Scope a TPM ProjectnThe RBS is intuitive and most meaningful to the client nThe RBS is a deliver
22、ables-based approachnThe RBS is consistent with the PMI PMBOKnThe RBS remains client-facing as long as possible into the planning exerciseCharacteristics of the RBS Ch04: How to Scope a TPM ProjectnDoes not require a trained facilitatornDoes not require learning one of the contemporary approaches to
23、 requirements gatheringnPresents an intuitive approach to gathering requirementsnAllows the client to work with the project team in an environment familiar to them, i.e., to stay in their own comfort zonenPaints a clear picture of the degree to which the solution is clearly definednProvides the inpu
24、t needed to choose the best fit PMLC modelAdvantages of using the RBS Ch04: How to Scope a TPM ProjectnCompleteness Are the requirements essentially complete or are some missing?nClarity Are the requirements clear? Are they ambiguous or imprecise?nValidity Do the requirements reflect client intentio
25、ns?nMeasurability Does the requirement have a fit criterion (measurement)?nTestability Can the criterion be used to test whether the requirement provides the solution?Verifying Attributes Ch04: How to Scope a TPM ProjectnMaintainability Will the implementation be difficult or easy to understand or m
26、aintain?nReliability Can the reliability and availability requirements be met?nLook and Feel Have all human factors been met (GUI, ergonomics, etc.)?nFeasibility Can the requirements be implemented?nPrecedent Has a requirement similar to this been implemented before?Verifying Attributes (continued)
27、Ch04: How to Scope a TPM ProjectnScale Are the requirements large and/or complex?nStability How often and to what degree might the requirements change?nPerformance Can the performance be met on a consistent basis?nSafety Can the safety requirements be fully demonstrated?nSpecifications Is the docume
28、ntation adequate to design, implement, and test the system? Verifying Attributes (continued) Ch04: How to Scope a TPM ProjectnNot always obviousnCome from many sourcesnNot always easy to express clearly in wordsnMany different types of requirements at different levels of detailnNumber of requirement
29、s can become unmanageable if not controllednRequirements are not independent and may create conflict situationsnMany interested and responsible parties nChange as a result of changing business conditionsnCan be time-sensitiveThe Challenge of Requirements Management Ch04: How to Scope a TPM ProjectWh
30、at to do to get requirements gathering started Diagramming business processes Prototyping Business validationSometimes 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 ProjectA bu
31、siness 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 stateBusiness ProcessInput BInput CInput AFigure04-04 Ch04: How to Scope a TPM ProjectWhat is a B
32、usiness Process?Figure04-05 Ch04: How to Scope a TPM ProjectThe Top-Down, Left-to-Right FormatFigure04-06 Ch04: How to Scope a TPM ProjectThe Swim-Lane FormatFigure04-07 Ch04: How to Scope a TPM ProjectContext Diagramming ProcessFigure04-08 Ch04: How to Scope a TPM ProjectWhat is a Business Process?
33、Figure04-09 Ch04: How to Scope a TPM ProjectWhat is a Business Process?Figure04-10 Ch04: How to Scope a TPM ProjectnFunctionalnNon-functionalnGlobalnProduct/project constraintsCategories of Requirements Ch04: How to Scope a TPM ProjectFunctional requirements specify what the product orservice must d
34、o. Definition: Functional RequirementGive an example of a functional requirement. Ch04: How to Scope a TPM ProjectNon-functional requirements demonstrate properties that the product or service should have in order to dowhat must be done. Definition: Non-Functional RequirementGive an example of a non
35、-functional requirement. Ch04: How to Scope a TPM ProjectGlobal requirements describe the highest level of requirements within the system or product. They can bethought of as general requirements.Definition: Global RequirementGive an example of a global requirement. Ch04: How to Scope a TPM ProjectP
36、roduct/project constraints are those requirements that,on the surface, resemble design constraints or projectconstraints. Definition: Product/Project ConstraintsGive an example of a product/project constraint. Ch04: How to Scope a TPM ProjectHints on deciding which PMLC Model to use The degree to wh
37、ich 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 v
38、alue. Senior managers might prefer this. Ch04: How to Scope a TPM ProjectWhen to use each PMLC ModelPMLC Model TypeWhen to Use ItLinearThe solution and requirements are clearly defined.You do not expect too many scope change requests.The project is routine and repetitive.You can use established temp
39、lates.IncrementalSame conditions as the Linear approach, but the client wants to deploy business value incrementally.There may be some likelihood of scope change requests.IterativeYou feel that requirements are not complete or may change.You will learn about remaining requirements in the course of d
40、oing the project.Some features of the solution are not yet identified.AdaptiveThe solution and requirements are only partially known.There may be functionality that is not yet identified.There will be a number of scope changes from the client.The project is oriented to new product development or pro
41、cess improvement.The development schedule is tight and you cant afford rework or re-planning.ExtremeThe goal and solution are not clearly known.The project is an R & D type project.Table04-02 Ch04: How to Scope a TPM ProjectA general statement of the projectA reference for the planning teamA decisio
42、n aid for the projectTo get management approval to plan the project Purpose of the Project Overview StatementPOSsA one-page description that is: Ch04: How to Scope a TPM ProjectContents of the Project Overview Statement Ch04: How to Scope a TPM ProjectPROJECT OVERVIEWSTATEMENTProject NameProject No.
43、Project ManagerProblem/OpportunityGoalObjectivesSuccess CriteriaAssumptions, Risks, ObstaclesPrepared ByDateApproved ByDateOffice Supply Cost Reduction PAUL BEAREROur cost reduction task force reports that office supply expenses have exceeded budget by anaverage of 4% for each of the last three fisc
44、al years. In addition an across the board budget cut of2% has been announced and there is an inflation rate of 3% estimated for the year.To implement a cost containment program that will result in office supply expenses being withinbudget by the end of the next fiscal year.1. Establish a departmenta
45、l office supply budgeting and control system.2. Implement a central stores for office and copying supplies.3. Standardize the types and brands of office supplies used by the company.4. Increase employee awareness of copying practices that can reduce the cost of meeting their copying needs.1. The tot
46、al project cost is less than 4% of the current year office supply budget.2. At least 98% of office supply requests are filled on demand.3. At least 90% of the departments have office supply expenses within budget.4. No department office supply expense exceeds budget by more than 4%.1. Central stores
47、 can be operated at or below the breakeven point.2. Users will be sensitive to and supportive of the cost containment initiatives.3. Equitable office supply budgets can be established.4. Management will be supportive and consistent.5. The existing inventory control system can support the central sto
48、res operation.Olive BranchDel E. Lama9/2/119/3/04Example POSFigure04-11 Ch04: How to Scope a TPM ProjectPOS Problem/OpportunityA 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
49、proposed project will be based. Ch04: How to Scope a TPM ProjectPOS Project GoalA 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 ProjectPOS Project Objectives 5 or 6 brie
50、f 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 ProjectP
