{"pageinfo":[{"Stamp":"pgo_4fa223da34380","Topic":"Scope Management","PageTo":"0","PageMark":"2","Header":{"PageNo":0,"Title":{"TitleText":"Scope Management"}},"Sections":{"Title":{"TitleText":"Gather Requirements","TitleAuthor":"K Srikanth, PMP"},"Matter":[{"Para":"Generally a Project Charter is said to contain brief scope of project. Scope is planned, examined and explored in detail during preparation of master plan or project management plan. Scope planning effort may vary in depth and details depending upon complexity of project. Understanding voice of customer or project requirements of the initiator is better gathered or collected if right mix of requirement illicitation methods are used such as grough-meeting, prototyping, survey, brainstorming sessions etc. Upon completion of requirement elicitation exercise Requirement Document is created which would contain Functional, Non-functional, and Traceability requirements as main sections apart from any other information on project requirements to help chart out further course of action including Requirements Management Plan (the way in which these requirements will be managed by the responsible authority).

e.g: Functional Requirements - 50 seater ofice space, 5 cabins, 1 conference & pantry room
e.g: Non-functional Requirements - Feel good factor, ease of access
e.g: Requirement Tracebility Information - Cabin Requirement -- Cabin Design -- Cabin Material Procurement -- Cabin Setup -- Cabin inspection -- Cabin Finish.<\/font>"}],"Subject":{"Related":"Requirement Elicitation Techniques"}},"Footer":{"PageNo":0,"Title":{"TitleText":"Scope Management"}}},{"Stamp":"pgo_4fa2251d614d9","Topic":"Scope Management","PageTo":"0","PageMark":"2","Header":{"PageNo":1,"Title":{"TitleText":"Scope Management"}},"Sections":{"Title":{"TitleText":"Define Project Scope Statement","TitleAuthor":"K Srikanth, PMP"},"Matter":[{"Para":"Business or Customer requirements are translated into more specific work statement by the performing team to have better technical understanding of the deliverables.

Various analysis may be performed by the performing team to present technical work components and express them as Project Scope Statement.

Project Scope Statement generally would have Introduction Summary, Product Scope ( The characteristics or features of final deliverable), Assumptions, Constraints, Boundaries (in scope - out scope), Acceptance criteria etc. Team employing various Analysis to arrive at Project Scope Statement could be Product Breakdown Analysis, Value Engineering (maximize profit minimize cost, e.g. reusable design), Value Analysis e.g: Cost of Quality (COQ) - Preventive vs Appraisal vs Rework cost. Project Scope Statement is verified with the project initiator or with responsible authority.<\/font>"}],"Subject":{"Related":"Product analysis, Technical analysis, Product Scope, Project Scope"}},"Footer":{"PageNo":1,"Title":{"TitleText":"Scope Management"}}},{"Stamp":"pgo_4fa2251d61732","Topic":"Scope Management","PageTo":"0","PageMark":"2","Header":{"PageNo":2,"Title":{"TitleText":"Scope Management"}},"Sections":{"Title":{"TitleText":"Baseline of Scope","TitleAuthor":"K Srikanth, PMP"},"Matter":[{"Para":"If requirements document is for the initiator help, Project Scope Statement is for the team implementing customer requirements, then for a project manager Work Breakdown Structure (WBS) is a tool for managing. WBS is graphical representation of logical grouping of work components. WBS is a hierachical structure like an inverted tree where each branch is a logical work component (mostly as deliverable work). As we further go down(decompose) sub branches finally we would arrive to the leaf work component. This leaf work component we call as Work Package (WP) is the end of WBS detailing. WP contain Project Time management planning aspects (essentially listing of physical activities within each WP). The WP which does not have information in detail can be called as Planning Package (yet to plan or room for progressive eloboration). The process of arriving from branch-to-sub branch further down to the leaf is called as Decomposition. Each WP is suppose to contain information of it called as WBS Dictionary e.g Budget, time frame, milestones, contrator info etc.

The decomposition is generally based on deliverable mindset e.g. 1.0 House Construction -- 1.1 Excavation, 1.2 Super structure, 1.3 Interior & Exterior. Once Work Packagers are ready, project manager baselines (finalizes) the Project Scope for execution \/ implementaion time inputs or for tracking. Each WP will have an unique identifier and is mapped to book of accounts (Chart of Accounts). Example, a work package called 1.1 Excavation may map to several account heads in accounting department records such as Transportation Cost, Printing and Stationary, Travel Expenses, etc. Control Account manager with a Control Account Plan records or monitors expenses against the budget.<\/font>"}],"Subject":{"Related":"Project organization chart, Control account, WBS Dictionary, Time Management Planning"}},"Footer":{"PageNo":2,"Title":{"TitleText":"Scope Management"}}},{"Stamp":"pgo_4fa2251d61964","Topic":"Scope Management","PageTo":"0","PageMark":"2","Header":{"PageNo":3,"Title":{"TitleText":"Scope Management"}},"Sections":{"Title":{"TitleText":"Verificaion of Scope","TitleAuthor":"K Srikanth, PMP"},"Matter":[{"Para":"As the Work Packages are built (which may mean part deliverables or final deliverable) initiator or respective authority is expected to validate or perform aceptance testing before signing as approved and fit to be as deliverables. e.g In a banking environment, ATM Machines can be pilot tested by the Bankers when ATM vendor handsover the ATM fully operational as claimed by vendor. If Project scope Statement parameters such acceptance criteria are met then it may be deemed to be delivered to the banker or ATM is verified by the banker.<\/font>"}],"Subject":{"Related":"Acceptance testing"}},"Footer":{"PageNo":3,"Title":{"TitleText":"Scope Management"}}},{"Stamp":"pgo_4fa2251d61b99","Topic":"Scope Management","PageTo":"0","PageMark":"2","Header":{"PageNo":4,"Title":{"TitleText":"Scope Management"}},"Sections":{"Title":{"TitleText":"Scope Change Management","TitleAuthor":"K Srikanth, PMP"},"Matter":[{"Para":"As a policy or project processes all changes has to be controlled including Scope changes. Scope changes can happen due to various resons or source. e.g During implementation the team can raise a scope change for achieving towards customer's project objective or the customer can introduce new wishlist upon verifying a deliverable. In any case the change request irrespective of the source should follow controlled change procedure or perform variance analysis (comparing planned vs present scope) or go through Change Control System (CCS) to avoid scope creep or to support meritorious scope change.

Scope change requests source can be from Team meetings, clarification with initiator, technical analysis, WBS or activity decomposition, implementation time, testing or inspections, risks response, functional change, during plan approvals, charter change (seldom) and any other sources.<\/font>"}],"Subject":{"Related":"Change control, change control system"}},"Footer":{"PageNo":4,"Title":{"TitleText":"Scope Management"}}},{"Stamp":"pgo_4faf0d2ae95a4","Topic":"Scope Management","PageTo":"0","PageMark":"2","Header":{"PageNo":5,"Title":{"TitleText":"Scope Management"}},"Sections":{"Title":{"TitleText":"PMBOK coverage","TitleAuthor":"K Srikanth, PMP"},"Matter":[{"Para":"Planning : Collect Requirements, Define Scope, Create WBS

Monitoring & Control : Verify Scope, Control Scope<\/font>"}],"Subject":{"Related":"PMBOK coverage"}},"Footer":{"PageNo":5,"Title":{"TitleText":"Scope Management"}}}]}