Herding Cats

Averages Without Variances are Meaningless - Or Worse Misleading

The current Flap over the Public Debt and Growth paper originally produced by Reinhart, Carmen M, Vincent R Reinhart, and Kenneth S Rogoff. 2012. Public Debt Overhangs: Advanced-Economy Episodes since 1800. Journal of Economic Perspectives 26, no. 3: 69-86, brings out some core issues we face in the management and assessment of complex projects using performance data.

As well, there is a flap over the use of Excel for modeling econometric processes. Which was addressed more in the NPR segment. More on Excel and modeling later.

In the original paper - which has now been updated, there are several key words that trigger red flags in any credible statistical analysis of dynamic systems like the economy or complex programs. There is an assessment of the original paper. Let's start with the response to the original paper from the original authors addressed to the author of the critique.

This brings us to the core conceptual issue, which Herndon, Ash and Pollin argue greatly biases our results. They argue that we (they) use an “unconventional weighting of summary statistics.” In particular, for each bucket, we (they) take average growth rates for each country and then take an average of the result.

• Averages without variances are not very useful. We all know the story of measuring the most likely temperature in two locations Cody Wyoming and Trinidad-Tobago and the misrepresentation of Averages.
• Since economies and projects are driven by stochastic processes, we must model their data as random.
• Everyone claiming to forecast the future or make correlations between random processes must have on their shelf and have demonstrated to have read How to Lie with Statistics, Darrell Huff.

So ignoring for the moment the very naive statement by two Harvard professors of averaging the averages in the absence of the variances, and then making projections of the correlations, there are other problems.

• Using Excel for modeling can certainly be done, but there are much better ways to model statistical and probabilistic processes - R for one. MathLab is another.
• Excel also suffers from the in auditability problem. If you build a spreadsheet and send it to me to make management decisions, I have to look at every cell to determine the right formula, right range for that formula, and right data is in the right rows and columns for that formula to work. A pain in the ass for simple spreadsheets. A nightmare for larger ones. This is simply bad modeling. Especially since R is free and an academic version of MathLab or Mathematica is under $300. Come on Harvard professors, earn your reputation.

So What Does This Mean for Project Performance Analysis?

There are pictures in the links above to show that projects are statistical processes. So here's the bottom line:

• All numbers in projects and econometric models are random numbers.
• Correlations between the source of these numbers may also be random or at least changing over time - nonstationary stochastic processes.
• Models that don't consider this information are probably not that useful and may actually - and I'll be crass here - BOGUS.
• If we are ever to produce credible models of how projects work - cost, schedule, risk, and technical performance models - they must be credible statistical models. That means averages and averages of averages are simply not allowed without the variances and even higher order moments and the correlations between the generating functions of these random variables.

So however, this turns out with the Bad Math people at Harvard, we've got to do better.

• The current Earned Value Management processes don't consider the statistical nature of the performance indices. This is bad. Here's a simple and very understandable paper "Performing Statistical Analysis on Earned Value Data."
• As well, the calculations of future performance use cumulative numbers which wipe out the varainces, the current period which is a point sample to compute the Estimate At Completion. This is not only bad it is naive math.
• And then we are surprised when things don't turn out as expected.

Some final thoughts

• Correlation is not causation.
• All numbers are random numbers drawn from a known or possibly unknown population. If you don't know the population statistics your assessment of the numbers is different than if you do.
• All random numbers need variance, standard deviation, and higher order moments to be considered credible as sources of any analysis.
• Drawing a picture of the average of anything is very sporty without the proper statistical analysis.
• Read Huff, reread it, read it all the time. Also go buy a good statistics and analysis book. Start with Advanced Statistics Demystified.
• If there is an academic paper that is being used for public policy has not been peer reviewed, and then throw it away. The Reinhard and Rogoff paper is the basis of Paul Ryan's economic plan. He may have really good points, but it built on sand.
• Same advice from self-proclaimed experts in anything, especially project management. If there is a PhD thesis that has ZERO references in CITESEER, ignore it. 
• Read more in the linked references below to see how bad statistics can go even more bad.
• Download R, download the free books, learn how to think and act with credible statistics. Learn how many sample you need, learn how to assess the needed population statistics confidence levels, learn how to make decisions based on confidence levels not absolute numbers. We have a 70% confidence of completing on or before a date, or we have a 70% confidence or completing at or below of specific cost must be the answers when management asks about cost and schedule performance.

Related articles

Deterministic versus Stochastic Trends in Earned Value Management Data

Everything is a Random Variable

Memo to Reinhart and Rogoff: I think it's best to admit your errors and go on from there

Reinhart-Rogoff Response to Critique

A Point Measures Need A Variance

The Reinhart - Rogoff Study Controversy

Reinhart-Rogoff Data Problems

More Reinhart and Rogoff

Another Nonsense Statistical Survey

An Interlude

A new release of Sakharov's book that was banded in the Soviet Union, with the content smuggled out on postcards. This book details the search for the structure of matter and the forces that hold this matter together. 

For project managers, the process of discovery and theory are tightly intertwined in similar ways to physics. Our theories are relatively simple - some fundamental principles and some fundamental practices and the some several types of processes around those principles and practice.

The theory of project management hasn't really changed that much. What Sakharov speaks about is the abundance of particles and the failure of the theory to explain why. Turns out of course the explanation is the lack of understanding of the underlying processes that produce the particles.

Our notion of the multitude of ways to manage a project have lost the connection with the fundamental principles, practices, and processes. So no matter the details of the implementation of a method, a tool, a cleaver approach, the Principles, Practices, and Processes need to be in place of any hope of project success

Related articles

Project Success

The Myth and Misunderstanding of Waterfall

Crackpot Index

John Baez has a Crackpot Index he uses for scientific theories. Here are his points:

• 5 point starting credit. 
• 1 point for every statement that is widely agreed on to be false. 
• 2 points for every statement that is clearly vacuous. 
• 3 points for every statement that is logically inconsistent. 
• 5 points for each such statement that is adhered to despite careful correction. 
• 5 points for using a thought experiment that contradicts the results of a widely accepted real experiment. 
• 5 points for each word in all capital letters (except for those with defective keyboards). 
• 5 points for each mention of "Einstien", "Hawkins" or "Feynmann". 
• 10 points for each claim that quantum mechanics is fundamentally misguided (without good evidence). 
• 10 points for pointing out that you have gone to school, as if this were evidence of sanity. 
• 10 points for beginning the description of your theory by saying how long you have been working on it. (10 more for emphasizing that you worked on your own.) 
• 10 points for mailing your theory to someone you don't know personally and asking them not to tell anyone else about it, for fear that your ideas will be stolen. 
• 10 points for offering prize money to anyone who proves and/or finds any flaws in your theory.

Maybe we can construct a similar index for project management theories and processes.

• 3D WBS will build a schedule for you in 1/10 the time, yes 1/10, that is 10 times faster - probably not
• Self directed teams are best for solving complex problems - except when spending other people's money on a fixed schedule and budget, with a mimimal set of features.
• Football self organizes within the boundaries of the playing field, so should software development teams - really, no play books, no called plays, no positions, no team captain, no coach calling in plays from the side line? 
• Self organizing appears without a central authority - not true at any level, we'd have to suspend the laws of physics.

Related articles

Project Controls is the Basis of Project Management

How to be a Master Scheduler

Learning from mistakes is overrated

In a classic quote "...I have never really learned much of anything from success..... The lessons which stick with me are those which I learned through failure ... " It is clear that something needs to be done about this nonsensical approach to improving our lot in life as project managers.

If we have no notion of looking for what works, what has been shown to be useful, and what steps we can take to reduce the risk of failure, then we're simply not paying attention. The picture to the left is all too common these days, when it is popular to bitch and moan (it's called bully bluster) about how bad things are and how they are getting worse, instead of looking around for guidance for improvement.

There is a cultural fascination with failure being the source of great lessons to be learned. What did you learn? You learned what didn't work. Now you won’t make the same mistake twice, but you’re just as likely to make a different mistake next time. With that approach you could know what won’t work, but you not gaining any information about what will work. That’s not really the approach we need for increasing the probability of project success (PoPS).

How about we put our energy into studying how others have succeeded. What have others done right? What have others done that increased the probability of project success? What have others done to make it work? Has what they've done repeatable on our project?  

Success gives use a basis for decision making that is actually actionable. Looking at all the mistakes reveals all the mistakes, but doesn't really provide any guidance other than don't do that again. When something succeeds, we know what worked – and we can do it again.  And the next time, we'll probably do it even better.”

We all know the platitude of Everything is a learning experience. But it's just that a platitude.

But all learning is not equal. If your approach is to be the curmudgeon who points out all the failings in the past your going to spend your time with your head in the sand. Instead if you focus on the wins not the losses, the lessons you'll be learning well give you a better chance at continuing your success.

So what's a PM to do?

• Making the Impossible Possible - a case study of success
• Modelling Complex Projects - provides guidance for dealing with complexity
• Anti-Patterns in Project Management - while anti-patterns sound like "what went wrong," they are not. They a patterns to avoid and can be used to learn what to avoid, from the success of others.

This post was inspired by 37signals and Jason Fried and David Heinemeier Hansson contribution as those Bully Bluster voices that take great delight in standing on the side lines pointing out the mistakes of others, while standing on the side lines, like Teddy Roosevelt's Man in the Ring, they want their voices heard without wanting to actually contribute.

Probabilistic Cost and Schedule Processes

We hear all the time about how project managers can't make credible schedules or generate credible cost estimates for IT project or even other types of projects - mega project construction for example.

I'd have to say Flyvbjerg is a bit over the top calling estimaters fools and lairs, but he does have a point about the in-credibility of cost and schedule estimates.

We about how building such estimates is a waste of time and we should switch to doing everything in an agile manner and let the requirements emerge over time while spending the clients money to discover them.

This is an exaggeration I know and it literally doesn't work that way even for agile processes. But it brings out the point that developing credible estimates of cost and schedule is actually hard and requires careful consideration to the processes.

The first thing to recognize is there is no such thing as a credible estimate in the absence of the underlying statistical and resulting probabilistic processes being applied to that estimate. The notion that we can forecast the duration of a work activity or the cost of that activity without a probabilistic confidence to that forecast is näive at best and delusional at worse.

Maybe if Flyvbjerg had used the work "delusional" it would set better with me. Liar implies malicious intent. Fool implies no one else was looking after the work and a "fool" was left in charge of the estimiating process. 

What To Do About This?

Here's an example of the probability distribution of a cost estimate for a project.

This is from a model project that has a cost loaded IMS. The model will be only as good as the IMS is good and the resource loading is good. So this approach ONLY works when the model is right. That's a problem of course, but for now let's assume the model is right, since it came from a VERY credible source. David Hulett and I work the Risk and Opportiunity policy segment of the US DOD, along with others from government and industry.

The 50^th percentile cost is $2,296,898 (a small project in the A&D world BTW). That means there is a 50/50 chance the project will cost more than that or less than that. That number is the median - the middle of the range. If we want to know what the number is with an 80% confidence, than it is $2,333,153. That says there is an 80% confidence that the cost of the project will be $2.3M or less.

When we speak about schedule, we can use the same terminology. In this case there is an 80% confidence the project will complete on or before 11/06/2015. 

These graphs are generated from a Monte Carlo simulation tool applied to a resource loaded Integrated Master Schedule (IMS). If there is any doubt as to why you MUST create a resource loaded schedule, please please put those doubts away. These two graphs are the source for the Joint Confidence Level showing the over all probability distributions for both cost and schedule for the project.

This picture should convince anyone that the "joint" probability of completing on or before the target date (I didn't say what that was) and at or below that planned budget (didn't say what that was either) needs to be modeled in a way that would be considered credible. 

Outside of a small domain of aerospace and defense this is rarely if ever done. Most IT projects have some made up budget and schedule. Their strategy is based almost entirely on HOPE with no underlying assessment of the statistical and probabilistic drivers of the cost and schedule, let alone the technical aspects coupled with risk.

And we wonder why IT projects come in late and over budget.

Turns out of course large defense and space programs have the same problem - poor estimating, politically motivated estimating, naive estimating, etc. But they are required to produce data like this, so we know it is bogus sometimes early enough to fix it - sometimes not.

But the real root cause of most serious overages for A&D comes from other sources. Those can be found in the Nunn McCready breach reports at RAND in Volume 1 and Volume 2. IDA has there assessment as well. There are some professional provocateur voices that conjecture all this can be fixed with a good WBS, a scaled down Earned Value Management System, and "firing the program managers when they go over cost and schedule." That of course is probably not the real solution.  Read the RAND reports for the root causes of major overages. Read the Feb 18th issue of Aviation Week, "Slaughterhouse Five: If sequestration can rewrite U.S. strategy It's time to kill the sacred cows in industrial policy." F-35's current cracked first compress blade grounding and the world wide subcontracting effort that provides the program with nearly invincible support in congress.

We only wish it were as simple as many would have us believe. But sadly it is one of those wicked problems that we simply have to manage in the presence of. Many have suggested solution - credible ones, not the cocka mamy ones - but those solutions usually don't address the political forces in play when you are working with the public's money.

Why I've Followen in Love with R

In the programming language R, drawing the joint probability plot is done with a simple command

> pairs(X)

produces a scatter plot of the variables defined by the columns in X. Every column in X is plotted against everyother column of X and the resulting n(n-1) plots arranged in a matrix with constant plot scales over the rows and columns of the matrix.

Intelligence (or lack thereof) Gets In the Way of Conversation

One down side of high intelligence and low intelligence is to use this intelligence (or lack there of) to spin ever more ways of deceiving yourself. - Ray Pierrehumbert's Tyndall's lecture at the 2012 AGU Conference. 

Complex Problems Require Better Solutions

There is a class of responders on the forums that continue to seek simple and simple minded solutions to complex problems. Claiming the problems can be solved with simple solutions. Of course those solutions cannot be demonstrated with any credibility outside of a limited domain. Let's start with Mencken

For every complex problem there is an answer that is clear, simple, and wrong.  - H. L. Mencken

In the project domain most of the problems start with poor estimates of cost and schedule. Hollmann starts it off  http://lnkd.in/vjf4X4. Bent Flyvbjerg takes a more radical view, calling estimators liars , but I chalk that up to a language barrier.

The core problem starts with the politics of estimating. Rarely do the buyers of the project know what it should cost. So when they hear a number that is larger than their expectations, they reject the number. They signal to the sellers what they expect to pay for something. This expectation can come from poor knowledge or simply a naive understanding of the problem, or worse a public promise that simply can't be kept. 

But a second problem exists. That across domains, there is the wrong headed belief that one domain has the solution to another domains problems. We need to break the loop we're stuck thinking that problems are only found in other domains and making the ill-informed suggestions that "if you just did it my way," there would be no problem. There is a fundamental issues with managing complexity and managing in the presence of uncertainty. We want it to be simple, it is not, but since it is hard, people don't want to actually work hard on the solution. Instead seeking simple and may times "simple minded" solutions - buy this tool, use my excel spread sheet, dumb down the processes.

So What Is The Solution

First is to recognize that ALL domains have similar problems. Cost and Schedule estimates have been discussed for many decades. Lots of literature leads us back to the singular source - the political will to search for the credible estimate, even if that means not starting the project. Or better yet, to start the project knowing the estimates are flawed.

One provocateur voice in our community suggests that PMs that take on project with poor estimates should be held criminally liable for the results. This of course is laughable, but it demonstrates the complete understanding of the problem and the solution.

This approach reminds me of Pauli's quote when presented with a nonsensical submission from a student.

They were worse than wrong because they could not be proven wrong. Famously, he once said o: Das ist nicht nur nicht richtig, es ist nicht einmal falsch! "Not only is it not right, it's not even wrong!"

Thus is where we are now. Not much in the form of research and questioning, lots of pontificating about how the other guy is all messed up, and if you'd only do it my way, you'd have your solution. Reminds me of the current US political problems. Do it my way. Of course that doesn't work, because we have complex - wicked - problems, and there is no single way. Mencken was right, and he was right long before any of the current problems.

We may be doomed to repeat history with first recognizing the problem is us.

Standing on the side of the road and pointing out problems

There a number of people in the Project Management world that seem to take delight in standing on the side of the road pointing out all the failures of projects, processes, and the people managing them. I'm working a program for a federal agency to produce a set of Essential Views of program performance. These views will be leading indicators of performance measures, which will provide management with insight to take corrective actions. 

During the research side of this work I came across this ...

My first thought was how can we improve our forecasting processes. Then I thought of those voices essentially bitching that projects aren't meeting the expectations of the public, while at the same time never providing any actionable suggestions beyond their personal gripes. 

I concluded to start ignoring those type of statements and work instead on providing small and incremental steps toward Increasing the Probability of Program Success. The book Little Bets is one of our guides.

This brought me to the quote of Theodore Roosevelt, from his 1910 "Man in the Arena Speach," at the Sorborne, Paris, France.

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat. 

It's Not Chaos It's Football

There is a popular myth - mostly by those Agile Management 3.0 thought leaders who don't play or even know much about team sports involving balls, grass - about "emergent" behavior. The myth is that the "rules" of the game and the boundaries of the field are the governing guidance in the game of Football.

The Michigan coach in the picture to the left is looking at his playbook. The playbook defines what plays can be, or are going to be, used during the game.

The playbook has to follow the rules of the game. That's the role of the referees and field judges. If the play is not in the playbook, it is not going to be used during this game. There may be more plays available to the team than are in the playbook for today's game, but they're not going to be used.

So here's the lesson for Project Management.

Where is your Playbook? And If you have a Playbook, are those Plays going to increase your chances of winning?

Don't have a playbook?, then it's going to be an ugly day. Have a playbook but don't execute the plays properly?, it's going to be an ugly day. Execute the proper plays in the proper sequence, your chances of winning will improve. No guarantee's, just be improved.

The Playbook for a project is the Integrated Master Plan. The application of the plays, like American Football, depends on the emerging situation that resulted from the last play. Not the score on the score board. That's the Integrated Master Schedule.

Does this mean the Master Plan doesn't change during the game or during the project? Of course not, that would nonsense. But you better have a really good reason for changing the plan. In football and baseball, that's actually a strategy - to get the other team to change their plan. To go off the playbook and try doing something that they haven't practiced well enough to properly execute. To disrupt the flow of play.

How about changes in the Master Schedule during the game or during the project? Happens all the time. Here's a thought to put to work in ball games as well as projects.

Planning is not “plan and forget” but an ongoing dynamic activity that peers into the future for indications as to where a solution may emerge and treat the plan as a complex situation, adapting to an emerging solution.

If you have a Plan B, you should have given thought to the possible Plan B's, before you execute Plan B. Otherwise your Plan B may be just what your opponent wants you to do - decrease your probability of success.

This idea comes from a colleague Mike Dwyer, IT Program Manager, used with permission.

So why the notion that a football team - or a project - that self-organizes within the boundaries of the playing field and the rules as they are laid down by the football association? Without the understanding of the Playbook, with most times the plays being called in by the coach. Can't say. Maybe because those notions come from observers of football, not players of football.

The Naviety of Solutions to Wicked Problems

In this silly season of national elections, the notion of simple solutions to wicked problem is rampant. The same is true for wicked problems in the project and program management space. Government procurement is a wicked problem.

There are always voices out there ranting on about how bad everything is - and there some real examples of how bad things are - without actually providing any credible solutions.

If we first look at what it means to have a Wicked Problem we see, Rittle and Webber's definitions

• There is no definitive formulation of a wicked problem (defining wicked problems is itself a wicked problem) - this makes some sense, but is not too useful for searching for solutions
• Wicked problems have no stopping rule - this means the problem is continuous. Air pollution, green house gases, health care, federal procurement as examples of the "no stopping rule."
  
• Solutions to wicked problems are not true-or-false, but better or worse - even the better or worse may not have units of measure. Better or worse for who, over what time?
• There is no immediate and no ultimate test of a solution to a wicked problem - if we knew that it wouldn't be wicked would it?
• Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial and error, every attempt counts significantly - this doesn't have to literally be the case. For weapons systems acquisition for example, the problem can be "wicked" but still be repeatable if the complexity is high enough. We know what we want in a stealth fighter, but the actual acquisition of a stealth fighter is a "wicked" problem.
• Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan - this is the basis of Capabilities Based Planning. We need to know a small number of capabilities. When there are 100's or 1,000's of top level requirements, the problem becomes "wicked."
• Every wicked problem is essentially unique. Every wicked problem can be considered to be a symptom of another problem - a colleague at a local defense contractor said “The problem is…that’s not the problem.”
• The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution - explaining the problem, becomes a "wicked" problem.
• The planner has no right to be wrong (planners are liable for the consequences of the actions they generate) - this is common in all "wicked problems" for cost, schedule and technical performance estimates.

Your Speech is Toxic

I usually don't repost other peoples work. I love to read other peoples work. I get great ideas from other peoples work. I reuse many of these ideas in my work. But it just seems redundant to repost what someone has already posted.

But this presentation deserves the widest distribution it can get for many reasons. It's timely in light of our "political conversation." It's timely in light of the problems we face as project managers. It's a wonderful example of using visual messaging to convey important information.

Your Speech is Toxic from Chiara Ojeda

 

Competency Model For Project Managers

There are lots of competency models for project managers. Most Federal Agencies have one (FAC-P/PM), most project based firms do as well. There are even competency based certifications. Those commercial certification organizations that charge you money to test your competency are a bit suspect of course, but even they have a framework for competency.

Here's a set of competency assessments for Department of Energy Decontamination and Decommissioning projects, that were developed from the experiences of the project managers accountable for the success of the program. A peer based set of competencies.

Performance Measurement – the ability to collect and analyze project information to determine where the project stands and to predict future status and progress.

Competent project managers apply performance measurement to:

• Actively monitor project status using tangible measures of physical percent complete
• Insist on constructive analysis of variance, with corrective action plans for everything.
• Use the plan to manage the project, with defined measures of increasing maturity of all deliverables.
• Hold regular status review meetings, where progress to plan is presented, corrective actions to get back on plan, forecasting of future performance, and risk retirement are presented.
• Encourage an attitude of no surprises using analyitical measures of probability of project success.
• Measure (and report) performance against the plan with forecast for next period.

Submit status reports on time. Communicating is the exchange of information. The sender must make the information clear and unambiguous. The receiver must make sure the information is complete and understood. Communicating has many dimensions: written and oral; listening and speaking; internal and external; formal and informal; vertical and horizontal.

Competent project managers apply status reporting to:

• Send clear messages with actionable outcomes.
• Choose the form and timing of the message for their audience.
• Create professional communications traceable to the mission and vision of the project.
• Use language carefully to assure no confusion occurs around what actions need to be taken for the current situation.
• Confirm the accuracy of information sent and received with tracability to the source documents.
• Explain things well, so all receivers have the same understanding, no matter their level of technical or operational understanding.
• Listen carefully to others with all points of view, record this information for later assessment.

Organizational Effectiveness – is the ability to get things done. It requires an understanding of the formal and informal structures of all the organizations involved.

Competent project managers apply organizational processes to:

• Knowing who to go to for help.
• Wining approval of requests for support.
• Show respect for individuals regardless of position.
• Maintain a network of contacts from whom to get assistance.
• Knowing which resources are scarcest and manage them most carefully.

Team Building – a team is a group of individuals who hold each other accountable for a shared outcome (no one succeeds unless we all do). Team building means encouraging and enabling people to work together as a team to accomplish the project.

Competent project managers apply team building processe to:

• Define the team to include all the stakeholders.
• Share management responsibilities with the team.
• Talk about process as well as results.
• Work hard to achieve consensus on all major decisions.
• Insist on the best the team can do.
• Call attention to team achievements.
• Develop good team players.
• Build teams that perceive themselves as teams.

Staff Development – the process of encouraging personal and professional growth among the members of the project team. It includes training your replacement as well as encouraging growth in an individual’s chosen functional area.

Competent project managers apply staff development to:

• Insist on the best that each individual can do.
• Demonstrate knowledge of team member’s personal and professional goals.
• Value the individual’s growth and achievements.
• Give credit promptly and sincerely.
• Provide constructive criticism promptly and in private.
• Provide timely and useful performance reviews.
• Delegate appropriately for the person and the situation.

Perspective – the ability to elevate ones view; to take a broader organizational view rather than a narrower project or personal view; to discern how the project relates to a hierarchy of larger undertakings; to sense and assess potential interactions with outside conditions and events; to connect seemingly unrelated events or conditions to the project.

Competent project managers see their job through the proper perspective to:

• Demonstrate awareness of the organization’s vision and mission.
• Demonstrate awareness of competitor’s strengths and weaknesses.
• Encourage the team to consider big picture issues.
• Avoid getting immersed in unnecessary detail.
• Actively seek to acquire new knowledge.
• Read widely.

Negotiating – working with others in order to reach an agreement. A successful negotiation is one where all parties are satisfied with the agreement.

Competent project managers have the proper negotiating skills to:

• Advocate for interests rather than positions.
• Seek agreements that satisfy the interests of both parties.
• Work to keep personalities out of the negotiations.
• Open to innovative and creative solutions.
• Use objective criteria to evaluate proposed agreements.
• Negotiate agreements that can be kept.
• Negotiate agreements that preserve the working relationship.

Risk Management – is the ability to identify, analyze, and respond to risks over the course of the project. It includes both minimizing the consequences of adverse events and maximizing the results of positive events.

Competent project managers apply risk management to:

• Consider both the impact and likelihood of risk.
• Use contingency and management reserves appropriately.
• Distinguish between risks (always in the future) and issues (in the present).
• Take prudent risks and exploit unexpected opportunities.
• View past problems as current risks and plan for them.

Problem Solving – is a combination of problem identification (what is the problem), solution assessment (what can be done), and problem response (implementing a solution). Project problems may be technical, managerial, or interpersonal. Problem solving may lead to decision making when a problem has many possible solutions.

Competent project managers have skills and experience in problem solving to:

• Use a structured approach for all significant problems.
• Look for root causes, not just symptoms.
• Seek (and listen to) both facts and opinions.
• Encourage innovative and creative solutions.
• Involve the team in problem solving.
• Ask perceptive questions.
• Follow up to ensure that the problem remains solved.

Decision Making – the ability to make the best choice from among many alternatives. Decisions can be "gotten" (from the customer, from the team, from other managers) as well as made. Decision making has a time element to it – the best alternative may not be the right decision if it is made too early or too late.

Competent project managers possess decision making skills to:

• Use a structured approach for all significant decisions.
• Seek (and listen to) both facts and opinions.
• Make decisions when needed.
• Document important decisions.
• Delegate or escalate decisions when appropriate.
• Follow up to ensure decision was implemented.

Books PMs Should Read and Put To Use

There are several shelves of books about many topics in our house. Project Management and related topics are in the Office. The list of books below have specific attributes. They have not only been read, they have been marked up, reread, and used in practice. I have many books that are read, but not marked up. Other books that have been read, marked up, but not put into practice. And a hand full of books that have all three attributes plus one more. The contents of the book has changes how I do my job.

There are other books that I've read, marked up, and concluded the content was either not applicable to the problems I work on, or in a few cases complete nonsense. By this I mean the content is not only not appropriate to the problems I work, but if applied will result in disappointment.

So here's my must have list. This list is not populist in nature. By populist I mean a book or paper in which you CANNOT calculate some outcome. A populist book is something to read if you are just coming to the topic and want to discover the lay of the land.The books listed here are nit populist books

This list is in no particular order, other than they were taken off the shelf in this order. One other attribute is if I know or met the author.

General Project Management

These books are about the general concepts of managing projects, including agile projects. They are from authors who are or have recently benn project and program managers. This is important for the simple reason that who wants to read about something from someone that actually doesn't practice what is in the book. By the way, project management techniques that do not address agile approaches are not that useful anymore. As well, authors with 1996 style credentials have likely been passed by the current approaches as well.

• Making the Impossible Possible: Leading Extraordinary Performance, Kim Cameron and Marc Lavine - this is a case study about the management processes at Rocky Flats. Here's a quick summary of the concept of Positive Deviance and Heliotropic Abundance.
• Strategic Performance Management: Leveraging and Measuring your Intangible Value Drivers - Bernard Marr speaks to managing the business value from projects. There is lots of discussion around this, with lots of soft terms. This is a book that turns that populist view into a balance sheet view.
• The Handbook of Program Management, James T. Brown - I have met Dr. Brown. He is a former Program Manager at NASA. This is a book about program management. Program Management is about managing collections of projects. It is a hands on instructional advice type of book.
• The Radical Elements of Radical Success, Dan Ward - this is a book from a person practicing Program Management. Dan is an Air Force procurement officer, just back from theater. It's one of those books that causes me to think. Dan and I have had long discussions about the issues in government procurement. Here's a pre-defined search for Dan's work
• Project Management the Agile Way, John C, Goodpasture - I know John professionally, but have never been face to face. John and I share many common principles. This book is published by Management Concepts, which I do work for. MC publishes books, provides courses, and services for the Federal Government. John's book shows you how to deploy agile processes in the presence of the governance based environment. One where you are spending other peoples money and are accountable for success to external parties, like the Federal Government, a Board of Directors, and share holders.
• Flawless Execution, James D. Murphy - I cam across the After Burners at a PMI conference. The speakers are all ex-fighter pilots. There approach is logical, concise, and clear. The perfect paradigm for managing projects. This approach is not for everyone. It holds all members accountable for their actions, builds teams in ways not found in any other approach and is not one of those touchy feely styles.
• Catastrophe Disentanglement: Getting Software Projects Back on Track, E. M. Bennatan - there are many books about recovering projects. I'm reading another and writing a review. But this book is a check list book, with a step-by-step process of recovering projects.
• Beyond the Hype, Robert G. Eccles and Nitin Nohria - this is one of those must read for anyone interested in processes. Many if not most of the new ideas are actually old ideas in new cloths. Or worse, poor copies of old ideas promoted by self aggrandizing authors who know how to market. This book speaks to the problem of not knowing the past, so you
• Reinventing Project Management, Aaron J. Shenhar and Dav Dvir - this is a good starting point for PM in the IT environment. With field proven approaches, the books provides the step-by-step activities needed to manage projects in the Enterprise business domains.
• The 7 Habits of Highly Effective People, Stephen R. Covey - this is one of my populist books that has direct applicability to project management. Our method - Performance Based Management - contains most of the content of Covey's book is for Project Manager, including the Performance Based Management process we use on our programs.
• The Seven Secrets if How to Think Like A Rocket Scientist -Jim Longuski describes the processes needed to manage complex projects. It's a check list of items rarely thought about in the normal project management paradigm. This is done, because the domain Jim works in has projects that blow up and kill people of not properly managed.
• A Bee in a Cathedral - Joel Levy's book is here because using analogies in the project management world is very common. And most often the analogies are bogus. read this to see how to use analogies properly, since they are powerful tools to get points across, reveal understanding.

Leadership

There are so many books on leadership in the project management space. I'm simply burned out listening to all the voices on leadership from folks who speak and write about the topic, but who have not actually lead people under circumstances that require real leadership. Here's the books that you need from those people who have.

• How NASA Builds Teams - Pellerin led the Hubble Space Telescope program and speaks to how that worked and didn't work.
• Augustine's Laws - Norman was the leader of Martin Marietta here in Denver. These Laws are general business processes but for high tech firms.
• 8 Basic Habits if Exceptionally Powerful Lieutenants - this book and the next come from the Air University Press,  many in downloadable PDF.
• Commanding an Air Force Squadron in the Twenty-First Century - this is another survey books about how leaders learn to lead.

Systems Engineering

In the aerospace and defense business Program Management is a Systems Engineering paradigm. This is because the technical architecture of the program has to be matched with the programmatic architecture. The product that is being designed must also be built and shipped. This means the value stream flow of work needs an architecture as well. This is the purpose of the Integrated Master Plan (IMP) and the Systems Engineering Management Plan (SEMP)

These books are the basis for being a good project manager. Here's a list of specific topics, meaning more technical, needed for project success.

• System Engineering: Coping with Complexity, Richard Stevens - this is another handbook for designing, developing, and deploying systems.
• The Art of Systems Architecting, Second Editon, Mark W. Maier and Eberhardt Rechtin - everything is a system. No those silly descriptions of those populist systems where you can't design or calculate anything. But system we encounter in the real world. The air traffic control system, the banking system, the internet, the enterprise IT systems, manned space flight, building the 787. Systems like that. Rechtin is the father of the approaches used to build real systems. Yes, people are in these systems. And people are an important part, but in these types of systems, the components of the system are the basis of success.

Risk Management

There are lots of risk management books, articles, websites, and Bloggers out there. Here are the two you should own and read.

•  Risk Happens!: Managing Risk and Avoiding Failure in Business Projects, Mike Clayton - I've corresponded with Mike for several years. This is a great book for starting the process of risk management. It follows the steps defined in many locations - the best is the SEI Continuous Risk Management (CRM) model. There are simialr guides from DOD and DOE. PMI has a Risk Management Practice Guide, but like most things PMI they have their own way of doing things and rearrange the work processes.

As an aside determining risk drivers is a critical success factor for any Risk Management process. Typically risk management means making lists of risks, ranking them, and doing some kind of handling. This is not only naive, but it is wrong. You must determine which risks drive which undesirable outcomes of your project. Start with A Framework for Categorizing Key Drivers of Risk and Taxonomy-Based Risk Identification. I worked with one of the authors.

• Effective Risk Management: Some Keys to Success, Edmund Conrow - I've worked with Ed on a proposal and he turned me on to several concepts that I use daily. The first is the serious error in the PMBOK about multiplying the probability of occurrence with the ranked outcome to produce a risk score. This is not mathematically possible, since both are probability distirbution functions. The Method of Moments can help if you don't have a Monte Carlo Simulator. But if you don't buy Ed's book and read how to do Risk Management the right way.
• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hillson - I have met David, and spoken with him over the web. This is good book for addressing the opportunity concept. You should read Conrow's advice for mixing opportunity and risk before doing so yourself.   

Earned Value Management

There aren't really a lot of books about Earned Value Management. But there is a ton of misinformation about how EV is used, no used, applied, and misapplied. So these books and sources should be the starting point

• Performance Based Earned Value - Paul's book came out a few years ago, and the ideas have been with me ever since. The notion that Technical Performance Measures are part of Earned Value was present in the C/SCSC days, but was lost in 748-B and needs to come back. See Paul web site of the same name for good background.
• Earned Value Management Intent Guide - is the National Defense Industry Association's offical document for US Government Earned Value Management. This guide tells you how to comply with the 32 Guidelines of Earned Value Management. For most projects outside the government this is not applicable. But you should read this anyway, just to have an understanding of what the largest implementations look like.
• Earned Value Management Maturity Maturity Model - Ray's book provides a framework for assessing the processes needed to improve the maturity of your Earned Value Management implementation
• Earned Value Management site at the Office of Secretary of Defense, Performance Assessments and Root Cause Analysis.
• Earned Value Management at the NASA site has lots of background as well.

There are other sources of Earned Value, even in the agile world. But care is needed. To properly use Earned Value you must be able to do several things:

1. Maintain a baseline of the capabilties at least - the end outcomes of the project should not be changing
2. Know the total budget - the end budget and some notion of how this is spread over time.
3. Have some measure of physical percent complete and know how much physical percent complete you should be at when you measure it.

If you can't do these, you shoulded be considering Earned Value for your project

Statistics and Math

Project managers need to know somethings about probability and statistics. All the numbers in project management, cost, durations, head count, technical performance are random numbers. In the absence of knowing how to use statistics and probability, you're going to be late and over budget before you start.

• How to Lie With Statistics - every PM must have this book, must have read it, and must put it to use. When you have a conversation with anyone on the project, have this conversation in the context of this book.
• Then get Advanced Statistics Demystified or Statistics for Dummies and learn about sampling, variances, inferences, and other models of how your project is going to be working even if you don't know that is working that way.

 

Good Project Management Advice

Jesse Fewell has a nice post of how to deliver less and be more successful. What's interesting is this straight forward agile approach is also the straight forward IMP/IMS approach.

Jesse has three major steps to success

1. Define Business Success

In the IMP/IMS world this means having a defined set of capabilities connected with mission success. What capabilities do we need to accomplish the mission? This could be flying to the moon, driving around in the desert with equipment on board, sailing the ocean blue protecting the fleet.

But the mission statement must be based on capabilities. These capabilities must be defined in Measures of Effectiveness. These capabilities described through:

• Operational concepts
  • Partition the system capabilities into classes of service within operational  scenarios.
  • Connect these capabilities to system requirements using some visual modeling notation. A block diagram to a sysML model.
  • Define Measures of Effectiveness (MoE) and Measures of Performance (MoP).
  • Define the delivery schedule for each measure of performance and effectiveness.
• Use Cases or Scenarios
  • Define scenarios for each system capability.
  • Connect these scenarios to a Value Stream Map of the increasing maturity of the program.
  • Assess value flow through the map for each needed capability.
  • Identify capability mismatches and make corrections to improve overall value flow.
• Assessment of needs, cost, and risks of each capability simulatenously
  • Assign costs to each system element using a value flow model.
  • Assure risk, probabilistic cost and benefit performance attributes are defined.
  • Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance.
• Define explicit, balanced, and feasible alternatives
  • Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts.
  • Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs.

2. Define the Business Constraints

Build the Plan for the project using an Integrated Master Plan (IMP). The IMP describes the Significant Accomplishments (SA) and the Accomplishment Criteria (AC) for the Packages of Work needed to provide those Significant Accomplishments.

With the SAs and ACs arranged in the proper order to produce increasing maturity of the deliverables, the constraints can be defined:

• Is there enough time and money?
• Are the impediments to progress defined and handled?
• Can you measure progress to plan in units meaningful to the decision makers?

3. Deliver the Mimimum Necessary to meet the Business within the Constraints

This is where the IMP comes in again.

The topology of the Integrated Master Plan and the Integrated Master Schedule is focused on defining the incremental and iterative development of the increasing maturity of the projects capabilities that meet the mission need. This paradigm is applicable to all project domains, technologies, and product and project management methodologies. It is universal.

There are some key outcomes of this approach - the IMP/IMS approach - that can address the concerns raised by Jesse

1. All requirements must be traceable to a system capability. Why do we need this requirement? What capability does it support? How does it increase the Effectiveness of the system and how would we measure this Effectiveness in tangible units.
2. Over-engineering may be a problem, but the root cause - resulting from the 5 Whys of why is this over-engineered - must be answered first. If we know the Measures of Effectiveness and the Measures of Performance, the Technical Performance Measures, and the Key Performance Parameters, then over engineering is replaced with right engineering.

These issues can be addressed by developing the proper measures, starting with the Mission Need.

For each of the Technical Performance Measures, actual units meaningful to the decision makers can be developed and tracked during the project's life cycle.

No matter the method - agile or traditional - some form of these processes is needed to answer Jesse's need - produce more by doing less. Actually produce more by doing the right amount.

The Critical Missing Element of Most Project Managment Methods

Most projects we come to for recovery or triage, we find there is a missing piece of the puzzle.

No one knows what actual Capabilities are needed from the system when it is complete, or even what incremental capabilities are needed along the way to the end.

A capability is defined and managed ...

Planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates choice.

By Identifying system capabilities, the elicited technical and operational requirements can be traced from the Measures of Effectiveness to each deliverable in the Integrated Master Plan and Schedule. Capabilities state the “why” of the system.

Without a clear and concise description of the needed capabilities, requirement - technical and operational - have no home. The system them becomes a solution to a laundry list of "stories," "needs," "requirements."

Agile is starting to address this notion through Epics, but the formal development of Capabilities is not found in traditional project management methods.

This approach is the foundation for the business value proposition.

This by the way is where some in the IT business get confused about the "value" of Earned Value. Scott Amber for example, makes this mistake when he claims Earned Value does not represent business value. He is correct, but for the wrong reason. The term "earned value" in the ANSI-748-B paradigm was established long before the notions of modern agile "business value" were and therefore has a different definition. Both are needed, but 748-B earned value speaks to the amount of the budget that was "earned" at the time of assessment, versus the planned amount of budget for that same time.

Using the assessment of the capabilities is how you know that you are actually delivering Business Value. With the defined Capabilities, each Requirement now has a home, you know the reason for the requirement - the why are we doing this question.

Here's the Offical definition of Capabilties Based Planning from the ToGAF 9.1 source

Capability-based planning focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. Capability-based planning accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities. Often the need for these capabilities are discovered and refined using business scenarios (see Part III, 26. Business Scenarios and Business Goals).

From an IT perspective, capability-based planning is particularly relevant. For example, setting up a data center is really about consolidating corporate data and providing the related services. Lead enterprise architects for this capability will find themselves involved in managing construction, personnel training, and other change management tasks as well as IT architecture tasks. In the past, many IT projects were less than successful even though the actual IT implementation was brilliant, but the associated other tasks (business process re-engineering, client training, support training, infrastructure, and so on) were not controlled by the enterprise architects and planners and often were not satisfactorily completed.

On the other hand, IT projects were often described in terms of technical deliverables not as business outcomes, making it difficult for business to appreciate what was being delivered and often the IT architects lost sight of the ultimate business goal. Capability-based planning frames all phases of the architecture development in the context of business outcomes, clearly linking the IT vision, architectures (ABBs and SBBs), and the Implementation and Migration Plans with the corporate strategic, business, and line of business plans.

In many governments, horizontal interoperability and shared services are emerging as cornerstones of their e-Government implementations and capability-based management is also prominent although under many guises. In the private sector, the concepts of supply chain management and Service Oriented Architecture (SOA) are increasingly forcing planners/managers to govern horizontally as well as vertically.

It is the needed Capabilities that fulfill the Mission and Vision of their value proposition.

Practice without Principles Does Not Scale

The Checklist Manifesto suggests all success comes from practice based on principles. Here's the current discussion of both the principles and practices needed for project success.

Performance based planning in a nut shell (V5)

View more presentations from Glen Alleman

There are some key points here.

• Defining outcomes in units of measure meaningful to the decision makers is critical. Without the Measures of Effectiveness for the customer, only technical measures are used - Measures of Performance. This is a common problem for IT projects, where the "techies" speak to the customer in their units of measure.
• Defining what done looks like in incremental measures - iterations, rolling wave, releases, drops, or some physical percent complete along the way - is the ONLY way to measure progress. Measuring effort is not, measuring consumption of resources is not. Define what is coming next then measure progress to that.
• The repeated mantra of Risk Management is How Adults Manage Projects (Tim Lister) cannot be over emphasized. All numbers are random numbers, determine the underlying statistical distributions and use that to make decisions.
• Incremental development and emergent requirements are fine. But you MUST have a vision of what done looks like in terms of needed capabilities. Agile calls this an Epic. Others have a Concept of Operations (ConOps) or Statement of Objectives (SOO). This is the anchor for the governance of the project. Any requirements that emerge that do not fit in with the ConOps or SOO need to be seriously questioned - why do you want this?
• On the personnel side, never get diverted by the search for Harmony over Execution. Larry Bosidy says in all You cannot have an execution culture without robust dialogue - one that brings reality to the surface through openness, candor, and informality. This means truth over harmony. This is the source of many failures in the project domain.

Empowered to do WHAT?

Derek Hunter's blog presents and idea of how to capture the team's decision making. Nice idea, but what struck me is the statement

If the team is not empowered, they are not an Agile team.

Empowered to do what? I don't hear the answer to that question very often.

Where is the discussion of Governance is spending other people's money.

From hands on experience with eXtreme Programing in an enterprise development environment, our success came from chartering the XP teams with the needed capabilities from their work. They agreed to the charter, they could n't change the needed capabilities - these were enterprise needs - but they could organize in any way they needed, work any process they wanted (as long as it did not violate the business rules), and pretty much do what they needed to do with the governance bounds.

So where is additional qualification of empowering the team within the governance framework?

If you're spending your own money, no one cares. But what if you're spending someone elses?

Managing in the presence of all things

Came across this Twitter from Dave Snowden

The notion of trying to manage risk, chaos, or anything with an underlying probabilistic driving process is futile. But attempts to reduce complexity or chaos. Or reduce risk, without understanding the underlying probabilistic driving processes is also futile.

Blanket statement about reducing complexity that don't state how this complexity will be reduced, or how the underlying probabilistic drivers will be altered is futile, or worse nonsense. The naive and populist notion that complexity simply emerges in the absence of the equations of motion for that complexity is the start is the problem of managing in the presence of complexity and managing in the presence of uncertainty.

So when you hear someone say the world is too complex, we need to reduce the complexity, ask what are the units of measure of the complexity, what are the driving functions for this complexity, what are the equations of motion exhibited by these driving functions, and how would these be changed to reduce the complexity.

Trust but Verify and Other Realistic Approaches

Lately there have been several voices that resonant with my World View. Ronald Regan's "trust but verify" is a phrase many times forgotten in our project management and process improvement world. I came across Carol Deckers through a twitter reference from Dan Galorath. Dan provides estimating tools used in our aerospace and defense world and other places like enterprise IT.

The notion of "trust but verify" is close to show me you can produce what you claim you can produce. In the management processes applied to our programs, we start with the Federal Acquisition Regulation, which is essentially based on "trust but verify."

• We have a Validated Earned Value Management System (EVMS). The validation is provided by the Defense Contract Management Agency (DCMA). This validation is the basis of the trust to the customer (the federal givernment) that the numbers provided to them (the customer) each month come from the people, processes, and tools that have been verified. But even with that there is a surveillance process that verifies this trust.
• When the defined capabilities of the product or service produced by the program are agreed on, the Contract Officer (CO) and the contractors management have a "trust but verify" arrangement, with periodic Technical Interchange Meetings (TIM) and periodic Integrated Program Management meetings to "verify" that the trust placed in the contractor to do what is planned to be done is there.

So we're back to the core issue

When an initiative is suggested we need to Trust there is a credible outcome. Otherwise, we'll be spending all our time worried that it won't work. But this trust has to be based on something real:

• It's been done before
• It has references in our domain and context
• The outcomes from the past performance are close to what we're looking for
• The person or firm has a track record of success in this are - this is call past performance

And we need to verify

• There are working examples of the process and its outcome
• Those working examples are close enough to what we want that we can "trust" it can be made to work here
• The numbers for the stated benefits can be verified in ways that give us confidence they are actually true.

This is the source of my constant suspicions around 2.0 and 3.0 effort from individuals with ancedotal experiences and a good publisher. This happens about once a year for the past decade or so. First was Project Management 2.0. The old project management processes were failing. Turns out the project failures for the most part come from failing to follow the old project management processes. I loved one of the suggestion of PM 2.0 that social media was the answer to better project management. Yea let's manage out projects with Twitter. This BTW is the antithesis of agile, where face-to-face is the starting point.

Then the hordes of new and innovative business and change management processes. SoI always start with Beyond the Hype approach to assessing the suggestion. I know some will say you're way to conservative here, You'll never make progress with that attitude. Well we manage other peoples money when managing our programs, so yep you're right.

Shouldn't Complexity Theory and Emergent Systems Start with the Mathematics?

The answer of course is a resounding yes. If we can calculate something we don't have to rely on hand waving, references to populist articles that do their own hand waving, or at least references to dead people who did the hand waving before.

The very notion that a stranger is going to spend good hard earned money to make changes to something that actually belongs to someone else - possible share holders - in the absence of some sort of verification that that hard earned money is going to get returned some time in the future - is well - out of their freck'in mind.

This approach to social systems is based on the belief there are enough people out there who don't have the accountability to the share holders, a contract officer, a government procurement officer, or someone themselves accountable to look after the money, is common. It's common because those getting really excited about changing the world aren't always the ones accountable to those pesky shareholders and contract officers.

That's not to say the world doesn't need changing, because it does. The world needs people who expect it to change from their own ideas. The world needs people who come up with completely new ways to make things happen. But the world is also a cruel task master when it comes to funding these ideas. Ideas that a cheap when they don't involve spending money.

Like getting together at Starbucks to scheme on how to do things better. Like let's fix our status meeting process. That doesn't take much money, just effort. Or let's restructure our organization and not focus on earnings per share instead focus on having harmony among the product development teams first so we can improve EPS sometime in the future. Ah, you'd better have the CFO, CEO and Chairman of the Board, and the Investor Relations VP at Starbucks before you jump off that cliff.

Without some notion of the credibility of the idea of how to change anything, it simply doesn't happen. This of course doesn't stop people from trying, never has, never will. But being cranky and disappointed should not come as a surprise - change is hard.

There is a critical difference between something being possible and something being possible. It may be possible to change to world but is it probable in the domain and context you work. If not probable, it's best to look for work somewhere else.