Easy in theory, difficult in practice

The PMBOK® Guide, Seventh Edition defines a Work Breakdown Structure (WBS) as a "hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables".

While this definition provides a good understanding of what a WBS is, it doesn't provide guidance on how to organize the structure of a WBS. This is helpful as it provides flexibility for teams to determine what is the most appropriate means of doing so for the context of their project.

Although there is an infinite variety of projects, I've found three approaches used by most teams who develop WBS's:

• Deliverable-oriented - each of the top-level components of the WBS represents a key deliverable, and the subsequent levels focus on the decomposition of those deliverables to an appropriate level of detail
• Phase-oriented - each of the top-level components of the WBS represents a phase or stage in the life cycle of the project, and the subsequent levels focus on the decomposition of the outputs of each of those phases or stages
• Responsibility-oriented - each of the top-level components of the WBS represents a contributing stakeholder to the project's delivery, and the subsequent levels focus on the decomposition of the outputs produced by each of those stakeholders

A deliverable-oriented approach helps to focus the team on everything required to complete each deliverable without worrying at that stage about who does it or when it would be done. This can work well for projects where the full scope of a project can be decomposed early on, but can be challenging when a rolling wave approach is taken unless there is a clear identification of planning packages which need to be elaborated at a later date.

A phase-oriented approach works well with a rolling wave approach as the team only needs to focus on what will be completed in the upcoming phase. However, there is the risk that the team might miss key scope elements for specific deliverables as they won't be focusing on decomposing a single deliverable at a time.

A responsibility-oriented approach works well when there are multiple stakeholders and there is the need to have a clear segregation of responsibility for planning and execution between them. It suffers from the same risk as the phase-oriented approach, but more severe as there is the potential for deliverable sub-components to be assumed by each stakeholder to be the responsibility of another.

I ran a poll in PMI's LinkedIn Project, Program and Portfolio discussion group as well as the ProjectManagement.com community to gauge the distribution of usage of these three approaches. Out of the combined 141 responses, 57% were using a deliverable-oriented breakdown, 28% used a phase-oriented approach and 9% used a responsibility-oriented one. The remaining 6% indicated they used another approach but when I reviewed the comments those participants had submitted, it seemed that they were just using a combination of these methods rather than something entirely new.

While the WBS is commonly-used tool with projects following a predictive life cycle, this doesn't mean that those following an adaptive one can't benefit from it. If we consider a user story map, it is just a WBS constrained to two to four levels and developed in a progressively elaborated manner. With a story map, the structure might be persona-oriented or theme/capability-oriented.

Regardless of how your team chooses to decompose the scope of work on their projects, a WBS or a variant thereof should be considered as a valuable tool in their toolboxes.

In a project-oriented structure where the project manager has people management responsibilities for their team members, it is expected that an individual's performance on project work is the primary basis for their formal (HR) evaluation. But in a matrix structure, formal evaluations get carried out by the functional managers to whom the team members report to.

This can generate a number of risks, especially when the team members are spending the majority of their time doing project work including:

• Team members perceiving that their evaluations are based on a fraction of their actual work
• Team members prioritizing their functional work higher than their project work
• Functional managers "flying blind" when completing the team members' formal evaluations

When HR policies require functional managers to seek input from the project managers whom their team members worked with, and project managers are required to provide objective feedback into the formal evaluation process, it mostly eliminates these risks.

But this is not something I've run across frequently.

Alternately, it is possible to address the risks by having proactive functional and project managers who will respectively request and provide feedback without being mandated to do so.

And even if the functional managers are disinterested in hearing what the project managers have to say about their team members, some project managers will provide the feedback unsolicited to the functional managers, or at worst, only to the team members, leaving it to the team members to bring that feedback to the table during formal evaluations.

The common thread across these choices is the demonstration of a proactive leadership stance by the project managers. However, if a project manager isn't interested or they've had their wrist slapped for doing so in the past, team members receive no feedback which increases the likelihood and impact of the risks being realized.

While I've witnessed project and functional managers engaging in all of these approaches, I wanted to bring this to a broader audience and did so by conducting a poll within PMI's LinkedIn Project, Program and Portfolio Management discussion group as well as the ProjectManagement.com community. The poll question was simple: "Do you provide feedback to managers about their team members' performance as an input into formal evaluations?"

The poll received 95 responses, with the following breakdown of responses:

1. Yes, and it is requested by the functional manager: 38%
2. Yes, but it was not requested by the functional manager: 29%
3. No, I provide it to neither the team member nor their functional manager: 19%
4. No, I just provide it to the team member: 14%

While I do find it encouraging that the vast majority of project managers see the value of providing formal feedback on their team member's performance, it is unfortunate that almost one out of five project managers doesn't.

While this is bad for the team members, it can also hurt the project managers, especially if other project managers working with the same team members do provide such feedback. In such cases, when a team member has to juggle multiple, competing projects, which project manager is likely to be given a higher priority?

Ken Blanchard said "Feedback is the breakfast of champions" so do you want to deprive your team members of the most important meal of the day?

Whether we are looking at project or operations, understanding what progress has been made with the individual work items owned by your team is part of a normal day or week's work for most leaders. This information is critical to using tools such as earned value management and information radiators such as burn down or burn up charts.

But how you ask for work item updates will influence the quality of the work performance data you receive.

If the work items are small enough and are likely to be completed within a single reporting period, an effective, objective method is to report status as not started, not done or done. The expectation is that work items which are reported as being in a not done state will move to done by the next status review or would be escalated as being blocked.

However, when work items are not small, greater granularity of reporting for work items in progress might be warranted.

Here are three of the more common ways I've seen this information requested:

• What percentage of work has been completed?
• How much time (effort or duration) have you spent on the work item?
• How much time (effort or duration) is remaining to complete the work item?

Except in situations where progress can be independently and quantifiably assessed, the first method suffers from the Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent!

And even if you are able to objectively measure percentage complete, it still assumes that past performance on the work item will persist till the work item is completed. The second method is even worse as it only considers the past and doesn't educate us on what the future might hold.

The third approach has the benefits of forcing the team member to check if the expected remaining effort or duration for the work item is accurate and if it is not, a re-forecast can be done.

Putting theory aside, I wanted to see what was actually happening in practice.

I ran two similar polls for a week in PMI's LinkedIn Project, Program and Portfolio Management group and on ProjectManagement.com. I received 239 responses with the following breakdown of votes:

• How much work is left: 49%
• What percentage is done: 29%
• Is it done or not: 16%
• How much work have you done: 6%

It is encouraging to see that the two better methods are used in almost two-thirds of cases. However, this means that a third of respondents are using the methods which are least helpful in forecasting what may happen in the future.

Requesting useful progress updates is yet another case of "It's not what you say, it's how you say it"!

Whether you call them work boards, Scrum boards or Kanban boards, visualizing work using physical boards or online tools is a common practice for both operational and project teams.

Such boards can provide a number of benefits including:

• Helping team members to see what work remains to be done
• Giving them an opportunity to pull work items at their pace as capacity frees up
• Focusing the team's attention on blocked work items
• Providing stakeholders with a lightweight, pull-based method of understanding what's going on

But there are as many different ways for boards to be set up as there are ways in which teams do their work. And sometimes, the way a board is configured might not be optimal for the way the team works.

One example of this is the decision to use or to not use multiple columns to reflect items being worked on.

If a team has adopted the Scrum framework, is made up of generalizing specialists and is engaged in cross-functional activity where multiple team members collaborate to complete work items, then having a single In Progress column works well, especially when their work items are completed in a "small" amount of time.

But, if that same board is used by a team made up of specialists who often work solo on different work items, or where the work items take more than a small amount of time to be completed, the team and stakeholders will miss some useful information. In such instances it might be better to replace the In Progress column with individual columns representing the main steps of adding value to the work item.

Another decision is how to represent work items which are blocked due to factors either within or outside of the control of the team. Some teams will flag the work item within the column they are currently in. This is sometimes done by changing the color of the work item.

Other teams will choose to use a Blocked column and move stalled work items to that column. There has been a lot written about the evils of using a Blocked column including:

• It encourages the team to keep pulling in new work items rather than focusing on un-blocking the stalled work items and over time, the Blocked column becomes a garbage can
• Blocked is not a value-adding step in the process of completing work items

I wanted to understand what approaches were most used and ran another poll in PMI's LinkedIn Project, Program and Portfolio Management group.

Out of the twenty-six responses I received, 62% indicated they used a simple three column (To Do, In Progress, Done) board. 19% indicated they did the same but also used a Blocked column. And the final 19% of respondents indicated they used multiple columns for active work items as well as a Blocked column. No one indicated they used multiple columns for active work items with no Blocked column.

As Scrum continues to be the most popular agile framework, the majority response for the first choice is not surprising. What is surprising is that more than a third of the sample were using a Blocked column in spite of its downsides.

Context counts whether we are choosing a delivery life cycle or individual tools and techniques.

Rather than blindly adopting a work board configuration, take the time to understand what best fits the team's context and their objectives for visualizing the work and work flow.

In the project management world, being a vigilante is rarely advisable. Managing a project without proper authorization is not keeping Gotham or your company safe. And the Commissioner Gordon of your organization is more likely to put you in Arkham Asylum than congratulate you for showing initiative.

So what prompted this week's Dark Knight analogy?

I recently taught a project management foundations course in which I spent some time talking about the importance of having a project charter.

I asked my learners to recall one of the old Western films they might have seen where an unnamed drifter (usually played by Clint Eastwood or a similar actor) rides into a town which is clearly in need of some law and order. The drifter makes quick work of a couple of baddies in the local tavern but happens to attract the attention of the town's sheriff. The sheriff is aware of his own ineffectiveness and convinces the drifter to clean the town up. And to make it official, the sheriff pins a deputy badge on the chest of the drifter.

And that's what a project charter does for us.

It could also provide a whole slew of other benefits including:

• Providing stakeholders with a high level understanding of the why, what, when, and how
• Helping to resolve any "grey areas" before we proceed further
• Identifying some of the key stakeholders and their roles (e.g. sponsor, PM)

But it's primary value is to formally authorize the existence of our project. Without it, we are consuming the organization's resources towards a well intentioned goal, but without evidence of any approvals for this work.

In the case of projects done for or with third-parties, a contract might be in place before a project starts. In such cases, the contract serves as a charter if a separate one isn't created.

However, on projects which don't involve contracts such as those done wholly within a company, are charters still used?

I decided to pose that question to the members of PMI's LinkedIn Project, Program and Portfolio Management discussion group. I gave them three choices to choose from for how their company's internal projects are authorized:

• A verbal request from a leader
• An e-mail request from a leader
• A written, formal document

My expectation was that the third choice would win nearly all of the votes. While it did receive just over two thirds of the seventy votes cast, 13% indicated a verbal request was used, and 19% responded that an e-mail request was provided.

An e-mail message might not be sufficient to satisfy some of the other benefits of having a charter but it does at least provide evidence of approval as long as it describes the work to be done and is issued by an appropriate authority figure.

A verbal request on the other hand is worth the paper it was written on.

So the next time someone asks whether you are a project management Batman, the only correct answer is "No!".