As a functional manager, your goal is to keep the project team and your stakeholders focused on deliverables. I am not proposing that you become an expert at decomposing deliverable structures, also known as work breakdown structures (WBS). However, deliverable structures are a fundamental element of project planning, one that is often misunderstood and incorrectly used.
I attended a project management conference a few years ago; a presenter at the conference was discussing the effective use of work breakdown structures. He asked a room of about 150 certified project managers if a WBS was created by inputting a series of tasks into a scheduling tool. From earlier chapters of this book, you know that is not the case. But, led by the speaker to think this was a normal, standard practice, 90 percent of the workshop audience agreed and raised their hands. This is strong evidence that practitioners do not understand the power and purpose of a deliverable structure. Another telltale sign was the project managers’ response regarding whether to involve the customer in creating a deliverable structure. When workshop attendees were asked, roughly six out ten said no.
The process of creating a deliverable structure is most likely new to you, but do not expect your provider to have mastered this skill, either. Many project managers think creating a deliverable structure is a technical process, a task done by the project manager as a means to facilitate scheduling or satisfy a project office requirement. I have heard experienced project managers argue, “My customers don’t need to see the WBS, they just want it done!” This attitude is troubling and has repercussions for both you and your provider.
A deliverable structure can be considered a portrait of the work. Provider/customer partnerships must be effective in creating a portrait—preferably using graphics—that aligns with the real need and vision of the project. This planning document is built with and for the customer and team members. It is essential for defining the scope and then executing and controlling the project.
A deliverable structure with the appropriate level of detail for the situation is invaluable. If it has too much detail, the stakeholders will get lost; if it is too vague, it will be a waste of time. The right level of detail will generate dialogue that enhances buy-in to the project plan. Each major deliverable should have obvious value to the project or program, its processes, and, ultimately, its end result. I recommend writing a short objective statement for each major deliverable.
Project teams frequently make the mistake of focusing too much on technology; stakeholders then follow that lead and fail to think strategically about the change being proposed. One customer of mine was creating a new business-to-business website so that all of their customers could conduct transactions over a web portal as opposed to placing orders by phone. The customers were wholesalers who would purchase large volumes of financial transactions and many had longstanding relationships with the individuals who serviced them. These relationships provided the customers with a level of assurance that they could always talk to a person to get an issue resolved. However, the industry was changing; the speed at which these financial transactions had to take place was being revolutionized by technology. The current process was slow, prone to errors, and costly. In the initial deliverable structure of this project, depicted in Figure 7-1, we had to convince stakeholders not only that the project required clearly defined current and future state processes, but also that we needed a sustained communication initiative with the wholesalers to get them to buy in to the new processes, namely, the technology. Their buy-in would, we hoped, accelerate adoption of the new web-based transactions and realize tangible benefits for my customer.
Figure 7-1 Project Deliverable Structure, Level One
Every customer and project team has a right to understand why valuable resources are being expended to create project deliverables. Projects that are driving change often require deliverables that help to continuously clarify the ambiguity of the change as it occurs. Writing a clear objective for each major deliverable helps the team and stakeholders understand what it is being used for and how best to manage the quality of the deliverable.
In technology projects that require users to adapt to change, the major deliverable from the project team may be to deliver “ready users” who are excited, knowledgeable, and trained on all aspects of the process and technology. This will speed the adoption and subsequent recognition of benefits. Once the project team and stakeholders agree on this objective, the detailed deliverables—marketing collateral, training materials, and promotional events—become clearer to everyone.
Once stakeholders agree on deliverable objectives, the team can define acceptance criteria. What constitutes a “ready user” and how does the team measure it? You can now discuss surveys, knowledge, and proficiency tests with the stakeholders to identify the most appropriate measurement technique that ensures success. These questions about definitions and measurement are ones you should be asking during the creation of your deliverable structure. Use the deliverable structure to drive these discussions to reduce scope creep while allowing your stakeholders to actively participate in the creative process of planning.
Deliverables also greatly help manage expectations throughout the project. The goal for any deliverable structure is to ensure that it includes all the work needed and no unnecessary work. Ultimately, these deliverables translate your project mission statement into actionable realities.
Using graphics seems to be the most effective style for a deliverable structure, but it is not the only method of creating one. The first level of your deliverable structure influences the rest of the structure. This first level should identify the project’s major deliverables, subprojects, or phases, and it should be structured around them.
A simple process to create a deliverable structure is as follows:
1. Identify the final product of the project. This is the top level of the deliverable structure and may also be the project name.
2. Identify the major components of the product, service, or result to be created (product approach) or the sequence of phases of the project (phase approach).
3. Decompose the major deliverables within each component, following the rules of deliverable structures:
Each element should be a single, tangible deliverable.
Each element should be an aggregation of subordinate elements.
Deliverables should be unique and distinct.
4. Review and refine with stakeholders.
Let’s revisit the project mission statement for the fulfillment project discussed in the previous chapter. The Fulfillment Customer Data Protection project will create new processes, interfaces, and system modifications (project’s main deliverable) to be used by our fulfillment operations (primary customers) to achieve compliance with federal regulation XYZ by December 31.
Early in the planning stages of the project, you and your provider have a critical choice as to how you will structure the first level of the project. This first level will influence how the project organization, customers, and project and advisor team members visualize the project.
One option is to use a phase-oriented approach to the first level of the deliverable structure. In Figure 7-2, the first level identifies the major phases of the project.
A phased approach to level one provides the life cycle view of the project. This can be helpful, and often users and stakeholders can absorb this approach quickly. However, the phase approach doesn’t really reveal much about the project deliverables.
Another approach is to organize level one around the major components of the project’s product. This breaks down the project into components that may be aligned with different functional areas within the project team. In Figure 7-3, the deliverable structure is aligned with regulatory analysis, the help desk current and future state, and the system development deliverables. It is also decomposed into a second level, which indicates the deliverables associated with each functional area.
The product approach may spur more critical thinking among the project team and stakeholders, which is what you desire. Your goal should be to flesh out the first one to three levels of the deliverable structure while making sure that you capture the breadth of the level one structure. When using this product approach, a common mistake is to get too caught up in the product and leave out critical project management and communication deliverables that are essential to project success. The deliverable structure should contain all the work of the project, including communications, status reports, and planning artifacts. In Figure 7-4, the deliverable structure includes project management and communication deliverables for the Fulfillment Customer Data Protection project. Note that the level two deliverables have been aligned vertically under level one for presentation purposes.
Figure 7-2 Fulfillment Project Deliverable Structure, Level One, Phase-Oriented
Figure 7-3 Deliverable Structure Aligned with Functional Areas
Figure 7-4 Deliverable Structure with Project Management and Communication Deliverables
The level of detail in a deliverable structure will vary with the size and complexity of the project; you can use differing approaches and different levels of detail across each branch of the structure.
The process of identifying lower level deliverables is called decomposition, meaning breaking down the deliverables into smaller, more manageable components. The common mistake is to dive immediately into tasks or activities when decomposing your project. Our brains are trained to think in terms of actions first, not outputs.
Understanding these two terms is important.
Deliverables are any tangible work product (e.g., documentation, analysis, process map, data file, software interface).
Activities or tasks are actions performed to create deliverables (e.g., create draft specifications, conduct meeting, review plan).
When I teach project management courses, I have the participants do a deliverable structure exercise. I instruct them not to identify any activities; instead, they should identify just the tangible, verifiable outputs. Activities begin with verbs: create specification, meet with product development, or purchase software. Deliverables are nouns: specification document, contract, or test plan. I warn participants that some of them will add activities to the deliverable structure, and nine times out of 10, I am correct.
Thinking about activities at this point is fine, but you should think through activities to the point of creating an output or tangible deliverable. In our sample fulfillment project, the team may see the need to meet with the largest fulfillment partner to get an understanding of their initiative to be compliant with the new security regulations, so that your systems can work together. Then the project manager captures some key activities into his project scheduling software: meet with key partners, get the details of the initiative, and meet with IT. This is logical, but the point of the deliverable structure is to have management control points. These identify baseline scope, cost, and schedule against which to measure the actual details of the project. In our sample situation, the control point could ultimately be a requirements document for this fulfillment partner’s system to interact with your system. In Figure 7-5, the Large Partner Requirements Document is decomposed into activities. Intermediate deliverables may also exist, such as meeting notes, process diagrams, or technical specifications, all of which need to be gathered in the activity of meeting with the fulfillment partner.
By starting your deliverable structure with a group of random activities and the deliverables they generate, you will keep project team members busy in the short run, but they will fail to see how their work connects with the end product. Thinking through the activities first is fine as long as it leads to determining the specific deliverables you need. But you must first structure the deliverables and then move on to planning those activities that the deliverables require. In many cases, once everyone understands the deliverable, its purpose, features, content, quality standards, and acceptance criteria, then the activities become a sequential series of tasks, often intuitive. Clearly defined deliverables allow you to delegate with confidence and many workers appreciate a level of autonomy to determine how to complete a quality deliverable.
Figure 7-5 Activities for a Major Deliverable
As you define the deliverables, remember who is the customer accepting the deliverable and who is the project team member(s) creating the deliverable. Get these people in the same room or on the phone together and connect them with the deliverable. In our example of the fulfillment IT requirements document, the customer may be a technical functional manager in IT. The project team member may be an analyst from IT who is collecting the information and putting it into the requirements document. In other cases, the customer might be a vendor who needs the information.
A technical deliverable, like the IT requirement documents, may not fall under your direct responsibilities in the provider/customer relationship. Maybe your provider is managing these activities, but you need to be able to tell whether he or she is just managing random tasks or has thought through the activities of the deliverable to develop essential management control points.
Consider another example in the project that is more business focused. Your subordinate tells you that she can’t perform her process effectively if the fulfillment vendors don’t have access to certain customer payment information. You are not sure what the effects would be of giving this access, so you need to start digging into it before anything gets implemented and causes major operational issues or partner and customer satisfaction issues.
The first thing you decide is to confirm what is actually in the new regulation and how it impacts your process. The tendency again is to send people away on a task: analyze the impact of regulation on this particular process. This may include getting access to the regulation, having certain subject matter experts provide interpretation or opinion of the regulation, meeting with the fulfillment help desk manager and workers to review their processes, discussing changes with partners, and so on. But you have to be focusing on a deliverable of all these activities.
Thinking through activities to arrive at a tangible, verifiable output is fine; in this case, the output may be a gap analysis. The gap analysis document, now added to the deliverable structure in Figure 7-6, may include a document with legal opinions of the regulation, an impact analysis of the current state process, and the current state process and future state process with data being restricted.
You now have to determine who will be the creators of this deliverable and who will ultimately consume it. This consumption of the document will lead to decisions or actions to overcome the gaps and impacts. The process then starts again. Perhaps the remediation of the gap is to allow the fulfillment help desk to get approval from the customer to release the restricted information. The planning process of defining the needed deliverables begins again: what are the activities that lead to prudent management control points, who are the providers and customers, and what are the acceptance criteria? Or, perhaps the remediation is a high-level deliverable that is not fully decomposed until you get more information from the gap analysis. But the initial deliverable structure includes this remediation effort and all project work at some level of detail. High-level deliverables to be completed in the future are inserted as planning components that can be decomposed into more manageable deliverables as the time gets closer. This is known as roll wave planning.
Figure 7-6 Deliverable Structure with Added Gap Analysis
If your project manager takes the initiative to develop a straw model of the deliverable structure and present it to you, make sure he has included the following five components that are often missed.
1. Integration: Technology projects commonly have multiple system efforts in scope, and these systems likely have to communicate or integrate with each other. Each system may have its own deliverables for requirements, design, code, etc. But the project also needs deliverables that address any integration points.
2. Business analysis: Business process modeling deliverables are often left out by project managers with a technical orientation. The development of current and future state processes and a gap analysis should be in the structure.
3. Testing: Although testing deliverables are not usually left out, they may be less visible than they should be on the deliverable structure. If they are subdeliverables of a build stage, the effort is likely to be underestimated. If testing is a critical component of the project, elevate it to level one or two in the deliverable structure. A common problem is project managers’ borrowing time from testing to make up for slippage that occurs in earlier phases. The more visibility testing has, the harder it is for them to do this.
4. Communications: For change initiatives, communications are critical components. These could be newsletters, websites, and email campaigns to drive the behavior in project customers that will produce benefits.
5. Project Management: Project management deliverables consume time and resources and must be a part of any deliverable structure. This category includes not just planning documents, but status reports, regular project updates, and project reporting deliverables.
Project teams use various techniques and tools to create deliverable structures. As stated earlier, the worst practice is to have the project manager key activities into a scheduling tool and then think the work is done. Creation of a deliverable structure can serve as a team-building exercise, which can be done with facilitated brainstorming sessions or mind mapping exercises. Secure a strong facilitator and make sure your participants understand what a deliverable structure or WBS is and why they need to create one. Otherwise, the participants are likely to be confused, and your planning efforts will suffer a serious setback.
If facilitated group meetings are not an option, then you must initiate the creation process with your project manager and construct a straw model deliverable structure to which stakeholders can react. Yes, react. The goal is to get your stakeholders to understand how these project objectives will be achieved and how the different deliverables will help achieve them. You need to understand your stakeholders’ preferences and the level of ambiguity in the project to determine the best approach.
Please don’t make the excuse that you don’t have the tools to do this. At the most basic level, a white board, a marker, and the authority to write “do not erase” is all you need. You can use MS Office® tools such as PowerPoint or Visio to create graphic representations of your deliverable structure or invest in tools that integrate with project scheduling tools. WBS Charter is one that I use and it synchronizes your deliverables with Microsoft Project. I also use mind mapping software if I think the group needs a less-structured approach in the initial definition phase. If you have very creative people, this less-structured approach may be better; in this scenario you capture all the various deliverables in no order or structure, then take the information back to your office, assemble it into a structure, and then present it back to them.
Others seem to like a process of identifying the deliverables and organizing them into their hierarchical structure at the same time. This approach works when participants are familiar with the deliverable structure process, it is not their first time doing this, and the project has less ambiguity.
The deliverable structure defines the project work in the form of deliverables. It is the basis for effort and cost associated with deliverables and it assists the team in understanding who is accountable for accomplishing the work and who for accepting the work. The deliverable structure is your foundation for planning and control. It allows for input from project and customer team members to define the project work, it protects against scope creep, and it increases communication with key stakeholders. There are two measures of the success of your deliverable structure:
1. Is it complete and accurate?
2. Is it understood by the project team and customers?
When the deliverable structure meets those criteria, it becomes a part of your scope baseline, along with your scope narrative and requirements.
Creating a meaningful deliverable structure will present serious challenges in addition to the tendency to jump straight into activities. Participants will want to start sequencing the work immediately. Keep them focused on identifying the work first; sequencing is also critical, but it must be done afterward. Another challenge is that some will get caught up in the details of a particular deliverable and distract the team from a comprehensive view of the project.
Your involvement as a functional manager in the initial versions of your deliverable structure is crucial. Developing the top three or four levels of the deliverable structure should be done in close partnership with your project manager. Once the structure begins to stabilize, then your project manager can use this structure as input into other critical planning processes including:
Activity definition
Resource estimation
Cost estimation
Cost budgeting
Quality planning
You also face the risk of getting too detailed in the deliverable structure. You and your project manager must balance need for detail against the dual burdens of excessive reporting and updating. Deliverables should be limited in size and defined for effective control. For most projects under $1 million, a three- to four-level deliverable structure is appropriate. The project manager can then decompose further, first into more detailed deliverables and then into activities. That is their area of competence. When you feel comfortable that you have a structure of deliverables that aligns with your project objectives and the project organization comprehends it, turn it over to your project manager.
Some project managers use the 80/8 rule. This means that all deliverables are decomposed into activities that require no more than 80 hours of work but no less than eight hours.
How do you know if you have enough detail? These six questions can be applied to each specific deliverable in your deliverable structure.
1. Can you estimate cost and duration accurately? If not, the deliverable should be decomposed further.
2. Is more than one individual or group responsible? If so, the deliverable should be decomposed further.
3. Does the work element include more than one type of process or deliverable? If so, it may need to be broken into smaller, more manageable components.
4. Can you clearly define the acceptance criteria for the deliverable? If not, it should be decomposed further.
5. Can you measure progress objectively? If not, the deliverable should be decomposed further.
6. Is the work element clear to the project team or customer? If not, it should be decomposed further.
Your project manager is responsible for updating the deliverable structure on a regular basis. Here is a good test to determine whether your project scope is stable: walk around the halls of your project team and ask them what they are working on, with a copy of the deliverable structure in hand or at least in your mind. If team members are engaged in efforts that do not directly relate to a deliverable on the deliverable structure, then you have potential problems. Either the scope has changed and the deliverable structure does not reflect the actual work (a common occurrence), or team members are working on unapproved changes, which is, unfortunately, an even more common occurrence.
A community college determined that the location of its computing infrastructure limited its ability to grow and keep up with new technologies. The project mission was to create a new location for the university computing infrastructure and applications to be used by IT to host, support, and maintain the systems used by business users and students. Users would achieve a benefit from increased reliability and 24/7 availability with a 99 percent up-time service-level agreement. A major constraint of the project was that mission-critical applications could only be offline on Saturday night, for a maximum of seven hours. The project needed to be completed by October 31 because the lease on the current space expired on that date. The project was a management objective of the CIO.
The IT operations manager was leading the project. He had little project management experience; his project plan consisted of his latest white board diagram, created in a discussion with one of his engineers. Little documentation existed for the project; the issues, impacts, and risks were floating around in conversations and in peoples’ heads. The CIO was getting concerned because, after kicking off the project, no project plan existed and progress was difficult to gauge.
The solution was to team the IT operations manager with a competent project manager to create the important provider/customer relationship. Mark, the IT operations manager, was essentially a functional manager and now took on the role of a customer. His department would be one of the primary users of the new data center. Mark and the CIO were the primary stakeholders. Various divisions in the university made up the secondary stakeholders: Finance, Academics, Human Resources, Student Services, and, of course, the students themselves.
I took on the role of the project manager with the specific goal of getting a plan together and working with Mark to ensure success. As step one, we documented and agreed upon the need and project mission statement presented above. I then began to document the scope of the project, identifying which applications were moving and which were not. Other questions included: What needs to be done to get the space ready? Does it need to be built out; is raised flooring already in place? Are we physically moving the computer hardware or adding new computers? I completed the scope narrative and reviewed it with Mark and the CIO. Our next step: begin creating a deliverable structure. The goal was to get not just Mark and the CIO on the same page, but also the application development manager, the network manager, the head of security, the hardware engineers, and key department leaders.
Mark and I started at the white board and made a list of all the different aspects of the project that he had been keeping in his head. What we produced was just a brainstorm of work that needed to be done. Items on Mark’s mental list included:
Building out rack space for the servers.
Purchasing and installing new servers.
Moving the student information system application.
Updating applications that had hard-coded IP addresses.
Ensuring that the power requirements are installed.
Testing the bandwidth of the internal network and feedback out to the Internet.
Determining how databases would be replicated.
Implementing a new backup and recovery process.
I had five pages of notes by the time I left his office. My goal was to organize a high-level deliverable structure and bring it back to him, ensuring that I had captured the major components of the project’s product. My first iteration started very simply with four main components of work, as represented in Figure 7-7.
Figure 7-7 Case Study: Data Center Move Deliverable Structure, First Iteration
The first level of the deliverable structure consisted of environment, physical assets, software, and services. Environment related to the preparation of the new location including the raised space, power, rack space, etc. Physical assets were related to all the computer equipment going into the space: servers, network hardware, etc. Software was related to all the software applications that would be hosted in the new location, and services were operational tasks such as backup and recovery, monitoring, and database replication that would have to be in place on day one of the move.
I met with Mark and reviewed the draft structure to get his input and buy-in before I went much further. I also reviewed the first draft with the application development manager and network manager to get their perspectives as well. After some discussion and minor tweaks, I went back to develop the additional layers of detail.
The next iteration began to decompose each level one section into more detail. Figure 7-8 illustrates the environment section.
Environment had three major subdeliverables: power, network, and space. I’ll focus on power for illustration. Power seems like a hard thing to quantify into a tangible, measurable deliverable. You can plug in a computer and if it turns on, you’re done, right? Of course, it’s not that simple. I decomposed power into two deliverables, the first being a document with the sizing of the power requirements to meet the existing requirements and to accommodate future growth. The second deliverable was the site itself with the power requirements provisioned (“provisioned” was a word Mark liked, so I used it). The project team member creating the sizing document would be a contracted electrician. The customer accepting the document would be both the lead hardware engineer and Mark. The project team member actually delivering the power to the site would be the power company. The customer accepting it would be the lead hardware engineer, who would use tools to measure the quantity of voltage available to the new data center. This discussion occurred as we reviewed the deliverable structure, thinking systematically through who the customer is, who the provider is, and what the acceptance criteria are.
Figure 7-8 Case Study: Data Center Move Deliverable Structure, Environment Section
The physical assets and software components of the deliverable structure were more complex, primarily because several applications were to be moved and each required its own servers. After a few iterations, we decomposed the physical assets by application servers, network equipment, Web servers, email servers, and file services equipment. Why these? This was how Mark and the technical team visualized the components; this was how he organized the various assets in his mind. So we went with it.
As we began to decompose the application servers, it became apparent that these servers and applications were the most critical and must be up and running at 6:00 A.M. the morning of the move. As we discussed all that was involved with these critical applications, we decided to go back to management and request that we move in two phases. Phase I would occur one week in early October, with phase II later in October. We updated the deliverable structure and organized both physical asset and software components around these two phases. Figure 7-9 depicts the decomposition of assets, software, and services and delineates the work that will take place in phase I.
Figure 7-9 Case Study: Data Center Move, Physical Assets, Software, and Services
The key point is, during the creation of the deliverable structure, certain risks may present themselves that can be identified and brought to the attention of management to determine an appropriate response. For each deliverable, we identified who is accountable for the deliverable and who is accepting it. In many cases, the business users and their functional managers—other customers—would become responsible for part of the acceptance criteria the evening of the move, probably sometime in the early morning hours.
Within the software component, the student information system (SIS) was a large subcomponent. Its mission criticality was very high and any hiccups in the movement of this application would have visibility to senior management. This is why we added more detail to the deliverable structure. We easily could have stopped at the different environments for this application: development, test, stage, and production. But we decomposed further because each environment required specific software that would be handled by different groups of engineers (see Figure 7-10). The operating system and patches being loaded on a server was a deliverable to be completed by a junior hardware engineer and accepted by a senior engineer. This deliverable could have been decomposed into more detail, specifying the actual software OS and patches residing on the server with a checklist completed by the junior engineer to illustrate that the installation and patching had been followed in the proper sequence.
The deliverable of a server with patched OS software would be handed on to the database administrators who would install the database software. The database administrators are now customers consuming the deliverable produced by the junior engineer. This is a classic example of how one deliverable, “servers,” would combine multiple disciplines and cloud the accountability and level of control if not decomposed with greater detail.
The level of detail we used was necessary. It was the level of detail we needed to reliably control the project. Not every component of the deliverable structure needs to be decomposed to the same level. In this case, we chose to decompose further on the student information system because it was high risk and visible to management.
Figure 7-10 Case Study: Data Center Move Deliverable Structure, Decomposed SIS Software
You may have noticed that this deliverable structure did not address project management, testing, or communications. Project management should have been included—my mistake—as should the communications component. Testing was a different animal, because we could only test some of the many factors before the move. The actual move and implementation was a onetime event with critical steps that could not be truly replicated as a test.
As the project continued, we saw the need for a detailed, step-by-step plan of all the events to occur the night of the move, from bringing down the first server to bringing up the last server. During this sequence of events, we would have to test certain functions to make sure we were successful. Thus began the Saturday Night Special Plan. The plan was not a part of the original deliverable structure, but we realized it was critical and beneficial so we added it to the scope of the project. Keep in mind that you can update your deliverable structure and change your scope if the change is beneficial.
The move was occurring on a Saturday night and into Sunday morning, and this plan had to be extremely detailed—and accurate enough to make sure this project was successful. The result was a detailed script with specific dependencies of 700 events that had to be executed. Some ranged from 15–30 seconds, while others would take 15–30 minutes. All of this had to be sequenced and timed to ensure we could meet the deadline of 6:00 A.M. About 50 percent of the script could be tested beforehand; the other 50 percent could not.
The move went smoothly and all parts of the system came up a few hours before the 6:00 A.M. deadline. I was even able to catch a few hours sleep before my tee time at 9:00 that morning.
In summary, lead your project with a deliverable structure. Defining the work in a manner that connects deliverables with objectives and achieves buy-in will make your project run more smoothly. Don’t worry about sequencing these deliverables while defining them. Sequencing of these major deliverables is the next critical skill you need.