« Why Project Managers Shouldn’t Run Your Portfolio Management Effort
Rise of the Project Workforce, Chapter 9: Workforce Planning »

Creating The Project Scope - Defining the Project Scope

April 15, 2008 | Author: PM Hut | Filed under: Project Scope Management, Scope Management

Creating The Project Scope - Defining the Project Scope (#2 in the series Creating The Project Scope)
By Joseph Phillips

In project management (and to some extent in lawn work), there are actually two different scopes. The first is the product scope, which is what the end result of the project will create. The product scope is what customers focus on—what they are envisioning for you to create. The product scope describes the thing or service that will exist as a result of your project.

The project scope, on the other hand, describes all the work to create the product scope. It includes all of the work, and only the required work, to complete the project deliverable. In my lawn-work experience, the product scope could have been summed up as a manicured lawn suitable for a photo-op for Home and Garden magazine. The project scope would include the details on how to get there: Mow the lawn, pull the weeds, trim and edge the property, and edge the shrubs.

The project scope and the product scope support one another. In the IT world, if you’re creating an application for a stakeholder, they have expectations of what the application will do. When they discuss the requirements with you, they describe the end result of the application. Stakeholders think in terms of the vision, of the product existing. They can see into the future and experience the application before it’s created. Stakeholders usually have a way of seeing the problem solved and the organization with their solution, and can feel a sense of relief and urgency to get the deliverable into production.

Unfortunately for project managers, some stakeholders don’t have this gift. Their approach to requirements-gathering is more like Ms. Rite. They don’t know what they want until you’re doing the work. These stakeholders have a common mantra: “I don’t know what I want, but that ain’t it.” These are fantastic and joyous times for a project manager (that’s sarcasm, of course).

The goal of requirements-gathering, for those of you who’ve not experienced these wishy-washy stakeholders, is to define exactly what the project will create. For most people, it makes perfect sense; if you don’t know what the project is supposed to create, the project will fail.

Sometimes this isn’t the stakeholder’s fault; sometimes it’s really the project manager’s fault. If the project manager doesn’t capture the same vision that the stakeholder has for the end result, he’s setting himself up for failure. I know some project managers (and I bet you do, too) who have come up through the ranks of IT. Their background is in technology, they are technological geniuses, and they can configure Novell servers to make toast. The trouble is, some of these folks don’t take the time to listen to what the customer is really asking for. They don’t take the time to capture the product scope. They can’t see the end result that the customer sees.

The technical project managers gravitate toward a solution that solves the problem they think they understand rather than the problem the customer has. We don’t really need technical project managers. Let me write that again so you don’t think it’s a typo: We don’t need technical project managers.

What we need are project managers who can capture what the customer wants. We need project managers who listen to customers describe their vision of what the project will create. We need project managers who can listen, query, research, and revisit the problem that the stakeholder needs resolved. Or who can work with the customer to ensure that the project will seize an opportunity. Or who can rely on their project team to create a solution that does both. Technical project managers are great, but I’ll take a project manager who listens and understands the project purpose any day.

If you get nothing else out of this article, get this: You cannot—must not—begin a project until you know the requirements for acceptance. We see this all the time: You wouldn’t build a house without knowing what the house will look like at completion. You wouldn’t create a call center without describing the purpose and features of the call center. You wouldn’t create a car without specs on what the car should have. I understand that technology is fluid, and that as IT project managers we have to be able to adapt and evolve, but we must have some clear specifications of what the deliverable should be before we commence the project. Without a clear vision of the project deliverables, the project is doomed.

Joseph Phillips is the author of five books on project management and is a, PMI Project Management Professional, a CompTIA certified Project Professional, and a Certified Technical Trainer. For more information about Project Management Training, please visit Project Seminars.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Tuesday, April 15th, 2008 and is filed under Project Scope Management, Scope Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories