Challenged by the Word "Scope"? – Part 2
Last month we talked about the problems of using labels on certain key words without defining, or even being sure, what a particular set of words mean. Along the way, we learned that:
- Slight changes in definition wordings, designed simply to avoid copyright infringement, do create corresponding changes in meaning and that leads to unnecessary confusion.
- Consequently, writers of any serious articles or papers should provide their definitions of the principle terms on which their thoughts hinge, and
- Lawyers do it in their documents so why don't we?
Now, let's take the word "scope" for example. Or perhaps you would rather not, since it really is a dog's breakfast. The word "scope" on its own simply means "breadth, fullness or wideness", or the nautical term "compass" meaning range. It is a simple descriptor that establishes the intent to set boundaries, with the inevitable hanging question: "scope of what?" It needs an operand that could come from almost any part of the project management field, such as "project scope" or "product scope".
Setting aside any so-called official definitions of these two terms, we could simply apply standard English translations to these coupled words. But then we suddenly find we run into a new problem: What do we mean by "project" or "product", especially as many people seem to use the terms interchangeably! Moreover, in various project management literature, I have encountered over 30 variations of the term "project",[1] and there are probably more. Yet, essentially in simple English, a "project" is just a "planned undertaking".
On this basis, "project scope" simply refers to the limits set on the planned undertaking. Of course we are so used to thinking of scope, quality, time, and cost as being the major project constraints with which project managers are faced, the immediate reaction is to assume that this is what is implied. But these are distinct project management knowledge areas, each with distinct skill set requirements of their own.
Instead, there are other dimensions of more immediate impact such as how far are we allowed to go to obtain the required information for doing the planning? Where are we allowed to go and look? Who are we allowed to contact? How much research into previous projects can we afford? In short, how far can we go before we have to stop and simply make assumptions? If you think that some of these questions are ridiculous, believe me they are very evident in projects where management deems that utmost secrecy is necessary because possible forthcoming changes are in the air.
Now let's move on to "product scope". "Product" simply implies "something produced". Here we are probably on firmer ground because, depending on the nature of the thing to be produced, we can think up all sorts of attributes of the product that we might have to meet. In other words, the "requirements" represent the "product scope" that must be met to satisfy the sponsors of the project.
I think that it is useful to have a clear idea of these two distinct interpretations because it helps to focus the mind. I have no objection to anyone who wishes to imply other meanings by these terms, so long as they make it clear what they have in mind for the dissertation that follows. Given the diversity of opinions on the meaning of "project" in particular, it may be fruitless and even counter productive to try to establish standard definitions that apply universally.
That is not to say that "official" publications of Glossaries of Project Management Terms are not useful. Indeed, they are useful for interpreting the intent of other documents published by such organizations. It's just that you do not have to slavishly use them, if you prefer to use more relevant or more robust definitions for your particular piece, or project work.
So, back to the original question posed last month: "Could you comment on the difference between 'evolution of scope' vs. 'evaluation of scope'?" Based on the foregoing, I would just say that "evaluation of scope" can mean what ever you want it to mean, so long as you spell it out and make it clear before you start!
As Humpty Dumpty said to Alice: "When I use a word, it means exactly what I want it to mean, neither more nor less!"[2]
1. Wideman Comparative Glossary of Common Project Management Terms, version 5.5
2. Quoted from: Alice's Adventures - Through the Looking Glass, by Lewis Carroll
|
