By: Charlie Harp

Project Execution Pointers are my thoughts on why projects go astray and what prevents us, as faithful software professionals, from achieving our objectives in a swift and effective manner.

One of the problems that often contribute to ‘failed’ projects is a disregard for defining and managing thescopeof a project.

What is the scope of ‘scope’?

The word scope can be traced back to the Italian word ‘scopo’ and Greek ‘skopos’ which mean ‘a mark to shoot at’.

根据项目管理指南ody of Knowledge (PMBOK), Scope is “the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It is primarily concerned with defining and controlling what is or is not included in the project“.

Essentially scope is another word for the “boundaries of a project”. This may lead you to ask: why does a project have boundaries? Projects have boundaries to control the cost, time to market or feature relevance.
In other words, how much I can spend, how long I can wait and what I need it to do.

Captain’s Seafood Platter

When I was a kid, my family did not have a lot of money. On the occasions when we did go out to eat, my father would say, “We don’t have a lot of money, so don’t go crazy”. The first time I remember this happening, I was eight years old. When the waitress came to take our order, I proudly ordered the Captain’s Seafood Platter… My father, who had ordered the blue plate special, gave me a look like I had done something wrong. There was nothing crazy about the captain’s seafood platter!? It was fifteen dollars worth of the best deep fried battered goodness that Denny’s had to offer. Upon reflection, I did not understand the scope of our little dinner project. I didn’t know what ‘a lot of money’ meant. I was expected to infer the scope from a subjective, ambiguous statement from the project champion (aka Dad). Had my father explicitly defined the scope; say, providing a reasonable limit of six dollars for the meal (including the drink), I would have made different choices. Needless to say, the project was not considered a success.

The Perils of Scopelessness

Once a project gets approved, resources get assigned and things start to happen. In a project that does not start out with a well defined scope, often falls prey to one of the following scope altering events.

Pet Project

Lurking in the dark alleys of most large companies, there are pet projects, and other stuff that some people want to get done. They have requests for their favorite customers, or items that they are convinced will make a big difference, that they have been unable to get approval for on the pet projects merits alone. In a project that is not protected by a well defined scope, it is not unusual for these pet projects to be ‘rolled into the project’ for various and sundry reasons. This can be something as innocuous as adding a field or attribute, or as obvious as a totally unrelated collection of functionality. In either case, each little pet project increases the drag coefficient of the project.

Feature Creep

“Feature creep” is like what happens when you buy a car (remember when people used to buy cars?) and the salesman says “do you want the optional 8-track player for $200?”

You think to yourself, “I am already spending $20k, what’s another $200.” Before you know it you have spent $30k on a car with features, like scented side view mirror warmers that you really don’t need.

“Feature creep” happens on a project when the functionality of the objective is increased in some seemingly insignificant increment. These small changes are so trivial that it seems like a ‘no brainer’. Unfortunately, this type of behavior is habit-forming and these small changes accumulate in way that impacts all of the critical aspects of the project. Before you realize it, you are six months behind schedule and way over budget.

A Well Defined Scope

I have seen a number of scope templates and scope sections. In many of these they encourage the business analyst to express scope in the limitation of features. In order to express scope in terms of features, you need to create your requirements, which should be constrained by your scope, which is based on the requirements, which is based on the scope…(Sorry, I was caught in a loop).

Scope should be defined by your needs and limitations. Needs are like requirements but they are expressed from the perspective of the user so they are much less specific than features of software. This is because very often a need can be satisfied by various means in the ultimate solution. In fact, some needs can also be met through a non-software solution, like a change in process. Scope limitations are typically defined by money, resources and time.

So, when you define the scope of your project, talk about the needs of the users that must be met and the limitations you have to deal with in order to meet them.

Scope Management

Having a well defined scope is not just expressing the boundaries. Defining scope is also about the rules of engagement, because one thing that you can say about scope with certainty is: it will change. Things will happen during the course of a project, lessons will be learned, circumstances will change and feedback will be received. In order to deal with this, it is important to (a) attribute the reason for the original scope boundaries and (b) decide on what events should result in a re-examination of the scope of the project in the beginning.

For example, if an original boundary was related to cost and budget, for that boundary to be shifted the money situation should have changed. If the original boundary was related to time to market, for that boundary to be shifted, the time to market situation should have changed. You catch my drift.

In this way when someone wants to change the scope boundaries, you can examine the original reasons for the boundaries in the first place and ask difficult questions.

Show Them the Money

One thing that I found very useful, especially in internal projects, is to relate scope, and changes to scope, in terms of cost and not time. People tend to value money more than time. When you say “that change will take and extra two weeks”, they say “Only two weeks!” If instead you where to say “That change will cost (3 people * 80 hours * 80/hour) $19,200 dollars”, they will say “That’s a lot of money!” (If you think I am kidding, try it at your next meeting.)

Give Scope a Chance

Do your next project, and all involved, a favor. Define the scope and the reasons behind it. Make it a point of discussion with the team members and stakeholders. Re-examine it when considering changes and include a review of the changes in scope in your project post-mortem.