A Dialogue on Scope Definition
by Ken Ganshirt
This article is an excerpt from a long-running discussion in a project management mailing list that I participate in. The discussion is about scope definition. The basic debate that has gone on for a long time is whether there should simply be a single "Project Scope" which addresses all scoping issues related to all aspects of the project or whether we should break it into smaller pieces which we hope might be more focussed. The two pieces most commonly discussed are:
- Project Scope - pertaining to the project management process itself, and
- Product Scope - pertaining to the desired outcome or "product" of the project.
I chose to describe another aspect of scoping which, in an earlier message in the thread, I contended gets far too little attention. I referred to it as "Process Scope". Let's listen in on the conversation from that point...
Glen asks:
where does this "process" scope fit in? It sounded like
some were making it synonymous with "project" scope, others were
talking about a new animal.
Ed continues:
Ken,
clarification...did you mean project scope?
Ed & Glen,
I did not mean project scope when I referred to "Process Scope". That is, I was very specifically NOT referring to the project management process, as Glen correctly suspected.
First let me constrain the scope of my original comments .. something I should have done at the time .. 20/20 hindsight.
The domain I am most experienced in is the domain of building/assembling and implementing computer and telecommunications systems for the primary purpose of introducing some sort of change to how our business operates.
The technology, whether a computer system or telecommunications system or some combination, is at the heart of the ability to introduce this change. It is the Enabler of the change. Without the technology, the change -- at least, this particular change -- most likely would not be possible, or even conceivable. So the technology is at the core of the project.
BUT....
The project is not about the technology.
It's about using the technology to produce some sort of change in how the organization goes about its business; whether that change is to produce internal efficiencies or to realize new revenue opportunities.
It is certain that you will not realize the business or organizational objective(s) of such a project without also introducing changes beyond the installation of the technology. Those are the changes I referred to as "process" changes; changes to the processes within the organization which are necessary to achieve the desired outcome of the project. These process changes are as necessary as the technology itself.
In too many projects the focus is on the enabling technology and not on the changes in the organization's processes which will be needed for the technology to do its job. If the necessary process changes are not identified, analyzed, designed and implemented as carefully and rigorously as the technology change, the project will fail just as surely as if the technology installation is messed up.
So, if the goal of a project is to [buy or develop] and implement technology in an organization for the purpose of producing a change in how that organization can conduct its affairs - whether for operational efficiencies or revenue opportunities - the project manager must ensure that the project scope encompasses both the technology aspects and the process aspects.
In the case of my previous comments, the Product Scope would define the extent of the technology capabilities that are being developed and the Process Scope would define the extent to which the organization must change itself to assimilate the technology and employ it to produce the desired outcome.
I'm anticipating that some in the group may feel that in such projects the Product (Outcome) of the project would be defined as the sum of the technology and process changes I've outlined above, and therefore there would be no need for what I've called Process Scope. It would all be covered in the Product Scope. If so, I have no argument with that. My point is that in most technology projects the organizational process change is too frequently downplayed, underestimated, and just plain overlooked.
Again, I emphasize that this description is constrained to those projects which have the purpose of implementing technology(ies) in order to change how the organization functions. I believe this type of project is most common to all organizations. It is quite independent of what business you are in, it's size or mandate.
This would generally exclude what Glen does. Since Glen's job is to build the technology for some other organization/business/company to use to change itself, I consider his business to be manufacturing. My description would only apply to projects that his organization undertakes to change how they do their work, not to his development work itself.
I hope I haven't thoroughly confused anyone.
It occurs to me that it might be easier to carry on the discussion of Project vs. Product if we change the term "Product" to "Outcome". That way we could talk more easily about the Project itself and how to conduct it versus the Outcome of the project. In many projects, there is no easily identifiable "product", as most of us are used to using that term. But there is always a desired "outcome", whether that is an actual, tangible product, or something more complex which might include introducing or changing technologies combined with procedural, organization and even location changes.
Just a thought... .... ..
Ken Ganshirt
Regina, SK, Canada
October 28, 2002
About the Author
Ken
Ganshirt has been an IT professional and IT manager in the telecommunications
industry for 28 years. He implemented his first methodologies (Software
Life Cycle, Project Management) in the early 80's.
Ken Ganshirt <
ken_ganshirt@yahoo.ca>