In this chapter, you learn how to further refine your work breakdown structure (WBS), decide whether your labor should be part of the WBS, find out the importance of reintegrating project staff as the project winds down, and discover distinctions between the WBS and other planning tools.
Before a project was assigned to you, an authorizing party or committee determined that it needed to be executed. They allocated resources to the project. At the least, this included costs of your services. They might have also formally or informally made assignments of plant, equipment, and human resources to the project.
At some point you were summoned. You discussed the desired objective, how long the project will take, the key events in pursuit of the final objective, and if the project is best approached via distinct phases. Perhaps a feasibility study was already done. Maybe there were notes and other documents that enabled you to achieve a running start as to what you would be required to do. Often, your initial assignment is to define your own role and present your definition to the authorizing party or committee.
Once the decision was made to launch the project, and as soon as you were given the formal go-ahead, the order of the day became laying out your plan, developing the WBS, and presenting to your superiors, as depicted in Figures 7 and 8.
Preparation of your WBS and the actual commencement of project activities is a chicken-versus-egg issue. For example, many experts advise that you first identify staffing resources and then proceed with the work breakdown structure. Following that approach, the opportunity to allocate staff as necessary comes first, followed closely by budget allocations.
Until you plot exactly what needs to be done, however, you can’t allocate staff hours. Some experts advise creating the WBS independently of staff allocations. Essentially, you identify what needs to be done, and then you assemble the requisite staff resources based on the plan that you’ve devised. I recommend the latter, because it is a prudent approach to laying out and assembling your plan—you identify needs first and then allocate appropriate staff resources.
FIGURE 7 Laying out the Plan, 1
FIGURE 8 Laying out the Plan, 2
When does it make sense to start with the staff in mind?
◾ When they are all full-time
◾ When the project is relatively short
◾ When the project is labor intensive or requires a lot of expensive equipment
◾ When you likely have the needed skills and experiences within the existing allocated staff
Another chicken-versus-egg issue to consider is if planning itself represents a task to be included on the WBS. Experts argue that especially for large and involved projects, planning can represent a variety of tasks or events, or even subtasks. Planning can even be synonymous with a project phase. For example, depending on what you’re trying to achieve, the outcome of Phase I might be to develop a plan that will be crucial to the execution of Phase II. One project manager for a large company contends that planning is definitely a task and that it needs to be incorporated into the WBS. “Does it not take human resources as well as time to plan?” he asks.
Some critics argue that while planning does consume time and budgetary resources, it is not appropriate to incorporate it into the WBS. They say that the WBS and any other type of planning document merely represent the outcomes of the planning process. A plan is considered completed only when the project actually begins. Thus, the work of the project itself is separate from the plan that enabled the work to commence.
On this particular chicken-versus-egg issue, you decide whether you want to include the planning of the project as a task or event in itself, or simply have it represent a prelude activity for the actual work of the project. As an option, Phase 0 could be planning and buy-in, and what’s next is Phase 1. In any case, you can’t skirt chicken-versus-egg issues, as they could make a significant impact on your budget and overall plans if you don’t consider them.
Should your activities and contributions to the project as project manager be listed in the work breakdown structure? Some experts say no. They argue that project management represents pure management—it’s there from the beginning; it will be there at the end, and
◾ It isn’t a task.
◾ There are no milestones or deliverables attached to it.
◾ There are no events or activities dependent on project management per se.
Those who argue the opposite—that project management needs to be plotted in the WBS—note that though the four bulleted items above might be in effect, the act of managing a project is a vital project input, and it
◾ Involves labor.
◾ Consumes resources.
◾ Helps to achieve outcomes.
◾ Is clearly a valuable resource.
◾ Is part of the overall budget (in the form of the project manager’s salary).
For these reasons, I advocate that the project management function of a project be included in the work breakdown structure.
As arduous as it could seem, constructing a WBS is relatively easy when all or most of the resources are internal, such as your staff, equipment, and other components supporting project efforts.
What about when you have to rely on external resources—outside vendors, consultants, part-time or supplemental staff, rented or leased facilities, and rented or leased equipment? Then the job becomes more involved: External project resources are more difficult to budget, schedule, and incorporate at precisely the right time.
It can also be argued that monitoring the work of outside vendors, consultants, or supplemental staff is more challenging than working with internal staff. Concurrently, external human resources who bill on an hourly or daily basis have a strong incentive to perform admirably, on time, every time.
In perfecting your WBS, have you accounted for the reintegration of your project staff back into other parts of the organization as the project comes to a close? This is an issue that even veteran project managers overlook. On some projects, the staff work a uniform number of hours for much of the project. If the project veers off plan, perhaps they work longer until the project is back on course. Sometimes, project staff work steadfastly right up to the final project outcome.
The WBS needs to reflect the added measure of staff meetings, reviews, and one-on-one encounters that are often vital to maintaining performance near the end of a project. By design, since your project is a temporary engagement with a scheduled end, it is logical also to assume that the fate and the future activity of project team members need to be determined before the project ends.
The project manager who overlooks the concerns of project staff, who naturally wonder about their immediate futures, will find that as the project draws to a close, they could start to lose focus or perhaps display symptoms of divided loyalty. Project staff are justifiably concerned about what they will be doing next, whether it’s moving on to a new project or gravitating back to their previous positions. You can’t blame them, because they have their own career and own futures to be concerned about.
Abrupt changes in job status, such as working full bore on a project to a nebulous status, can be quite disconcerting to employees. Equally challenging for the project manager is when the brunt of the project work occurs sometimes before the actual completion date. Thus, many project staff members might be in a wind-down phase, having worked 40+ hours a week on the project at its midpoint and now, perhaps, spending 20 or less a week on it. They then devote the rest of their time to some other project, or they return to their old position.
In such cases, the project manager needs to account for issues related to diverted attention, divided loyalties, and perhaps leading several project staffers who simply don’t have their “heads” in the project anymore. Remedies are available, however, such as meeting with each team member, one-on-one, to solicit their ideas and perspectives, or holding a half-day, team member input session offsite.
Whether you employ an outline, tree, or combination WBS, it’s useful to acknowledge distinctions between types of tasks. Parallel tasks can be undertaken at the same time as other tasks, without impeding the project. For example, you might have several teams working on different elements of the project that are not time or sequence related. Hence, they can all be making progress without impeding any of the other teams. While parallel tasks represent two or more tasks that can be undertaken at the same time, this doesn’t imply that they have the same starting and ending times.
Dependent tasks are those that can’t begin until something else occurs. If you are constructing a building, you first have to lay the foundation. Then, you can build the first floor, the second, and then the third. Obviously, you can’t start with the fifth floor and then move to the third, at least not in three-dimensional space as we know it. So, a dependent task is a task or subtask that can’t be initiated until a predecessor task or several predecessor tasks are finished, while a predecessor task is one that has to be completed before another task can commence.
The WBS is not a useful tool for identifying the relationship between interdependent tasks. When preparing a WBS outline, you want to proceed in chronological order, much like your progression along a tree diagram. When you combine the outline and tree diagram type WBS, you end up with an extended outline describing the tasks and subtasks associated with the elements on the tree diagram. A full WBS, by contrast, includes the sequence and interdependence among tasks. As such, it can be employed to create a network diagram.
You can then alter the position of the boxes (see Figures 7 and 8) to be in alignment with what takes place and when. Hence, parallel tasks are on the same position on the chart. As you can see in Figure 9, some items, such as assignments and resources, occur simultaneously.
FIGURE 9 Laying out the Plan, 3 (adding detail to the WBS sequence)
Dependent tasks necessarily have to have staggered positions. These can be joined by the arrows that indicate the desired path of events or activities. Milestones don’t necessarily require any time or budget, as they represent the culmination of events and tasks leading up to a milestone.
A milestone is marker of accomplishment. It might or might not coincide with a deliverable. Milestones are vital, particularly to project team members, because they offer a visible point of demarcation. They let team members know whether the project is proceeding according to plan. They represent a completion of sorts from which the project staff can gain new energy, focus, and direction for what comes next.
In refining the WBS toward attaining its final form, it’s useful to revisit the basic definition of a project as introduced in Chapter 3, “So, You’re Going to Manage a Project?” A project is a venture undertaken to achieve a desired outcome, within a specific time frame and budget. The outcome can be precisely defined and quantified. By definition, the project itself is temporary in nature. It usually represents a unique activity to the host organization.
In many ways, the challenge of establishing an effective WBS is likened to meeting the challenge of various constraints. For example:
◾ Staff resources might be limited.
◾ The budget could be limited.
◾ Equipment and organizational resources might be limited.
◾ Crucial items on order might not arrive on time.
◾ Deliverables that you provide on time could be delayed by committees that have to follow various approval procedures.
Meanwhile, you have a project to lead and can’t, or don’t want to, spend the time waiting for committee members to respond. Even when deliverables are not the issue, you might encounter delays when you only need a simple yes or no. Key decision makers could be unreachable or too bogged down with other issues to respond to you in what you consider to be a timely manner.
What about when your project is delayed for days on end because some other project team has not conveyed a key deliverable to you? You might find yourself in a touchy situation. When progress on your project is dependent on the activities of other departments within your organization, or on the success and timely combination of some other project, frustration can mount!
What’s potentially burdensome is that relying on outside approval or coordination can be difficult to plot on your WBS. As you assemble your plan, you have to account for delays in the time outside parties take to respond to you, even though they promised that such delays would not occur!
From a planning standpoint, if a group is supposed to respond to you in two days, you could consider their turnaround time to be four days. And, you might need to build into your plans a series of announcements and reminders focused on inducing them to respond. Perhaps a better alternative is to assess any risks associated with late responses or late performance, and then develop a contingency plan.
In your quest to assemble a comprehensive WBS, you run the risk of going too far. As stated in Chapter 5, “What Do You Want to Accomplish?,” many a project manager has made the unfortunate error of mapping out too many tasks. When you subdivide tasks into too many subtasks, the WBS could become more restrictive or confusing than useful; this is analogous to government procurement specifications for acquiring a simple tool such a hammer or saw.
In assembling your project plan, avoid going overboard. Beware if you have hundreds of items listed for each event or task area, plus dozens and dozens of items scheduled each day for each staffer! Your quest is to maintain control of the project and have a reasonable idea of what each project team member is doing on any given day, but not venture so far as to become draconian. Some project managers have been accused, possibly unfairly, of charting bathroom breaks for staffers.
Micromanagement isn’t pretty, particularly when you delve into the nitty-gritty of what responsible, competent project team members can handle. Moreover, micromanagers often focus on the wrong issues. The goal in constructing a suitable WBS and of being an effective project manager is to help your staff members achieve predetermined milestones in pursuit of an overall desired project outcome.
What number of subtasks in support of an event or task represents the optimal? Eight is probably too many and two is not enough. Someplace between three and five is probably optimal.
Once the WBS is approved, your primary responsibility for the duration of the project becomes that of monitoring progress. This involves a variety of responsibilities:
◾ Keeping tabs on the progress, course, and direction of the project, noting any variation from the desired path.
◾ Modifying task descriptions when possibly needed as the project proceeds.
◾ Taking immediate corrective action if it appears that the project is veering off course, while continuing to adhere to overall schedules and budgets.
◾ Working with team members, enhancing their understanding of their respective roles, team building, offering praise and coaching, and incorporating their feedback.
◾ Controlling the scope of the project, which includes making sure that the desired levels of resources are expended on tasks and subtasks according to plan.
◾ While ensuring that roadblocks and barriers are effectively overcome and avoiding winning some battles at the cost of losing the war, sometimes you can expend too much effort in one area and leave yourself in a weakened position someplace else.
◾ Maintaining effective relationships with the authorizing party and stakeholders, keeping them informed, maintaining a “no surprises” type of approach, and incorporating their feedback.
Chapter 8, “Keeping Your Eye on the Budget,” examines the need to carefully expend resources, including dealing with budgetary limits, equipment constraints, and other potential roadblocks. Thereafter, in Chapter 9, “Gantt Charts”; Chapter 10, “Critical Path Method”; Chapter 11, “Choosing Project Management Software”; and Chapter 12, “A Sampling of Popular Programs,” we discuss how to manage more-involved projects.
◾ In assembling your WBS, there are several chicken-versus-egg issues that need to be resolved, such as whether to plot your own activities as a project manager and whether to include planning itself as a task.
◾ Project managers have an easier time maintaining visibility of internal resources, including staff, equipment, and facilities, than they do when managing external resources, such as consultants, rented equipment, and leased facilities.
◾ Your WBS needs to reflect realistic delays in receiving feedback from stakeholders following their reception of your scheduled deliverables.
◾ Once you nail the WBS, you shift from a planning to a monitoring mode.