Project Charter high level scope

By Marion Murphy,2014-01-12 03:24
6 views 0
Project Charter high level scope

     PMI I80 Breakfast Roundtable December 2006 Meeting Topic

The following content has been extracted from:

     The Project Management Institute Practice Standard for Work Break Down Structures

     The PMBOK? Guide 2000 Edition

1.0 Project Charter (high level scope)

     2.0 Statement of Scope (breaks down the high level scope defined in the charter)

    3.0 Work Breakdown Structure is used to define project scope and to estimate to a cost and time

     level (in terms of work packets)

     5.0 Project tasks and schedule defined.

The WBS as defined in the PMBOK? Guide 2000 Edition is:

     A deliverable-oriented grouping of project elements that organizes and defines the

     total work scope of the project. Each descending level represents an increasingly

     detailed definition of the project work (Project Management Institute 2000)

The WBS is used in projects to define

     The project’s work in terms of deliverables (a measurable, tangible, verifiable outcome or result

    that must be produced to complete a project or part of a project) and further decomposition of these

    deliverables into components. Depending on the decomposition method used, it may also define the

    project’s life-cycle process in terms of process deliverables appropriate to that project and organization

    And is the basis for establishing:

    o All the effort/cost to be expended on supporting processes and the creation of the deliverables.

    o The assigned responsibility for accomplishing and coordinating the work.

The two goals of the WBS are:

    ; To ensure that the project includes all the work needed.

    ; To ensure that the project includes no unnecessary work.

The WBS is the primary Input to four core processes and one facilitating process:

     Activity Definition

     Resource Planning

     Cost Estimating

     Cost Budgeting

     Risk Management Planning

The WBS also serves to facilitate communication between the Project Manager and all Project

    Stakeholders (regarding scope, dependencies, risk, progress and performance).

    The WBS provides the project management team with a framework on which to base project status and progress reporting.

    Preparing a WBS

     The WBS evolves through an iterative consideration of:

    ; The project’s purpose and objectives

    ; The functional/performance design criteria

    ; The project scope

    ; The technical performance requirements

    ; Other technical attributes.

    A high level WBS can often be developed early in the conceptual stage of the project. Once the project is defined and specifications are prepared, a more detailed WBS can be developed.

     The following should stimulate thought when developing a WBS to manage the project: ; Think through the entire project (What is to be provided /what is required)? ; Think deliverables (What is to be provided/what is required?)

    ; Think with the end in mind. (How will this component contribute to the finished


    ; Think through the production of the deliverables.

     What methods will be used?

     What special processes?

     What quality requirements?

     What inspections?


    ; What are the constituent parts?

    ; How do the pieces work together?

    ; What needs to be done?

     Factors to be considered

    ; Each WBS element should represent a single tangible deliverable.

    ; Each WBS element should represent an aggregation of all subordinate WBS elements

    listed below it.

    ; Each subordinate WBS element must belong to only one single parent (or superior) WBS


    ; The deliverable should be logically decomposed to the level that represents how they will

    be produced (designed, purchased, subcontracted, fabricated). The portioning of

    deliverables from higher levels within the WBS to lower levels must be logically related. ; Deliverables must be unique and distinct from their peers, and should be decomposed to

    the level of detail needed to plan and manage the work to obtain or create them. ; Deliverables should be clearly defined to eliminate duplication of effort within WBS

    elements, across organizations , or between individuals responsible for completing the


    ; Deliverables should be limited in size and definition for effective controlbut no so small

    as to make cost of control excessive and not so large as to make the item unmanageable or

    the risk unacceptable.

    ; The WBS development process should provide a vehicle for flexibility, particularly when

    the scope of the project effort may change. A well-managed project, however will

    incorporate a rigorous change control processs to document and manage scope changes.

    When work scope changes do take place, the WBS must be updated.

    ; Each entry in the WBS representing subcontracted or externally committed deliverables

    should directly correspond to matching entries in the subcontractor’s WBS.

    ; All deliverables are explicitly included in the WBS.

    ; All significant reporting items (e.g. review meetings, monthly reports, test reports, and so

    on) are included and identified in the WBS.

    ; All WBS elements should be compatible with organizational and accounting structures. ; A coding scheme for WBS elements that clearly represents the hierarchical structure when

    viewed in text format should be used.

    ; Technical input should be obtained from knowledable technical subject matter experts

    (SMEs) , and communicated to and validated by other key SMEs assigned to the project.

Report this document

For any questions or suggestions please email