Goals breakdown structure

Last updated

The goals breakdown structure (GBS) is a hierarchical structure linking high-level objectives or goals to more detailed goals. The GBS was originally developed for project management, but applies to product development and the organization as a whole. The concept is based on the Work Breakdown Structure (WBS) popular in the project management discipline. Like the WBS, project goals exhibit a hierarchical structure. The highest-level defines the overall goal or mission for the project. The next level down sets the goals the organization intends to achieve from the project. These might include such items as profit, market share, etc. The next layer down defines the features the products must exhibit to achieve the organization's goals. The next layer down defines the specifications each product or component of the product must have to meet the products features.

Contents

It also follows similar rules as the WBS as noted by the Project Management Institute's standard for project management, A Guide to the Project Management Body of Knowledge (PMBOK) [1] Similar to the WBS, the purpose of the GBS is to define all the goals and only the goals in a project needed to achieve the project's higher-level goals.

History

The GBS is the culmination of three concepts: the hierarchical relationship of product development, the work breakdown structure and requirements traceability.

The concept of a hierarchical relationship among objectives in product development was identified by Joseph M. Juran in Juran's Quality Control Handbook [2] where he states in section 2.2, subsection Hierarchy of Product Features, "Products exist in a sort of hierarchical or pyramidal organization. At the apex is the overall product or system. Below the apex are multiple layers made up of subsystems, components, etc. At each layer, the products have features which must be defined by specifications and procedures." The project work that creates the product, therefore, contains similar characteristics.

Requirements traceability also became popular in the mid 1980s, particularly regarding medium and large-scale government projects. The idea of requirements traceability is to demonstrate the need for a particular project requirement or work element by showing how it is needed to achieve particular goals.

The work breakdown structure is a hierarchical decomposition of the work to be done in a project.

The term "goal breakdown structure" was coined by Stephen Gershenson, working with Michael B Bender and Stuart Syme in the late 1990s. The concept was first presented in project management seminars during this period. The first publication introducing the GBS was in Bender's first book: Setting Goals and Expectations. [3] Bender embellished on the topic in his second book, A Manager's Guide to Project Management [4] In the latter publication, Bender expanded the concept to apply to the organization as a whole, based partly on the works of David P. Norton and Robert S. Kaplin in The Balanced Scorecard. [5]

Structure and rules

Rules

The GBS follows two rules for decomposition.

  1. Nothing missing. Each layer must contain all the goals needed to ensure the project achieves the next higher level goals.
  2. Nothing extra. No layer should contain any extraneous goals; goals not needed to achieve the layer above.

The first rule ensures success of the layer above. The second rule prevents the project from exhibiting extra scope and work that doesn't add value to the organization, saving time and money.

Structure

While the specific implementation of the GBS may vary from project to project, the classic implementation contains four layers or tiers. These are:

Project goal or mission statement

In the original work, the highest level of the goals breakdown structure is the project's goal or mission statement. This layer exhibits slightly different characteristics to the other tiers as its primary objective differs. The goal of the project mission or goal statement is to maintain the focus of the project team and stakeholders. Therefore, it is the one layer of the GBS that is not all-inclusive (it violates the Nothing Missing rule).

Business objectives

The next layer down contains the business objectives for the project. This is a list of objectives the organization's senior management expects from the project. Often, these objectives tie directly to the organization's strategic plan and include such items as: Return on Investment (ROI), Net Present Value (NPV), market share, efficiency improvement, etc. This is the first layer that must satisfy both rules.

Project requirements

The third tier contains the project's requirements. This is a list of both project and product characteristics required to achieve the business objectives. These include all the features, functions and characteristics that the project's deliverables must exhibit to achieve the business objectives. This also includes all the project's operational requirements and constraints needed by senior management. For larger programs, this tier may contain more than one layer. For example:

  • Program layer
    • Project layer
      • Sub-project layer

Product specifications

This tier identifies all the specifications for the project's products. This tier may contain more than one layer as show below:

  • Product specifications
    • Component specifications
      • Sub-component specifications

Notes

  1. ↑ Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th edition, 2012
  2. ↑ Juran, J.M., and Gryna, Frank M.; "Juran's Quality Control Handbook", 4th Edition, McGraw-Hill, Inc., 1988
  3. ↑ Bender, Michael B, Setting Goals and Expectations, Virtualbookworm Press, 2004
  4. ↑ Bender, Michael B, A Manager's Guide to Project Management, Financial Times Press, 2010
  5. ↑ Kaplin, Robert S. and Norton, David P; The Balanced Scorecard, Harvard Business School Press, 1996

Related Research Articles

Project management is the process of leading the work of a team to achieve all project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, and budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives.

<span class="mw-page-title-main">Work breakdown structure</span> A deliverable-orientated breakdown of a project into smaller components.

A work-breakdown structure (WBS) in project management and systems engineering is a deliverable-oriented breakdown of a project into smaller components. A work breakdown structure is a key project management element that organizes the team's work into manageable sections. The Project Management Body of Knowledge defines the work-breakdown structure as a "hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables."

A project plan, according to the Project Management Body of Knowledge (PMBOK), is: "...a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among project stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be sumarized or detailed."

<span class="mw-page-title-main">Project Management Body of Knowledge</span> Body of knowledge for project management

The Project Management Body of Knowledge (PMBOK) is a set of standard terminology and guidelines for project management. The body of knowledge evolves over time and is presented in A Guide to the Project Management Body of Knowledge, a book whose seventh edition was released in 2021. This document results from work overseen by the Project Management Institute (PMI), which offers the CAPM and PMP certifications.

In project management under the PRINCE2 methodology, a product breakdown structure (PBS) is a tool for analysing, documenting and communicating the outcomes of a project, and forms part of the product based planning technique.

Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which consists of both design documentation and undocumented concepts.

<span class="mw-page-title-main">Project manager</span> Professional in the field of project management

A project manager is a professional in the field of project management. Project managers have the responsibility of the planning, procurement and execution of a project, in any undertaking that has a defined scope, defined start and a defined finish; regardless of industry. Project managers are first point of contact for any issues or discrepancies arising from within the heads of various departments in an organization before the problem escalates to higher authorities, as project representative.

Quality assurance (QA) is the term used in both manufacturing and service industries to describe the systematic efforts taken to assure that the product(s) delivered to customer(s) meet with the contractual and other agreed upon performance, design, reliability, and maintainability expectations of that customer. The core purpose of Quality Assurance is to prevent mistakes and defects in the development and production of both manufactured products, such as automobiles and shoes, and delivered services, such as automotive repair and athletic shoe design. Assuring quality and therefore avoiding problems and delays when delivering products or services to customers is what ISO 9000 defines as that "part of quality management focused on providing confidence that quality requirements will be fulfilled". This defect prevention aspect of quality assurance differs from the defect detection aspect of quality control and has been referred to as a shift left since it focuses on quality efforts earlier in product development and production and on avoiding defects in the first place rather than correcting them after the fact.

In engineering, a requirement is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

A statement of work (SOW) is a document routinely employed in the field of project management. It is the narrative description of a project's work requirement. It defines project-specific activities, deliverables and timelines for a vendor providing services to the client. The SOW typically also includes detailed requirements and pricing, with standard regulatory and governance terms and conditions. It is often an important accompaniment to a master service agreement or request for proposal (RFP).

<span class="mw-page-title-main">V-model</span> Graphic of a systems development lifecycle

The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German V-Modell, a general testing model, and the US government standard.

<span class="mw-page-title-main">Organizational architecture</span> Procedural structure of an organization

Organizational architecture, also known as organizational design, is a field concerned with the creation of roles, processes, and formal reporting relationships in an organization. It refers to architecture metaphorically, as a structure which fleshes out the organizations. The various features of a business's organizational architecture has to be internally consistent in strategy, architecture and competitive environment.

In project management, the resource breakdown structure (RBS) is a hierarchical list of resources related by function and resource type that is used to facilitate planning and controlling of project work. The Resource Breakdown Structure includes, at a minimum, the personnel resources needed for successful completion of a project, and preferably contains all resources on which project funds will be spent, including personnel, tools, machinery, materials, equipment and fees and licenses. Money is not considered a resource in the RBS; only those resources that will cost money are included.

Terms of reference (TOR) define the purpose and structures of a project, committee, meeting, negotiation, or any similar collection of people who have agreed to work together to accomplish a shared goal.

<span class="mw-page-title-main">Integrated master plan</span>

In the United States Department of Defense, the Integrated Master Plan (IMP) and the Integrated Master Schedule (IMS) are important program management tools that provide significant assistance in the planning and scheduling of work efforts in large and complex materiel acquisitions. The IMP is an event-driven plan that documents the significant accomplishments necessary to complete the work and ties each accomplishment to a key program event. The IMP is expanded to a time-based IMS to produce a networked and multi-layered schedule showing all detailed tasks required to accomplish the work effort contained in the IMP. The IMS flows directly from the IMP and supplements it with additional levels of detail——both then form the foundations to implement an Earned Value Management System.

A glossary of terms relating to project management and consulting.

<span class="mw-page-title-main">Project management triangle</span> Model of the constraints of project management

The project management triangle is a model of the constraints of project management. While its origins are unclear, it has been used since at least the 1950s. It contends that:

  1. The quality of work is constrained by the project's budget, deadlines and scope (features).
  2. The project manager can trade between constraints.
  3. Changes in one constraint necessitate changes in others to compensate or quality will suffer.

The following outline is provided as an overview of and topical guide to project management:

Breakdown structure may refer to:

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.