

### SIMMER DOWN!

### How to Deliver Great Projects Despite Impossible Deadlines and Unrealistic Budgets

Copyright 2017 Douglas Brown

Published by Caltrop Press, via Smashwords

This book is also available in physical form from most online retailers

Smashwords Edition License Notes

Thank you for downloading this ebook. This book remains the copyrighted property of the author, and may not be redistributed to others for commercial or non-commercial purposes.

Even if you obtained it at no cost, there is value in the total number of people who actually download it. If you enjoyed this book, please encourage your friends to download their own copy from their favorite authorized retailer. Thank you for your support..

Get Even More Value

As a thank-you for being interested enough to download this book, please enjoy another free resource: Seven Ways Organizations Resist Change and How to Get Around Them

Starting up project management (or program management, enterprise architecture, process engineering, quality management, etc. etc.) is a change. Of course, for the better: more efficient, faster, better quality, and so on. Even so, not everyone is going to be on board with the change. Some will be working to make sure you don't succeed.

You and I won't change human nature. But we can be prepared for how others might interpret our well-meaning efforts, and we can tailor our approaches to the situation.

Send it to me!!

(You'll be getting it from www.decisionintegration.com, where you'll find other free resources too).

What People Are Saying ...

Before getting into the very nice things that people said about the book, I'd like to thank some wonderful people who gave it the ultimate endorsement: spending many hours, even during personal and business travel, to provide detailed edits and broad insights to help me make sure this book was up to the professional and editorial standard you have a right to expect (even at this price!).

  * Bob Hutchinson, President of RAH Consulting (<https://www.linkedin.com/in/robert-hutchinson-89392748/>) provides subject matter expertise and consulting services covering all aspects of business development and operational management improvement to small businesses.

  * Sheila Proudfoot is a career professional project and program manager.

  * Brian Hobbs is a business development executive with BAE Systems.

  * Frank Greco, the President of Greco Consulting (http://www.GrecoInc.com), whose quote is cited further just below.

*******

Now, about all those nice things people had to say: thank you for your support!

*******

Nice job. Not a book that you can do in one sitting, but good information. One important area that is touched upon throughout the book, and is hammered home ... stakeholder communication starts early and is done often. A PM must identify and know the project stakeholders to understand what the project really is. ... The PM must strive to manage within the bounds of the Iron Triangle, but must be objective enough to accept that many projects die, for numerous reasons: changing requirements, obsolescence, or money is diverted to other priorities. If a project dies of natural causes, move on and go to the next project.

_Greg Gephart,_ _Program Manager, US Customs and Border Patrol._

This book needs a second edition that is twice the size!

_Randy Luten,_ _CEO, Advanced Systems Design_

Just by reading the title you can tell that the author knows a lot about project management. 60% of a project's success is in the planning. Read the book today and learn how to avoid boiling your projects.

_Patrick Gallagher_ _, LinkedIn Author,_ <http://mybook.to/LinkedInSecurity>

"Simmer Down" offers tips for junior project as well as senior program managers. A quick read that boils down the basics, dispels the myths, and offers perspective on the methods employed by both industry and government project and program management. If you've ever had a project or program that's been stuck in a rut, this book is a MUST READ!

_Sheila Proudfoot_ _, Program Manager_

Doug packs much insight, wisdom, and sound advice into this book, and peppers it with amusing but serious observations of large-enterprise reality – making it a quick and enjoyable read. You will be a better project manager after absorbing it.

_Peter Gordon, PMP_ _, Program Manager, Hewlett-Packard,_ <https://www.linkedin.com/in/petergordon4/>

Dr Brown understands how to change attitudes, put a new paradigm in place, and turn an organization around by letting it simmer. After reading his book, you will as well.

_Jim O'Connor, Ph.D_ _., Program manager, Booz Allen Hamilton._

As I read through this book, I kept being reminded of any number of events in the past year, three years, ten years. This is exactly how it happens. I need to get some more copies of this for my staff so they can learn about how things really work and deal with it, before having to figure it out the hard way.

_Dade Bridgeman_ _, Programme Manager, Vodafone_

Another of Dr. Brown's books that share a career's worth of organizational realities and how to navigate them in a way that is easily understood. More importantly, it is easy to go out and do the things he suggests. PMPs need to pass their exams on the theory of PM, but then after that they need to get this book to find out how projects really work in organizations. On top of that, it's an easy read!

_Lynn Padgett_ _, Vice President, medical education association_

Enjoyed it, good job! It's logical, it's easy to understand, and it's worth reading the book just to get to a couple of gems like these: you need to understand the context within which you have to operate, and how to maneuver within that space to get the best result you can out of the resources that are or may become available. And, 'don't get caught out now being just another complainer with no real solutions. Be prepared with a realistic plan for getting the job done properly'. There are plenty more where that came from.

_Dr. Frank Greco_ _, President, Greco Research Engineering_

Engineering, program management business development, and consulting services

http://www.GrecoInc.com _._

Simmer Down! continues beyond where the formal standards for program and project management leave off. This book provides the project manager (PM) with real-world guidelines for managing projects and dealing with stakeholders from the Board of Directors to the Program Office to the eventual customers. An important and useful addition to every PM's tool chest.

_Harold Hunt_ _, PMP, Principal Consultant,_ Grantonomics LLC

Table of Contents

Who Is This Book For?

What Will You Get From This Book?

Chapter 1. We've Been There Too

The Theory According to Practice Standards

Theory Meets Reality

Where Do Projects Come From?

So Many Cooks

Business Rule Number One

Chapter 2. Seeing The Big Picture

The Big Picture

Corporate Context

Vision

Environment

Strategy

Capability

Programs

Chapter 3: Show Me the Money

Slicing the Pie

Key Tips for Fitting into the Strategy

Chapter 4. The Rack and Stack Illusion

How We Don't Do It: Decisions by Spreadsheet

Rack and Stack Case Study

How Your Broker Really Does It

How Some People Do It: The Grab Bag

Salami Is Baloney

How Organizations Actually Do It: Don't Look

Chapter 5: It's Your Turn

Introducing The Project

The Clock Keeps Ticking

Key Tips for Getting Your Investment Selected

Chapter 6. Tweak Those Baselines

It Depends on the Meaning of "It"

The Iron Triangle Again

The Obvious Solution: Adjust Scope

Bending The Iron: A Case Study

Not So Likely: Adjust Schedule

There's No More Money, But It Always Appears

Dealing with Impossible Constraints

Chapter 7. Learning to Love your Baselines

Executive Reviews and Redirection

Dependency Reviews

Technical Reviews

Change Control

Key Tips for the Control Phase

Chapter 8. Closing Out

The Big Picture

Pay It Forward

About The Author

Get Even More Value

One Last Thing...

Acknowledgements

Who Is This Book For?

Bottom line up front: this book is about why projects don't start out the way some book told you to do it, and how to succeed anyway. If you already know, then give it to someone who doesn't, so they don't have to learn the hard way.

If you think that every project runs "by the book", then maybe it's not for you. But please do contact me! There are thousands of professionals in this space who would really like to get a look at **that** book. Let's get it out to them.

For the newly-trained project manager (PM), your certification cram course instructor told you to suspend the reality you know if you want to pass the exam. Simmer Down brings you back from exam world to the real world. You can't change reality, but you can manage it.

Simmer Down is not just for newbies. After your early projects succeed, you'll end up managing other PMs. What you know best is "doing PM." In your higher role, you can't do that for every project; that's **their** job now. What should **you** do? You set the stage for your PMs to succeed. Simmer Down describes that stage.

If you are an experienced program manager, you want to mentor individual PMs to grow in understanding their craft. You'll certainly have to deal with the #1 complaint of PMs (see the next section!). Just give them this book before you give them their project's time and money constraints. Instead of complaining about how unfair everything is, perhaps they'll Simmer Down and make your life easier by presenting you with the information and ideas that make the program run better.

## WHAT WILL YOU GET FROM THIS BOOK?

This book explains how you can deal with, or help your colleagues deal with, one of the frustrations that PMs express most often: unreasonable deadlines and budgets handed out on Day One. You're certainly not alone, and you can succeed in this. You just have to know how.

In consulting engagements with dozens of organizations, many of the PMs have told me: " _We don't do project management here. What we do is pray for miracles. I get handed arbitrary budgets and deadlines with no prior analysis, before anybody has given any thought to what the project is all about, and then I'm expected to somehow make it all work out. We simply can't get there from here. I foresee a disaster. Then the next PM will get more time, tons of money and all the credit_."

Well, it certainly isn't project management as envisioned by the Project Management Body of Knowledge (PMBoK) or the other standards of practice out there.

It is project management in the more practical sense that this is how the job really is. Not just your job. Most PMs have encountered this frustration. It takes a few hard knocks over quite some time until you start seeing how this problem works. This book's for you. The better you understand what's going on, the better prepared you'll be to deal with it, and the better the outcome you'll be able to create.

Even if you just run one-off freelance projects, you face the same challenges. Customers change their minds or they cancel, even though you both recognize that the need hasn't changed. It's not unfair, and it's not personal (at least, I hope not). The customers exist within a larger context which itself is subject to internal and external realities.

At each level of the organization, the people in the levels below yours may seem to be progressively less cooperative and more interested in protecting their turf. Meanwhile, the people in the levels above you may appear to be increasingly unaware of practical realities and increasingly demanding of doing much, much more with much, much less.

Don't get too smug. From their position, they think exactly the same thing about you!

Understanding this challenge, and knowing what to do about it, is one of the major steps in the professional growth of a project manager.

Let's be clear: this book isn't a primer on everything you need to know about project and program management. It's not a replacement for the PMBoK and all those other great resources. What it does do is bridge the gap between the model behavior they recommend and the reality that you often experience. You can't play the game effectively if you have no idea what the rules are.

Because this topic is so important to the professional growth of a PM (and, to be honest, because the market is small enough that I'm not going to make thousands of dollars from this title anyway), I've decided to make the electronic version available to the project management community for free (or at least as close to it as the publishers will allow, since some won't permit you to use their platforms to "sell" books that are free. Others will). Of course, you might want to buy the paperback as a gift for a rising star: I've also kept that price as low as I can given Amazon's pricing models.

For access to more materials about a wider range of practical solutions to management issues, including various papers, a blog, video clips and information about my other books, then head on over to my main website (www.DecisionIntegration.com).

And don't forget to collect another short, useful, fun, free booklet on overcoming opposition to doing PM in the first place:

Send me the booklet !!

Thanks for deciding to read this book!

Chapter One. We've Been There Too

Let's go to instant replay for a few seconds.

" _What we do here is pray for miracles. I get handed arbitrary budgets and deadlines before anybody has given any thought to what the project is all about, and then I'm expected to somehow make it all work out_ ".

How many times have you had this thought, or heard another project manager (PM) say it out loud (well, maybe in a whisper)? Shouldn't the theory match the facts on the ground at least once in a while? Or are these folks just whining?

## THE THEORY ACCORDING TO PRACTICE STANDARDS

The leading standard for project management practices (in the USA at least) is published by the Project Management Institute. Yes, I know there are other accrediting bodies and other views on what's "best", so you can hold off on the cards and letters of aggrieved objections (although for Amazon purposes it might be better if you did post comments about this, so go right ahead!). The fact is that hundreds of thousands of project managers have trained on that standard, so let's start from there.

The "standard" way (that is, the way according to the best-practice standard) of starting a project, then, is to:

  * Develop a charter

  * Develop the requirements and a general approach

  * Develop a work breakdown structure

  * Work out the schedule and cost

  * Get approval for all that and establish a baseline

Well, that seems pretty reasonable. Except for four problems.

1. Approving a charter for a project that is truly "new", appearing out of the blue (or fresh out of your head), means that the organization is committing money that it does not have by diverting resources from projects that already got approved for work that also needs to be done. Those projects already have enough support to have gotten funding in the first place. In asking for a new project, you're asking for money to be taken from their projects. That will narrow your circle of friends!

2. It could take months just to get the requirements and approaches defined enough to put together a really solid cost and schedule estimate that a competent PM and execution team would be willing to stand behind. We can't do all that without any resources, and we can't wait that long to get started.

3. In most organizations, resources have to be programmed into a budget in a formal process that precedes the actual work by months if not years. You can't refuse to provide a number if you want any money. If the number's too big, you won't get any funding at all, so there's pressure to keep it small, perhaps too small. Unfortunately, the reality is that in many organizations, once you provide the number, that's the number.

4. In most organizations, because of formal budgeting and approval processes, by the time the word gets to you that you're even on the project, the number is already the number. Done, cooked, sealed: whatever word you want to use, those arguments are already over. This book isn't about how to change that reality, since you won't. It's about how to deal with it and still come out looking good.

## THEORY MEETS REALITY

Because of those practical problems, actual practice varies from the standard. Depending, of course, on what the meaning of "standard" is. We just listed the steps in the "standard" way, meaning "as defined by the standard", or the way that the professional community thinks it's supposed to work.

There's a much more common understanding of the word "standard," meaning "what is usually done".

Using that meaning, the standard sequence (which you certainly won't confuse with "best practices"!) is usually something more like this:

1. The sales team or internal advocates meet with stakeholders, talk loosely about what they're going to do, and try to convince the customer that what they want can be done quickly and affordably. Maybe they hold informal discussions about possible delivery dates and prices, optimistic to avoid scaring away a potential paying customer. The stakeholders talk about how important this is to them and lead the sellers to believe that price is hardly even a consideration if they can just get this problem solved.

2. The sales team manager, hoping to motivate the closing sales rep, loads the sales pipeline report with an optimistic revenue number for which the sales staff will now be held accountable. Meanwhile the buyer puts the understated cost and optimistic delivery date place-holders into the organization budget, at which point the back-of-the-envelope number inevitably turns into a baseline.

3. The PM, who wasn't involved in any of those discussions, is appointed to the team and develops a charter (often skipped).

4. The PM develops a work breakdown structure and schedule and starts reporting on the project against that schedule

5. The project team decides on a solution (if it wasn't agreed to earlier) and begins working on it.

6. The project team gets into areas of the solution that create some debate and begins to develop the requirements, often without the stakeholders who don't have time for all that (especially since the solution's already known).

7. The stakeholders start complaining about the lack of progress and the project team complains about the amount of rework due to the ever-emerging requirements.

8. Everybody starts casting doubt on the project manager's competence.

That might help to explain why projects so often appear to fail. By "best practice" standards, this project has been set up to fail from the very beginning. Cost and schedule commitments were made long before the requirements were understood. The PM doesn't stand a chance.

That may be the way it seems. You may even be dealing with just such a situation right now; that might be one of the reasons you decided to buy this book.

The good news is that all is not lost. As with many things in real life, things are not always exactly as they seem to be.

## WHERE DO PROJECTS COME FROM?

How did we ever get ourselves into this mess? More importantly, how are we going to get out of the mess and start gaining control of the situation?

The answer is in the different perspectives of the participants in the "real-world" scenario we just alluded to. The understandings were vague, and each party crystallized the part that was important to them — but only that part. Every other part offers an avenue for resolving what seems to be an impasse.

### You're Not Alone

Project management practices largely treat projects as if they exist in isolation and can be managed as completely independent entities. Sure, we recognize the existence of the stakeholders; perhaps tellingly, this is actually a relatively recent development in the PMBoK.

In this view, the role of the PM is rather simple to state. The PM is responsible for delivering the agreed product, by the agreed delivery date, within the assigned budget. (Please note that I didn't say it was easy or simple to actually do it).

Ideally, but infrequently, the PM can drive the solution through to the point that the solution is not just compliant with the constraints but actually succeeds in delighting the customer. Achieving those goals would be very praiseworthy, given that barely half of all projects succeed in meeting any of those goals, let alone all three. But notice that these objectives do not look beyond the immediate project.

In very small organizations that only run one or two projects, a project can be self-contained. For the vast majority of projects, think back to the frustrating fact that key resource decisions had to be made well before the project actually came into existence.

Egg, meet the chicken.

### Introducing the Program

Most projects actually exist as components of large, long-term undertakings that we call programs.

Programs are very much the mystery man in current management, both in literature and in practice.

It's been very popular in recent years to characterize the government as inept, but the truth is that modern project management practices in business and government alike stem from highly successful mid-1900s government programs such as ... well, the Manhattan Project, which was definitely more than one project and in many ways is still with us today, which makes it sound a lot more like a program. You can see where the confusion in terms begins!

The PMBoK describes programs as a collection of activities, most of which are projects, but also possibly including some operational (non-project) activities. The point of this collection remains undefined. That may be understandable, given PMI's need to generate consensus before publishing a standard, but it isn't very illuminating.

PMI also publishes a Practice Standard for Program Management, which does a fine job of laying out how to set up a program but doesn't offer much in the way of explaining why you might want to do that.

Operational activities are mentioned exactly once in each of those two publications as a passing remark within a paragraph on what a program is. I will hazard a guess that this happened because PMI is a community of project managers, and the top notch authors are firmly attuned to their audience's primary interest, which is how to excel in getting even one project wrangled through to completion Even with many years of experience and excellence at the project level, it always seems to come as a surprise, when a PM arrives at the level of the organization that sees more than one project, to discover that things appear rather different when you are not the only game in town.

Corporations don't often use the term "program", and where they do, they are pretty inconsistent about what the term means.

So back we go to the government. If you live and work inside or around the Washington Beltway, then you know that the government is largely driven by the concept of "programming". That term, which is little known or appreciated outside government (and often a mystery to those within it) is the method of allocating funds against large, general and fairly long-term objectives. Some agencies are better than others in how they handle this.

It's interesting that most senior government managers are very familiar with programming activities, but far fewer actually understand what a program is, even though they just finished allocating money to it.

The US Department of Defense (DoD) has a very useful concept of "capabilities": things the organization can do. The idea of a program is to establish and maintain a set of capabilities into the foreseeable future. This thought process is very helpful in understanding how this picture fits together. It focuses on doing what you have to do to create and sustain the capability, rather than doing projects because they seem like a good idea at the time.

Programs begin by starting projects to achieve the initial capabilities, but then they must sustain those capabilities over time. That's usually a very long time. Most of them seem to have always been there, and as far as anyone can tell, they always will be there, because nobody has yet figured out how to get rid of one. That's where the operational activities come in. Once the innovative period is over, the operations teams stay in place as long as they continue to deliver the desired capability effectively and with reasonable efficiency.

When the program manager can foresee that the program won't be able to do that anymore, then the program needs to crank up some more projects to make sure that there is a viable solution in place at the right time so the original solution can be retired.

Programs manage a continuing capability that is maintained by a cycle of innovations (projects) that are handed off to operations. When, preferably before, those solutions become obsolete, a new project launches to bring the capability up to the point of being able to meet the need for some further time into the future. When ready, that project is handed off to become the new operating capability. On it goes until the capability that the program delivers is not needed any more.

Theoretically, programs. like the projects that exist within them, have a beginning, a middle and an end. In practice, they often get started as pilots or innovations, before anybody can be sure that the initial solution concept does meet the need. Later, once the organization realizes that it needs to sustain this capability for the long term, then the program gets formalized. So, formally or otherwise, the program may have existed long before you got to the organization, and usually it stays in place for so long that you'll be retired before the organization decides it just doesn't need that capability any more.

### Making Program Decisions

Understanding that the project is just a means to the program's end really changes the view of what a project's objective is. For most PMs, as they prove their ability to deliver successfully, each project they work on gets bigger and more important, and so each project is the most important thing the PM has ever done. It's also their pathway to the next step in professional advancement. They feel personally threatened if events conspire to place obstacles in the way of the best possible result.

The program sees the project as just one of several parts that must work together to deliver the best result on a much wider front over a long period of time. Since there are limits to the resources the organization can call on, it has to balance its investments in all the possible capabilities, and in turn the programs have to make internal tradeoffs to deliver as much as they can for as long as they can.

Sometimes that means shifting resources away from one project, no matter how successful it has been or how cost-effective it promises to be, in order to reinforce success in another capability that delivers even more benefit or, perhaps, needs to be replaced more quickly. Where revenue forecasts are fluid or declining, the organization may feel compelled to protect the ongoing assets it has, and abandon investments in innovation (perhaps the very innovations that would catapult the organization out of the quicksand). Or, particularly frustrating, resources have to be diverted to shore up projects or operations that can't be turned off and aren't meeting expectations.

Nobody enjoys making any of these decisions. It's a lot easier, when money is flowing freely through the economy, to keep building new things. Those executives get paid those high salaries and bonuses to recognize when that tide has turned and to make those hard choices. It may be frustrating to be in the organization when they do that, but if they don't, then instead of dealing with a few cut-backs, the whole organization may end up in a death spiral. Then everybody will be looking for work.

Good PMs tend to be open and inclusive, but most of the successful ones also internalize their projects as a measure of their own success. It's very difficult for a good project manager to accept that it's not all about them. It isn't.

The most enlightened organizations actually reward PMs for recommending the scaling back or termination of their own project. It doesn't happen often, because program managers tend to come up the ranks of the PMs, and they also tend to see cutbacks as a black eye for them. But where cutbacks must happen, the program managers don't have much money held at the program level. They have no choice but to pass the cutbacks down to the next level, to the operating activity managers and the PMs, i.e. to you.

In this balancing process, the program decides:

  * How to deliver a capability

  * When the particular solution in place to deliver a capability will start to become obsolete, and

  * When to start a new project to deliver a new solution to maintain the standards expected for that capability.

Obviously, these decisions must come long before those same projects actually exist. Those decisions create funding envelopes and timelines within which the projects must deliver results to keep the capability intact.

Here's the reality: those up-front, apparently arbitrary baselines aren't always based on any data packages or the best advice you can find from people with appropriate experience. Actually, they represent unavoidable constraints, driven by:

1. Business needs: Your project is your most important focus. The organization is sponsoring dozens of projects. They can't all be number one.

2. Program integration: Your project delivers a piece of a solution. Your "best way" may not play nicely with someone else's "best way", and one or both of you will have to adjust scope, timing or cost.

3. Financial realities: Even the US government can't print money as fast as some people want to spend it. There are upper limits to what an organization is willing to invest to get a capability. You and all the other related projects have to fit within that limit.

## SO MANY COOKS

You can get along pretty well at the project level just by filling out the templates that the PMO gives you and walking through approval boards. But if you don't really understand what is going on around you, you won't be in a position to avoid problems or take advantage of opportunities.

In the early stages of an investment, everybody has an opinion. They're free to air them because right now it costs very little to entertain their ideas. A tweak here, a tweak there, and everybody's happy; hopefully some major disaster has also been averted. Ignore them, and it'll probably come back to bite you tenfold later in the project.

Who are these other soothsayers? Some include:

  * Strategic Planning

  * Budget Office

  * Operations Management

  * Security

  * Safety and Environmental Management

  * Enterprise Architecture

  * Portfolio Management, and, of course,

  * Program Management

That's not an exhaustive list. The real list is probably every discipline that you could find in a college catalog, and if you're in a mid-size or large organization, someone there has it. I worked for more than one CIO who majored in something that had nothing to do with IT, and they had the tremendous advantage that they were able to ask the "emperor has no clothes" questions.

Look around. Most of these folks love to share; in fact, usually they feel greatly under-appreciated and they may seem almost desperate to share. For all that, if they're in one of the corporate-level offices, they're closer to the center of decision power than you are with your one project. Or at least it may appear that way, but even if they're not really connected and not really players, they'll be all the happier to have you take an interest in their ideas. Just don't give the people at your level the impression that you're sneaking around Mahogany Row in an effort to bypass them too.

The more you know about the advice the executives are getting, the more you'll be able to work out how your project can fit into the overall picture. Not only will your project meet your program's technical goals, which is essential, but it may also be possible to tweak it so that it and the program reinforces key organizational directions. The closeness of that fit is what will keep your project on the list and fully funded.

## BUSINESS RULE NUMBER ONE

One of the fundamental rules of business isn't taught much in business schools. Maybe that's because it comes from the car dealer on Main Street instead of the recent college graduate on Wall Street. Or maybe it's because both professors and Wall Street only play with other people's money, so the rules don't really apply to them, at least until reality catches up with them as it did in2008. The lesson that real businesses, especially the smaller ones, are well aware of is: Cash is King.

In most cases, making decisions based on long-term return on investment is a nice theory. The reality is that you don't get to enjoy that ROI unless you have the money to make the investment. I'd love to have some of Warren Buffett's Berkshire Hathaway stock in my personal portfolio. If I did it would probably do very well. But at nearly a quarter-million dollars per share, it doesn't matter what the ROI really is, because I don't have that kind of cash handy.

Many programs and projects are the same way: great idea, poor timing, little money. For most programs, cash flow is the real metric. That means no matter how worthy your project may be, if we can't afford it today, then you'll just have to wait until another day.

Another secret which hides out in plain sight: there is a law much stronger than any economic principle. That's Murphy's Law. Stuff happens. You have to deal with it. Above you, others are dealing with it, and its consequences drip downhill.

Perhaps one of the divisions of the organization becomes the latest victim of cyber-crime. It gets all these extra resources to help deal with it (none of which gets the actual product any closer to completion). Those resources came from somewhere, specifically from everyone else's programs and projects. Usually you're part of "everyone else". Those resource reallocations at the enterprise level translate into more and more unreasonable constraints on your project.

This doesn't just happen to you. Every program has to deal with it; every PM gets inflicted with some portion of the burden. That doesn't mean the PM is just a helpless pawn; there are ways to deal with the situation. Somehow, all around you, work is getting done and solutions are being brought to market, thousands of them every day.

When life hands you a lemon, make lemonade.

Maybe you just need to know how. The first step to knowledge is understanding. In this case, we need to understand the context within which you have to operate, and how to maneuver within that space to get the best result you can with the resources that are or may become available.

Let's go take a look!

__[Return to the Table of Contents _]_

Chapter Two: Seeing the Big Picture

Early in your PM career, when you first got hit with top-down constraints, you were probably told: "you have to look at the bigger picture". The only thing is, nobody seems to have a copy of this famous Bigger Picture. It's part of the rite of passage that you have to work it out on your own. Or not.

## THE BIG PICTURE

The previous chapter talked about making decisions at the program level long before the project team is even formed. That process spirals down from the very top of the organization, down, down, down, until eventually it arrives on your project's doorstep in the form of pre-defined constraints.

In this chapter I'll go over my version of a Big Picture. Don't worry about trying to decipher it all now (if you want the whole thing you can download it from www.decisionintegration.com). The rest of the book walks you through each part. The specific graphic that I use was developed for an IT department, but the whole point wasn't about how to manage IT; it was to get them to understand how they fit into the wider business picture. You'll see as we go through it that there is almost nothing in it that is at all dependent on the nature of the work.

I've worked with dozens of organizations in the public and private sectors, in several different industries. Their project environments have almost all wound up looking pretty much the same. That's not because I force-fit them into my model. The model came about because after doing this a few times I noticed that the project and program environments seemed to be remarkably similar from one to the next.

Of course, your organization's map will differ somewhat, but you'll find that if you adjust a bit for local terms, there's a surprising level of consistency across all organizations.

It seems so obvious that a consolidated process map is needed. It might relieve a lot of the frustration that's going to arise over the next few years while you figure it all out for yourself. Why haven't the experienced veterans in your organization laid this out for you?

For the same reason that you, if you've been in your organization more than a year or two, probably haven't done it yet either. You're just too darned busy with real work, hopefully billable work, to spend hours building stuff that is interesting, useful and, well ... not required.

In a few cases - and despite all the rhetoric to the contrary, it **is** only a few cases - the stereotype of organizational behavior is that "knowledge is power". People have gotten the idea that their knowledge of how things work makes them indispensable, so they would be wise not to share it. Like most stereotypes, there are some anecdotes underneath it that give it the wings to get started, but there aren't really that many actual cases.

There are lots of less sinister motives with equally counter-productive outcomes.

First, most of the people who know what goes on are quite busy. They don't need to take on extra work, particularly if it has no benefit for them. They don't need a map of a process they understand intimately. Their mental map is even more detailed and includes a number of uncharted tunnels that make things work even more smoothly than it appears on paper. In many cases those routes are not only unofficial but unauthorized, so they're not going to commit their knowledge to paper or electronics.

Yes, there are a few analytic snobs who may simply want to protect you from hurting your little newbie-PM head with this complex view of the world you're living in. Again, there aren't too many of these creatures either.

A much larger group is under-analytic. They come to work from 9 to 5 and do what they're told without much thought for why or whether it might be done better, if they even care about that: the more disorganized things are, the more need there is for labor. They're survivors, though. They don't cause anyone any trouble and they figure out how to get through the jungle without getting mauled. They have some notion in their own heads about how things work, based on their own years of trial and error, but it would never occur to them to actually map it out. Some people are perfectly happy that way, not needing a mental model to codify what they've learned. They know what's going on, but they don't really understand it in a way that could be shared even if they wanted to.

A surprising number of people are very insecure. They won't share what they know because they are afraid of unwanted criticism. A few of these are afraid they don't really know anything about whatever topic is being discussed, so they keep their heads down until it goes away. The vast majority aren't incompetent or oblivious; on the contrary, they're overly conscientious and that makes them insecure about potential criticism. They worry that even though they do know what is going on, they don't have it expressed exactly perfectly. They don't want their work product to appear incomplete or unprofessional, so they never produce anything unless you make them download it from their personal file folder. It sounds kind of silly when you read it in black-and-white, but a very large proportion of people think that way.

Many more people have never been trained in the idea that the whole organization benefits if this knowledge is passed on rather than forcing each person to work out their own version of reality over the years. It's just never occurred to them that whatever happened to them in the past may not be the best possible way going forward.

For all these reasons, the odds are you won't get handed what you need by your home organization, and you'll just have to accept the degree to which I can help with my version of the Big Picture. And now you can have one! It is my hope that this relatively short book and a walk through this generic model will help you understand your own organization's decision processes a lot better. Again, this model is a generic description. You'll need to go out to observe the reality where you are.

## CORPORATE CONTEXT

PMs don't often get invited to the board room. When they are, it often doesn't bode well. Actually, what goes on there isn't all that complicated. More to the point: nothing really goes on there at all, other than public affirmation of what has already been decided through many interactions leading up to "the vote".

Don't be distressed. Regardless of what you may have learned in MBA school, you'll soon see that there are a lot of subjective components to decision-making. You don't get subjectivity out of an Excel spreadsheet (although many of them have a lot of hidden subjectivity baked into them). The only way for the decision-makers to incorporate subjective considerations is to talk to people, as many as needed, until they have a sense of the story behind the story.

Executives aren't paid those big salaries and bonuses just to agree with everyone's recommendations. But most of them are past the point of being able to offer useful technical insights. So what value do they add?

What they are there for is to provide subjective balancing of intangible elements. In plain English: they do the politics.

Here we're not talking about the slimy knife-in-the-back office politics. We're talking in the larger sense, defining politics as a way of reaching decisions where simple rational analysis is inadequate, which is pretty much every time you have people's interests involved. Executives earn their money by getting this part right. If they do, then once the decision has been made, it will stick because people won't be going around trying to undermine it.

Once that happens, the rest of the organization can get on with a more rational process of dealing with the decisions that have been made, because the simple act of making those decisions removes a great deal of the subjectivity. But not all! You'll still have your own chance to exercise your creativity and tenacity. Never worry about that going away.

Now that the top-level decisions have been made, you can do your PMBoK thing. It's true that the balancing act that occurred before you got handed this hot potato might have created some logical contradictions. Politics is, after all, a non-rational approach; you have to expect that it's going to result in some answers that don't fit a rational framework very well. That's going to throw a wrinkle into your best-practice solution, which is based on rational analysis and logical exposition, because that's the only way you can write a document that explains this standard of practice.

So, no, the guidance you will get won't conform to your professional standards, and it won't be entirely logical. You, the PM, get paid to make good things happen anyway.

## VISION OR MISSION

Let's take it from the top in painting the picture of where your unreasonable constraints came from. The top is just where we should start, too, because that is exactly where it all began.

Number one on the list of executive responsibilities is to define the vision and/or mission of the organization. Why does it exist?

Perhaps a private or public corporation wants to make lots of money in the real estate business, or perhaps an agency wants to make sure that corporations like that don't abuse the rights of potential customers in the process. Whatever it is that they want to do, they can't achieve that effectively if they just go around spending money on whatever activities come to mind that day.

Achieving your aims implies that you actually have some aims and a certain mindset about what sorts of activities are either morally acceptable or business-relevant. That's the vision.

If the organization's exposure and capabilities grow, new opportunities may open up. The housing developer's vision may expand to include golf courses, or casinos. Or railroads, who knows? But, because of the vision and the corporate culture that develops around it, totally different activities such as, say, selling mutual funds, wouldn't even be considered. Even if they were, they would be turned down as distractive diversions of effort even if they were potentially lucrative. Well, at least up to the point that the opportunity is so lucrative as to cause yet another rethinking of the vision.

A vision statement doesn't explain how to get there. It just describes where "there" is and what it looks like. To be useful, it should be quite specific about the end state and what the point of it is.

Such a general statement ought to be simple enough to come up with. They aren't. Many executives, being largely political animals, have worked out that there's risk in specifics that they can be held accountable for. It's much easier to rely on vague statements that nobody can really argue with.

Unfortunately, there are many bad examples floating around and being offered up for use as templates.

As a result, you get vision statements such as:

  * We want to be the employer of choice in our state, or

  * We want to do our part to make the world a better place to live in

These sorts of statements are pointless because they don't steer the organization towards any particular direction, nor do they preclude any. They certainly don't convey any sense of the organization's real purpose.

Aside from being pointless drivel, it's a bit scary because it means that the executives have no idea what they really are in business to do. That in turn means they're going to make terrible decisions, which will roll downhill to you, the PM, in the form of ever-more waffling priorities and ever-more drastic mid-course resource shifts. Luckily for you, once you get over the shock, you'll find out that it also means that there's no real expectation that anyone actually meets those demands (as long as everyone has a good work-life balance, of course).

We started earlier by noting that there isn't anything you can do about the organization's culture and major business practices. Why is all this Vision business relevant to a project manager who operates three or more levels below the executive offices where the vision is created?

I'm not suggesting you should began a masters' thesis deconstructing the psycho-social roots of the vision statement. And don't waste your time or political capital turning your observations in to the CEO via the employee suggestion line. I am suggesting that you get familiar with the vision statement because, no matter how fuzzy it is, it may give you some insight into how the people at the top level of the organization think. Over time, the longer the senior executives last, the more that style of thinking trickles down. And since that's where your funding starts, that's a good tune to know. You don't have to believe in it, but you will undoubtedly have to sing it. Partly, we're covering it here because the company's programs (of which your project is one part) are supposed to be supporting the organization's primary intentions. What happens at the top trickles down and creates the situation that leads to your apparently arbitrary baselines. The vision is where all this starts.

Later we'll explain how you can cement or reinforce the resources you have, or shape and tweak the expectations that have been established. Just as visions aren't always crisp, sometimes strategies and programs are a bit vague too. If you want to position your project to get the executive support and resources you need, then you need to know what the executives are thinking about. In the absence of a seat in the executive dining room (or, since few organizations have those any more, wherever your executives hang out nowadays), the vision is hopefully another window into the attitudes and motivations in the board room.

In governmental organizations, the vision-mission statement is (or ought to be) fairly clear, because agencies are set up to do things in response to specific laws. You might say that the Constitution provides an overall vision of how the government is supposed to operate, and what it should and should not be engaged in.

The legislature assigns missions to agencies, in the form of Authorization acts, and grants resources in the form of Appropriations. Taken together, these create long-standing programs with long-term objectives and incremental funding. Those decisions aren't made totally independently; the agencies have a lot of input, and legislatures hear plenty from other stakeholders.

Once those decisions are made, the executive agencies are supposed to go ahead and execute the law as written. (We can set aside for this book the fact that they don't always do that.)

So, although we call our agency heads the Executive Branch, in fact it is the legislature that performs the executive function, while the executives are basically high-level line managers.

This model also works for organizations that aren't in the government sector. The overall guidance is set by the board of directors (with a great deal of input from the organization). Once those higher-level decisions have been reached, it's up to the organization's executives to manage the organization through to achieving those objectives.

It's a pretty picture, which makes it handy as a model for explaining how things work. But it's just a model. Reality can be a lot messier.

Fortunately for you, as the PM, the politics are above your pay grade. The consequences aren't. but the action is. Most PMs wouldn't enjoy it anyway (that's why they're good PMs). As frustrating as being assigned arbitrary deadlines and budgets may be, participating in office politics on the grand scale is much more frustrating and stressful.

Even at the program level, you only get the chance to have so much input. But your program is directly linked to the vision and strategy. You'll have to have at least one version of your story that shows how your program advances the top-level vision.

All you have to know is where you fit in the Big Picture, which really doesn't change much regardless of the games that may go on at the highest levels.

## ENVIRONMENTAL PRESSURES

The vision sets a grand direction, but even a well-crafted one isn't all that specific. Wisely so. The vision and strategy need to be durable over time, able to survive the normal turbulence in the external environment. That doesn't mean that the environment didn't affect the formulation of that vision and strategy.

It's an unwise investor or entrepreneur who decides to "build it and they will come". Both general and specific directions are shaped by external factors.

Here's a very small sample of typical concerns you might have as to how things will shape up in the foreseeable future:

1. Politics. Existing laws and rules may encourage or prevent the formation of certain types of business; new laws or regulations can make or break a business. Sometimes you can affect how that plays out: that's what lobbyists (or self-styled "foundations") are paid to do. Even if you can't change that landscape, you need to be aware of it. The IRS or the EPA can break your business. States may decide to hand over wads of cash if you open a facility there. If you're in a government agency, you're not exempt from those pressures.

2. Industry developments. Do you really want to be the last company not to have a presence on the Internet? Are services that were considered premium now being given away for free, or are other companies starting to make a lot of money by charging for things that used to be free? Are competitors emerging, and if so, how do they compare to what you could do? Could the supply of your core raw materials dry up? Are unions getting stronger or weaker, and where?

3. Technology. We've seen the explosion of broadband demand as everyone climbs on the Internet and starts replacing email with video clips. What's next? Will you be able to make dramatic reductions in the cycle time or labor costs of your existing processes? Will you be able to make major changes in how you handle raw materials? Or, on the other hand, will the technology you use today be considered laughably inadequate in just a few short years?

4. Market or global conditions. Are customer interests changing? Is your customer base widening or shrinking? Do you have to think internationally? Is your workforce bringing the right skills and expectations?

Your organization needs to keep an eye on all of this, and much more. It's a lot less expensive to monitor it than to be surprised by something everyone else saw coming. You don't want to be the second-to-last buggy-whip manufacturer. Perhaps you might choose to be the last one so you can charge premium prices for memories of a bygone era. It's a gamble, but that's what the executives are there for.

If nothing much is going to change, then it might be that it is not worth spending a ton of money just to have the latest gizmos that don't actually increase productivity but do increase the turmoil in the organization. Unless, of course, the organization perceives an opportunity (or a risk) that is worth all the disruption that self-reinvention might entail.

The point is to have this be a matter of choice rather than being locked in a constant effort to catch up to what already happened.

At the executive level, dealing with these possibilities means making decisions well in advance of the actual events. Those decisions lead to the constraints at project level, and while they may not make much sense given only today's situation, they may well be part of a larger whole picture.

Once the organization has a general vision of the desired future, and a general understanding of what may lie between now and that future, it will be in a position to form, or perhaps just update, its strategy.

With your one-year or maybe two-year horizon at the project level, none of this may seem important to you. Again, if the problem is unrealistic constraints, you'll need support in getting relief. If you can show how your project guards against, or leverages, trends that the organization sees as having a big impact, you'll find it much easier to locate the needed support.

## CAPABILITIES

Commonly, the organization strategy is considered the highest-level plan. As a specific document, that may well be the case. But before we can have a strategy, we must consider capabilities.

Perhaps your organization's vision is to be the largest retail enterprise on the planet. The executives foresee that China will become one of the largest economies, and they've observed that many Chinese speak Chinese rather than English (yes, I know, there are radically different dialects of Chinese). They're going to conclude that your organization needs to have some fluency in the Chinese language (or languages, if you prefer).

That's a capability, not a strategy. It doesn't set any particular direction as to how we're going to approach this market. It just recognizes that, whatever the approach is, we're going to need some people familiar with the chosen market.

Do we have that? Do you have in mind a project that increases the organization's capability in that regard? If so, you may be able to find some sponsorship, which means "money". if not, your project just doesn't seem to have any customers.

One does get to another chicken-and-egg situation here. If I don't have the necessary capabilities (such as my own linguists, a set of ready local partners, and a product of interest to Chinese consumers), it doesn't really matter that my strategy was to crack the Chinese market. Without the needed capability, it's just not happening.

Perhaps the first phase of the strategy is to build those capabilities. That means we'll need some long-term initiatives (which are also projects) to bring those capabilities about. Is your project one of those? Can you imagine that if it were, you'd be much more likely to get the time and resources you need? Is the secret starting to reveal itself?

Maybe the organization can't wait for those longer-term actions to have their effect. Any action that gets the ball rolling right now will have to build from alternatives that are feasible within the capabilities that the organization does have. If your initiative is one that keeps alive a capability that is essential to the strategy, you're probably going to have many more sympathetic ears when you start moping around muttering about inadequate resources.

Those choices are made and brought to life via the key initiatives laid out in the strategy that explains how the organization will move toward the vision.

## STRATEGY

A strategy sets out specific large-scale actions that will be needed to accomplish the vision by bridging the gap between the capabilities we have now and specific outcomes that we want to achieve, taking into account the way in which we expect the environment to change in the meantime.

Those actions are defined at a very high level, but they are specific enough to permit concrete planning to begin. Maybe we decide to take on a Chinese venture partner. Maybe we decide to focus on Chinese expatriate communities and hope they get the word back into their stay-behind families in China. Maybe we decide to try the political angle, and we make a donation to the Fixer Foundation in return for expedited construction and business permits.

Now we've got some direction. Each of these strategic objectives can be defined using the SMART rule (specific, measurable, achievable, rational and time-bound). They can be broken down into as many sub-components as necessary to make each one digestible.

## PROGRAMS

Any worthwhile strategy is going to be complicated and is going to take time to accomplish. There must be numerous projects rolling out over an extended period, and once each part of the solution is achieved, it is going to have to be sustained. Each major enhancement of an organizational capability, or each strategic initiative, will be made up of dozens of projects and operational activities — in other words, they form programs.

This concept wasn't invented just because your project came along. The organization is already doing lots of things, and has lots of programs in place. Sometimes the organization will establish a fully self-contained program to ensure that some group is focusing on getting some portion of the strategy done. More commonly, elements of the strategic goals are parsed out among different existing programs.

They're not the only ones competing for resources. The organization's elements (like Purchasing and HR) that provide ongoing services to all other elements have to get geared up to support all this project activity. They too are programs: they have some modernization projects on top of all the usual ongoing operational activities.

Amid all this pushing and shoving, each of these program managers work out what solutions will be needed to bring about their assigned objectives, and somewhere in that mix, one and only one of those program managers decides to undertake a particular activity that (if successful) will become your project.

_Woo-hoo, did you just say projects_? At last, we are talking about you, the PM. One of our star performers, of course!

A star, perhaps, but possibly just one of several stars in a constellation that is just one grouping of many stars in a galaxy. You're not alone, and even if you're the closest one to us and the brightest one we can see, the odds are that you aren't the most important star in the picture. It's all a matter of perspective.

So at this point we're starting to talk about projects, but officially you, as a project manager, are not even in the picture yet. Decisions are being made at the executive and program level. If you've even been identified as the PM at this point, your role is to stay under the radar, supporting your program manager in presenting the situation as realistically as possible

__[Return to the Table of Contents _]_

Chapter Three: Show Me The Money

## SLICING THE PIE

I've never seen it happen that the programs run out of ideas for solutions before the organization runs out of money. That's a good thing. If it did happen, it would mean the people in the organization aren't engaged enough to be bothered with thinking up any good ideas about how to make things better. If you've ever had a significant other, you know that "everything's fine, just fine" doesn't mean what the words seem to say.

Almost all of these great ideas that people are having would really be needed to get to the originally-stated vision. As a minimum, each of the PMs and probably the program managers believe that about their initiatives! Somehow, the organization has to decide which of the many great ideas it can afford to pursue. Sometimes it's a matter of timing and deferring gratification; sometimes it requires giving up on some aspects of the dream altogether.

Here's another moment where the executives earn their exalted status and compensation. Special creative juices might have been required in the visioning effort, but at least it was fun imagining all the things we could do. Now comes the harder part: deciding which of those wonderful things we simply cannot do. Later on will come the hardest part of all: making those decisions stick.

## PROGRAMMING AND BUDGETING

In most organizational settings, the activity of looking into the future to see how much money you're going to need to do the things you want to do at certain times is called budgeting. The US federal government reserves that term for next year's forecast only.

Any deeper view is known as "programming", and it's important in that for the most part only the budget is supported in law. The deeper forecasts are just ideas, but in being placed on the table over a period of several years they acquire quite a bit of moral force.

The near-term budget is often quite a bit more detailed and demands much more supporting detail. It's also expected to be very stable. The idea is that by the time you're going to spend amounts in the millions of dollars next year, you should really have an idea of what exactly you plan to use it for. With the amount of time the investment was in the programming phase, you really should know quite a bit about it by this point. If nothing else, you'd better be deep into the implementation phase of any purchasing actions you'll need to make that work happen.

After everyone has done all that work to come up with the final budget, they're not going to take kindly to someone having a cool new idea at the last minute and cutting into the line.

Programming simply represents the fact that substantial organizational moves don't just happen overnight. Investing in new capabilities will require spending money now for benefits that will occur later. While we're waiting for those benefits, we still have to invest in the current solution. That means each investment has to be packaged in with all the others over an extended period to make sure that all the lifecycle implications are included.

Programming is generally done ... well, at the program level. That seems rather obvious, given the name, but that's the point. We're not selecting specific investments. The next chapter has more to say about how specific investments get chosen for inclusion, but for the most part those details don't even make it into the programming phase.

Here the organization is just expressing how much of its forecasted resources it wants to allocate to its major capabilities, checking to see what is really needed over time so it can do what it must to make sure those resources are available, or tamp down expectations. Individual investments (especially projects) are only brought into this discussion for the very few in which the enterprise has placed such importance that the executives want to ensure that they are properly resourced, planned and carried out.

The other reason that investments may undergo detailed scrutiny this early on is that the decision board no longer has confidence in the ability of the program manager (or the PM or the PMO) to present an honest statement of needs. That's not a good place to be!

## ALLOCATION

Allocation is another enterprise-wide process that can create what appear to be capricious decisions with unreasonable impacts on your project. It's another of those things you don't hear much about, maybe because it's considered too nerdish for decent people to bring up in conversation. That, of course, makes it all the more important that you do know about it.

Every organization has rather stable revenue cycles. Some retail businesses experience the majority of their revenue for the entire year arriving between Thanksgiving and Christmas. Government agencies run out of money at the end of their fiscal year; more money will not become available until the beginning of the next fiscal year (or, depending on the politics of the day, or the decade, maybe it waits another few months beyond that). Public and private organizations alike cannot simply spend the money at the moment it happens to be physically there. We have to make sure we can still get through the next summer, when there's no money coming in and nothing but bills in the mailbox.

To maintain a steady and sustainable flow, the CFO will allocate funding by time periods, either to try and squeeze through until the new money comes in or to hold back enough to cover known future costs. You, as the PM, may need to get a contract awarded in January but you may be told that you won't have enough money to pay for it until April. Sometimes this has further repercussions, such as expired support contracts and gaps in service.

You can complain about it if you like, but nothing will change. Or you can plan around it. Move your bills to the part of the year when money is more likely to be available. Let the purchasing and finance offices know why you're doing this and make sure they are ready to execute their processes when that little window in time does come. Your project will be sailing along while other less proactive PMs are sitting there whining about how life is unfair. You may even end up sailing along with some of their money!

## OTHER INFLUENCERS

Not all of the decisions that flow down to you come from inside your organization. Not all of the external impacts are included in the strategy; some just pop up.

One way to avoid being surprised by events is to keep your connections open with the other groups in the organization who are responsible for trying to peer into the future. The program-level office should be doing this but, depending on how mature that office is, you may find it necessary to supplement the information they give you with your own relationships.

Offices that might be of help to you include:

1. Strategic Planning office: If your organization is really part of another larger one, you'll have to deal with regular changes in strategy at one level or another, since they're rarely synchronized vertically. Any of those changes could affect your requirements, even if not your project's funding priority.

2. CFO or Comptroller: There's never any value in fighting the Golden Rule, which is "the person with the gold makes the rules." It's always handy to understand how it works in your organization.

3. Program offices (PGMOs): Is this a surprise? If your project is part of a program, it seems obvious that you're talking to the program office. Too many PMs view their program office as yet another source of frustration, to be dealt with as quickly as possible so that you can go about your business. While your project envisions a different end user or retail customer for the product, the fact is that the PGMO is your customer; they are your business. The better they know you, and the better you understand them, the more likely it is that your project will be treated generously when it comes time to make unexpected shifts. And don't visit only with your direct program office. The more you know about what is going on in other programs, the more you can tailor your solution to be of benefit to the wider enterprise.

4. Enterprise architecture: Of all the governance disciplines, this one tends to be the most overlooked. Even in non-IT projects, they have a lot of relevance. If they're on their game, they can tell you about other initiatives that are nibbling around the same objectives that your project is addressing, so that you can coordinate instead of being in unwitting competition. They may also be able to help you articulate many other second-order benefits that your project creates, or derivative impacts that changes to your funding might create.

5. Security: Time has moved very quickly since security was the beefy guy at the door who removed troublesome visitors. Now for many PMs, "security" means IT systems security. That's the other end of the spectrum. In the modern world, almost every business operation is heavily dependent on some form of automation. Very few organizations can afford the heavy hit in credibility that is sure to result from a serious breach in security, whether electronic or physical. Nowadays, when this office squeaks, it gets the grease. They can give you interesting perspectives because they see across your organization and often collaborate across your industry. It's also well worth your time to understand their issues so they don't derail your project down the road.

The idea of schmoozing at the program office and these other offices is to maintain situational awareness of the influences that might impact on your project and your program.

Confine your activities to gathering impressions. Do not start lobbying for your project anywhere except within the program office, where you'll simply be seen as annoyingly over-eager. Try this with other groups and you'll be seen as undermining your program manager. That won't increase your likelihood of getting the funding you need from your program manager or any other manager.

## KEY TIPS FOR FITTING INTO THE STRATEGY

Well, that title really says it all. Try to fit in!

Once you realize that you do have to fit into the Strategy, the challenges of fluid resources and uncertain executive support won't disappear. But the frustrations will ease, because now that you know what's going on, you can take some concrete steps to keep your project in the game.

### Find a Sponsor

If you're just now coming up with an idea, you'll have to fit that idea into the organization's programming cycles. These cycles, even in the commercial sector, tend to look a couple of years out, and in the public sector are seldom less than three years and often exceed five. The budget programming effort we just described has developed solutions for today's known problems and today's strategic initiatives. Perhaps only the top half of those solutions made it into the multi-year budget at all, let alone actually getting funding for this year.

So you might have to wait three to five years to get funding. Well, heck, by that time, the need, the opportunity, or the technical basis for your solution may have disappeared.

In most organizations, the real answer isn't "three to five years". It's more like "now or never". If your idea doesn't solve a problem that anyone in the organization recognizes, then you're not ever going to get funding for your idea. By the same token, if your idea solves a genuine problem that one of the programs is experiencing, then that program will be happy to provide you some funding from within its existing resources. After all, their existing resources are stuck and probably burning money anyway. So they'll find your funding now to save themselves money now.

That's why I suggested you get to know the other program offices. You never know when a sponsor from another program will come in handy.

### Tell Them a Story

No, not that sort of story. Don't lie to anyone. It works for politicians, but even they usually end up getting stung eventually.

We already said that the key role of the executive level is to make those subjective calls. In other words, they want to hear a story, one that helps them in making their decisions. Since they're not going to be looking at your specific project, all you can do is help your program manager to set up a story that sells.

Actually, if the program manager you've found as a sponsor has been around for a while, he or she probably knows how to do this pretty well.

You, as the PM, should just simmer down. Take the time in these early phases to look around and see how the program manager is getting funding, and whether their way is producing a fair shake of the resources.

Most importantly, does the program manager's plan and received funding still have room for your project (even if it's not specifically mentioned)? If it doesn't seem to be in there, talk to the program manager and see what the actual plan is.

Maybe your project is hidden in there under innocuous (but still truthful) verbiage because the program manager thinks it will be a tough sell in the budget wars. Maybe the program manager plans to make some shuffles in the actual execution period once the money is in hand. Maybe you are in fact not in the running, at least not at the moment.

**Simmer down**. Keep your ego in check. Unless you're an external project manager trying to sell your product or services, you don't actually have any skin in the game whether your project is selected or not. If you're that superior, they're not going to lay you off. They're going to have you do something else.

Even if they were going to lay you off, starting a subversive campaign to undermine and reverse the program manager's plan is unlikely to improve your chance of making the A-list. Everyone you talk to will be wondering whether this is how you act whenever you don't get everything you want.

Instead, show some patience. Things change all the time. Besides, the real decisions haven't even been made yet. That's in a later chapter.

Before we go there, let's dispel a few myths about how decisions are made in most organizations.

__[Return to the Table of Contents _]_

Chapter Four: The Rack and Stack Illusion

The programming and planning described in the prior chapter is done at a fairly high level. Specific projects may not even be part of the discussion. As we get up towards the start of a new fiscal year, the allocation process kicks in, and the organization is about to start handing out some actual money. If you're a project manager, this is where you start getting into the picture.

To this point, resource decisions have been made in a somewhat subjective way. At some point, we have to start giving money to real projects that can make things happen on the ground. The organization has four basic ways of doing this:

1. "Rack and stack" applies a weighted scoring system to compare all the projects against each other. The most important or best value projects are selected, until we run out of money.

2. The Grab-bag: All the money gets hoarded by one or a few decision-makers who then dish it out as they see fit on an ongoing basis.

3. Salami slice: Each organizational division gets the same percentage increase or decrease compared to prior years.

4. Program managers decide what projects are needed within their programs.

Well, given those choices, the grab bag seems a pretty dysfunctional one, and the "program manager's choice" seems rather arbitrary and is certainly not optimized at the enterprise level. That "rack and stack" approach sounds like a winner, doesn't it?

But it isn't.

## HOW WE DON'T DO IT: DECISIONS BY SPREADSHEET

There are many adherents of the rack-and-stack approach. Most books that include "portfolio management" in their titles endorse this approach. The reality is that very few organizations have adopted such a system, and most of those that have do not stick with it.

That's because this approach rests on a gross misperception out there among project and program management authors that organizations are supposed to be highly "rational" (meaning quantitative). Since it is possible to present portfolio management as a simple mathematical exercise, those authors believe that such an approach would be very attractive to organizational leaders.

But it isn't.

Well, if this isn't how executive decisions really get made, why talk about it at all? Why not just keep this section shorter and move on to talking about how it actually is done?

It's important to talk about what doesn't work because before long you'll find one of those many other books and think "Hey, this is a pretty cool approach. How simple and logical! I'm surprised that Doug Brown didn't mention it". Then you'll get mad at me, and you'll get all enthusiastic over this magic bullet. But then when it falls apart you'll come back to this book and get mad at me all over again for not having warned you. So let's just make it explicit.

The idea in these traditional books is that you can come up with a scorecard and then use it to rank-order every project. In the most simplistic version, you don't even need a complex scorecard: you just line them up based on the return on investment. In more complex versions, you come up with a weighted score on some range of factors, and you rank them based on that score. Either way, you deal out the money to the highest-ranking ones until you run out of money, meaning you get to the total budget ceiling that you can afford.

That idea got sold because it was described as a Wall Street model and, after all, who would know better than Wall Street how to maximize money? Unfortunately, most actual Wall Streeters are recent college graduates whose main skill is to work the call center phones and read the script, and the professors writing PM books ... well, if they were Wall Street wizards, they wouldn't be writing PM books, now would they?

And yes, that includes me.

The fact is, organizations simply do not make important decisions that way. Its mechanical nature doesn't match the way that organizational decision-makers think about problems or about their own roles, and its elegant simplicity just doesn't match the practical realities and complexities of what organizations actually do.

## RACK AND STACK CASE STUDY

I've seen this approach done effectively in exactly one organization. This retail company executed enterprise-wide activities that rolled out across all of their tens of thousands of locations, and they did use a very elaborate quantitative model to decide the order in which each store would get its upgrade.

As impressive as this massive list of stores was, it wasn't really an enterprise-wide investment rack-and-stack. The upgrades affected a good number of the activities that went on in the stores, but it didn't affect all of them, and the corporation had other massive investments in several other areas that were not (directly) related to store operations. In other words, a lot more money was sprinkled around the company beyond this upgrade, which was ... well, a program. And in fact, to test its effectiveness, the upgrade program itself was conducted with a forced even spread across geographic regions (which went against the ROI mathematics).

I once thought I was going to be setting up such a portfolio for a Fortune 100 company that had hundreds of projects going on. They really did want to rank things like marketing programs and new network segments into one massive investment model.

A senior executive pointed out, quite correctly, that even the marketing programs were complementary and it was impossible to assign ROI precisely to different efforts if they were launched simultaneously to the same customer base.

Were customers signing up because of the new bandwidth or the ability to offer lower prices? Which of the various incentives was causing them to stay in the service? Which of the campaigns would not have done as well (or might have done better) if the others hadn't been going on at the same time?

If it was nearly impossible to compare similar initiatives within the product domain, how about matching them up with totally different domains, such as the value of adding a new network operating center? It simply could not be done.

(Well, you can do it, by force-fitting the needs into a framework, but the fact that you can just make up an equation doesn't mean that you should do so).

In his view, the whole point of hiring experienced, capable executives and paying them a bunch of money was to allow them to exercise their judgment in making a market basket of investments with the idea that the overall strategy was sound.

If the division ended up doing well on the top line (or the bottom line, depending how you want to look at it), then the VP must have done his job well. If they didn't hit their numbers, then it didn't really matter which particular initiative was flawed: the executive would have made a bad strategy choice overall, and would expect to suffer the consequence.

It's also possible that the executive's division would get good results because they were lucky that year, or get bad results through a series of external misfortunes. Again, that's what this book is about: the reality. In this case, things like that sorted themselves out over two or three years. If you've got a bad executive who gets phenomenal results year after year because of sheer luck ... buy the company's stock until that executive retires. Napoleon's only question when asked to promote officers to the rank of general was: "Is he lucky?"

But back to our story.

"Maybe a computer could make all these comparisons and what-ifs", he said. "But that means somebody with no experience of this business whatever would have to program the computer, because we VPs certainly couldn't come up with the algorithms for them. If they're that bleeping smart, why don't they just come in and run one of these divisions?"

That's the practical reason why portfolios aren't really used all that often in many organizations, at least not for prioritization purposes.

There's another important reason why organizations haven't jumped onto by-the-book portfolio management; more accurately, they have tried it and given up on it quickly. It ignores the 60-85 percent of the money that goes to fund operations. Even if someone tried to make sure that their portfolio process did include all organizational resources, in 20 years of looking at this topic I have yet to run into anyone who can show me the ranking sheet that can accommodate operations and projects sensibly.

Even if it were possible to do that, there's another terminal condition. Executives won't accept having their judgment replaced by a spreadsheet, especially one compiled by a very subordinate staff entity, i.e. this PMO, whatever that is.

In our context of portfolios that are made out of business investments, aside from the matter of not knowing how to include operational activities, even when you consider only the "projects" you'll find that not all investments are tradeable. Another great sales promotion might make a lot of money, but it won't get you out of that legal compliance problem in the finance or HR departments.

"Oh, well, we'll treat those as known exceptions".

As soon as you start creating manual override cases like that, your whole math approach goes up in smoke as everyone comes up with their own variation and their own exception.

## HOW YOUR BROKER REALLY DOES IT

The reality is, the "Wall Street" ever-so-rational decision model includes much more subjectivity than you would think. That's why your brokers regularly chant their mantras: "your results may vary", "past returns are not an indicator of future performance", and "I can't make any guarantees".

In fact, the professors may have been onto something they just didn't quite grasp.

If you've had any dealings with a financial planner (even the ones who are just following a script), they don't just seek the investments with the highest ROI. If they did, since you can't afford to buy up every outstanding share of the best investment they can find, you'd never get to the second-ranked choice. Your portfolio would consist of just one stock or bond (and a heck of a lot of faith in your advisor's evaluation algorithms).

Instead, they ask you a very subjective question about your level of risk tolerance. Then they ask you when you are thinking about retiring. Then your wizardly financial planner disappears behind the curtain, presses the F9 key on their computer, and out comes a recommendation.

The resulting recommendation will be a mixed portfolio of investments, some of which have higher potential return than others, and some of which appear to have less risk than others. The precise mix has very little math and absolutely no science behind it at all. It's a predetermined, subjective mix that in the best opinion of some expert at the financial planner's company was appropriate for anybody who answered these questions in a certain way (set aside the possibility that the algorithm just happens to maximize the brokerage's commissions).

Who is this expert? I don't know, you don't know, and most likely your broker doesn't know. Quite often, it's not even that person your broker is raving about anyway. It might have started out with that named guru a few years back, when he was a hot stock picker, but actually he retired five years ago. Now his assistant runs the program, with the help of an advisory board that uses a computer program that just averages out everyone else's recommendations. Really, you don't want to look behind that curtain!

Here's the important point: it's still subjective.

Actually, that's not too far off from what the executive layer of the organization does with its internal investment decisions.

## HOW SOME PEOPLE DO IT: THE GRAB BAG

The grab-bag, in which the central decision-maker hoards all the money and deals it out as the need or the whim strikes, is unfortunately prevalent in many organizations. It's never a good situation because it tends to be all politics all the time, and this time I don't mean the "right kind" of politics (a subjective allocation of resources) we spoke about earlier. This time, it's the ugly kind of politics. Decisions are never really "made"; they reveal themselves after secretive meetings. They are based on friendships or deals, rather than on hard decisions about what is best for the organization. And they're only as good as the last meeting.

In that case, unless you have a personal connection to The Decider, the best you can do is to go see them with your great idea and explain it with a good story (as in the previous chapter) backed up by sound reasoning (as explained in this chapter). Even if you do have that personal connection, they might appreciate having a good reason for a change.

If you're in such an organization, my sympathies are with you (been there, done that). You're trying to manage things like a professional in an organization that doesn't have the culture to support it. You would, however, benefit from reading "Let It Simmer: Making Program, Portfolio and Project Management Practices Stick in a Skeptical Organization", which as you can tell from the title was written about this very situation.

## SALAMI IS BALONEY

Executives aren't going to make multi-million dollar choices based on some spreadsheet that reduces their role to a rubber stamp. For the reasons we've seen, the simple math model won't work, and the average executive can figure that out before you finish explaining why it would be a great idea to do it. That's because they can sense how the subjective relationship-based picture works while many of us in the PM business struggle to accept that it even exists.

If you're lucky, you're in an organization that's a bit more advanced than the medieval grab-bag approach.

So what do the executives do instead?

The deciding executives have an idea of how much revenue they expect to have over the timeframe of the strategy. With this as a constant to work from, they look at the overall amount of money that their various programs are demanding to meet the strategic objectives. Since this amount is greatly more than what is actually available, they begin slicing the ceiling down to size through a series of well-placed questions.

Hold the presses ... no, quite often they don't do that at all.

In most cases that's what they'd like to be able to do, but it's not what usually happens.

In many organizations, the divisional managers have never really had to explain why they need their resources. Unable to explain what they accomplish and why it costs as much as it does to do that, many fall back on simply stating what they are doing different from the prior year. They ask for the same amount of money they had last year, plus ten percent (or some such number). They are unable to articulate what the impact of any changes in resources might have.

Under those circumstances, the executives have little opportunity to make sensible decisions. All they can do is order the program managers to cut everything down by the same flat percentage as needed to get to the total top-line number they want to invest. Nobody likes it, but nobody knows what to do to make better approaches possible.

Salami slices. Every activity pays equally, regardless of its total size or relative priority. Everybody agrees that it's unfair, not optimal, and usually downright counter-productive. But nobody gives the executives any basis for acting differently.

## HOW ORGANIZATIONS ACTUALLY DO IT: DON'T LOOK

You know what they say about a political process: Don't ask how the sausage gets made. What's important is that it does get made, and it comes out right.

Sausage and salami aren't quite the same thing.

Let's say that the organization has worked through the logic of what the requirements actually are.

Now, let's try that approach we started out on and abandoned in the previous section.

The deciding executives have an idea of how much revenue they expect to have over the timeframe of the strategy. With this as a constant to work from, they look at the overall amount of money that their various programs are demanding to meet the strategic objectives. Since this amount is greatly more than what is actually available, they begin slicing the ceiling down to size through a series of well-placed questions.

The decision board can look at things such as:

  * Are there any really strategic investments that must be protected or any legal compliance mandates that must be respected?

  * What does it cost to "keep the lights on" (to do the same as last year without interruptions)?

  * How did the various programs actually do compared to what they promised last year?

  * Is the furnished supporting information real or just moonbeams?

And, yes, they horse-trade among themselves.

That's how it works. What each program or division gets out of it is what falls out.

What do you, the PM, get out of this? Nothing.

Oh, wait. You're thinking about your project again. Well, here's the truth. Once you grasp it, will be the breakthrough for you in understanding how this whole thing works. Unless you're leading one of the enterprise's few really major projects, you and your project are not even in this discussion.

It's about the enterprise. It's not about you.

These decisions are being made at the enterprise-to-program level. Projects are being discussed only in the sense that they help to describe what the program manager is proposing to accomplish in the coming period. Except for the few cases where a project is reserved for the constant attention of the executive level, these boards don't approve funding for specific projects.

So why did I say this book would be useful for you, if it's going to ignore your concerns altogether? Because you have to know how the game works if you want to play it effectively. Then you'll know how to bring your concerns to a level where someone is actually listening, and how to structure your pitch so that someone might be interested in what you have to sell.

Now we have the good news: it's your turn to shine!

__[Return to the Table of Contents _]_

Chapter Five: It's Your Turn

Once the horse-trading is over, then the program managers get to figure out what they're going to be able to achieve with whatever funding they ended up with. They have to keep the capability running right now, and they have to make sure that it will still meet the organization's needs at some future point when today's solutions won't be effective any more.

## INTRODUCING THE PROJECT

Hi, is that you again? The PM with the project, still waiting to find out how much money you got from the organizational pie-slicing process?

Your project is not a stand-alone entity. It is, or hopes to be, just one of several components of a program that has the task of delivering an organizational capability, or bringing about a strategic initiative, on a large scale over an extended period. The question is, how is your project going to fit into that picture?

What you've learned by now is that your project, an innovation of some sort, needs to provide an enhancement to the program's capabilities. That may mean meeting a current mission need, setting up to replace a current solution that is nearing the end of its useful life, or perhaps providing a means of relieving some pressure on the operational costs to allow the program to free up more funding for more enhancements.

The program manager has to balance the operational costs needed for today's activities, which may still be in place for several years, with investments in projects (yes, that's a plural) to keep modernizing. If you want your project to get in on the action, "everyone else is doing it" isn't going to cut it. You're going to have to be able to show how it achieves some necessary component of this solution.

If you've:

1. made a strong case for the business benefits of your project (including cost-benefit, strategic alignment, legal mandates, process improvements and so on)

2. put together solid estimates that look like they have substance behind them

3. considered reasonable risks without being alarmist or going to ridiculous extremes,

then your project might fare well in this fluid process. Or, through absolutely no fault of your own, it might not.

Now is the time when your project will make that cut, or not. Maybe all the available money has to go to another project to research the market demand for your product, or to validate the basic technology you'll need. So it goes.

Beyond all that, the most likely outcome is that the program needs your project's solution, but it needs other projects' solutions just as much or more. So you get some portion of the funding that you need, with the idea that you'll get more to do the whole project in the next go around. The only thing is that the specifics of what you're supposed to get done in the first iteration may never be defined. And for political purposes, the fact that the final delivery will occur over multiple iterations may also remain undefined for as long as possible.

That's frustrating, but it also gives you the opening you need to succeed.

The vagueness of the allocation process as it trickles down to the project level is the reason that you get assigned what appear to be unrealistic budget and schedule constraints. You've probably gathered this by now but let's spell it out: appearances can be deceiving.

You've probably seen versions of this quote before:

I would have written a shorter letter, but I did not have the time" Blaise Pascal, 1656.

No, Mark Twain wouldn't paraphrase it for another 200 years, and Winston Churchill came another 75 years after that.

To steal from that classic, the decision authority would have written more specific standards if it had deemed the investment critical enough to do so.

Your organization's top-priority investment probably has an exact calendar date for the grand kickoff or opening day of whatever the product is, and the organization's contracts and budget people watch it like a hawk to make sure it has what it needs. If you're not running that project, it's probably going to be stealing your money soon enough. Everybody knows this.

Your budget is an actual number, because it's almost impossible to allocate funds in ranges, and even if you think you've been short-changed considering everything that needs to be done, don't get too comfortable with even that limited baseline because you'll likely get shaved of more of that as time goes on.

But, compared to project A-1, your timeline is a lot looser, expressed perhaps in quarters rather than dates. Your scope is probably vaguer too, using words like "improve on ..." rather than "achieve ...".

"We could have been more specific, but we didn't want to" means "do the best you can".

The program manager has already advised the decision authority (let's call it a "board", even if it's just one person) of the consequences of various levels of funding. The board has made a decision as to what the organization can afford in light of all its other priorities. They have accepted that the project will not deliver everything that you (or they) may have originally envisioned.

At least, that's what they were supposed to have done. You need to act as if they did, even if they didn't.

This, perhaps, is the point where you perceive a divergence from the PMBoK, which treats the scope statement as the foundation for all that follows. As we've just seen, your stakeholders have already accepted that yours is just one of many fish in the sea. There may be a scope statement on paper from some prior planning cycle, but that was then. This is now. Now the stakeholders are no longer wedded to it. Now you're going to shift from Managing Scope to Managing Expectations.

It's up to you to redefine what exactly you are supposed to deliver with that money by when. It's what the program is expecting you to do, and it is what the board is expecting the program manager to do, but it might be that they think it is so obvious that you never get told to do it. That's why so many PMs are left to bemoan the impossibility of their situations.

When you make clear what can and cannot happen based on the funding you do have, you can take control of your own destiny. If you can execute with what you do have, you may even end up scooping up money from other initiatives that lumber along trying to follow unrealistic plans and getting nowhere.

You've probably picked up by now that a theme running through the book is that the big challenge for a PM is to shift from executing best practices to dealing with things as they are in our imperfect world, not how they should be. How things really are is what you need to understand if you want to know why your project gets assigned these unreasonable constraints. It also helps you see how you can work the system to end up with an outcome that the stakeholders agree to be successful, even if it isn't everything that everyone had imagined it could be..

This approach may be imperfect, but it seems to be one that works when it is used. In many years of looking at many organizations, I haven't found any other way that works at all, let alone a better way. I've seen organizations try to do it better and faster, but mostly they just get into trouble because more streamlined or more elegant processes tend to overlook one or more of the problems we've just been describing.

When an organization invests political energy into putting an elaborate decision process into place, it seldom tolerates the discussion of Plan B under which funds would be allocated if the great algorithm-based investment-picking machine implodes. That's unfortunate because we know that for all the reasons listed in this chapter, the algorithm isn't likely to work out, and the odds are that Plan B becomes Plan A. In that case, it should have been Plan A all along!

Without Plan B, it's everyone for themselves. The budget turns into the big grab bag we discussed earlier as the worst possible alternative. Funding gets dished out based on the personal relationships between the program owners and the person holding the bag. That, I can assure you, is no way to run an organization. So be careful what you wish for.

## THE CLOCK KEEPS TICKING

The main thrust of this phase may be portfolio management, but there's a lot more going on than just fitting projects into budgets.

Time has passed since the Strategic Plan was released. It's being re-evaluated constantly. It's going to change: the future is always a moving target. Stay up with the strategy to make sure your project remains aligned with the current priorities.

The program management offices are juggling resources to help some activities get to the finish line, to keep those projects that are "givers" ahead of the projects that are "takers" where there is a dependency, and to deal with the inevitable crises in the operational activities. Maybe your project can benefit from periods when resources are standing down from the top-priority initiatives. If you are the one holding that top spot, you'd better be ready to use those critical resources that have been reserved for you when they show up, or they'll be given to Project B-6, which is ready to use them.

The program's cycle of component activities and solutions (its "enterprise architecture") continues to get built out and replace itself. Especially in technology, the distant past may only be a few months ago. Make sure your project is heading in the technical direction of the future, not the past.

External financial events continue to occur, forcing adjustment of the resources that may be available. If you don't plan for the obvious, you won't have a Plan B when events occur. Then your only option may be to shut down.

## KEY TIPS FOR GETTING YOUR INVESTMENT SELECTED

Now that you know how most organizations approach the complex problem of selecting between widely dissimilar choices, it's not too hard to come up with a strategy for getting what you need.

Many PMs fight the idea that there is a fixed budget and you have to fit into it. They think that if the benefits are great enough, the resources need to be found. Most of the time, that's simply not going to happen. Remember, Cash is King. When the organization runs out, it has to stop, no matter how wonderful the things are that might have been done if they just had a few more dollars. Because they don't.

So your challenge is to fit in to what is there.

### Solutions Get Funded. Wishes Don't.

They say you have to see something seven times before it sinks in.

1. To get funded, offer a solution to a current problem. By "current", I mean one that is recognized right now as a problem that needs to be solved so that the program can make progress, even if it will not actually occur for some time. By "problem", I don't mean riots in the streets or massive daily losses; it's just a capability gap that needs to be closed. So, if your project is the solution to something that the program manager wants to get on with right now, you'll likely get whatever funding the program manager can scrape together for you (which of course will not be as much as you said you needed).

2. To get funded, offer a solution to a current problem

3. To get funded, offer a solution to a current problem

4. To get funded, offer a solution to a current problem

5. To get funded, offer a solution to a current problem

6. To get funded, offer a solution to a current problem

7. To get funded, offer a solution to a current problem

Did I get you to notice that you'll need to offer a solution to a problem that people who are making the decision will recognize right now as a problem that needs to be solved? Great! Otherwise I'll have to say it again.

### Never Give Up. Real Requirements Seldom Die.

You don't always get what you want. At least in my experience, that's the case more often than not. Especially at first, it may seem as if you never get what you want.

Here's a basic truth. Real requirements never go away. They just keep moving to the right, and the longer they go unmet, the more complex (and expensive) they become.

It's really an extension of the previous list. If a solution is needed, then it will remain needed until the problem gets solved. Sooner or later, if the problem is severe enough, it will become obvious that fixing it now will cost less than continuing to put up with the problem for another year.

The better and more cost-effective your solution is, and the more people know that you have this solution, the more people will insist on adopting your solution to deal with the problem as soon as possible. That benefits everybody (well, except for the providers of the solutions that got bumped for yours!)

### Embrace Zero-Sum

Zero-sum is just the famous Iron Triangle come to life.

If you're not familiar with those terms, zero-sum is the concept that the total pool of resources is fixed and already fully allocated. Changing where the resources are going requires taking existing resources from some and giving them to others.

The iron triangle is the project management world's key tenet: in any project, the cost, scope and schedule are inherently linked. You cannot adjust one without having an impact on the other two.

Zero-Sum is really just an obvious variant of that. In the short term, the availability of funds is a constant. When you've accounted for all the money, any increase in any of the investments has to come from one or more of the other investments.

You can read a lot more about how to leverage the idea of Zero-Sum in my earlier book, "Let It Simmer: Making Program, Portfolio, and Project Management Practices Stick in A Skeptical Organization", and it is at the heart of much of my other materials at www.decisionintegration.com.

Given the reality that real requirements never go away, you're better off embracing the budget caps. Now your problem becomes showing how selected core components of your project are the best use of the organization's limited funds. Thinking that way forces you out of thinking "hey, it's a good thing, let's do it" and into thinking "how can I make this the most valuable asset possible?"

Maybe you lose the budget battles at the overall level because you've been assigned to a project that doesn't aspire to rock-stardom. In that case, bring zero-sum back into the game by ratcheting down on the deliverables towards a Minimum Viable Product.

If you can demonstrate that the program cannot achieve its objectives without your product, and if you can get your total costs to a level that is insignificant by the program's standards, you should seldom have difficulty getting at least some funding to keep moving forward.

Usually the problem in budgeting is that the program gets down to the last ten percent or so and each one of the investments left on the list requires more money than is left for all of them. Now along you come with a very modest request that fills in the gaps very nicely. Consider yourself funded.

Holding out for all or nothing usually gets you nothing.

Why so? The organization has already said that the full benefit you had planned to deliver doesn't really compare to what other projects are bringing in. In that case, spending what little money you can get to make sure that at least something useful is completed is a better use of funds than struggling through partial completion of a wider scope. It emphasizes that your original estimates weren't padded, and it reinforces the message that you only get what you pay for. When you do deliver something that works instead of a stack of requirements documents, your project will start to get that subjective boost that executives give to projects run by people who know how to get things done.

"Product talks, paper walks": Frank Greco.

### Find Some Dependents

The best way to make it onto the funded list and stay there is to be working on a solution that people feel that they just have to have. It doesn't have to be a retail customer out in the wide world; there are internal customers too.

Ideally, your solution solves a problem for another program component that enjoys strong support. In that case, they cannot deliver unless you do, and you've just earned yourself some powerful allies. Now all you have to do is deliver!

I'm not suggesting that you make bogus promises of what your solution will be able to do just to scam them into supporting your project. But if there really is a relationship there, it would be irresponsible not to note it.

You can get some help with this from the corporate strategy group and the business architecture team, which may call themselves by other names in your organization. What you're looking for is the groups that can see across all initiatives and will be able to help you see connections that don't jump right out at you. There may be some activity going on in an entirely different business unit that could really benefit from what you're planning to do.

You might even find a piece of your own solution over there, too, in which case you can reduce the cost of your own project.

It wouldn't be right, or sensible, to add "cool factor" bells and whistles to your project plan in an effort to fish for support from the kind of executive who is always a sucker for the latest shiny object. (Be forewarned: there are lots of both shiny objects and suckers out there). It would just make your project more expensive without meeting any more of the program's capability needs. The program manager ought to kill that idea off as soon as it appears, and it will probably make him or her start doubting your own motives or common sense at the same time.

What is legitimate, if you can find the opportunity, is to tweak your solution so that it also meets the needs of some other initiative (or some group that doesn't even have one on the books). Now you're delivering a capability that the organization does need for a marginal increase in cost on your project instead of cranking up another whole project.

Better yet, the manager of the other group may be able to throw some funding your way: even if they weren't able to afford a whole new project, maybe they can afford to co-sponsor part of a project (i.e. yours).

### When Opportunity Knocks, Be Prepared

This tip is a bit of an extension from the others, and it doesn't come into play until later in the organization's decision cycle. But here is where you set things up for success.

Once you've set up your project phases to deliver what you can with what you are going to get, don't stop there. Look at the elements that you had to let go and set them up for execution too. Maybe the organization will get unexpected revenues.

Even more likely, maybe one of the other investments will stall out, leaving funds available to be re-invested elsewhere. When that happens, if they even apply at all, the formal decision processes are thrown into disarray because the new number one criterion becomes "who's got something that we can launch right now?" And there you'll be!

Of course, being there is one thing. Being prepared is another. If your project didn't get the funding that you wanted up front, live every day as if some additional funding might appear tomorrow. When it does, you need more than a plan. You need to be ready to roll right into action:

  * Have your benefits story (your elevator speech) ready and rehearsed.

  * Have your project broken down into bite-sized chunks of useful increments

  * Have the contract instruments you need already in place, or as close as possible to being ready to launch

Even if funding doesn't show up, you can be guaranteed that others will try and steal some of whatever you did get. So don't stop telling people about the benefits of your project.

Whether it's a sudden opportunity to tell the governance board that you're in the perfect position to absorb that last bit of unspent budget, or to explain why it would be a bad idea to cut your project back, remember: tell them a story. Tell them about your initiative in a way that resonates with their subjective views of total business value, not your nuts-and-bolts world. Give them something to work with.

If your description of what your project is about is simply a recitation of the features it will have or the methods it will use, you're not going to win much support. Think about the purpose of the solution, of the problem that it solves, and speak to that.

Just don't overdo it. If you're doing a hard sell with all promises and no substance, you'll lose support quickly and permanently if the executives do give you that money and you come up empty-handed.

__[Return to the Table of Contents _]_

Chapter Six: Tweak Those Baselines

At long last, the approved budget or current-year funding makes its way down to the project level.

The odds are that it won't be what you think you need to get the job done to the degree that everyone seems to be expecting. More likely, you're going to get assigned to the project after it is approved and you're going to wonder how in the heck "they" thought they were going to get this done in the time and for the money that you've been given.

From the title of this book, you've had a right to expect that I wouldn't just talk about how things work and why you get hit with these crazy baselines instead of doing the proper analysis that the PMBoK calls for. The title promised ideas on what to do about it. So far, I've said repeatedly that it's all the result of largely political, non-rational assessments and once it gets to you they're not really likely to change. That may be helpful in philosophically accepting how things came to be, but it doesn't help you in moving forward.

Here's where that part begins, and most of the rest of the book will indeed be about how to get a successful result out of this unpalatable beginning.

If you want to amuse yourself for a few days, try to find the person or persons who submitted the original concept and estimate. If you can find them, then you might learn something about a way of doing the work that hadn't occurred to you or the project team members (if they have even been assigned yet).

Don't put anything else on hold while you're looking for those people. The odds are that they are nowhere to be found, for several reasons:

1. The sales representatives trying to win new customers, the budgeteers who had to put something in the spreadsheet, the executives who launched a boasting contest over coffee and cigars as to who could do what faster and cheaper, and the program managers throwing numbers against the wall to try to out-guess how much money was in the pot ... none of them are about to admit that they just made up a number that "sounded right", or added up a series of speculative guesses. Yes, they did do it, and in my other books you can read about why they probably should have done it that way, but even so they'll never admit it..

2. The program executives handed out several batches of seed money to see what would work, in hopes of getting money once the concepts proved themselves. Now, rather than cutting back on any of the pilots, whatever money could be found has been sprinkled across all the pilots in the hope of keeping them all alive until adequate money appears. So the money you have is not in any way related to the amount you actually need.

3. The organization may well be process-averse enough (or liability-obsessed enough) that there really aren't many records of what got decided or how.

4. The program manager doesn't feel able to articulate how the overall budget got shredded out to your satisfaction, so they decide to fob you off with some lame story that is even more unsatisfactory than the reality. Now that you have this book, you probably do understand how the number got to be what it is. Consider giving them a copy of this book and ask whether it conforms to the reality in your organization.

As you've learned so far, it doesn't really matter how the numbers got to be what they are. They aren't going to change unless there's a major blow-up, which as the PM is something you want to avoid for career purposes.

Or at least, they're not going to appear to change. What can change is the understanding of what those numbers mean.

What happens next depends on your situation. If the project is being done for internal purposes, there's probably a lot of wiggle room. If it's being done on a contract to someone else then there may not be so much flexibility, and failing to meet a date may have serious financial consequences, but there's usually room for interpretation on what exactly "it" is.

While we're here I'll just note that in over 20 years of working with contracts, I've only once seen a case where the customer or contracts office insisted on proper and complete accountability for all the original deliverables, and that's even when there was no cutback in funding. Usually, as long as the customers are getting the result they want, the rest works itself out.

That lone exception was, ironically, the precise opposite. It wasn't that the customer wouldn't provide relief: the providing company refused to ask for it.

My company was advising the former major consulting firm EDS in its execution of a massive contract. My risk team warned them that they needed to get relief from milestones that were written into the contract as hard dates, even though the contract itself was awarded some 9 months later than anticipated. EDS didn't want to do anything that would add any further delay to getting the contract signed and chose not to bring this matter up with the contracting office, which would certainly have made this simple administrative change with little fanfare. We didn't see a happy ending for this story and terminated what could have been a lucrative contact with them.

Six months later, just as we told EDS might happen, the Navy defaulted EDS for the first payment of $750 million for failing to deliver to those original dates, since EDS hadn't asked for relief. They did it twice more before EDS caught up to the milestone calendar but by then it had lost so much money \- literally billions and billions - that the entire massive company folded.

Lesson learned: you can't assume that you're going to get relief on a contractual provision; you may end up having to deliver something that the customer's technical lead is going to accept. But you should assume that there's little harm in asking and there's a lot of harm in failing to ask.

## IT DEPENDS ON THE MEANING OF "IT"

At this point in the project, you're thinking that you can't possibly get it done in the time remaining with the resources allocated.

Remember what happens in the majority of projects that are launched, according to PMI, Gartner and the Standish Group. The calendar marches on, and to keep up with it, projects continue to move forward ... and to fail ... and yet move forward. You need to understand that even if you don't deliver all of the currently-stated requirements within the approved schedule and budget, there will not actually be an organizational meltdown.

The solution is pretty simple, at least in concept. Of course there's more to the art of actually pulling that off, which is why we're going to spend another 25 pages on it, and you're going to spend a career perfecting your approach. But at the core, it's a really simple perspective.

You think your problem is that you can't get "it" done.

To borrow from the example of Bill Clinton's infamous quibble, it all depends on the meaning of the word "it".

## THE IRON TRIANGLE AGAIN

In the case of a project, you've got three different ways to get the angels to dance on the head of your pin: scope, cost and schedule.

If you've been in the PM game for more than a few months, you've heard of the Iron Triangle. Cost, scope and schedule are locked in a permanent equilibrium. You cannot adjust one without having an impact on the others.

If, in your view, your project is grossly under-funded, or the milestones have gone beyond "aggressive" and are into "insane" territory, you are drawing that conclusion based on your assessment of what the scope is.

Most PMs assume that, since the purpose of a project is to deliver the product that the customer is expecting, the scope side is locked in by those expectations. If that's the case, then, to get the triangle back on its feet, either the budget or schedule need to be loosened up to match the scope.

Now is when your PM chops come into play. Being a capable PM isn't about being able to develop the most exotic Gantt chart. Just as for any manager, the job is rarely about performing technical functions. It's about getting people who do not work for you to do things they don't necessarily feel like doing.

Program managers and customers don't want to give you more time and more money. Customers don't want products that cannot meet their every need and desire. Team members don't want to work night and day to deliver to a specified date that doesn't seem to have any actual significance. Suppliers don't want to give you their real best price or most responsive delivery. The list goes on.

You have no choice but to adjust as much as you can to their realities. What we tend to forget is that they realize (even though they would never admit it) that, within reason, they are also going to have to adjust to yours.

I'm not suggesting here that you abrogate contracts or cut corners to deliver something that appears good but isn't. Any adjustments need to be on the table and made by mutual (if, perhaps, reluctant) agreement.

Focus on the end game. If the customer is going to end up happy, only in progressive steps rather than a big bang that might fail, you might even get more support than you expected. Maybe you can sweeten the pot by delivering high-value capabilities earlier than agreed in return for flexibility on the lower-value products.

If that doesn't happen, if the constraints are in fact unrealistic and nobody on any side is willing to give the inches needed to deliver successfully, then perhaps you were right to be gloomy about the project being doomed from the start by decision-makers who have now shifted from being non-rational to hyper-rational. "This was the deal, now do it!"

More likely, though, you'll find out that iron triangle isn't quite as unyielding as it looks. It has a bit of give to it. Whatever "it" can be made to mean.

## THE OBVIOUS SOLUTION: ADJUST SCOPE

A lot of PMs forget that the triangle has three sides. They tend to think about crashing schedules to save time, or ways to leverage resources (mostly labor) to save money.

Most organizations don't do very well with managing scope. That's why so many projects fail! Project stakeholders just know they want something that is better than what they have today. It gets a lot harder when you start asking "better in what way?"

It's an ill wind that blows nobody any good. The sorry track record of requirements management is, for once, your ally.

The primary cause of project failure continues to be "bad requirements." We would be wise to assume that this will apply to us too. And we're not going to simply stall the project in its tracks until we get a perfect requirements document.

There's a saying in the consulting field: "I don't want it good, I want it Thursday". It's not that you're going to refuse to take it if it is good, but what you really need is a solution to your problem by Thursday. It just has to be good enough to solve the problem.

In fact, it may only have to be good enough to solve part of the problem. Sometimes we have to solve the most important part. Sometimes just relieving the most annoying part is good enough for a start. Go back, read the statement of work, if the acquisition has gone that far, and really understand what it asks for.

Now go see the program manager. (Apologize, if you should, for your earlier whining!) Learn more about the context of your project. How did the project actually come into being? Where are the pain points?

Now, if it's possible to do so without undermining any role the program manager and sponsor should play, go meet key stakeholders. As a PM, you should be doing this to the maximum extent you can anyway, but perhaps you've been doing that from a relationships perspective.

These visits are about actual content. All too often we leave the understanding of the requirements in the hands of subject-matter experts, often specialist consultants, who always get deep in the weeds but often miss the actual business point. You, the PM, need to find out what the real boundaries are and define them before these experts eat up what little budget you do have.

So don't go in with your elevator speech about how your project is going to yield a product that is better than sliced bread. Don't try to sell them on your project as you have envisioned it. Instead, listen to what they really want and let them build the elevator speech you'll use going forward.

Find out what problem the stakeholders are trying to solve, and what the cause of it was. This isn't a detailed requirements analysis. You're trying to determine a solution or, better yet, a series of incremental solutions that will meet the customer's objectives and can be phased in within reasonable affordability limits.

You'll be very surprised to learn the degree to which most customers are able to accept incremental successes.

Some customers will even be happy with increments that simply demonstrate that things are moving in the right direction. I'm not usually a fan of that logic, but when the capabilities and solutions are very large and will take a long time even when they are going well, insisting on Agile-style "delivery" every month or so just isn't going to happen.

As often as not, it will be your own internal subject-matter experts who are opposed to this approach. They want the organization to look good and not deliver something half-baked.

That's understandable, but what they fail to appreciate is that the organization looks a heck of a lot worse if it fields a massive solution that is garbage, or if it forces the customer to wait interminably to produce the exactly perfect solution (which, by the way, it never will be).

Again, successful delivery of something useful gets you a lot more credibility than promising to deliver something great at some date to be announced. When you have those small wins, people are more likely to open up their bank accounts for the next-step enhancements.

One caution: if the statement of work includes the old-school deliverables, you can't just brush them off. See about getting it changed. Down the road, some recent-college-graduate auditing intern will inquire about those deliverables, and the contract monitors (if they are still there) will develop amnesia as to how they concluded an agreement on best value contrary to the statement of work and not documented anywhere.

Unfortunately, for fear of those same future interns, many program managers prefer to cover their trails in the here and now with paper to defend against those future criticisms, rather than taking steps now to drop deliverables that are simply not necessary or to descope deliverables that are greatly over-specified in light of the projects' reduced ambitions. Then you'll have to figure out how to deliver minimally-compliant documents without wasting much time on them. Those go into the record. Then you and your customer can go back to the effort of delivering a solution.

By the way, this isn't a diatribe against all non-product deliverables. Many auxiliary documents are valuable. They'll be important later on in supporting a product long after everyone who worked on it has moved on, and they can be useful to other PMs who will undertake similar efforts in the future. But if they are designed to describe or manage a situation that no longer exists, then they aren't helping at all, and they are diverting resources from work that is needed. In an already-underfunded situation, you want to minimize that.

Sometimes, incremental solutions are impractical. If you're replacing a financial management system, you're pretty much either using it or not using it. For instance, very few organizations would split their financials across two different systems. At least not willingly. But even in that case, there are often issues of scale that force organizations to work out some sort of transition.

## BENDING THE IRON: A CASE STUDY

When the cellular telephone business first started taking off, the major telephone companies spun off cellular companies as subsidiaries to avoid further regulation. Dozens of cellular startups sprang up, and for a couple of years it was really quite confusing to try and purchase cellular service. Quicker than one could even imagine (in the space of perhaps 3 or 4 years), the subsidiaries grew to the point that they in turn ate their parent companies and many of their siblings.

The next thing you knew, the cellular industry had reverted to three or four major players, just like the landline business they had replaced. In the midst of all this, I landed on a project to integrate billing systems for Bell South Mobile, which bought dozens of companies while becoming Cingular, which was one of the dominant players for a decade before being in turn acquired by AT&T.

Bell South needed to get these companies onto the same financial platform as soon as possible, because the old companies had legally ceased to exist. Certain transactions, such as the customer's basic account, had to be concluded on Bell South's computer systems. Until the conversion could occur, customers would be subjected to having their information entered into two or three different computers in the same store, and Bell South would be totally dependent on the unknown processes lurking somewhere in the acquired company's system. They wanted this problem to be resolved by the end of their fiscal year so they could start the new year with clean, comprehensive financial information. Not to mention keeping things simple for the Internal Revenue Service, which is always wise. So it had to be done, by that date.

There's a certain finality with the words "had to". When they come from the person signing your paycheck, or your contract payments, that makes you stop whining and get on with it.

But even a major organization like that doesn't always get what it wants.

Bills are just numbers, aren't they? How hard can it be to reformat reports that essentially describe the same event, selling cell phone service to a customer? Harder than you might think.

It seemed insane that an apparently simple thing like a cellular bill couldn't be standardized, but that was the case. The myriad of incentives and local deals the acquired companies had offered during their growth spurts made it impossible for Bell South to figure out what was going on and integrate systems for more than two of the acquired companies at a time, and there were over a dozen of them.

Most of the effort was in figuring out what all the different variants were, and that required human-to-human interactions followed by manual postings and validation. Once that was done, automating the business rules that would sustain these various incentive plans in the new central system went relatively quickly and the conversion process itself could be automated.

These conversions could also be done on parallel tracks that would then lead to a point where systems could be converged. But it would have required dedicating several more teams at a cost of over two million more dollars, and the consolidation wasn't worth that big of a hit to the corporate overhead. For that kind of money, the company would prefer to limp along and continue running multiple systems in parallel until each one could be integrated. So, even though it was critical to get something done by a certain date, we ended up coming up with a plan to keep the ball moving forward as fast as possible but missing the desired date by many months for the total completion of all the work.

Once it was clear we had done our homework on the level of effort and degree of due diligence required, the executives were disappointed but agreed that having a third of the companies completely converted this year was a lot better than having all of the companies' systems one-third converted.

That's what we did, and over the extended period the company completed this massive effort flawlessly, at least as far as anyone could tell. That placed it in a very small club, at a time when, after a wild decade-long ride of mergers and acquisitions, many industry titans began to experience the procedural hangovers that led to the popping of the dot-com bubble. Despite "failing", this project was a huge success.

It may also be a warning not to take the "failing projects" hysteria generated by the Standish reports and other sources too seriously. Of course you want to deliver a good product, on time, under budget, but what you **really** want is a satisfied customer.

That doesn't just describe the situation in the world of IT. In fact, the less the solution is about an automated system, the more likely it is that you would be able to deliver it in increments. You'd have a hard time thinking up a business program that couldn't split itself somehow.

For instance, if you're an academic institution starting a new on-line master's degree program, you don't really have to have all the syllabi completed and all the video lectures recorded on hand right now for the full three-year program. All you need is the ability to get students enrolled and enough courseware to get through the first semester. Now you've got three more months to come up with another semester's worth of courseware, and within 18 months the whole course will be complete.

What about construction? You can't do half a building. No, but in the very neighborhood where I live, there are lots on which office towers will someday be built. They've bought the land, they've got the permits. They haven't broken ground. And just as well. Nobody wants office towers any more. They want multi-use buildings, with apartments above stores. Just was well we didn't build a bunch of empty towers! Of course you can phase construction.

## NOT SO LIKELY: ADJUST SCHEDULE

In the commercial world, commitments tend to be made based on schedules, not on cost or scope. That reflects a key reality. You can always re-release a "new and improved" product, you can usually find more money somewhere, but you can never recapture time.

Some time commitments are real: elections are on a certain day, the World Championship contests of any sport are held during certain periods, annual trade shows must happen on the date advertised, and so on.

Others are self-imposed. Perhaps the most common is the fiscal year ending date. It's convenient. It's not carved in stone; if it has to move, it can (but you should expect a lot of resistance, for all the pragmatic reasons).

In large publicly-held corporations, another self-imposed date is a bit more rigid even though it usually is quite vague. For such companies, the major financial news analysis houses have a stock analyst whose sole job is to follow the activities of each company (or a group of similar companies). When a corporate executive makes some sort of public statement, or issues a press release, indicating that something will be delivered "this year", "in the third quarter" or "soon", that analyst dutifully records it as a corporate commitment and starts tracking it to see if the company comes through.

Time is a simple enough idea that your average recent college graduate (i.e. your average "analyst") can understand a calendar date. If your product is full of holes but people tolerate it, then they'll write articles about your vibe and your connectedness with your customers. Miss a delivery date and you would think the entire economy had gone into a tailspin. If the company doesn't deliver, or the market doesn't like the product, the analysts downgrade their assessments of the company. The stock value slides. This can cost company executives millions of dollars in their bonus programs and stock options, so they view these dates as having supreme importance.

If you're in the government, there are certain dates that really are deadlines: on the last day of the fiscal year, you run out of money even if you had some. Certain regulatory schemes require customers to file their reports by a certain date, so you'd better not let the staff take vacation at that time.

Having said all that, we know that over 50 percent of all IT projects don't make their baselines, and the returns from non-IT projects are not so much better. As the deadline looms, the organization is faced with hoping for miracles (which seldom arrive) but, in the absence of such a miracle, the delivery date shifts. As often as not, neither your organization nor the customer fall apart, so that emotional must-have date appears not to have been quite such a cataclysmic event as all that.

If your project still doesn't get the priority and resources that it needs, then the date will slip again.

Nonetheless, if any commitments have been made to a paying customer, shifting the promised launch date is probably the least likely area in which to get relief.

There is a common belief in the Washington area that as long as the delay is caused by the customer, and therefore not punishable under a contract, that somehow the deadline has shifted. One of the classic maneuvers is writing customer reviews into the contract, with final deliverables due "30 days after receipt of comments". Since the government is almost always tardy in providing such reviews, that buys the performing entity more weeks or months of time to deliver something acceptable, and it creates an automatic shift in expectations, even if there is no formal change in the baseline.

That may be true from a contractual standpoint, and it may work in Washington where the typical deliverable is just a bundle of paper anyway, but it isn't true for customers who wants actual things to happen.

If your company is building an Olympic venue and it doesn't open on time, you may have figured out some way in which you're not contractually liable, but you're going to have a hard time getting much work in the future.

Even in the government, the fact that something that should have been completed in 2014 and is still alive and kicking in 2017 is something that the average harried bureaucrat cannot fix (or, in reality, just does not know how to fix), but that doesn't mean they see it as fine and dandy.

Just because it's legal doesn't make it right.

## THERE'S NO MORE MONEY, BUT IT ALWAYS APPEARS

I've seldom worked with an organization that didn't claim to have allocated out all the funding that it expected to have. I've also never worked with one that didn't produce money out of the magic hat when the CEO decided that some new idea to Save the Planet (and make Lots of Money) needed to get under way Right Now.

The same goes when some very important project is about to fall off a cliff. Somehow, resources appear to shore it up. So if that's about to happen to you, the world will probably not end.

At least, not for your project. I have to admit that it may not look good for you, although you'd be surprised at the resiliency of many organizations' attitudes as long as the project does indeed deliver value at some point.

This isn't a great road to follow. When handed an insane deadline and a few pennies from the kitty to get it done with, it may be slightly comforting to know that eventually reality will assert itself. If it really is needed, the money is likely to appear somehow. While you may get your delivery out the door, no matter how nice people try to be about it, you will forever be known as the PM who pretty much put the company at risk, or at least the one who blew the budget forecasts and ended up taking everyone else's project money (or, worse, ate up the bonus pool).

Bottom line?

  * You're not going to get more time, until you blow the first deadline

  * You might be able to get more money, although the odds are that you won't get it until the project has reached a desperate situation

  * You will probably be able to figure out how to break the project into chunks that will fit into the time and money available and will still satisfy the customer's most pressing needs.

That being the case, rather than spending a lot of time "crashing" the schedule to ever more unrealistic durations and ever more radical dependencies on resource availability, the best bet is to redefine the meaning of "it".

## DEALING WITH IMPOSSIBLE CONSTRAINTS

So that's the answer to the question in the title of the book. Negotiate what "it" means to you and everyone else. Then, if you have to, re-negotiate, and keep doing it, as long as the customer is getting the best possible result that can be expected from your organization.

It's possible that the customer will decide that your best isn't good enough. If that's true, and there are other organizations that can provide these services better, faster and cheaper, then the problem isn't with the project, it's with your organization. In that case it's up to you to decide whether some internal process improvement is possible; if not, you'd be wise to start looking for organizations that can be competitive in their market.

By now you know why program managers assign these impossible deadlines and unrealistic budgets: you're just part of a bigger picture, and you're not the top priority. It's probably a complex picture too, which means there are a lot of moving parts, several ways to put them together, and some wiggle room between the parts.

Keep making sure that it is crystal clear that any suggestions you might make are intended to help meet the program's objectives within the constraints you've been allotted. When the program manager is convinced that you are playing along and coming up with the best possible approach, they might just tell you they've decided to fund a better approach (yours) now that they understand the issues.

It happens more often than you might think (partly because so many other PMs fight the system to the bitter end). Don't get caught out now being just another complainer with no real solutions. Be prepared with a realistic plan for getting the job done properly, maybe with a bit of extra money but within the business-driven deadlines.

Or maybe they won't.

Either way, from this point forward you'll be operating under whatever deal was agreed to, or whatever you've been ordered to do.

So let's get out there and deliver something!

__[Return to the Table of Contents _]_

Chapter Seven: Learning to Love Your Baselines

Well, all right! You've got your funding, and your project is under way. We don't have to spend a lot of time on the Control phase, because you've already learned about how the project constraints really are set and how to influence that. Now that the project has started, the baselines are what they are.

Or are they?

Hopefully you got lucky leading up to this point and the project has nice healthy cost and schedule buffers. In theory, then, you should be fat, dumb and happy: just execute.

If you didn't get so lucky, then you're starting out over-promised with little likelihood of over-delivering. How your project is progressing against the baseline is going to be a source of contention for the remainder of the project's life.

The good news, if you can call it that, is the odds are that after a little while the lucky folks are probably not going to have it any easier anyway. They'll be running into our good friend Murphy. A corollary to Murphy's Law says: "When you've planned for the worst imaginable situation, the real situation is always much worse than anyone ever imagined". The next thing you know, the fatted calf is going to be bucking up against its baselines.

Either way, before long the PMs will be bleating again about unrealistic schedules and impossible budgets. Only now it's not just a theoretical discussion: these projects are actually under way, and the meters are turning.

Let's face it, the baselines are just a tool. They have no religious significance (except when you are taking your PM certification examination), but they do have a great deal of practical significance.

1. No project is an island. You don't get to do whatever you think best, whenever you want. Your project exists to deliver a needed capability to the program it is part of.

2. In any complex organization, projects have many points of integration. That has to be coordinated somehow.

3. It's not **your** project. You didn't get the money from the tooth fairy. The people who gave it to you are entitled to seek some assurance that they'll be getting what **they** paid for.

In other words, there are realities out there beyond the mere fact of a baseline. Most of the people who can actually influence things don't even know what a "baseline" is. What they want is a solution.

Therein lies the opportunity to succeed despite everything that may have happened before the project got onto a stable footing. Baselines serve a purpose, but they're not religious artifacts. They can change, and they will, especially when they have to.

Just make sure that the change is being forced on the project by circumstances beyond your control. I suppose it feels better if it's one you foresaw and warned about from the start, although this seldom endears you to any of the other stakeholders because it implies that they were stupid for not listening to you earlier, so don't make a big deal out of it.

## EXECUTIVE REVIEWS AND REDIRECTION

One of the great First Sergeants I served with in the Army used to tell his troops: "If you can't get out of it, get into it".

In other words, since you can't avoid having to do the reviews, you might as well make the most out of the opportunity. And it is a great opportunity to have the undivided attention of senior executives who you seldom see otherwise, and to observe how they interact and to hear their thinking processes. Do well and it's a shortcut to stepping up the corporate ladder. You can't get out of the reviews, nor should you want to, so ... get into it.

Make the project reviews worth the board or sponsors' time, and they in turn will provide the support you need when the going gets tough.

I know, it takes a lot of effort to get together an executive review. You feel like you have to have it just perfect for these highly placed people, and there doesn't seem to be any upside, only an opportunity to embarrass yourself. I'm a bit of a ham myself, so I don't usually mind making presentations, but even so those thoughts do cross my mind too. Any PM who doesn't find it at least a little bit stressful doesn't really understand the gravity of the situation.

Now it's going to seem as if you spend half your time as a project manager preparing for reviews by people who didn't pay attention the last time you told them and don't seem to understand what you're talking about anyway. Meanwhile you're taking valuable days away from the actual work on your project.

Get over it. It's not your project, it's the organization's project, and these are the people who are giving you the money for it. They're the reason the project exists at all.

Yes, it often happens that the sponsor and customer are happy to offload this project onto your shoulders. It's very flattering to the ego to know that these senior people trust you with their prize baby. But if you let them do that, it will be very hard to get them back to the table when their support is most needed.

Of course you must be respectful but you must communicate to them that most of the problems that happen on projects come from the people deciding it's not their top priority. The executive probably will be able to fix things by getting involved after there's a problem, but why go there? Their active involvement will keep the project team in the boat and make it less likely that things will go wrong in the first place.

I've been on projects that had frequent and sometimes tedious executive reviews. I've been on projects that just trundled along by themselves. Sure, if everything goes absolutely perfectly, then appearing with trumpets and a perfect delivery can lead to those gratifying oohs and aahs. You'll find out that this halo dims after a couple of days.

Most of the time, you'll be wishing you could get more time with your sponsor and with your key stakeholders, not less.

First, let's shed the negativity. The reviews aren't intended to be inquisitions. They are supposed to be a means of letting the business sponsors and bill-payers know that the project is maintaining good progress towards delivering the solution to their business problem. A solution in which, by the way, they've invested a lot of money. That was their part of the deal.

All they want in return is a warm fuzzy feeling that their investment is still working out and, where needed, early warning of potential issues, so they can help clear them away before they become serious problems that undermine that investment.

It only becomes an inquisition if you're not living up to your end of the deal.

In practice, maybe 95 percent of projects do run into issues. It would be a surprise if they did not. After all, the point of a project is to do something that is at least a little bit innovative (even if only in this organization's experience). When they do, timely and open reviews will not only ease the way if things really do go wrong, but also they may well generate the resources needed to stop them from going really wrong.

That in turn will result in pulling the resources from somewhere else, leaving two or three other PMs complaining about capricious and uninformed decisions by the executives (and even more loudly about your incompetence as a PM).

So now you know. When Murphy hits a project that is not your project harder than anyone could have imagined, the resource adjustments needed to deal with that problem have to come from somewhere. In the absence of any new source of money, that means taking it from other lower-priority investments. That's you. And that is where your unreasonable budgets and impossible deadlines come from!

## DEPENDENCY REVIEWS

Not all reviews are with the executives or governance board. Many are held on a more informal basis, although it may turn out that you end up with a baseline change anyway.

One of the most important things the program manager should be doing is to hold dependency reviews. These are quite similar to normal status meetings, except that all the affected projects attend, and the review covers only the tasks that create cross-project dependencies.

It may be "only", but you'll find that it will give you quite enough to handle.

If you're dependent on another project and they announce that they're running 60 days behind the schedule, it's pretty annoying. It could well force a change in your baseline. But, thanks to the review, you find out about this 120 days in advance of the originally-planned delivery date, so you can start reworking your plans. Finding out at the last minute really would put your project into an impossible position.

## TECHNICAL REVIEWS

You might have noticed in the SDLC picture we shared earlier, in the part that applies to in-flight projects, that projects have reviews on the top and bottom side of the SDLC phases, and most of them are on the bottom side. The ones on the top represent "Decision Authority" reviews, i.e. decisions by the business executives; those on the bottom are technical reviews led by technical experts.

That's a fairly typical arrangement. The executives can't be experts in every possible technical solution the organization might undertake. It's a waste of their time to have a bunch of executives sitting for three or four hours through a detailed assessment of design details, legal compliance or manufacturing specifications.

Don't be misled into thinking they don't have the technical skills to do such a review; a good executive will often surprise you that way. But the organization already has (or had better have!) good people who understand the details. The executives are there to make the gut calls: given what we now know about the problem and the solution, is this investment still worth it?

At those management reviews (the top line of reviews in the picture), the focus needs to be on why this investment will be, or remains, a good idea. That discussion is based on customer needs, costs, benefits and preferably some confidence level around those metrics. These discussions are about larger-scale issues and should not devolve into an arcane technical discussion. The executives expect that the progress reports and proposals to move into the next phases are supported by solid information on the solution, and all they want in that department is a "thumbs-up" or "thumbs-down" from their best experts based on their assessments during these technical reviews.

Even though these reviews are subsidiary to the final decision, don't under-estimate them. A red flag on the technical review means that the executives simply won't entertain an approval review. If you can't get clearance to proceed, that's going to play heck with your ability to meet your baselines.

Of course, there's a way to turn all this into a positive. Just start working with the technical review teams early on. Unless it is patently absurd in the situation, adopt the ideas they're already sold on. And co-opt them: have them help you design a solution that meets their standards.

You don't have to do that. Going it alone just means your reviews will become obstacles. If you thought your deadlines were impossible before, wait until you keep getting sent back to redesign your approach. Do yourself a favor: do it the easy way!.

## CHANGE CONTROL ACTIVITIES

As much as we complain about the limited funds and time that the organization was able to allocate at the start of a project, the greater indignity comes from mid-course corrections to accommodate organizational priority adjustments. Sometimes, of course, the project causing the issues is yours.

We save the most angst for those times when, despite our best efforts to conserve those funds, Murphy hits hard. Considering that we had to limit our ambitions in the first place to a level below what is realistic to accommodate the "bigger picture" of other realities across all the program's investments, it seems only fair that the organization should now hand over resources to help our project when it starts to struggle just as we predicted it would.

Life, as we know, is not fair.

In most organizations, once it becomes obvious to everyone that your project has no hope of meeting its baselines, you have to fill out some sort of change request form saying something to the effect that you need more money because you've used up whatever you had. You're also requesting additional time because the original delivery date is only a few days away. By the time the decision is actually made, that date will probably already have come and gone.

That isn't really a request; it's more like a blackmail demand. "Give me more time and money, otherwise our whole investment goes for nothing". You may indeed get them, but it won't be seen as a feather in your cap.

If your work is on a contract rather than for internal purposes, the client might just call your bluff and decline to provide the extra time and resources. If you're on a fixed price contract, your organization may well end up not getting paid at all. I've seen that done, to the tune of billions of dollars, with the result that the company disappeared from the Fortune 100 and eventually went out of existence altogether. Not career-enhancing.

Give the decision authorities something to work with at a time when they can intervene effectively. After all, they want to see this thing succeed too. Let them know of the challenge far enough out that practical adjustments can be made. If you're not going to be able to meet the cost, schedule and scope, are there ways in which you can meet two out of three?

If you don't, you'll be left in a straitjacket of expectations that are even more unachievable than what you had to begin with.

## KEY TIPS FOR THE CONTROL PHASE

It is a bit ironic that the longest part of the project gets the shortest chapter. Mostly, that's because the best opportunities to affect the baselines are in the earlier phases of the project. Still, there are plenty of scenarios in which the unrealistic constraints can become even more unrealistic once the project moves from planning to reality.

We've already talked about the key principles to apply. Don't be one of the many self-victimizing PMs who spend much of their time muttering about people needing to get a grip on reality. Carrying all that negativity around just increases your stress levels, and it's a long time between now and the end of your career as a PM.

If you find yourself grumbling about impossible deadlines and unrealistic budgets, just remember:

1. It's not **your** project. It's **our** project. Sometimes our priorities trump your ego.

2. Baselines are commitments, but they're not graven tablets. The customer doesn't usually have an all-or-nothing mentality. Give them what they really need and they'll give you some slack in the rest.

3. Reviewers aren't out to get you. They want your project to succeed. Help them help you: coordinate with them early and often, and when things start going pear-shaped, give them options.

4. Transparency is the best medicine. A few minutes of confessing to potential issues on month three is a lot less painful than embarrassing the company with a massive failure to deliver on month twelve.

And, of course,

5. Life isn't always fair.

__[Return to the Table of Contents _]_

Chapter Eight: Closing Out

Congratulations! You delivered the product!

Now you are free from those annoying uninformed people placing ever-more ridiculous constraints on you. Until tomorrow.

As soon as you get assigned to your next project, it all starts over again. Your new project has to work within the program that sponsors it.

Yep, more constraints.

## THE BIG PICTURE

Hopefully this time you're coming into the picture early enough to influence the constraints. And of course now you can see the big picture. It will get more and more comprehensible each time you run through the project cycle.

## PAY IT FORWARD

Paying it forward means passing the opportunity you've been given on to others who follow. Once your project gets to the end, you can't do much about the actuals and the baselines. They are what they are, or at least they are whatever you put into the files.

If you're going to pay forward your learning on how to get your scope, budgets and schedule adjusted to relieve the largely self-imposed stress of impossible constraints, then provide the people who come after you with some decent records and some hints as to how things actually worked. Would it be too shameless to suggest that this book might be a handy resource for them? Maybe so. Maybe I shouldn't do that ... Well, heck, it is free (or close to it) after all.

Another of life's little ironies is that every project management text makes quite a fuss over the need to close projects out properly, but it seldom happens. My recollection of the PMP and PGMP examinations was similar: a lot of questions about project closeout reflected PMI's belief in the importance of this activity.

That being the case, why doesn't it happen more? Mostly because the project team gets reassigned to other projects as soon as possible. Many will leave before the final deployment activities. Even if you tried to have a retrospective (or lesson-learned session) it might be hard to find a quorum. And if the project hasn't gone well people are reluctant to come together just to confess for the record all the things that they screwed up.

Not only does this situation go against best practice, but it deprives the organization of effective data on how long it takes and how much it costs to get things done. It also prevents recording when and why things didn't turn out as they have been forecasted.

Consequently, when it's time to stand up a new project, the organizational process assets are unable to assist in forming a realistic view of what may be required. It might almost be better not have any at all than to have a bunch of half-baked stuff that, unfortunately, the PM of the future thinks is real.

You owe it to yourself and the PMs who will come after you to make this close-out step work somehow. It doesn't have to be elaborate; it does need to expose the issues and drivers your project had to contend with.

Here's a last opportunity to take advantage of the Simmer System. One of the key principles of that system is to leverage what people want in order to get closer to what you wanted. The project team doesn't want to do a post-mortem review in which they are the cadavers under inspection. But they'll be more than happy to gripe endlessly about how the project under-performed because the rest of the organization didn't do its part. So capture that information . Much of it is probably true.

As you and other PMs start doing this across the organization, all the finger-pointing simply results in a more rounded picture. It also helps to identify areas in which the organization does need to improve its processes. The actions taken in response to issues raised on just a few projects will end up making the whole organization better, faster and more cost-effective.

Don't be the cause of one last failure in the last step of this project. That may well turn right around to be the cause of the next project starting out in the wrong direction with impossible deadlines and unrealistic budgets.

I think we've heard that before somewhere ... let's do what we can so that we don't have to hear it any more.

###

__[Return to the Table of Contents _]_

About the Author

Douglas Brown is the author of multiple books in the Simmer System series, starting with Let it Simmer: Making Program, Portfolio, and Project Management Practices Stick in a Skeptical Organization.

He has a PhD from the American University and holds the PgMP, PMP and CSP certifications. He has over 20 years' experience as an internal senior manager and as a consultant with private industry and government organizations. His particular specialty is helping organizations get control of their situations quickly using the people, data and resources they already have, before making expensive long-term investments. You can learn more about the kinds of work he does at www.decisionintegration.com. He lives with his wife and dogs in Alexandria, Virginia.

Before you go: to thank you for getting this book (and getting this far in it!), turn the page for another free resource!

Get Even More Value

Since you're interested in this topic, please enjoy another free resource: Seven Ways Organizations Resist Change and How to Get Around Them.

Bringing in project management (or program management, enterprise architecture, process engineering, quality management ... ) is a change. Of course, it's a change for the better: more efficient, faster, better quality, and so on and so on. You know that. Not everyone believes you.

You and I won't change human nature. But we can be prepared for how others might interpret our well-meaning efforts, and we can tailor our approaches to the situation.

Send it to me!!

Click the link, or visit www.decisionintegration.com.

Connect with Douglas Brown

I really appreciate you reading my book! It's amazing how many people say "Yes, that's happened to me too, so many times". Hey, I don't make the world the way it is. I just try to make sense of it for myself, and fortunately that seems to help other people too. Maybe it's just that the people I know have experienced some reality too. If you'd like to join in on some of those circles, here are my social media coordinates:

Follow me on Twitter: <http://twitter.com/dbrownpm>

Favorite my Smashwords author page: <https://www.smashwords.com/profile/view/dmcbrown>

Subscribe to my blog at: <http://www.decisionintegration.com/resources>

Connect on LinkedIn: <http://www.linkedin.com/in/douglasbrownpm>

Visit the Simmer System community website: http://www.simmer-system.com

One Last Thing

If you enjoyed this book and/or found it useful, I'd be very grateful if you'd post a short review on the website where you typically buy books. Your review really does make a difference for future readers. With hundreds of e-books out there, some only 5-10 pages long, the ratings help PMs find the much smaller number of references that are actually useful. Hopefully you've found this to be one of them.

This book exists primarily in electronic form, so it's quite easy to update. To be honest, an adverse review can do a lot of damage, so I'd like to ask that if you aren't happy with the book and it's something I can fix, please contact me first (via my website, Linked-In, etc.) so I can fix it before your review goes in. But if you really can't stand it, then that's the way it is; at least say why so other readers know what the issue is.

I know some people get a bit nervous about writing something that others will see. A review only needs 2 or 3 sentences for people to find it useful. Many people find this sort of comment useful (answers to any one of them will do):

  * 2 things I learned:

  * The top insight I gained

  * Was the book fun to read, considering the topic?

  * Do people need a lot of prior experience or study to get value out of the book?

Thanks again for your support!

When you're done with your review, maybe you'll want to try:

  * Let it Simmer: Making Program, Portfolio, and Project Management Practices Stick in a Skeptical Organization, or

  * My forthcoming book, "Mind the Hot Spot: Using the Simmer System to Get Your Enterprise Risk Management Practice Off the Shelf" or

  * Visit my website (www.decisionintegration.com) to set up a training session, consulting session, or just take advantage of the free content I'm creating there

Acknowledgements

The formatting for this book comes courtesy of the extensive materials provided by Mark Coker on the Smashwords website (see <https://www.smashwords.com/profile/view/mc>).

The book itself got done in a matter of months thanks to numerous technical tips as to how to get the book done in the first place, came from the free support and training from Tom Carson-Knowles at EbookPublishingSchool.com

The push to provide something of value as a free resource for our professional community came from Nick Stephenson in his training video series. See: <http://www.yourfirst10kreaders.com/>.

While we're talking about Nick, you might enjoy his detective thriller series too! I do, anyway.

I'd like to thank a small army of people who read an advance copy of the book and provided comments that made the final product much better than the draft. While sometimes a short targeted point had tremendous value of its own, I'd like to express special thanks to the detailed word-by-word reviews provided by

  * Frank Greco, President of Greco Consulting

  * Bob Hutchinson, President of RAH Consulting, who provides subject matter expertise and consulting services covering all aspects of business development and operational management improvement to small businesses

  * Sheila Proudfoot, a career professional project and program manager, and

  * Brian Hobbs, a business development executive with BAE Systems

In the opening material, you can find links to contact most of these great reviewers.

All of them gave very generously of their time, even during personal and business travel, to provide edits and insights.

Aside from suggesting numerous valuable redirections in various parts of the book that had wandered off course, they caught any number of syntax errors and garbled thoughts. To the extent that you still find some, it's most likely that for reasons known only to me at that moment I decided to deviate from their very sound advice.

P.S: If you've enjoyed the experience enough that you got all the way back to this page, please do consider leaving a review wherever you bought it. Since the book is coming for nothing, or next to nothing depending where you bought it, many people assume that there's no reason to leave a review. With millions of books being published every year, the reviews are more critical than anything in helping potential readers decide whether a book is worth the time to download. So please take a minute or two and put even 2-3 lines up to help them in that choice.

Thanks for everything!

