Game Theory in Management

Since my ProjectManagement.com colleagues are hard at work researching, analyzing, and writing about effectively working with and implanting project requirements, it naturally falls to me to do the exact opposite: make the case for abandoning requirements. But I am not doing so simply to indulge a contrarian impulse – there really are times when requirements need to be ignored if they stand in the way of attaining project goals, specifically in implementation projects that seek to advance a capability within the organization.

An anonymous commenter posed a question on last week’s blog, asking how to get the organization out of the habit of comparing budgets to actual costs as a way of performing cost performance analysis, when the organization didn’t even plan very well in the first place.  When I read the comment I was reminded of a certain program director who was in charge of over thirty (!) project leaders, each of whom was responsible for a small project, but had no cost or schedule reporting capability. None at all. The organization had no PM requirements and, even if they did, the PLs would not have respected, much less obeyed them. I was assigned to assist this program manager along with an associate from my organization, whom I’ll call Ed. Ed was on fire to write up a series of requirements, attain the necessary approvals, and set out in implement them. Fortunately, I outranked Ed.

At our first meeting with the program manager I brought examples of every type of cost and schedule performance report formats I could find, and asked the PM to select his favorite. He chose what we would end up calling a Bullseye Chart, essentially an XY graph that showed each project’s Cost Performance Index (on the X axis) and Schedule Performance Index (Y axis), with the size of the bubble indicating the size of the total budget. To make it easier to read this already highly-intuitive format, we placed text boxes in each of the four quadrants: positive cost and positive schedule (“Great!”), positive cost and negative schedule (“Get on the gas!”), negative cost and positive schedule (“Get on the brakes!”), and negative cost and schedule (“Trouble!”). As we left the meeting with the PM, I went to work on Ed. I pointed out that, when it came down to it, we only needed four pieces of data from each project to get that report into the PD’s hands:

·         Total budget,

·         Actual costs,

·         Budget by month,

·         Estimated percent complete as of the end of each month.

I further pointed out that the first two elements were already available, the third, if not available, could be guessed (level-load the total budget across the period of performance), leaving one measly data point needed on a recurring basis. Ed was having nothing of it.

“What about the requirements? What about ANSI 748 (the standard for Earned Value Management Systems)? We have to verify the basis of estimate! We have to capture their scope in a work package, and establish control accounts! Then we have to issue our own requirements that direct them to use the proper method for collecting their Earned Value! You can’t just collect the data and start reporting the cost performance!”

“Watch me.”

We informed the PD of the approach we wanted to take to get him his Bullseye Charts, and then communicated the same to all of his project leaders.  At the end of the month, we collected our percent complete data (or tried to, at least), generated our reports, and prepared for the project review meeting. What happened next was fascinating.

At the beginning of the meeting we projected the Bullseye Chart for the first set of projects onto the screen, with one added data set: a list of the projects that were not reporting. The program manager spoke to those first.

“Why is your project listed in that category?” the program manager demanded of the uncooperative project lead.

“The data requirement was difficult, and I was really busy at the end of the month.”

“They only asked you for one extremely easy-to-estimate figure, and you couldn’t accommodate that?”

“No, I guess I could. I’ll make sure I get it in next month.”

“See that you do. (Looking at the PL for the next project in the list) Why is your project on that list?”

The next uncooperative PL already saw the futility of claiming difficulty in compliance with the requirements and, like all of the others on the list, apologized and promised the data would be available for the next project review. Sure enough, at the next project review, not only were the Projects Not Reporting boxes empty, but the PLs were talking about their projects’ performance like seasoned PMs. It was a remarkable turn-around – the Program Director was getting his critical performance information, and the quality of that information, as well as the management itself, continued to improve throughout the life of the program. Even Ed was impressed.

And all we had to do was abandon the unnecessary requirements.

As I have stated (on multiple occasions) in this blog, the worst 20% of managers who are in possession of 80% of the information they need to obviate the best decision in any given circumstance will outperform the top 80^th percentile of managers who only have 20% of the information they need to illuminate the circumstances of the decisions before them. It follows, then, that any discussion on IT project requirements must include some sort of analysis that answers the question, which information?

I once worked with a VP who had a Ph.D. in statistics, and simply loved combing through page after page of the actual costs the projects were incurring, by line item, and comparing this data to the basis of estimate that made up that project’s cost baseline. Any deviation, of course, demanded an investigation. I tried to reason with him.

“David, consider the scenario where a $100K project baseline had $25K in labor costs, and $75K in heavy machinery. At the end of the project, the actual costs were $75K in labor costs, and only $20K in heavy machinery. By your analysis technique, a major problem has occurred, when, in reality, the project came in under budget.” But he refused to budge.

He wasn’t very successful.

I am, however, not without sympathy. As I discuss in my recently-released, must-have book, advocates of specific management information streams will push their products way, way past their epistemological limits, promising that, should the manager adapt their narrative, the path to perfectly informed management decisions will be there for the taking. This is not how management science theories are tested and validated – it’s how products are sold. And, when salesmanship and marketeering are allowed to trump legitimate management science research, organizational chaos ensues. Here’s a short list of a few of the pseudo-management science techniques that have wormed their way into Project Management Offices everywhere, and yet are, without question, invalid.

The Bottoms-Up Estimate at Completion (EAC). This is the PM technique of re-estimating the remaining work on a project, adding this figure to the cumulative actuals, and, shazaam!, you have a valid EAC. Except that you don’t.  According to AACEI, a “detailed” estimate, generated by a professional estimator using off-the-shelf estimating software, can only reliably provide an estimate accurate to within 15%, best case. As I have previously noted, using the formula EAC = Total Budget / Cost Performance Index gets you to within 10% on a consistent basis, and is far, far easier an analysis to perform. And yet, the “bottoms-up” aficionados have this insipid little technique firmly entrenched in many U.S. Government procedures, orders, and policies. It’s really just make-work for the organization’s estimators once the cost baselines have been approved.

Comparing Budgets to Actuals. As I pointed out in the previous story, this technique is not only invalid, but it returns misleading information. However, since our friends the accountants like to pretend that the general ledger must be THE source and residence of any and all management information that has to do with costs, this silly technique remains in all unenlightened managers’ tool kits. It’s so intuitive, though, isn’t it? Of course, the valid (and infinitely superior) way of relaying a cost variance is to compare the cumulative Earned Value (% complete * total budget) to cumulative actual costs, but the invalid version will never really go away. This information stream is just make-work for the accountants, when they’re not out nagging others about other irrelevancies.

Calculating the Cost Baseline’s 80% Confidence Interval. Of course, the risk management types as well as the statisticians just love performing this analysis, but it’s as useless as a sundial in Seattle. All of the assumptions about alternatives that go into either a Monte Carlo or a Decision-Tree analysis are nothing more than guesses by the project team. And quantifying and processing data based on guesses yields an information stream that is simply over-processed and over-thought guesses. I would normally wrap up this paragraph by saying that this technique is just make work for the risk analysts, but virtually everything these guys do is make-work, so why just pick on the 80% confidence interval?

If your customer accuses your project of failing due to one of these metrics, or, worse still, if performance against these techniques is called out in your requirements, then the good news is that your customer isn’t very advanced in valid PM techniques. But if your project team is doing this to themselves, then the bad news is … your team isn’t very advanced in PM techniques, and your odds of succeeding just dropped.

Do not ask me the exact percentage of how the odds of success have dropped. That piece of irrelevant information can be pulled out of thin air (strikethrough) generated by your risk analysts.

Every junior-high school English student knows what classical plot structure looks like: you introduce the characters and a problem confronting them, then the conflict increases leading to rising action, which continues until the protagonists, using their talents, skills, and energies, overcome the antagonists/source of the conflict at the climax, then falling action, followed by the conclusion. For whatever reasons this structure has shown itself to be highly successful in all forms of story-telling, from ancient Greek theater to modern blockbuster movies, when it is done correctly. However, structuring your plot incorrectly, or abandoning the classic structure altogether, is to court disaster.

Take Star Trek, Gene Roddenberry’s masterpiece of 1960s science fiction television drama. Roddenberry has been quoted often as having sold the original series (TOS) to prospective network buyers as “a Wagon Train to the stars.” For those of you too young to know, Wagon Train was another television drama set in the American West frontier. Westerns were very popular during the late 1960s, and I think Roddenberry’s use of this particular idiom to describe his idea for a science fiction drama was a way to convey that the writing for his series would follow the classic plot structure that the Westerns did, just in a different setting/time.

But before we go to that different time, the 23^rd Century, let’s jump back to the 5^th Century B.C.  In ancient Greek theater, where the classic plot structure was introduced to Western culture, even here a pernicious element entered the fray. The plot device of deux ex machina, literally “god from a machine,” made its appearance. This silly plot device entailed the introduction of the characters and central conflict, consistent with classic plot structure, as well as the rising action leading to the climax. However, with deux ex machina, instead of the protagonists overcoming the conflict’s source/antagonists with their efforts and talents, some Greek god would be craned onto the stage and, using their divine powers, set all of the issues aright. This dopey device was recognized at substandard, even in ancient times. This recognition didn’t stop its use, however.

Now let’s jump back to the 20^th century. TOS’s episodes were mostly written using classic plot structure, and were highly enjoyable, save when the writers swerved into overly preachy social commentary. Twenty-one years after TOS was cancelled, Roddenberry was back with Star Trek: The Next Generation (TNG). However, in the intervening years Roddenberry came to see himself less as a producer seeking to entertain audiences, and more as some kind of visionary with special insights in to how the future should unfold. Unlike TOS, TNG often abandoned classic plot structure in favor of deux ex machina, with the “god” Communication craned into the story to set all aright: all that conflict we’ve been experiencing for the first 49 minutes of the episode? It was all a big misunderstanding, don’t you know, rooted in some base human instinctive reflex. While the special effects in TNG were vastly superior to TOS, the writing was, in my opinion, vastly inferior, which is perhaps why TOS’s Enterprise is on display in the Smithsonian’s National Air and Space museum, along with the Wright Flyer and the Apollo 11 command module, while TNG’s Enterprise, well, isn’t

What’s all this got to do with requirements management, you ask? In reviewing some of the literature addressing issues central to requirements management, the theme of better communications is often invoked. Not to criticize, but my take is a bit different. Requirements management is to IT project management what scope and configuration control is to construction or hardware PM. In these arenas, there’s a natural but subtle source of conflict in establishing the scope baseline: the customer is rewarded for allowing a certain vagueness in the scope documents by having the latitude to “move the goalposts,” or surreptitiously add scope without increasing costs.  The contractor is rewarded for imprecision in the scope baseline by delivering a cheaper product that fulfills the most basic interpretation of the contract terms. With both parties thus motivated, the problem is NOT in the communications themselves, meaning that improving the communications will not necessarily help remediate the most common problems encountered in requirements management space.

In my opinion the most common issues in the requirements management arena are rooted in a reluctance to abandon those business devices that allow greater latitude in the managing of projects, even if those devices depend on a certain deviousness. That’s the enemy that must be overcome, using our talents and energy, and waiting for the communications god to get craned onstage to set everything right is a futile pursuit.

Last week I “ran out of space” just as I was getting ready to reveal how to get people to stop hating your PMO. As I stated, the answer comes from Game Theory. I go through the complete analysis in my must-have books Things Your PMO Is Doing Wrong and Game Theory in Management, but I’ll offer up the simplistic version(s) here.

As I pointed out last week, one of the major reasons people tend to dislike Project Management Offices is because they tend to be headed by managers who do not understand that it’s impossible to leverage organizational power to compel an advancement in a capability. Put another way, even if you are these people’s organizational superiors, you really can’t make them “do” project management. Yes, yes, I know you’ve been told you can by your superiors, and you have had individual successes previously doing just that, especially if you have been in the military. But it’s undeniably true, even though the attempts take a variety of forms.

One of the silliest such attempts involves the writing of a procedure that requires people to participate in creating baselines and providing status, and then getting the organization’s executives to sign/endorse such procedures, followed by plopping copies of the new procedures on the desks of those from whom you need participation to make your new systems work. Here’s an intellectual exercise: four weeks after the procedures hit everyone’s desks, drop by the offices unannounced, and look where the procedure is located. Ninety-nine times out of one hundred, it’s on a bookshelf, or buried beneath other documents (maybe even the quality and risk procedures, heh heh, heh). I provide more extensive analysis of tactics that don’t work in my first book, but, for now, suffice to say that you can’t compel the advancement of a capability.

Interestingly enough, the quality that’s needed for a successful implementation from the PMO team, and especially its leaders, is absolute gold, but perhaps even rarer. It’s humility.

Let’s momentarily examine the opposite quality, arrogance. Besides being highly off-putting in inter-personal relationships, arrogance also carries an opiate that prevents its carriers from being able to recognize when they have committed an error.  I have seen this time and again, where a newly-minted PMP® or CCE®, having studied hard and exerted great effort to get their certifications, automatically think they can not be wrong in asserting anything that ought to occur in project management space. I don’t mean to pick on the certification-granting organizations here – advanced degrees, being involved in large, high-profile successful projects, or even an absurdly inflated opinion of the self, all can lead to the same crippling frame of mind. And once that sets in, the PMO’s chances of success have all but evaporated. The project teams your PMO is supposedly providing a service to now perceive that you seek to be their masters, or, at the very least, highly irksome, know-it-all kibitzers, best left out of the decision-making process.

However, the humble PMO knows it exists to generate an information stream for the benefit of the decision-makers in the organization. This information stream doesn’t have to be expensive or difficult, but it does have to be accurate and timely. If the information stream thus provided is either of the former, and neither of the latter, that’s on YOU, Mr. or Mrs. PMO director, NOT on the macro organization around you.

Most writers will often begin their careers with a set of ideas they feel they need to get off of their chests. Successful writers will soon encounter a transition where, instead of expressing themselves for the cathartic value of doing so, they will seek to provide what their writers want to read. Similarly, virtually all PMOs begin life with an idea that they will be the mechanism by which the macro organization advances in its project management capability. The successful ones will quickly undergo a transformation, where they realize their contribution is maximized when they provide accurate, timely, and (most of all) relevant information streams to the organizations’ decision-makers, and do so as unobtrusively as possible. Once the organization’s decision-makers realize the benefit of having ready access to the information they need to make the best choices on a regular basis, they will also realize that they won’t be able to function at their new, higher level without the PMO’s input.

At that moment, your PMO will be loved.

In 1415, King Henry V of England was leading an army through France, attempting to reclaim the territory he believed was rightfully his, being the descendant of William of Normandy, later William the Conqueror. Henry was confronted by a much larger French army near the village of Agincourt and, on the 25^th of October, the two armies came to battle.

When an army, in this case the French, confronts a significantly smaller force, the usual path to victory is to simply envelope the smaller force, forcing them to fight in every direction with no path to retreat. However, this tactic was denied the French, since the battlefield was in a long narrow field bounded on either side by thick forest. But even this did not seem problematic to them – they could simply throw more cavalry and infantry against the English front lines and overwhelm them that way. Unfortunately, the evening before saw torrential rains on the recently-plowed field. It was a sodden, muddy mess.

The typical man-at-arms of the period wore around 80 pounds of armor, either plate or chain-mail, and mounted knights wore far more. As the French advanced the approximately 300 yards, they became exhausted from trying to move forward in the muck. As soon as they came within range of the English longbowmen, they had to endure hundreds of iron-tipped arrows which could easily punch through most of their armor. By the time the remnants arrived at the front of the English lines they were easy marks for Henry’s men-at-arms who, wielding axes and maces, easily dispatched the exhausted French. One account maintains that a 5-foot-high wall of wounded, dead, and struggling Frenchmen lay just in front of the English position. By the end of the day Henry had won an astonishing victory.

Okay, Michael, you say, what does all of this have to do with the reason I clicked on this article, after having seen the title? What does this have to do with the Chief Financial Officer having a corner office, while the PMO personnel are lucky to not have to share cubicles? Well, I’ll tell you.

Back when the precepts of modern project management theory and practice were being codified, the United States Department of Defense was getting a little tired of major programs’ overruns and delays. They created the Cost/Schedule Control System Criterion, or C/SCSC. These guidelines for setting up baselines and generating cost and schedule performance reports were somewhat stringent; but, most of all, they were required of all contractors who wanted to do significant business with the DoD. You don’t want to “do” C/SCSC? Okay, fine, we’ll just take our mega contracts to your competitors, case closed. Generally speaking, this is no longer the case, what with the advances of the so-called graded approach and all. But at this time, “doing” PM was a rock-hard, inescapable requirement for doing business, much like observing Generally Accepted Accounting Practices is now.

The august managers who head up many of the PMOs currently cut their teeth on project management information systems and techniques during this period. It never occurred to them that parts of the macro organization would either silent veto attempts to advance a project management capability, or even resist them outright, until they found themselves in charge of the PMO and saw that exact reality unfold. For many, the fallback position was to engage in eat-your-peas style hectoring, which worked about as well as you would think. Some would resort to near-begging, with little better results. Project managers who did not want to have to engage proper PM techniques no longer had to, and those who wanted things to be different became very unpopular. Like the French at Agincourt, a major condition of the conflict had changed, and changed utterly. The ensuing reverses in applied PM tools and techniques has led directly to the type of management science caste system we see now, where accountants are somehow held to be far more valuable than Earned Value or Critical Path analysts, even though (as I have complained extensively in this blog) the general ledger can’t provide near the amount or quality of management information needed for an organization’s decision-makers that they claim. No, the answer to all of this, interestingly enough, comes from game theory, and is…

Oops! Out of space again. I will address the most appropriate technical approach to advancing the PMO’s mission in my next blog, assuming no accountants equipped with longbows get to me first.