ANDY CROWE ● BILL YATES ● NICK WALKER ● CELESTE CLANCY
NICK WALKER: Welcome to Manage This, the podcast by project managers, for project managers. It’s a chance for us to get together every couple of weeks and have a conversation about what matters to you as a professional project manager. We’ll cover subjects such as project management certification, doing the job of project management; and we’ll get inside the brains of some of the leaders in the industry and maybe hear your stories. I’m your host, Nick Walker, and with me are our resident experts, who have been in the trenches and stood on the mountaintops. They are the project managers who mentor other project managers and those working toward that title, Andy Crowe and Bill Yates.
Andy and Bill, we have a lot to cover today. We’ll get to some certification subjects in just a bit. But let’s start off by talking philosophy. It’s about the WBS, the work breakdown structure that organizes a team’s work into manageable sections. There are a couple of different philosophies about this subject when it comes to project management. Andy, what are those?
ANDY CROWE: Well, you know, a couple of the approaches that we see out there sort of follow the overall approaches in project management. It’s either top-down or bottom-up. And so really a lot of the top-down crowd, which you might consider to be Waterfall, SDLC, sort of a traditional approach, they’re really going to favor the WBS. They’re going to favor looking at it, decomposing the scope, breaking it down, getting to the work packages. And we’ll talk more about that and explore that.
The Agile community doesn’t really do this. So you’re not going to see a WBS chart on the wall of an Agile team. Agile takes a different approach. They have a more dynamic approach. So the goal with the WBS is to get the work documented and really understood upfront. And Agile believes that maybe it’s not always better to do that. So we’re going to be talking to the traditional crowd. We are going to have some things to say to the Agile community next week, I think. But this week is more for the traditional SDLC crowd.
NICK WALKER: All right. Bill, tell us a little bit about your experience in all of this. Do you have a take on this?
BILL YATES: Yeah, absolutely. The work breakdown structure, there are some different names. Andy, when you hear WBS, are there some other things that you think of? I’ve heard one, I know Louis likes to refer to it as “work bite sizes.”
ANDY CROWE: Hah, I like that.
BILL YATES: There are some other uses for that abbreviation.
ANDY CROWE: Yeah, that’s good, that’s good.
BILL YATES: And they’re making some up there. There are – it’s very interesting when we talk about the WBS. One of the common fallacies that I think we’ve all seen is people having confusion between, okay, what’s on the work breakdown structure and what’s on the schedule?
ANDY CROWE: Right, where does one end and the next one begin, sure, sure, sure.
BILL YATES: Yeah, yeah. Or I’ve seen cases or heard conversations with project managers where I think there’s a complete misunderstanding of which is which, what goes where. And so simplicity, if you think about a work breakdown structure as being a visual graph that helps us see what are the outputs, what are the things that we’re going to produce with this project, then that’s a great way to differentiate that from the schedule. So simplifying a work breakdown structure focuses on the “what.” What is it that I’m going to produce? What are the deliverables? Andy, I remember when I was studying for the PMP exam, one of the things, an analogy that was helpful was “noun versus verb.”
ANDY CROWE: Right.
BILL YATES: So the nouns are on the WBS.
ANDY CROWE: Right.
BILL YATES: This is the outcome of all of our actions in our work. Whereas the schedule of best practice is to take those nouns, those deliverables that we’ll produce that are on the WBS and then translate those into actions or verbs on the schedule.
ANDY CROWE: So this is an interesting point you’re bringing up, and it really leads to a lot of confusion with practitioners because you go out and you buy a program called Microsoft Project, or maybe you’re using Primavera, or one of the common project management tools. And here’s the problem is those don’t really, by default, have any understanding or any concept of the WBS. They start with a schedule.
So I always thought, you know, Microsoft Project should probably be better named Microsoft Schedule or something like that. It doesn’t get into some of the bigger aspects of managing scope and managing change orders and managing breaking down the scope and controlling all of that. Which is a confusing thing.
BILL YATES: Well, it is. Yeah, Andy, I mean, think about it. When you start to define a task, they want to know, you know, the software is asking you, when does it start, and when does it finish?
ANDY CROWE: Right, right.
BILL YATES: So right off the bat you’re being asked these questions, while I’m still trying to understand what it is.
ANDY CROWE: And they’re not asking you, why is this important? Give me the attributes of this task. Give me the origins of it. Who requested it? Why is it here? All of those things. So by the time you get to Microsoft Project, it’s sort of implied that you’ve done a lot of this work. But a lot of people don’t.
BILL YATES: Right.
ANDY CROWE: So it gets them in trouble. It’s like teaching somebody to write by handing them Microsoft Word and saying, “Now you’re a writer.”
BILL YATES: Yeah.
ANDY CROWE: Well, you might be. But there are other elements to writing that Word will simply facilitate. So, yeah, it is a tricky problem. I wish that those applications, I wish that the vendors, and maybe somebody’s listening to this who can translate this into reality at some point. I wish they would incorporate more aspects of a WBS and more aspects of scope management in general into these applications. It’ll help practitioners. It’s an absolutely fundamentally important thing that, if you’re going to build a schedule, you need to have a thorough understanding of the scope.
BILL YATES: Right.
ANDY CROWE: Otherwise a schedule’s relatively meaningless at this point. It’s just a bunch of bars. And that’s the reason people wonder why everything goes over schedule.
BILL YATES: Yeah.
ANDY CROWE: Well, it’s because they didn’t have a good understanding to start with.
BILL YATES: Andy, let me ask you another question related to a practice with a WBS. One of the things that I think you and I have talked about before is walking into the room of a project team and seeing a work breakdown structure up on the wall, and things that you hope to see on it and things that you hope are not on it. What have you seen? Like, for instance, I know there’s a rule that you have regarding what should be included on the WBS.
ANDY CROWE: Okay. And so, you know, the WBS should have all the work that’s going to be done on the project.
BILL YATES: So everything we’re going to create.
ANDY CROWE: Everything that people are going to be working on. So one of the first questions I ask when I walk into a room and see a WBS, is there work being done that doesn’t map back to this? Inevitably the answer comes back, well, yeah, there is some. And that becomes a problem because then what are you going to do? You’re going to run over budget. You’re going to run over schedule.
One of the tricks that’s important, though, when you get into creating a work breakdown structure, is the way it’s organized. And this is something that I have found to be tremendously helpful. So if you know of the big consulting firm McKinsey, McKinsey’s a high-end consulting firm. And they have this concept – and I don’t know that they pioneered it, but they popularized it – called MECE, M-E-C-E. And MECE stands for Mutually Exclusive, Cumulatively Exhaustive. What it means is big words for this. It means that everything that’s going to be done on this project is represented on the WBS once and only once. There’s no duplicates. There’s no overlap. And there’s no gaps. And so that is an art to create, to break down the scope to a level. So Bill, how low do you go with the WBS?
BILL YATES: Boy, that’s a great question. Yeah, yeah.
ANDY CROWE: How far do you break it down?
BILL YATES: I’m going to give you the consulting answer. It depends.
ANDY CROWE: Okay.
BILL YATES: It’s interesting, I was looking back at some past projects we’ve done with companies, large organizations, those that have tried to answer that question. And interestingly, you know, I think what I typically hear is anywhere from three to six levels.
ANDY CROWE: Right.
BILL YATES: There was one organization, a large manufacturing organization, that really wanted to stop at three, which I thought was, well, it’s a little bit higher than I would have expected. But three to six I think is probably typical for the industry.
ANDY CROWE: So the textbook answer says you know you’ve broken it down far enough, it’s generally one day to two weeks is sort of the heuristic, or the unwritten rule. It should be the size of a work package. But really we know that, when you can assign it to somebody – it may be an outside vendor; it may be an internal employee; it may be a group. But when you can assign it to somebody, and they can take it from there to estimate, you know it’s far enough.
BILL YATES: Right. There’s another rule of thumb that I like that I was reminded of in preparing for this. There’s that 4 percent rule of how do I know when I’m at a work package level, my lowest level? When have I decomposed enough for this WBS? That work package should not exceed 4 percent of my overall project.
ANDY CROWE: Right.
BILL YATES: So it needs to be smaller within.
ANDY CROWE: You know,
