Real World Project Management: Managing the Project Scope
- Defining the Project Scope
- Documentation Means Everything
- Creating the Work Breakdown Structure
- Decently and In Order
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 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.