PROJECT MANAGEMENT: A BEST PRACTICE FOR PREVENTING SCOPE CREEP

One of the most insidious things that will wreck havoc on your project is scope creep. The term refers to the addition of one addition after another to the original objective. The additions are usually done in a subtle manner and seem minor initially. Unchecked, you may find yourself with an objective that is more complicated, time-consuming, and expensive than the objective that was originally agreed upon.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

One way that a customer or a stakeholder can try to introduce an addition is by insisting that his people meet directly with your people. He insists that he wants the information “raw.” He believes that if the information passes through the project management office (PMO), the information is filtered before it reaches him. As a Project Manager, you may have to permit his people meet your people directly as he requested. However, your permission should be given with the condition that your people are not authorized to accept or otherwise permit any changes to the original project objective. Any proposed additions must go through the PMO. Make sure that your people and theirs acknowledge and agree to that condition—in writing if you think that it’s necessary.

An effective way to create an environment that discourages scope creep is through the careful use of terminology. Here’s an example.

After the project’s scope has been agreed upon, the scope is captured in a baseline. This baseline is one of the most important documents in the project. Time and again, everyone from the project team to the stakeholders will return to the baseline. You might say that the project baseline is the reference standard of the entire project.

If you think about it, the baseline captures more than the project scope. It also incorporates the time and costs. The baseline typically takes the form of a tracking Gantt chart. A tracking Gantt shows the actual project’s progress beside the original forecast. The Gantt shows the project’s duration by task. The sum of task durations is the agreed-upon schedule (or time) of the project. The agreed-upon costs are visible behind the chart. The costs are shown by resources and the amount of resources used by individual tasks. These explain why the baseline is so important. It contains the triple constraints of scope, time, and costs.

The baselining, i.e., act of creating the baseline, is typically done at the end of the project planning phase. As the term suggests, the project has been planned and the stakeholders have signed off on the plans.

From that point, the Project Manager (PM) should clearly notify all stakeholders that from this point forward, the team will be strictly adhering to the change control process. The PM must emphasize the seriousness of the change control process. From this point forward, the PM must emphasize that the baselining process must be followed.

An addition, if it is accepted without going through a formal change control process, becomes a requirement. It becomes part of the scope. This is what scope creep is—the scope changes incrementally, i.e., it creeps.

Returning to that earlier example, the PM should instruct his team to never say or use the term “requirements” by itself. Again, never use the term “requirements” by itself with stakeholders and especially customer-stakeholders. Remind them that the scope and project requirements were already agreed upon and documented in the baseline.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using these adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

Any change that pops up after the baseline is not included in the scope. It is referred to as a “preliminary requirement.” It stays preliminary until it goes through the change control process. If the change is accepted, then it turns into a “baselined” requirement.

I consider this to be a best practice for psychological reasons. Stakeholders, especially customers, tend not to take the original requirements of the planning seriously. Consequently, these stakeholders never treat the baseline with respect. Left unchecked, these stakeholders will continually submit new requirements and expect their acceptance without any consequences. That should not be the case. The baseline reflects everything that all stakeholders had agreed upon. Any changes have a “preliminary” nature until they are formally accepted.

It’s a subtle thing that works. Train your team to always make the distinction between preliminary and baselined requirements and the environment will change. Everyone will stay alert and know the difference between the original and the still-unaccepted requirements.

One of the most insidious things that will wreck havoc on your project is scope creep. The term refers to the addition of one addition after another to the original objective. The additions are usually done in a subtle manner and seem minor initially. Unchecked, you may find yourself with an objective that is more complicated, time-consuming, and expensive than the objective that was originally agreed upon.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

One way that a customer or a stakeholder can try to introduce an addition is by insisting that his people meet directly with your people. He insists that he wants the information “raw.” He believes that if the information passes through the project management office (PMO), the information is filtered before it reaches him. As a Project Manager, you may have to permit his people meet your people directly as he requested. However, your permission should be given with the condition that your people are not authorized to accept or otherwise permit any changes to the original project objective. Any proposed additions must go through the PMO. Make sure that your people and theirs acknowledge and agree to that condition—in writing if you think that it’s necessary.

A practical way to create an environment that discourages scope creep is through the careful use of terminology. Here’s an example.

After the project’s scope has been agreed upon, the scope is captured in a baseline. This baseline is one of the most important documents in the project. Time and again, everyone from the project team to the stakeholders will return to the baseline. You might say that the project baseline is the reference standard of the entire project.

If you think about it, the baseline captures more than the project scope. It also incorporates the time and costs. The baseline typically takes the form of a tracking Gantt chart. A tracking Gantt shows the actual project’s progress beside the original forecast. The Gantt shows the project’s duration by task. The sum of task durations is the agreed-upon schedule (or time) of the project. The agreed-upon costs are visible behind the chart. The costs are shown by resources and the amount of resources used by individual tasks. These explain why the baseline is so important. It contains the triple constraints of scope, time, and costs.

The baselining, i.e., act of creating the baseline, is typically done at the end of the project planning phase. As the term suggests, the project has been planned and the stakeholders have signed off on the plans. From that point, the PM should clearly notify all stakeholders that from this point forward, the team will be strictly adhering to the change control process. The PM must emphasize the seriousness of the change control process.

The PM must clearly notify all stakeholders that, from this point forward, the team will be strictly adhering to the change control process. The PM must emphasize the seriousness of the change control process. From this point forward, the PM must emphasize that the baselining process must be followed.

An addition, if it is accepted without going through a formal change control process, becomes a requirement. It becomes part of the scope. This is what scope creep is—the scope changes incrementally, i.e., it creeps.

Returning to that earlier example, the PM should instruct his people to never say or use the term “requirements” by itself. Again, never use the term “requirements” by itself with stakeholders and especially customer-stakeholders. Remind them that the scope and project requirements were already agreed upon and documented in the baseline.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

Any change that pops up after the baseline is not included in the scope. It is referred to as a “preliminary requirement.” It stays preliminary until it goes through the change control process. If the change is accepted, then it turns into a “baselined” requirement.

I consider this to be a best practice for psychological reasons.

Stakeholders, especially customers, have a tendency to not take the original requirements of the planning seriously. Consequently, these stakeholders never treat the baseline with respect. Left unchecked, stakeholders will continually submit new requirements and expect the acceptance of these additions without any consequences. That should not be the case. The baseline reflects everything that all stakeholders had agreed upon. Any changes have a “preliminary” nature until they are formally accepted. The distinction is subtle and should continually be pointed out. Train your team to always make the distinction between preliminary and baselined requirements and the project environment will change.

Through this practice, a PM will not be forced to implement the ban on unauthorized changes alone. Team members will stay alert and know the difference between the original and the still-unaccepted requirements. This involves them in the fight against scope creep. The team helps the PM with one of the most vexing problems that confront a PM during the execution phase of the project, namely, scope creep. Training your team in the manner described above turns the effort to control scope creep into a team effort.

MANAGEMENT: CONDUCTING EFFECTIVE MEETINGS

Meetings can be the biggest time-wasters or progress-markers. It all depends upon following several guidelines.

Numerous articles abound that give advice on this topic. I have my own short list but I’ll first mention several good ones I’ve found on other sites. There won’t be any duplicates.

Sources: effectivemeetings.com, personal experience

DON'T MEET

• Avoid a meeting if the same information can be covered in a memo, e-mail or brief report.

VENUE

• Don't hold the meeting in your office. Meet in a conference room or another office. This enables you to leave the meeting more conveniently.

ASSIGN THE MEETING PREPARATION TASKS

• Give all participants something to prepare for the meeting, and that meeting will take on a new significance to each group member.

MEETING’S PURPOSE

• Keep the number of participants in any meeting to a minimum and ensure that each person attending knows the agenda in advance and why they are attending.
• Know why you’re meeting and ensure everyone knows it. Know what to expect from the meeting.

AGENDA

• Prepare the agenda beforehand and ensure everyone has it.
• Follow the agenda. Start and end the meeting on time.
• Start with the priority items. If time runs out, the most important items will have been covered. The remaining items can usually be postponed to another meeting.
• Create a “complete” agenda. This contains every item that needs to be discussed. The items are organized by priority, by subject, or by any meaningful category.

IS IT A STATUS UPDATE MEETING?

• A well-conducted status meeting works on an exception basis. It uses the same principle of an exception report. This report that contains only those items that stand out as exceptions to the rule. If two projects out of ten have problems, then the report will only go into detail for those two projects.

USE TIME PRESSURE

• Use the 80/20 rule, namely, 80 percent of the work will be accomplished usually during the final 20 percent of the meeting time.
• Try a stand-up meeting.

WHEN TO SCHEDULE THOSE QUICK MEETINGS

• Schedule your 15- to 20-minute meetings at the start of the day. If you learn about problems, you will have the rest of the day to try to resolve it. Then, if necessary, you can hold another brief meeting at the end of the day.

SETTLE ANY POINTS OF AGREEMENT AND DOCUMENT THEM

• Typically, a discussion will ensue regarding an issue. At the right time, the leader or a facilitator should intercede and canvass the participants to determine whether a consensus has been reached.

NO DOMINATION

• Do not let any one person dominate the meeting or agenda.

UNINVITED PEOPLE SHOULD STAY OUT

• Prevent uninvited people from joining the meeting.
• Depending upon the environment, some bosses like to drop in unexpectedly. Although they certainly have the power to do so, their presence can inhibit participation. Furthermore, more people at a meeting tend to slow down the meeting.
• Place a "Do Not Disturb" sign on your door when you don't want to be interrupted.
• Diplomatically inquire about the purpose of the person’s presence at a meeting. If it doesn’t make sense, politely request that person to leave.
• Stand up when someone enters your office, and meet them at the door. If you and your visitor remain standing the meeting will tend to be shorter.
• Remove any extra chairs from the meeting room or stack your books and papers on top of any extra chairs. If you change your mind about unexpected visitors, you can always remove the books and papers.

THE HALO EFFECT

A Book Review


A BRIEF BACKGROUND

Consulting firms have their place in the business world. These organizations abound with brainpower armed with advanced academic degrees. That's wonderful. Most of the time, these firms do a great job of providing insightful answers to problems that bedevil management. When management is too close to the trees to be able to objectively evaluate the challenges confronting them, consultants can be a big help.

What's the connection? Two fairly recent prominent business management books, "Good to Great" and its companion follow-up best-seller, "Built to Last,” were written by consultants.

Mr. Jim Collins, a former McKinsey consultant, authored the first singlehandedly and, for the second, co-authored it with Mr. Porras.

NOW THAT YOU KNOW…

In "The Halo Effect" it’s author, Professor Phil Rosenzweig held "Good to Great" and "Built to Last" as the primary subjects of his argument about the "halo effect."

The good professor points out that both tomes used hindsight to unearth the success factors that made the companies in their respective lists such standouts. The problem with that approach, Rosenzweig points out, is that hindsight—as the saying goes—is 20/20.

Take two boys who grow up in the same village. One becomes the company president while the other never rises beyond the rank of junior manager. From the vantage point of the villagers, could they have foreseen who was going to become what? Maybe but probably not. On the other hand, if that question was tackled by starting from the present and then having their careers retraced back to their youth, the factors that made them into what they are can be easily discovered.

That's the fallacy inherent in basing analysis on hindsight. You'll always come up with answers.

Are they the correct answers? Not necessarily. Assume, for example, that the president rose through the financial ranks of the company. Does the fact that he graduated with an accounting degree constitute a valid success factor? Of course not. If that accounting degree was present in the biographies of 99 other company presidents, does that now make it a valid success factor? I still think not. And yet that's how the authors of both books presented their case. They used an expanded sample population and retraced the path of each company that made it to each book's list. They then isolated the factors that appeared in every company's path. Aha!, they said. These are the common factors that propelled these companies into our list. Now, they stated, we know what works. From that, the authors proceeded to make broad extrapolations about how the reader might use these factors to make their own companies successful.

I did what the professor did. I checked the standing of many of the companies in the first book, “Good to Great.” I came up with a review of mixed results. Using the same measure that the book used, some companies were doing well, most had become average, and a few were lagging.

Take CIRCUIT CITY, for instance.

Back in March 2007, less than five and a half years after it became “great,” Circuit City was in doo-doo. Here’s a quote from The Motley Fool:

Nice going, Circuit City (NYSE: CC). You may have just axed some of your top store associates—and deflated the aspirations of the rest.

The consumer-electronics superstore's move to fire some of its pricier employees makes sense on the surface. The company announced that it was letting go 3,400 unit-level associates who were earning salaries well above the market average. They will be replaced by more nominally salaried hires.

So make a note to call your slacker nephew and let him know that Circuit City is hiring. But am I the only one worried about the implications here? Nobody gets their pay bumped higher because they're incompetent. Whether they're seasoned associates who know the stores inside out, or employees whose hard work has helped them get aggressively promoted, they're paid well for a reason. How many high-def DVD players will you be able to sell with that green associate who doesn't know the difference between Blu-ray and HD-DVD?

If I can make the obvious joke, you're a real firedog, Circuit City. It's not just that you're letting go what may be some of your productive associates. What kind of message does this send to your remaining hires? Don't overachieve. Lay low. Do just enough to stay with the pack.

I'm already dreading my next trip to Circuit City, when I ask for help and everyone runs the other way, as if I just pulled the pin on a grenade.

To be fair, Circuit City isn't just whittling away on the front line. It's also eliminating about 130 corporate jobs by outsourcing its IT infrastructure needs to IBM (NYSE: IBM). Last month, it announced a regional-level realignment that also trimmed some fat.

I get it, C.C. Consumer electronics isn't always a cakewalk. Best Buy (NYSE: BBY) is eating your lunch, and now companies like Wal-Mart (NYSE: WMT) and even Home Depot (NYSE: HD) are making an aggressive push in this niche. You have to keep your cost structure in line.

But do you really know what you're doing? You just handed over 3,401 pink slips at the store level. Yes, I said 3,401. You're canning 3,400 store associates, but you're also handing morale its walking papers.

What happened? After all, Publishers Weekly mentioned Circuit City in its editorial review of “Good to Great”:

To find the keys to greatness, Collins's 21-person research team (at his management research firm) read and coded 6,000 articles, generated more than 2,000 pages of interview transcripts and created 384 megabytes of computer data in a five-year project.

That Collins is able to distill the findings into a cogent, well-argued and instructive guide is a testament to his writing skills.

After establishing a definition of a good-to-great transition that involves a 10-year fallow period followed by 15 years of increased profits, Collins's crew combed through every company that has made the Fortune 500 (approximately 1,400) and found 11 that met their criteria, including Walgreens, Kimberly Clark and Circuit City.

At the heart of the findings about these companies' stellar successes is what Collins calls the Hedgehog Concept, a product or service that leads a company to outshine all worldwide competitors, that drives a company's economic engine and that a company is passionate about.

An even easier way to check the validity of these so-called success factors is to compare the list in both books. Surely a company that had transitioned from good to great would stay great enough to ensure that it was built to last. Right?

Wrong.

I have to agree with the professor. There is no success formula embodied in the advice proffered by that book. Those nuggets of advice are misleading. The advice is misleading because their source—the research results—are flawed. The research results are flawed because the research assumption is flawed. What is that assumption? It differs slightly for these two books but it could be roughly stated as such: "Isolate the common factors behind the success of these companies—the ones that made it to our list. Extrapolate the lessons from those few common factors and write a best-seller." Or two.

And that's exactly what he/they did!

So, you might ask, after tearing down those two modern-day bibles of business management, what’s left? What does “The Halo Effect” think of success formulas? What about the objective, that elusive thing called SUCCESS? Well, you have to read that for yourself but the professor did remind me of something that’s overlooked too often and that’s the fact that success is relative.

I've read the two management books (by Collins and Porras) and I'm certain the reader will learn from and enjoy each one. However, after reading "The Halo Effect" (and agreeing with it), I know now that neither "Good to Great" nor "Built to Last" reveal any good, great, or everlasting secrets of business success.