Real World Project Management: Managing the Project Scope

How many of your projects fail? Can you blame that failure on lack of scope control, poorly defined requirements, or stakeholders who think your project is a la carte? If so, you need real-world scope management, as discussed by project management expert Joseph Phillips.

From the author of

Do you like the smell of freshly cut grass? I do. To me, there's
something fantastic about the smell of gasoline, cut grass, and piles of steamy
mulch. It brings back teenage memories of mowing acre after acre of neighborhood
lawns, mulching shrubs, and sweating for a few bucks. Of course, I'd invest
my lawn-mowing monies into safe ventures such as firecrackers, baseball cards,
and matinees.

One lady, we'll call her Ms. Rite, insisted on following me around her
yard as I mowed. She complained about the height of the mower, the way I bagged
the grass, and the way I tied my sneakers. In addition to mowing the lawn, this
princess also hired me to pull the weeds, rake the leaves, trim the shrubs,
clean out the gutters, and tons moredepending on the weather and when her
coven was meeting.

It wasn't that I didn't want to do all those choresit was the
constant comments and the addition of activities as I completed what was agreed
upon. For Ms. Rite, cleaning the gutters could easily have stretched into
installing new shingles. Planting a small tree could have stretched into
installing an in-ground pool. To her, a deal wasn't a deal unless she got
her 20 dollars worth. I dreaded every project I did for her because I knew that
she'd change the activity as soon as "we" got started. Oh the
joys.

The one thing I learned from this demanding customer was that you must have
clearly defined requirements for acceptance before you begin. If only I had
learned this lesson when I was 14, I could have bought a few packs more of
baseball cards. When Ms. Rite hired me to pull weeds, I could have stressed that
the job meant the weeds that were visible around her yardnot the ones that
might be in the crawlspace or that might pop up overnight.

If I had known then what I know now, I would have defined the scope.

Defining the Project Scope

In project management (and to some extent in lawn work), there are actually
two different scopes. The first is the productscope, 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 projectscope, 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.