How do you breakdown your work?

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.

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Categories: Project Management | Tags: , | Leave a comment

Are you giving your team members “breakfast”?

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?

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Categories: Project Management | Tags: , , , | Leave a comment

HOW is as important as WHAT when requesting work progress updates

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“!

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Categories: Operations, Project Management | Tags: , , | Leave a comment

Blog at WordPress.com.

%d bloggers like this: