Narrative Description

The narrative description paints a picture of the end result in more detail than the charter. It gives a richer representation of the project overall. For example, the Dionysus Winery vision statement is:

For adults who appreciate wine and good times, the Dionysus Winery is a state‐of‐the‐art winery that caters to the fun and frivolity in all of us. Unlike other wineries that only offer wines, clubs, and tasting rooms, the Dionysus Winery will offer education and recreation activities, unique lodging, and innovative, locally sourced gourmet food.

The purpose, as documented in the charter, is:

Provide a fun, upscale, unique winery experience for individuals, couples, and groups.

The narrative description in the scope statement could be:

You can see how this narrative provides a richer description and deeper understanding of the project.

Deliverables

Each deliverable is elaborated to communicate a more complete concept of the deliverable. The process of elaborating each deliverable enables the team to start making decisions, reduce uncertainty, and shape the deliverables. Often the team needs to complete further analysis and research as part of completing the scope statement. This may include creating a decision matrix or breaking the deliverables down via a system engineering perspective, value analysis, product breakdown structure, or other means of identifying the component parts of the project.

An example for the Dionysus Winery project demonstrates the process of elaborating the grand opening event. The team was considering three options for the grand opening: a “Taste of Tuscany” buffet, a sit‐down dinner with complementary wine, or a grape stomp. Tessa prioritized her desired outcomes for the event as:

1. The more people the event can accommodate, the better;
2. The event should be memorable—something people don't normally do;
3. The cost should be reasonable.

The team used a decision matrix to determine the best option. A decision matrix evaluates multiple options by creating a matrix with a set of criteria important to the decision. The matrix lists the options in the left column and the criteria across the top row. The criteria may be weighted to indicate priorities. The options are scored against each criterion, and the weights are multiplied by the scores to determine the optimal outcome.

Using the criteria Tessa identified and the three options, the team created a decision matrix. They weighted the importance of the criteria based on Tessa's preference: the option that best fulfilled the criterion would be rated as a 5, the one that next best fulfilled it would be rated as a 3, and the one that least fulfilled the criteria would be rated as a 1. Table 6‐1 shows the decision analysis.

Based on this analysis, it was obvious that the theme of the grand opening event should be a grape stomp.

A deliverable description for the grand opening could be documented as:

Out of Scope

When elaborating and documenting scope for a project, it is just as important to identify those areas that are out of scope as it is to identify those areas that are in scope. By specifically identifying out‐of‐scope work up front, you can manage stakeholder expectations and address any concerns about in and out of scope before creating a baseline.

At the planning meeting the team identified the following areas as out of scope for the Dionysus Winery project.

• Any work and costs associated with fixing up and managing the vineyard;
• All maintenance and operations after the grand opening;
• Negotiating salaries;
• Staff labor costs are not included in the budget.

WBS Levels

There are some nomenclature concepts you need to know about a WBS. Each level has a number. The project is level 1, in this case Dionysus Winery. The top‐level organization is level 2 (Project Management, Construction, Grounds, Winery Management System, and Operational Readiness). Each lower level of decomposition follows from there, level 3, level 4, and so forth.

The WBS in Figure 6-1 follows a best practice of organizing the work by deliverable. Notice that other than project management, WBS elements are deliverables (nouns). Grouping by deliverable also means that the WBS is arranged by logic, not sequence. The work will be further decomposed into activities and put in sequence when it is scheduled.

Some projects use level 2 to organize by life cycle phase rather than deliverable. Projects that have multiple locations may arrange the work by geography. While arranging the WBS by major deliverables is a best practice, it is not the only way—as with everything in project management—so tailor your approach to meet the needs of your project.

The WBS will be progressively elaborated just like most project artifacts. As the project progresses, it makes sense to provide more detail. At some point working with a chart like the one in Figure 6-1 gets unwieldy. Usually when the project gets beyond level 3 or level 4 it is documented in outline format. The portion of the WBS from Figure 6-1 is shown below in an outline format.

1. 1. Dionysus Winery
   • 1.1. Project Management
     • 1.2.2. Contracts
     • 1.2.3. Planning
     • 1.2.4. Risk Management
     • 1.2.4. Stakeholder Engagement
     • 1.2.5. Reporting
     • 1.2.6. Oversight
   • 1.2. Construction
     • 1.2.1. New Construction
       • 1.2.1.1. Blueprints
       • 1.2.1.2. Grade
       • 1.2.1.3. Foundation
       • 1.2.1.4. Frame
       • 1.2.1.5. Roof
       • 1.2.1.6. Trades
       • 1.2.1.7. Finish Work
       • 1.2.1.8. Furniture and Fixtures
     • 1.2.2. Renovation
       • 1.2.2.1. Blueprints
       • 1.2.2.2. …

Since the construction scope is very predictable, that work can be decomposed to a low level at the start of the project. However, the winery management system is evolutionary; therefore, it only makes sense to decompose it to level 3, with the key functions we know about: the inventory module, the vineyard module, and the winery module. The wine club is using an incremental approach; therefore, that branch of the work will be decomposed as the team gets feedback on what the stakeholders want.

Work Packages, Planning Packages, and Control Accounts

For smaller projects that only require three to four levels, the information presented about the WBS thus far is sufficient. However, for a large project like the winery, you will also want to have some terminology to describe the level of detail. There are three levels of detail in a WBS, a work package, a planning package, and a control account.

A work package is the lowest‐level deliverable in a WBS. It cannot be decomposed any further without listing the activities (verbs) associated with the work. A WBS is not used to represent the activities, only the deliverables. The WBS in Figure 6-1 is not decomposed to show the work packages. If we were to decompose the roof into work packages, it might look like this:

1. 1.2.1.5. Roof
   1. 1.2.1.5.1. Roof frame
   2. 1.2.1.5.2. Insulation
   3. 1.2.1.5.3. Flashing
   4. 1.2.1.5.4. Shingles
   5. 1.3.1.5.5. Drains
   6. 1.2.1.5.6. Scuppers
   7. … .

A planning package is for work that hasn't been decomposed into work packages. This can be due to not having enough information to decompose the work into work packages, employing rolling wave planning, or an approved change request that hasn't yet been decomposed. The WBS in Figure 6-1 shows mostly planning packages that have not yet been fully decomposed.

A control account is used for control and reporting purposes. A control account is held at a high level on the WBS. It encompasses the planning packages and work packages beneath it. Each control account has multiple work packages, and each work package only belongs to one control account. A control account is used to measure cost and schedule performance. When reporting to senior management, they usually don't want to hear about every single work package, especially if there are no performance issues. Therefore, you “roll up” the performance information in a way that makes sense for the project.

For the winery project it might make sense to report performance for the Grounds, for the Operational Readiness, and the Renovation. Each of these would be control accounts, and the performance for all the work underneath them would be combined for reporting purposes.

For the new construction, Tessa and Anthony will have to determine what level of detail she wants. If Tessa wants high‐level information, then reporting on the new construction is fine. If she wants more detail, then it might make sense to restructure that branch of the WBS so it is organized the way progress will be reported.

Steps to Create a WBS

To create a WBS, follow these five steps:

1. Analyze the scope statement and requirements to understand the project work;
2. Determine how you will structure the WBS (by major deliverable, phase, etc.);
3. Decompose the work until you have work packages or until you can't realistically decompose it further;
4. Identify control accounts (if using control accounts for reporting purposes);
5. Establish a numeric coding structure, especially if your WBS has more than 50 work packages.

Elicitation

The first aspect of requirements management is eliciting requirements. Eliciting requirements includes more than just asking stakeholders what their requirements are. There are several techniques you can use to elicit requirements. I have grouped them into three main categories: working with stakeholders, research, and visual methods.

Prioritization

Once requirements are identified, they should be prioritized. One way to prioritize is by function, such as “inventory requirements are most important, followed by production, security, and so forth.” Another option is by schedule. For example, the vineyard operations will be active first, followed by production, storage, inventory, and then administration.

You can also have stakeholders participate in the prioritization by using a nominal group technique. To use the nominal group technique for requirements prioritization, follow these steps:

1. Brainstorm requirements;
2. Discuss the requirements so everyone has a common understanding;
3. Have every person rate each requirement. Here are three different examples you can use for rating:
   1. Each person numbers the requirements from most important to least important;
   2. Each person has a set number of points (such as 100) that they allocate based on their opinion of the relative importance of each requirement;
   3. Each person assigns a number from 1 to 5 based on their priority: 1 is not important, and 5 is critically important.
4. Tally the results.

A simplified version of nominal group technique is dot voting. With dot voting, each person has a set number of dots. They allocate their dots to the requirements they think are most important. When all the dots are placed, they are tallied.

Documenting Requirements

There are several ways you can document requirements. Large projects with hundreds or even thousands of requirements use software to record and manage requirements. However, you can also use low‐tech means, such as index cards or user stories.

Key Terms

• affinity grouping
• backlog
• control account
• decision matrix
• elicitation
• planning package
• requirement
• scope management plan
• scope statement
• user story
• WBS dictionary
• work breakdown structure (WBS)
• work package