Project Scope | Project Definition | Systemation Blog
The Problem with Getting it “Right”
July 1, 2009
Don’t Forget About the Project Environment
August 6, 2009
Show all

Defining Your Project Into a Box

The hardest thing to do when launching a project is to define it into a box. Yes, I said define it INTO a box. When a project starts there are lots of interviews with stakeholders. Every one of them has their vision for the project scope. This gets added, that gets added and pretty soon you have a big hairy monster on your hands. And, one that needs a serious haircut not just a little off the top.

Project managers and business analysts are responsible for defining a single vision for the project. A vision with little ambiguity that can be realistically accomplished and accepted by all parties involved. I’m not talking about detailed requirements here. I’m talking about the description of the project definition that is created for the project plan in the beginning. It’s what points the project in a direction and provides boundaries to contain future activities.

Most folks think the key to removing ambiguity in a project scope is to define the project in minute detail. This is not only hard to do at the start of a project it also doesn’t take advantage of another way to define a project’s scope through contrasting. Let me use an analogy to make my point clear.

A HDTV screen’s quality is determined by its resolution and contrast. Its resolution is the number of pixels that make up the screen. Everyone today knows that HDTV is better than regular TV because you have twice the number of pixels in HDTV. This gives the picture its detail. Contrast is the second contributor to screen quality and is the difference between how bright a white illuminated pixel is compared to a blank black pixel. That is why plasma screens are better than LCD screens. This gives the picture its crispness.

To improve the quality of your project scope definitions, work on the contrast too. Talk about what is not a part of the project in as much detail as you talk about what is in a project’s scope. Use the exclusions area of the project plan to do so. This may seem like you are being a “nay sayer” but believe me it will bring out all the points of contention related to your project’s scope. You see, people have the tendency to assume you meant to include what they wanted in your project definition, even if you don’t specifically include it. If you specifically state that the project is not going to include some aspect of scope and someone disagrees with you, you now are able to resolve the issue and create one vision.

The more you describe what is not in a project scope and project definition, the less ambiguity you will have and the closer you are to putting your project into a well-defined box.