Measurable Goals: Requirements Definition for Project Success

Making Goals Measurable Ensures Success

Project managers always talk about making goals measurable. In fact, wihtout measureable goals, we can't even know if we've succeeded! But how do we create measurable goals? We learn the art of clear definition and define objective requirements that everybody can agree on. Learn how.

From Definition to Measurement

Calipers are tools used to measure and compare objects. Development of this type of tool was essential to the understanding of the evolution of definition, comparison, and measurement.
Calipers are tools used to measure and compare objects. Development of this type of tool was essential to the understanding of the evolution of definition, comparison, and measurement. | Source

Defining the Beginning - Alligators in the Swamp

Sometimes, the beginning of a project is harder than defining the goal. This is often the case when repairing old computer programs or old equipment. Project managers call this finding alligators in the swamp, because we are trying to define problems we can't find until we go in and look for them, like alligators in a swamp. We don't know how many are in there until we go hunting!

An example occurred with repairs to the Space Shuttle. An indicator light indicated a problem with the temperature of a hydrogen fuel tank, even though the tank was fine. The problem was intermittent, but it delayed several launches. The goal was clear - a working temperature gauge. The initial situation - the source of the problem - was not. Buried somewhere in yards of wire and circuits over ten years old was some electronic something that went wrong sometimes.

In these situations, we start with what seems like a vague definition, "something goes wrong with this indicator sometimes." As we check various parts and they work, we exclude them as the source of the error. Through this troubleshooting process, we define the problem more and more clearly until we can solve it easily.

Define First, Then Measure

I've been to many business meetings and trainings where people are told to "make it measurable"! But very little is said about how to make our goals measurable. Coming from an engineering background, I know how to make things measurable. And I want to share these methods with project managers and other "soft skills" managers, because measurable goals are, indeed, crucial to success.

Measurable goals in project management go way beyond the introductory idea of SMART goals. There are five steps to defined, measurable success:

  1. Set the right goals. In business, choose goals that add value, improve the bottom line, and reduce cost and risk. Learn about this by reading Project Management Success: Best Practices in Scope Definition.
  2. Include everyone in defining your goals and scope by using a good method of Customer and Stakeholder Identification.
  3. Define goals clearly through excellent Requirements Elicitation.
  4. Give each goal a precise, measurable definition - that's what this article is all about!
  5. Add detail to your goals as you go with Progressive Elaboration.

Have you ever found yourself overwhelmed with demands from customers and details of customer requirements? If so, it's time to organize those requirements clearly, and define each one precisely. Read on!

Units of Measure for Time, Cost, Scope, and Quality

In some areas of project management - and life - we are given units of measure to work with. In others, we are not.

Everyone in the world (as far as I know) measures time in seconds, minutes, hours, days, weeks, months, and years. (Okay, some really geeky engineers measure processes in 1/100th of a minute, or 0.6 seconds and physicists use nanoseconds, but you get the idea.) So, for time, we have a unit of measure.

We have units of measure for cost, as well. In the US, we have the US dollar; Europe has the Euro; the Japanese have the Yen, and many more. But on your project, you probably know the right unit of measure for money.

But what is the unit of measure for scope? There isn't one! Scope isn't well-enough defined to have a single unit of measure. And the same is true of quality. We can't measure quality by counting Q-ons, or anything like that. (Ultimately, quality is measured as the absence of errors in process and defects in process, but this is not easy. To learn more about the relationship between defects and errors, please read this article about Quality Engineering and Root Cause Analysis.)

When it comes to scope, we need to do a lot of work to define functional requirements, features, and requirements of each feature before we can pick the best units of measure for each attribute of each feature. Let's do that now.

The Steps of Precise Definition and Measurement

We take these steps to create precise definitions with measurement:

  • Define what we are doing precisely, with inclusions and exclusions.
  • Connect the functional requirements (why) with the feature requirements (what)
  • Define our terms clearly
  • See if someone has already come up with a good definition to use
  • Choose our unit of measure
  • Define our requirements in measurements with tolerances.

Defining Scope Precisely With Inclusions and Exclusions

If we only define what we are doing on the project, then we will not define it with enough clarity and precision, and our project will run into trouble down the road.

There are two reasons for this. One is about customer expectations, and is fully explained in this article about managing customer expectations and scope creep.

The second reason is more technical. It is about the engineering process of creating a good definition: Anything is defined more clearly when we way what it is, and also what it is not.

I'll give an example I've used to train over 3,000 project managers. It's an exercise where we answer the apparently simple question: What is the Continental United States?

The Continental United States: Many Types of Definitions

When I ask all the students in a class of 30 project managers to define the United States, I get a few different types of answers. An unusual one is a historical approach: "The thirteen original colonies, plus the Louisiana Purchase, plus . . ." It's interesting, but not useful unless every customer and stakeholder is a historian! Some try to define it by saying "the 48 states." That has a problem in that it doesn't include Washington, D.C, which is not a state.

The Continental United Stated Defined by Inclusions and Exclusions

Usually, several students begin with "The Continent of North America, except . . .". This is the best approach for clear definition, and so it is useful in project management. Let's try this: "All of the Continent of North America except Canada and Mexico." Starting there, here are some objections and responses I have gotten. (Go with me a minute and you'll see why I'm doing it this way:

  • But what about the countries South of Mexico? In grade school I learned that they were in Central America, not North America. But in Texas public schools, they are included in North America. So we say "except Canada and Mexico and countries south of Mexico."
  • We note that Washington, D.C. is included. That makes this approach better than a definition that begins "All the states . . ."
  • People ask about Alaska. This leads to an interesting discovery. Until somewhere around 1990, the term Continental United States included Alaska, and "The 48 contiguous United States" did not. But we've all gotten used to shipping rates for the Continental US from UPS and Fedex that exclude Alaska. So we have to sort out the difference. And that is the key: This type of thinking about inclusions and exclusions both forces people to think clearly, and also makes it easy to define the results of that thinking. Which answer is right? That depends on our customer, and what the project is trying to do. If we are working on shipping, we may leave Alaska out. If we are working on counting citizens or protecting borders, then Alaska is in.
  • I push the class further: Is there anything left out? Sometimes they catch it. If not, I ask, "What about the island of Manhattan, and the Florida Keys, and Padre Island, Texas. At that point, they realize that some islands, even though they are not on the continent, are part of the Continental United States.

At this point, our definition reads: All of the Continent of North America, except Canada, Mexico, and countries south of Mexico, and any island that is part of a state already included."

That does very well. But we can go further. Are Native American reservations part of the Continental US, or not? What about foreign embassies? At this point, we realize that our definition is functional. If we are counting general population, then, yes, we would include these. If we are defining areas under US Federal law, we would exclude them. If we are trying to define borders where non-US citizens might cross (say for an anti-terrorism database), then Native American areas are part of the United States, but foreign embassies are not.

This is very valuable work. It connects the "what" of our project with the "why." Through defining things clearly with inclusions and exclusions, we help all customers and stakeholders really understand what the project is about, and why things are the way they are. We get a better set of requirements, and more customer buy-in on what we are doing.

Define and Measure: Ensure Agreement

There are many ways we talk or think, and we think we are being clear, but we are not. What is "user friendly" on a web site? One person's "large" is another person's "small." Is an item "free" if we charge for shipping?

When we allow these kinds of confusions, we set up a situation where we may disappoint customers. The solution is to move beyond definition to measurement. How many buttons and dialog box is too many, making a web page too complicated and so, not user friendly? How many ounces in a large or small cup of coffee? When we define the terms precisely, we can measure them. We know we've succeeded when anyone related to the project can agree that either the scope is met as defined, or it is not. We have reached out goal, an unambiguous definition of the project results and its features.

Connecting Functional Requirements and Features

Generally, we learn about functional requirements from executives and managers, and requirements of specific features from users, who might be workers, or, if we are making a product for sale, customers. It is our job to link the two together. If our project objective is "create a new ice cream flavor that teenagers will buy and love," then we need to do marketing studies that show kids will love the taste of, and like the name of. If we are told "replace the operations management tools to reduce the number of lost files while speeding up completion of each insurance claim," then we need to show how workers will lose fewer claims and get work done faster with our new, automated, web-based operations management tool.

We may need to go even further. If we want to do the very best to improve the system with our work, we will want to use requirements tracing, which ties functional requirements and features to specific components (such as programming object modules). Doing this, we can create a picture of all the components essential to producing the results we want.

To understand this, think of a dashboard. For a car's dashboard to work, we need to be able to define it's features. And underneath each feature, there are several components that make the feature work. Here are a couple of examples:

  • The fuel gauge shows how much fuel is in the gas tank. starting at the gas tank, we have a float that rides on the gas. An arm changes angle as the float rise or falls. Some type of mechanical or electromechanical device turns the position of this float into a measure that shows up on our (mechanical or digital) fuel gauge. If the fuel gauge shows very low, a warning light turns on. (That's 6 components for one gauge!)
  • The speedometer shows how fast the car is moving. A device measures rotations of a tire as it rolls down the road. A mechanical cable spins with that rotation. In older cars, the mechanical cable moves the speedometer meter up the dial as the car speeds up. In newer models, a device converts the speed of rotation of the measuring device into an electronic signal that is converted and displays digitally.

Do you begin to see how this works? Truly connecting the dots between a high-level, functional user requirement and the details of precise features, functions, and modules is a lot of work!

It's important work, too. Not only is it essential to project success, there's more than that. What about the future? If there is a problem, and we need to find it, this map of requirements to features and modules saves hours of work. Or, if we want to improve what we've done to make it better, then the documentation is essential, as well. In fact, I've known programmers and engineers who made a living for years - and it is difficult work - tracing undocumented systems in order to fix or upgrade them.

There's No Such Thing as an Intuitive Interface

There was a popular idea in the 1980s and 1990s that there is such a thing as an "intuitive interface," a natural way of designing things (especially computer screens or web pages) so that people will find them easy to use.

This is simply not true. All such "intuitive" effects, when we test them, turn out to be cultural. We are responding unconsciously, but with learned behaviors, not intuitive ones. In fact, even the ability to see a flat image and know what it is turns out to be learned. Anthropologists have discovered indigenous peoples who do not understand, and cannot make sense of photographs.

And no, that does not mean that such people are less skilled than we are. There are many things that they can do that we cannot.

In fact, no one knew how to make sense of the change of scene we now take for granted in movies when moving pictures first came out. The earliest silent movies showed signboard messages like "meanwhile, back at the ranch" to change scenes. They seem stupid now, but they were essential at the time.

The lesson: Effective systems depend on unconscious cultural assumptions. We may need to unpack these assumptions to make effective project results, especially in an increasingly multicultural world.

Define Our Terms Clearly

There are many buzzwords out there that do not have a single clear meaning. What makes a web page "user friendly"? A page we like may not work for our customers, especially if we are web designers. To learn more, read the sidebar on "the myth of the intuitive interface."

In ordinary language, terminology gets confused, and culture makes it even worse. For example, take a look at the simple phrase, "Drive on the right side of the road." Does that mean drive to the right, not the left? Or does it mean drive on the correct side of the road. In England (and elsewhere) the correct side to drive on is the left side. Does that mean that the right side is the left side? How confusing.

I'm writing about this in an enjoyable way, but such errors are very serious. The $125 million Mars Climate Orbiter was lost due to an error converting from the US standard to the metric system of measurement. The specification from NASA required all information to be in metric units, but somehow the contractor and everyone who checked and tested the system failed to see that this was not done.

See if Someone has Already Come up With a Good Definition

I don't want to give the impression that we must always re-invent the wheel on every project. Often, we can use past research, products, or templates to create the effect we want very easily, and at low cost.

Many decades ago, Bell Laboratories did extensive research and testing to discover that seven-digit phone numbers were most easily memorized if they were broken into two parts, three numbers, and then four. The North American phone number system was built on that research. If we're defining some kind of number, we don't need to do that research. We can trust Bell Labs and do what they do.

In fact, when I define a web site for a customer, I have them find web sites (or computer programs) that they do and do not like, and then I build a design that matches the sites they like. It's simple, easy, and quick. Why? Well, we're all like Plato; we can't define quality, but we know it when we see it.

Choose Our Units of Measure

Once we've done all the previous steps, we are ready to define our unit of measure. Boy, that was a lot of work! And yet it all boils down to: This is our unit of measure; this is how we will know what we are talking about.

One solution, though, may involve many units of measure. The best examples of this are in marketing projects for web sites. In reverse order, we use the units of measure in bold:

  • Dollars per day earned is a result of
  • Products per day sold times the retail price of each product sold, which is the
  • Products viewed per day times the close rate.
  • Products viewed per day is a results of clicks per day on ads

I could keep going. Clicks per day on ads is a result of the number of ads placed, quality of placement, and quality of location. And there are terms to learn every step of the way. My head is starting to spin!

Define Requirements in Measurements With Tolerances

Nothing is exactly one inch (or one centimeter) long. There is always some variance. The question is: Does the variance matter?

A complete definition of a requirement is a measurement with tolerances. So, for example, we might want screws one inch long. For woodworking, we might add a tolerance of +/- 0.1" (plus or minus one tenth of an inch). For metalwork, we might want much tighter tolerances, such as +/- 0.01" (plus or minus one one-hundredth of an inch.

Tolerances don't have to be symmetrical. There is a type of estimation in project management that creates a range of -10% to +15%.

When we have defined what acceptable results are in measurements with tolerances, we have defined or requirements to include what will work and exclude everything else. At this point, we are doing very, very well. We've eliminated many errors, and all the big errors, that could cause our project to fail.

From Definition to Action

Where do we go from here? It depends on the type of project we are doing.

If we are following a classical project management life cycle, then we are ready to build a complete project plan with all nine areas of project management, because everything else - all the eight other areas - are based on scope. Scope is what we are making, and if we know what we are making, we can figure out how much it will cost, how long it will take, and every other part of our plan.

However, it is a mistake to think that we have to get everything planned to the last detail before we can get to work on our project. There are alternatives to get moving sooner. To learn about them, please read this article about Progressive Elaboration.

More by this Author


Comments

No comments yet.

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working