3WORK BREAKDOWN STRUCTURE (WBS) A project is made more manageable by breaking it down into individual components that together

are known as Work Breakdown Structure (WBS). Such a structure defines unique work elements that can be arranged and completed in the order defined by the network diagram: sequentially, in parallel or in the specific order necessary to accomplish project outcomes. It facilitates project management processes such as estimating, scheduling, resource allocation, risk analysis, and measurement and control of the project. The WBS represents a clear description of the projects deliverables and scope. It is not a description of the process or the schedule that defines how or when the deliverables will be produced but rather is specifically limited to describing and detailing the projects outcomes or scope. The Work Breakdown Structure is a tree structure, which shows a subdivision of effort required to achieve an objective for example a program, project, and contract. In a project or contract, the WBS is developed by starting with: the end objective and successively subdividing it into manageable components in terms of size, duration, and responsibility (e.g., systems, subsystems , components, tasks, subtasks, and work packages) When finished, WBS examples are similar to a flowchart that has its components linked logically. The components may be explained in text, or in boxes. The tasks that are located at the lowest level signify the smallest activities, whose further sub-division is not recommended. A change in any of the tasks may influence the others. The following are reasons for creating a WBS in a project. To define the projects scope of work in terms of deliverables and to further decompose these deliverables into components. Depending upon the decomposition method used, the WBS can also define the project lifecycle as well as the deliverables appropriate to the project, program, or portfolio. This project decomposition balances managements need for control with a representation of an appropriate level of detail in the WBS To provide the project management team with a framework on which to base the project status and project reports To facilitate communication between the project manager and stakeholders throughout the life of a project. The WBS can be used to communicate information regarding the scope of the project. In combination with

Page 1 of 10

additional data, the WBS is the framework for communicating information that includes, but is not limited to, schedule, risk, performance, dependencies, and budget. As a key input to other project management processes and deliverables Indicates the project milestones and control points.

Principles 1. The 100% Rule One of the most important WBS design principles is called the 100% Rule (Haugan, 2002, p.17). The Practice Standard for Work Breakdown Structures (Second Edition), published by the Project Management Institute (PMI) defines the 100% Rule as follows: The 100% Rule...states that the WBS includes 100% of the work defined by the project scope and captures all deliverables internal, external, interim in terms of the work to be completed, including project management. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the child level must equal 100% of the work represented by the parent and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work. It is important to remember that the 100% rule also applies to the activity level. The work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package. 2. Planned outcomes, not planned actions If the WBS designer attempts to capture any action-oriented details in the WBS, he/she will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. For new product development projects, the most common technique to ensure an outcome-oriented WBS is to use a product breakdown structure. Feature-driven software projects may use a similar technique, which is to employ a feature breakdown structure. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable-oriented WBS. Work breakdown structures

Page 2 of 10

that subdivide work by project phases (e.g. Preliminary Design Phase, Critical Design Phase) must ensure that phases are clearly separated by a deliverable also used in defining Entry and Exit Criteria (e.g. an approved Preliminary Design Review document, or an approved Critical Design Review document). 3. Mutually exclusive elements In addition to the 100% Rule, it is important that there is no overlap in scope definition between two elements of a WBS. This ambiguity could result in duplicated work or miscommunications about responsibility and authority. Likewise, such overlap is likely to cause confusion regarding project cost accounting. If the WBS element names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements. The WBS Dictionary describes each component of the WBS with milestones, deliverables, activities, scope, and sometimes dates, resources, costs, quality, etc. 4. Level of detail A question to be answered in the design of any WBS is when to stop dividing work into smaller elements. A common way of deciding the detailing level is the time between status reports/meetings. If the team reports bi-weekly, the largest work package should be 80 hours. Then at reporting time a package is either not started, in progress, finished or late. This way makes it easy catching delays. A work package is a piece that: can be realistically and confidently estimated; cannot be logically subdivided further; can be completed quickly; has a meaningful conclusion and is deliverable; can be completed without interruption (without the need for more information); and will be outsourced or contracted out. There is a general 8/80 Rule that states that all and any Work Package should be more than 8 and less than 80 hours in duration. 5. Decomposition Considerations (Breadth vs. Depth) A WBS will tend to be most useful for project management when its breadth and depth are thoughtfully balanced. A common pitfall is to inadequately group related

Page 3 of 10

elements, resulting in one or more nodes of the WBS becoming "too wide" to support effective management. This can make it difficult for management to find risk-relevant roll-up points within the WBS, requiring manual subtotaling of nodes or eventual restructuring of the WBS in order to make useful cost data more readily accessible. While no concrete standard exists for optimal depth or breadth, a common rule-of-thumb is to avoid having more than 7 immediate subelements below any given node of the WBS. This rule-of-thumb appears to be derived from psychological studies indicating that an average human brain is only capable of processing about 7 to 9 considerations simultaneously. The relevance of that psychological consideration to any particular WBS elaboration is left to the discretion of the WBS designer. At a minimum, the existence of more than 7 sister-nodes at any point in the WBS should prompt the designer to carefully consider whether those sub-elements might not best be expressed (and tracked) in more logical sub-groupings. 6. WBS coding scheme It is common for WBS elements to be numbered sequentially to reveal the hierarchical structure. For example, 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point. A coding scheme also helps WBS elements to be recognized in any written context. 7. Terminal element A terminal element is the lowest element (activity or deliverable) in a work breakdown structure; it is not further subdivided. Terminal elements are the items that are estimated in terms of resource requirements, budget and duration, linked by dependencies and scheduled. A terminal element is sometimes called a work package, although the two terms are not synonymous. The WBS and WBS Dictionary are not the schedule, but rather the building blocks to it. The progression of WBS and WBS Dictionary development is as follows:

Page 4 of 10

WBS WBS (Diagram (Diagram or or List) List) Goal Define comprehensive list of project activities

WBS WBS Dictionary Dictionary Goals Describe task Sequence activities Estimate duration Estimate resources Identify constraints

Detailed Detailed Schedule Schedule Goal Integrate detailed list of project activities, dependencies, constraints, and resources to reflect complete timeframe

The various levels of the WBS also provide support for focusing communication with stakeholders and aid in clearly identifying accountability to a level of detail necessary for effectively managing and controlling the project. The upper levels of the WBS reflect the major deliverable work areas of the project in the projects life cycle. These levels also provide logical summary points for assessing team and individual performance, communicating accomplishments, and measuring cost and schedule performance with respect to individual deliverables as well as the overall project The content of the upper levels can vary, depending upon the type of project and industry involved. It is prudent to define the levels of the WBS prior to construction. The lower WBS elements provide appropriate focus for project management successes such as scope and schedule development, cost estimation and resource allocation. Deliverables The WBS provides the foundation for integrating the work package and intermediate deliverables with all other aspects of project initiation, planning, execution, monitoring and controlling, and closing. A deliverable-oriented WBS provides many benefits to the project, including the following: Better communication to project sponsors, stakeholders and team members. More accurate estimation of tasks, risks, timelines, and costs. Increased confidence that 100% of the work is identified and included. A foundation for the control processes within the project Design A well-designed WBS that presents information at the appropriate level of detail and in formats and structures meaningful to those performing the work is an invaluable tool in project management. It provides a graphical representation or textual outline of the project scope. The WBS roles in supporting clarity for project definition are:

Page 5 of 10

Decomposing the overall project scope into deliverables and supports the definition of the work effort required for effective project management Clearly and comprehensively defines the scope of the project in terms of deliverables that the project participants and stakeholders can understand Supports documentation of the accountability and responsibility of the various deliverables by having a direct relationship among the WBS elements related to the Organizational Breakdown Structure (OBS) identified through the Responsibility Matrix(RAM) Provides a structure for organizing information regarding the projects progress, periodic status, and projected performance for which a project manager is responsible Supports tracking of risks to assist the project manager in identifying and implementing responses necessary to achieve desired outcomes.

Management The WBS supports effective project management in several ways during the life of a project by: Separating project deliverables into component parts to ensure the project plan matches the approved project scope and will fulfill the overall objectives of the project Support the decomposition of the project scope into simpler components, providing one of the primary methods for managing complex objects Providing a framework for specifying performance objectives Provides a basis for integrating and assessing schedule and cost performance Supporting the planning and assignment of responsibilities Assisting in determining resource requirements such as technical skills, experience and knowledge Facilitating the reporting and analysis of project progress and status data, including resource allocation, cost estimates, expenditures, and performance.

Page 6 of 10

Representation of WBS The WBS can be represented in a variety of ways including graphical, textual or tabular views. Two common methods are the hierarchy diagram and the outline or tabular view as shown below:

Page 7 of 10

WBS processes, its advantages and disadvantages

The WBS process is normally created from the top down approach. It starts with the projects overall goal. It decomposes the goal into deliverables and the deliverables into modules. When it is finished, the tasks should be a few days work or less. This is an iterative technique to creating a WBS. The WBS iterations might produce only a part of the next level while requirements are still being worked out. However, it should produce some tasks, so that work can begin. It is a good idea to create the WBS as a group. This can prevent important activities from being missed and can add a level of peer evaluation to the process As you decompose the goal into deliverables, each deliverable might have its own team such as: The test suite would be within the expertise of the QA team

Page 8 of 10

The binary and source code distributions would be within the expertise of the developers or administrators The documentation might be within the expertise of the sales team, or the documentation team

There are guidelines for what is enough: Status/completion is measurable The activity/task is bounded The activity/task has a deliverable Time and cost are easily estimated Activity/task duration is within acceptable limits Work assignments are independent

The advantages of creating a WBS are: 1. WBS forces the team to create detailed steps The WBS forces the project manager, team members, and customers to delineate the steps required to build and deliver the product or service. The exercise alone encourages a dialogue that will help clarify ambiguities, bring out assumptions, narrow the scope of the project, and raise critical issues early on. 2. WBS lays the groundwork for schedule and budget It lays the groundwork for developing an effective schedule and good budget plans. A well-defined WBS enables resources to be allocated to specific tasks, helps in generating a meaningful schedule, and makes calculating a reliable budget easier. 3. WBS creates accountability The level of detail in a WBS makes it easier to hold people accountable for completing their tasks. With a defined WBS, people cannot hide under the cover of broadness. A well-defined task can be assigned to a specific individual, who is then responsible for its completion.

Page 9 of 10

4. WBS creation breeds commitment The process of developing and completing a WBS breeds excitement and commitment. Although the project manager will often develop the high-level WBS, he will seek the participation of his core team to flesh out the extreme detail of the WBS. This participation will spark involvement in the project. Limitations It can be a painstaking process. It can take quite a bit of time. A large WBS (one that identifies several thousand activities) can take many hours to develop. For another, it requires effort. There is a knowledge transfer and exercise of brainpower. The larger the scope of the project, the larger the WBS will be. More people must provide input and then approve the portion they are responsible to perform. It is hard to find the correct level of detail to include in the WBS. Since the WBS has to fit on one page, it is sometimes very difficult to find what tasks that should be included in the WBS and what should not. This often leads to the creation of a "vague" task, under which a set of non-similar tasks are grouped. The WBS can quickly be outdated: Although the WBS dictates your project schedule, it can become quickly outdated. This is because the project schedule usually changes during the execution of the project (change requests, etc...), but your WBS remains the same. Updating the WBS is overhead that probably no project manager does (what is the point of updating a document that nobody will read) It shows the tasks in no particular order, it does not show any dependencies, and it doesn't tell you which tasks are critical and which tasks are not. Finally, the WBS requires continual refinement. The first iteration is rarely right and as the project changes, so does the WBS.

Even after considering the downsides, the overall advantages still outweigh the known challenges. A good WBS makes planning and executing a project easier and lays the groundwork for the schedule, the tracking, the budgeting, and all the accountability throughout the rest of the engagement.

Page 10 of 10