WBS

WBS

The Scope Definition process has five inputs that we?ve already covered elsewhere: Scope statement Project constraints Assumptions Other Planning process outputs Historical information. The tools and techniques of Scope Definition are the work breakdown structure templates and decomposition. These tools work together to create the work breakdown structure (WBS), which we?ll look at next.

WBS

Decomposing the Deliverables Decomposition is one of the tools you?ll use when preparing your WBS. This process involves breaking down the deliverables into components distinct enough to support all the project management process groups (with the exception of Initiation). The idea here is to break down the deliverables to a point where you can easily plan, execute, control, and close out the project deliverables. Decomposition in the Scope Definition process typically pertains to breaking deliverables down into smaller deliverables, or component deliverables. Decomposing the deliverables to the activity level occurs in the Activity Definition process.

As stated earlier, it?s easier to estimate resources and costs, assign performance measures and controls, and assign resources when deliverables are broken into smaller components. According to A Guide to the ProMeta, this is a four-step process:

1. Step one includes identifying all the major project deliverables. This step was completed when you wrote the scope statement. A Guide to the ProMeta makes a point of noting that the deliverables should be defined according to the way the work of the project is organized. One way to organize a project is by project phases. The phases are your first level of decomposition, followed by the deliverables. For example, let?s say you work in the construction industry. The project phases used in your industry might include project initiation, planning, design, build, installation, and turnover. A feasibility study might be a deliverable under the project initiation phase and blueprints might be a deliverable under the planning phase, and so on. Also note that A Guide to the ProMeta says that project management should be identified in this step as one of the deliverables.

2. Step two includes determining adequate estimates for cost and duration. If adequate estimates cannot be made at this level of detail, you need to decompose the deliverable further until you can make adequate estimates. (That?s step three.) Not all deliverables will have the same levels of decomposition. In the construction example, a feasibility study is the deliverable in the project initiation phase. There are only two levels of decomposition needed to describe this deliverable in enough detail to make adequate cost and duration estimates. Other deliverables may require several levels of decomposition to get to a point where adequate estimates can be made. It?s possible that some deliverables on very large or complex projects may not be easily decomposed at this point in the project Planning process, especially if the deliverable is scheduled for production late in the project plan. If that?s the case, decomposition will come later when the deliverables are defined for each of the sub-projects that make up the larger project.

3. Step three involves identifying each of the individual components that make up the deliverable. A Guide to the ProMeta calls these constituent components. These components, like the deliverables and requirements, should be defined in tangible, verifiable terms so that performance and successful completion (or delivery) are easily measured and verified. Each component you identify in step three needs cost and duration estimates assigned. That means you?ll repeat step two of this process for each constituent component you identify. This step is only needed when it?s determined that adequate cost and duration estimates cannot be made at step one; that is, the major deliverables need further decomposition in order to determine adequate cost and duration estimates.

4. Step four is a verification step. Examine the decomposition to determine if all the components are clear and complete. Determine if each component listed is absolutely necessary to fulfill the requirements of the deliverable. Also determine if you can easily schedule, estimate, budget, and assign each component. If you cannot do this easily, you need to further decompose the components until you can.

WBS Level 1

Factory Unit

WBS Level 2

Requirement Definition

Design Specification

Program Modules

ý WBS Level 3 ý

Factory Requirements

Software Design/Hardware Design

Code Requirements

Testing Requirements

WBS Level 4

Define Characters / Determine Language / Design Screens/Speakers Design /Dsgn Module/DsgnUnit Test

Define Instruments/Define Systems/ /Design Use Cases/ Design Case /Program Module 1 Design System Test

Example :

2.0 Asbestos Abatement

2.1 Inspection and Identification

2.2 Plans for Removal

3.0 Office Space

3.1 Building Floor Plans

3.2 Plans for Office Space Allocation

3.3 Plans for Break Room Facilities

3.4 Plans for Employee Workout Room

Defining Work Packages :

As mentioned, the project manager is free to determine the number of levels in the WBS based on the complexity of the project. You need to include enough levels to accurately estimate project time and costs but not so many levels that it?s difficult to distinguish between the activities. Regardless of the number of levels in a WBS, the lowest level in a WBS is called a work package.

Work packages are the activities or components that can be easily assigned to one person, or team of people, with clear accountability and responsibility for completing the assignment. Assignments are easily made at the work package level; however, assignments can be made at any level in the WBS, as in the Lincoln Street Office Building scenario. The work package level is where time estimates, cost estimates, and resource estimates are determined. Including Activities There is some controversy among project managers over whether activities should be listed on the WBS. There isn?t a rule in A Guide to the ProMeta regarding this; it?s up to the project manager to determine how far to break the deliverables down and whether to include activities. In practice, I often include activities on my work breakdown structure, as it facilitates other Planning processes later on. In this case, the activities are the work package level. However, you should realize that large, complex projects will not likely list activities on the WBS. And for the exam, remember that you will decompose activities during the Activity Definition process. Work Packages as Subprojects Work package levels on large projects can represent subprojects that are further decomposed into their own work breakdown structures. They may also consist of project work that will be completed by a vendor, another organization, or another department in your organization. If you?re giving project work to another department in your organization, you?ll assign the work packages to individual managers, who will in turn break them down into activities during the Activity Definition process later in the Planning process. If you?re assigning work packages to external vendors, activities will not be listed on the WBS either. For example, perhaps one of the deliverables in your project is special packaging, and a vendor is responsible for completing this work. The vendor will likely treat this deliverable as a project within their own organization and break the work down to the activity level. However, for your project, it?s a deliverable listed at the work package level of the WBS. This may seem self-evident, but work elements not shown on the WBS are not included in the project. The same holds true for the scope statement? if the deliverable isn?t noted there, it isn?t part of the project.

WBS Dictionary:The WBS dictionary, according to A Guide to the ProMeta, is where work component descriptions are documented. It contains a description of the work package level and the details regarding the activities within the work package. Information such as costs, budgets, schedule dates, resource assignments, and activity descriptions are found in the WBS dictionary. Noting Milestones There?s one last topic I should mention regarding the WBS. Some project managers choose to note milestones on their WBS.

A milestone is a major accomplishment in a project. The completion of a deliverable could be a milestone, for example. Milestones are like checkpoints along the way in the project to help determine progress. In most cases, the higher levels of the WBS can be flagged as milestones. The higher levels indicate major accomplishments on the project. For example, Asbestos Abatement in the Lincoln Street Office Building example is a major accomplishment that could be considered a milestone. The project would not be considered successful or complete if this milestone was not met. Sometimes critical activities can be flagged as milestones as well. We?ll talk more about milestones in Chapter 7, ?Creating the Project Plan.? Scope Statement Updates Many times, you?ll find when you?re creating the WBS that deliverables might need further definition or refining. As you work through the decomposition process, you might discover new deliverables that weren?t thought of during the Scope Planning process. The scope statement should be updated to reflect these changes. Be certain to notify the stakeholders of the update. Scope statement updates are the last output of the Scope Definition process and allow you to do just that.

Identifying Quality Standards :Quality is one of the triple constraints found in all projects. It?s the third leg to the successful completion of a project and more typically defines whether stakeholder expectations were met. Being on time and on budget is one thing; if you deliver the wrong product or an inferior product, on time and on budget suddenly don?t mean much. Remember those career-limiting moves we talked about in a previous chapter? This could be one of them if you don?t plan and monitor quality properly on your project.

The Quality Planning process is concerned with targeting quality standards that are relevant to the project at hand and devising a plan to meet and satisfy those standards. The quality management plan is the primary output of this process. It describes how the quality policy will be implemented by the project management team during the course of the project. Everything discussed in this section, including the inputs and tools and techniques of this process, will be used to help develop the quality management plan.

Quality Policy The quality policy is a guideline published by executive management that describes what quality policies should be adopted for projects the company undertakes. It?s up to the project manager to understand this policy and incorporate any predetermined company guidelines into the quality plan. If a quality policy does not exist, it?s up to the project management team to create one for the project. Standards and Regulations As with the quality policy, the project manager should consider any standards or regulations that exist concerning the work of the project when writing the quality plan. A standard is defined by A Guide to the PMBOK as something that?s approved by a recognized body and that employs rules, guidelines, or characteristics that should be followed. For example, the Americans with Disabilities Act (ADA) has established standards for web page designers that outline alternative viewing options of web pages for people with disabilities. PMI guidelines regarding project management are another example of standards. Standards aren?t mandatory, but it?s a good idea to follow them. If your project creates a software product that ignores standard protocols, your customers won?t be able to use it. Standards can be set by the organization, by independent bodies or organizations such as the International Organization for Standardization (ISO), and so on. A regulation is mandatory. Regulations are almost always imposed by governments or institutions like the American Medical Association. However, organizations may have their own self-imposed regulations that you should be aware of as well. Regulations require strict adherence, particularly in the case of government-imposed regulations, or stiff penalties and fines could result? maybe even jail time if the offense is serious enough. Hmm, might be tough to practice project management from behind bars? not a recommended career move. If possible, it?s a good idea to include information from the quality policy and any standards and regulations that affect the project in the quality management plan. If it?s not possible to

Using Project Selection Methodologies Most organizations don?t have the luxury of performing every project that?s proposed. Even consulting organizations that sell their project management services must pick and choose which projects they want to work on. Selection criteria and methodologies help organizations decide among alternative projects. Project selection methodologies will vary depending on the company, the people serving on the selection committee, the criteria used, and the project. Sometimes selection criteria and methodologies will be purely financial, sometimes purely marketing, and sometimes they?ll be based on public perception or political perception. In most cases, the decision is based on a combination of all of these and more. This section looks at one input to the Initiation process called project selection criteria. This is how projects are selected and prioritized. (The other inputs to this process are product description, strategic plan, and historical information, which were covered in Chapter 2.) We?ll finish up by looking at one of the two tools and techniques of this process: project selection methods. This tool and technique calculates measurable differences between projects and determines the tangible benefits to the company of choosing or not choosing the project. Expert judgment is the remaining tool and technique of this process, and we?ll cover that in a later section of this chapter. Selecting and Prioritizing Projects Most organizations have a formal, or at least semiformal, process for selecting and prioritizing projects. In my organization, a steering committee is responsible for project review, selection,

and prioritization. A steering committee is a group of folks comprised of senior managers and sometimes midlevel managers who represent each of the functional areas in the organization. Here?s how our process works. The steering committee requests project ideas from the business staff prior to the beginning of the fiscal year. These project ideas are developed into a project overview, or project concept document, as discussed in Chapter 1, ?What is a Project?? These project overview documents contain the project goals, a description of the deliverables, the business justification for the project, a desired implementation date, what the organization stands to gain from implementing the project, a list of the functional business areas affected by the project, and if applicable, a benefit/cost analysis (we?ll talk about that in a bit). A special steering committee meeting is called to review the projects, and a determination is made on each project as to whether it will be included on the upcoming list of projects for the new year. Once the no-go projects have been weeded out, the remaining projects are prioritized according to their importance and benefit to the organization. The projects are documented on an official project list, and progress is reported on the active projects at the regular monthly steering committee meetings. In theory, it?s a great idea. In practice, it works only moderately well. Priorities can and do change throughout the year. New projects come up that weren?t originally submitted during the call for projects that must be added to the list. Reprioritization begins anew, and resource alignment and assignments are shuffled. But again, we?re getting ahead of ourselves. Just be aware that organizations usually have a process to recognize and screen project requests, accept or reject those requests based on some selection criteria, and prioritize the projects based on some criteria. Some organizations may use analysis to determine whether or not to pursue a project. Organizations must determine in advance what the criteria will be for selecting projects and who is to be involved in deciding what projects will be selected. Let?s look at these issues now. Needs Analysis Some organizations require a needs analysis or needs assessment of projects prior to the beginning of the Initiation process. The purpose of this is to perform a preliminary assessment of the viability of the project, the viability or perhaps marketability of the product or service of the project, and the project?s value to the organization. This is usually an informal process and not considered part of the project work itself. Needs analysis is typical for internal service-type projects and for projects that entail new product development. The project concept document can serve as a jumping-off point to perform a needs analysis. Large, complex projects may also require further review via a feasibility study before a decision can be made to accept the project. You will recall that feasibility studies determine the viability of the project and help the company determine if the product or service of the project is marketable, profitable, safe, and doable. Defining Project Selection Criteria What are the selection criteria? Funny you should ask. Project selection criteria are an input to the project Initiation process, along with product description, strategic plan, and historical information. According to A Guide to the PMBOK, project selection criteria are concerned

with the advantages or merits of the product of the project. In other words, selection criteria are concerned with what the product or service of the project will produce and how it will benefit the organization. Selection criteria involve the types of concerns executive managers are typically thinking about. This includes factors like market share, financial benefits, return on investment, customer retention and loyalty, and public perceptions. Selection criteria can be subjective or objective. The criteria for judging project selection could include financial measurements. For example, the selection criteria might dictate that projects must increase profits by a certain percentage in order to be considered. Equally, project selection criteria might include the criteria that an increase in market share or an increase in the public awareness of the company or product will be enjoyed as a result of this project. There aren?t any rules for project selection, as the components of selection criteria are up to the company, steering committee, or project review committee to determine. Power Players Predetermined selection criteria as mentioned in the preceding section are one aspect of project selection, but so is the individual opinion, and power, of selection committee members. Don?t underestimate the importance of the authority, political standing, and individual aspirations of selection committee members. Those committee members who happen to carry a lot of weight in company circles, so to speak, are likely to get their projects approved just on the fact that they are who they are. This is sometimes how project selection works in my organization. How about yours? Project Selection Methods Project selection criteria, as we just discussed, is an input to the Initiation process. Project selection methods are tools and techniques used during the Initiation process to measure the project?s benefit or value to the organization. Selection criteria differs from selection methods in that selection criteria are concerned with the product of the project and selection methods measure the benefits of the project, or they compare the measurable benefits of one project against another. Selection methods are also used to evaluate and choose between alternative ways of performing the project. According to A Guide to the PMBOK, there are two categories of selection methods: constrained optimization methods and benefit measurement methods. These selection methods are known as decision models and calculation methods. Decision models examine different criteria used in making decisions regarding project selection while calculations methods provide a way to calculate the value of the project which is then used in project selection decision making.

Constrained Optimization Methods For the purposes of the exam, all you need to understand about constrained optimization methods is they are mathematical models that use linear, dynamic, integer, nonlinear, and/or multi-objective programming in the form of algorithms? or in other words, a specific set of steps to solve a particular problem. These are complicated mathematical formulas and algorithms that are beyond the scope of this book and require an engineering, statistical, or mathematical background to fully understand. Projects of enormous complexity use techniques such as these to make decisions regarding projects. The vast majority of project selection techniques will use the benefit measurement methods to make project selection decisions. Benefit Measurement Methods Benefit measurement methods employ various forms of analysis and comparative approaches to make project decisions. These methods include comparative approaches such as benefit/ cost, scoring models, benefit contribution methods that include various cash flow techniques, and economic models. We?ll examine several of these methods in this section, starting with benefit/cost. Benefit/Cost Analysis One common benefit measurement method is the benefit/cost analysis. This compares the financial benefits to the company of performing the project to the costs of implementing the project. Obviously, a sound project choice is one where the costs to implement or produce the product of the project are less than the financial benefits. How much less is the organization?s decision. Some companies are comfortable with a small margin, while others are comfortable with a much larger margin between the two figures. When examining costs for the benefit/cost analysis, include the costs to produce the product or service, the costs to take the product to market, and ongoing operational support costs. For example, let?s say your company is considering writing and marketing a database software product that will allow banks to dissect their customer base, determine which types of customers buy which types of products, and then market more effectively to those customers. Some of the costs you will take into account are: The costs to develop the software such as programmer costs, hardware costs, testing costs, etc. Marketing costs such as advertising, traveling costs to perform demos at potential customer sites, etc. Ongoing costs such as having a customer support staff available during business hours to assist customers with product questions and problems. Let?s say the cost to produce this software plus the ongoing support costs total $5 million. Initial projections look like the demand for this product is high. Over a three-year period, the potential life of the software in its proposed form, projected revenues are $12 million. Taking only the financial information into account, the benefits outweigh the costs of this project. This project should receive a go recommendation.