Episode 144 Premium: Scope vs. Work

This episode is reserved for subscribers of the Premium Podcast. Learn how to subscribe to the Premium Podcast to access this interview and transcript...

This episode is sponsored by:

A little while back Bill Duncan published an article on the importance of clearly (and I really mean clearly) differentiating between the terms scope and work.

Everyone seems to agree on the importance of scope, but there is much less agreement on what it is and where to find it. By focusing on a project’s “product” (whether tangible or intangible), project managers create greater clarity around the implication of all changes.

His reasoning was that by doing so you get greater clarity in regards to what changes on your project should be considered as scope changes, you improve your communication with your customer and by applying "discover-define-deliver" you add another layer of clarity.

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner: This is The Project Management Podcast™. We bring project management to beginners and experts. Find us on the web at www.project-management-podcast.com or send your emails to This email address is being protected from spambots. You need JavaScript enabled to view it..

Cornelius Fichtner: Hello and welcome to this Premium Episode #144. I am Cornelius Fichtner.

This is The Project Management Podcast™ for the 17^th of April 2010, nice to have you with us.

Here is another Premium Episode to which only you, our premium subscribers, get access. And it's also just you, the premium subscribers, who receive a PDF transcript of every show. Just look in your iTunes to find them.

A little while back, Bill Duncan published an article on the importance of clearly and I really, really mean clearly, differentiating between the terms scope and work. His reasoning was that by doing so, you get greater clarity in regards to what changes on your project should be considered as scope change. You improve your communication with your customer and by applying ‘Discover-Define-Deliver’ you add yet another layer of clarity on top of all of that.

But there is much, much more to it. So let's get going with the interview.

Podcast Interview

Female voice: The Project Management Podcast’s feature Interview: Today with William Duncan, principal of Project Management Partners.

Cornelius Fichtner: Hello Bill. Welcome back to the program.

Bill Duncan: Hi Cornelius. Nice to be here.

Cornelius Fichtner: This time around, we want to talk about scope versus work. So let’s cut right to the chase here. What’s the problem that you see with these two words, scope and work, in regards to project management?

Bill Duncan: Okay. I think the real problem is with the word ‘scope’ and let me give you a little bit of background:

When I was working on the original PMBOK® Guide back in the early 1990s and trying to figure out what to write about scope management, I was asking people questions and really not getting much help and I figured that scope was fundamental to project management and everybody who is involved in project management really ought to know what scope was and what it was all about.

I went to one of the best known books on project management. I shall not mention the author’s name, but I went to the index to see what he had to say about scope and lo and behold, there was nothing in his index on scope. There was not an entry. And, it just absolutely blew my mind. How can you have and the book was rather thick 400-500 pages as I recall.

Cornelius Fichtner: It’s now about 800.

Bill Duncan: And I was saying to myself: How can you possibly write 500 pages about project management and either never mention scope or never mention it in such a way that it gets into the index?

So I looked at a couple of other books on project management and basically found the same thing. If there was a discussion of scope, it tended to come out from the contractor’s perspective and assume that somebody else had told you what your scope was.

So if I’m a contractor, if I’m a seller in an environment, if I’m building a house for example, the owner or the buyer says this is what I want you to build and I pick up the specs and that’s my scope and it’s very clear.

And working on the PMBOK® Guide and asking a bunch of people more questions, what I finally came up with was the idea that there were two different kinds of scope and that’s why people were getting confused and having difficulty answering the questions.

The first, I ended up calling ‘product scope’ and I defined product scope as the characteristics of the product or the project. So if you’re building a house, it is how many bedrooms, what is the kitchen like, where is it located, and so on. If you’re developing a piece of software, it’s what the user interface looks like, what language is it in, what’s the database that underlies it, and so on.

The characteristics of the product or the project is what we called product scope. Then we used the term ‘project scope’ to define the activities, the things that you need to do in order to actually deliver the product or the project. And it seemed to be fairly clear to me in many ways. It still is clear to me. But what I found is that people weren’t comfortably using compound terms that you would say product scope or project scope and they would immediately drop the modifier and switch to talking just about scope.

And I also found that people got confused…the PMBOK® Guide definition that we used for scope basically included both of them so if you want to look at it, you have scope with no modifier at the top and then you divide that into product scope and project scope. And I think that just continued to confuse people. So I eventually changed my language to use “scope” to refer to what we used to call ‘product scope’ and to use “work” to refer to what we called ‘project scope’ or the activities that have to be performed.

It is in fact language that has been fairly widely used in architectural and engineering field for many years so it isn’t something that I invented. It was just some ways that we…we have already got these terms that are much simpler than what you’re saying. Why don’t you use the simple terms so I’ve been using the simpler terms ever since. But I still find people not sure what scope is and getting confused about whether they’re talking about scope or whether they’re talking about work.

Cornelius Fichtner: So how then would you define work? You’ve given us your definition of scope, how would you define work?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.