Medium 9781567262056

The Six Dimensions of Project Management

Views: 114
Ratings: (0)
Master the Six Dimensions of the Project Management Universe!
Learn how to turn constraints into resources to achieve project objectives! Through case studies and practical exercises, The Six Dimensions of Project Management demonstrates the six possible combinations (or dimensions) of the “hierarchy of constraints"" (time, cost, and performance existing in a hierarchy of driver, middle and weak constraint) and the specific set of challenges and opportunities associated with each. Project managers will learn how to recognize a project's dimension and, by understanding its set of problems and resources, get the job done on time, on budget, and to spec!

You will uncover hidden flexibility, unlock valuable new resources, discover threats before they turn into problems, and win the admiration of customers and projects sponsors alike. You'll learn:
•How to use the “inner purpose” of a project to empower project mangers and team players
•Why certain kinds of failure point the way to higher levels of success
•What creates opposition to your project—and how to leverage it for your benefit
•Where to look to find creative opportunities on every project

List price: $59.95

Your Price: $44.96

You Save: 25%

Remix
Remove
 

10 Chapters

Format Buy Remix

CHAPTER 1 Into the Sixth Dimension!

ePub

We grow sometimes in one dimension and not in another; unevenly. We grow partially. We are relative. We are mature in one realm, childish in another.

—Anais Nin

Management writers have pillaged the lives of leaders both real (Attila the Hun) and fictional (Jean-Luc “Make-It-So” Picard of the starship Enterprise) to illustrate the principles of management effectiveness, even going so far as to call our attention to the royal companions of Oz who join Dorothy in her quest to find the wizard: what a leader I could be “if I only had a brain … a heart … the noive!”1

Project management is a discipline of the trenches, however, not of the classroom. A Guide to the Project Management Body of Knowledge® (PMBOK® Guide2) notwithstanding, that which is valuable and vital in the project management body of knowledge was developed primarily by practicing project managers, with the peculiar heroism that is specific to the breed. Traditionally, the project manager struggles with inadequate resources and a too-tight schedule while striving toward excellence—and surprisingly often achieves it. And this achievement comes in the face of a lack of sufficient formal positional authority, customers who may not know what they want (but who nevertheless recognize when you don’t give it to them), and an environment in which project objectives mutate like fungus in a cheap horror movie.

 

CHAPTER 2 Succeeding and Failing on Constraint Management

ePub

… Then, yielding to our intellectual onset, the gates of the Sixth Dimension shall fly open; after that a Seventh …

—A. Square, in Flatland: A Romance of Many Dimensions,
by Edwin A. Abbott (1884)

Skeptics and reluctant learners abound—and your authors have more than once been included in that number. Organizations ask, “What’s the ROI?” and the team member asks “What’s the WIIFM?”1 These are both good questions. We begin, therefore, with two case studies illustrating the payoff to be had by understanding a project’s hierarchy of constraints.

These two case studies both involve NASA. The differing outcomes have little to do with luck, as some might contend (although being lucky matters—Napoleon demanded it of his generals). Rather, they have a great deal more to do with how the project teams understood their missions and how they leveraged what flexibility they could find.

May you live in interesting times.

 

CHAPTER 3 The Triple Constraints

ePub

A project exists inside an organization or system. Like many seemingly benign statements about a project—temporary and unique, for example—characteristics that appear obvious on the face of it often have consequences that are much less obvious.

An organization or system has nearly an infinite amount of useful, desirable work that could be done, but it has limited and finite resources available with which to do that work. Choices must be made. And each choice consumes resources that otherwise could serve a different need.

Although we’ve made the choices we (or someone else) presumably think are best, if we use our limited resources efficiently, we get to accomplish more. If we give you a spendable resource, such as cash, or a resource allocated over time, like a person, for your project, we can’t use that same resource to achieve something else.

That’s why “the squeeze” is among the first techniques almost any manager learns. Budgets and schedules normally can take some degree of squeezing, and if the project can be accomplished with less, that’s good for the organization. (There are managers who seem never to learn any technique other than the squeeze, but that’s a different issue. When the only tool you have is a hammer, all problems look like nails.)

 

CHAPTER 4 The Hierarchy of Constraints

ePub

We’ve identified that one of the most powerful secrets of the triple constraints comes from ranking them in the order of their priority and impact on the project: deciding which pig is more equal than the other two.

The three terms we use to describe the hierarchy of the triple constraints are:

•  Driver

•  Middle constraint

•  Weak constraint.

The driver is the leg of the triple constraint that cannot fail without dragging the rest of the project down to failure along with it. Flexibility of the driver is not necessarily zero, but it has less flexibility than the other two legs. The consequence of failure is serious, visible, and inexcusable despite the level of success achieved in the remaining legs, even if the success was ahead of expectations. “We built a really great CO2 filter using half as many parts!” doesn’t even begin to mitigate the consequence of having taken too long.

Besides the obvious characteristic of being, well, in the middle, the middle constraint normally has a small amount of flexibility. Middle constraints sometimes can be quite close to the driver in terms of their importance to the project mission, almost seeming like a second driver. Other times, only the driver is strict and the middle constraint has flexibility more akin to the weak constraint. In the first case, you’ll seek almost all your flexibility in the weak constraint; in the latter, you have two constraints with which to play.

 

CHAPTER 5 Powers of Six

ePub

If I knew where I was sailing from, I could calculate where I was sailing to.

—“Number Six” (Patrick McGoohan),
The Prisoner (1960s television series)

As we’ve noted, the six dimensions of project management result from the six possible combinations of driver, middle constraint, and weak constraint. Each project, of course, remains “temporary and unique,” but unique only in some respects. In other respects, similarities exist. In each of the six dimensions, all projects with the same hierarchy of constraints contain common elements. By understanding the nature of each dimension, you can apply a series of insights to your project in its own dimensions, increasing your power and effectiveness as a project manager.

When time is the project driver, there’s a deadline of some sort after which the project is either irrelevant or at least worth substantially less. If the CO2 exchanger is late, there’s no point in continuing the project. If the Soviet Union beats the United States to the moon, however, it’s still important that NASA goes too, if only to demonstrate parity. However, the project produces significantly fewer benefits than if the United States wins the race.

 

CHAPTER 6 Strategies for Managing Time-Driven Projects

ePub

Many project management tools have a structural bias in favor of time as the driver. Cost management tools are derived for the most part from their counterparts in the finance and accounting world, reasonably enough (with the notable exception of Earned Value Method Analysis). Performance management tools are necessarily topic-specific tools. And those most famously associated with the project manager’s toolbox—the Gantt Chart, Program Evaluation and Review Technique (PERT), and Critical Path Method (CPM)—primarily manage the time constraint. After all, the characteristic that all projects have in common is that they end, or at least they’re supposed to.

The seriousness with which the project manager should enforce deadlines must be related to the relative importance of coming in on budget or achieving an exceptional level of performance. If meeting the deadline forces compromises in budget or performance, it may be better for the project to choose delay.

The Apollo 13 CO2 exchanger was a time-driven project. If not completed before the astronauts ran out of breathable air, it would be pointless to complete it at all. The consequences of failing to meet the deadline could not be undone. The right answer was to meet the schedule first, making compromises somewhere else, if necessary.

 

CHAPTER 7 Strategies for Managing Performance-Driven Projects

ePub

When the performance criteria drive the projects, the technically oriented project manager often feels that quality is in the driver’s seat. As we’ve observed, it’s important to distinguish between performance criteria and quality. Quality is what they want. Performance is what you do. Clearly, the two are related—but they’re not identical.

Salespeople are taught to distinguish between “features” and “benefits.” The feature is a specific characteristic of the product or service itself, such as the chip speed or hard drive size. The benefit is what value it provides the customer—a large hard drive can store your teenager’s entire collection of illegally downloaded music, or, more professionally, let you keep all the information from several major projects together on your laptop at the same time.

In our triple constraints model, the “benefit” is the why of the project, and the “feature” is the description of what it is we must perform. As part of the process of project scope management, PMBOK® Guide, Section 5.1.1.1 states, “The product description should also document the relationship between the product or service being created and the business need or other stimulus that gave rise to the project” in a way that is detailed enough to support later planning.1 In other words, the “why” must be part of a properly written product description to ensure full understanding of the characteristics and requirements that must be achieved.

 

CHAPTER 8 Strategies for Managing Cost-Driven Projects

ePub

When the cost constraint is the driver of the project, there’s a problem. A project should contribute substantially more value than it should cost, or there’s a real question whether we should be doing the project at all. Therefore, “normal” projects usually have some cost flexibility.

If that’s true, then why would cost ever become the driver? First, because the resources simply aren’t available or they don’t exist. As we’ve observed on the Apollo 13 CO2 filter project, the lives of the astronauts were worth a lot more money than the parts on the table, but the cost constraint was nonnegotiable; it was simply a fact. If the resources aren’t there, the fact that you might need them—even that lives might depend on them—is unfortunately beside the point.

Second, cost might be the driver if the project has a low priority in the organization. It’s worth doing, but other projects have a higher value, and there aren’t enough resources for all projects to be funded generously. If you have a low-status project, it’s part of your responsibility to yield right-of-way (and resources) to higher-status projects. Of course, you could legitimately make a case for increasing the project’s priority, as long as you do so with an understanding of the organizational issues at stake. It’s also legitimate to argue that the project has such low priority (and claim on organizational resources) that it is better to put it out of its misery. After all, we remember the project management lesson in the classic Disney film Old Yeller: sometimes a man’s got to be able to shoot his own dog.1

 

CHAPTER 9 Conflict Management and Multiple Stakeholders

ePub

In the ideal project management world, customers and senior managers make project decisions based on organizational mission, vision, and values. These decisions are clear, unambiguous, and without hidden political agendas. Your mission, Jim (should you decide to accept it),1 may be challenging, but it’s fair. Often that’s the way it is.

But sometimes it isn’t. There is often variance in how different people answer, “Why do I care about this project?” If the variance is small, there are few opportunities for conflict. If the variance is large, conflict is much more likely. People see the triple constraints differently, and conflict erupts over issues of schedule, resource use, and performance.

If you’re the project manager, then you know what it’s like to be the captain of the S.S. Minnow on a three-hour cruise.2 If you ask each stakeholder, “Why are we doing this project?” you will get different answers, and with each answer, you will end up with a different set of triple constraints and, worse yet, a different hierarchy of constraints.

 

CHAPTER 10 The Power of Three

ePub

Perhaps Hollywood really should make movies about project managers, because a peculiar heroism is specific to the breed. Traditionally, project managers struggle with inadequate resources and too-tight schedules while striving toward excellence—and surprisingly often they achieve it. And this achievement comes in the face of a lack of sufficient formal positional authority, customers who may not know what they want (but who nevertheless recognize when you don’t give it to them), and an environment in which project objectives mutate like fungus in a cheap horror movie.

Good project management processes—and, more important, good project management thinking—make a difference. Using triple constraints analysis on your project will set you up for earlier and better success. And that’s the way, as P.T. Barnum famously observed, to the egress.1

We’re reminded that when that modified CO2 filter was bungeed to the wall and the levels were dropping to a safe level, a console operator looked at one of the now-relieved engineers who’d designed the work-around and said, “You, sir, are a steely-eyed missileman.”

 

Details

Print Book
E-Books
Chapters

Format name
ePub
Encrypted
No
Sku
BPE0000250076
Isbn
9781567263909
File size
3.03 MB
Printing
Allowed
Copying
Allowed
Read aloud
Allowed
Format name
ePub
Encrypted
No
Printing
Allowed
Copying
Allowed
Read aloud
Allowed
Sku
In metadata
Isbn
In metadata
File size
In metadata