Project Management

Game Theory in Management

Modelling Business Decisions and their Consequences

About this Blog


Recent Posts

Agile Approach, Or Rubber Baseline?

Managing Resolutions Is Like Managing Float

Bridging The PM Communication Divide

“Are There No Workhouses?”

Is Your IT Project Using The Proper Coolant?

Agile Approach, Or Rubber Baseline?

I’m old enough to remember when risk management (no initial caps) first wormed made its way into mainstream PM guidance. One of its funniest manifestations was an assertion that, if a given project could assert that it was really, really not risky, then many of the conventional Cost/Schedule performance measurement systems should then be considered superfluous, and therefore not mandated for government work. Of course, non-risky work didn’t need all of that high falutin’ risk analysis performed, at least when it came to making the case for the imposed level of rigor of the Project Management Information Systems (PMISs) applied to the work. Essentially, the early forays of risk management (no initial caps) into the PM world worked to undermine its overall utility, a vehicle for sending those pesky Critical Path and Earned Value zealots packing.

Flash forward to the introduction of Agile/Scrum Project Management. I believe that one of the main reasons that Agile/Scrum received such quick and broad acceptance in the Information Technology (IT) PM world was due to the fact that it addressed a widespread problem in that arena, that conventional configuration management/ change control techniques were inadequate for software engineering scope. A typical Baseline Change Control Board, made up of senior project and customer managers, would meet only once per month. Then, if a Baseline Change Proposal/Request (BCP/BCR) wasn’t considered acceptable by every member of the BCCB, it would be back to the proverbial drawing board to address the concerns of the Board, and a re-submission, to be considered next month. Agile/Scrum represented a way around such an ossified process. The people who were in a position to approve relatively minor baseline changes – the kind that happen all the time in IT projects – could do so in near real-time, and the new scope could be pursued in a far timelier manner, all without inviting the stigma of having a rubber baseline.

What’s a “rubber baseline?” It’s the bugaboo of us traditional PMs, the equivalent of this line from Shakespeare’s Henry VI, Part I:

Is this the Talbot, so much feared abroad
That with his name the mothers still their babes?

To have a rubber baseline means that you can change cost, or schedule, or (by implication) scope informally, almost at will. Variances magically go away, and, with them, the integrity of your project’s cost/schedule measurement systems. To the generation of PMs who still think that quoting Shakespeare is hip, to unknowingly engage a rubber baseline is to self-identify as completely inept, and to do so knowingly is to “smile, and smile, and be a villain.” (Hamlet, Act I, sc. V).

Interestingly, even though Agile/Scrum was originally developed for Information Technology projects, many other sectors have adapted it, including manufacturing. Even so, this approach may not have delivered on its highly-touted potential. According to one source, 75% of IT executives believe that their projects are “doomed from the start.”[i] Naturally, one has to wonder what the proximate cause of this sense of inevitable doom could be – is it hardware? Lack of talented personnel? Sub-standard coffee delivery service? Or could it be … the Project Management approach?

Since both Agile/Scrum and the implementation of a rubber baseline have in common a weakening (or even elimination) of the Configuration Management/Baseline Change Control process, what could we say separates, or distinguishes them? Let’s use the Game Theorists’ favorite tool, the payoff grid:


PM is Virtuous

PM is Villainous

Appropriate Agile/Scrum

1A: It’s all good.

1B: No needed oversight, meaning real mischief.

Rubber Baseline

2A: PM is inept, if he’s “virtuous” but using a rubber baseline.

2B: Massive potential for massive chicanery.

Members of GTIM Nation will quickly observe that the only okay scenario here is 1A. All of the others represent trouble, either because the project is being run by someone who doesn’t have the awareness that he shouldn’t be using a rubber baseline and, therefore, is likely to crash the project based on sheer ineptitude, or because he’s a villain who has successfully circumvented the very cost/schedule performance measurement systems that would alert his superiors when the project is in trouble. Don’t misunderstand – I’m not arguing against the use of Agile/Scrum in all cases. The brutal truth of the matter is that traditional approaches to maintaining baseline integrity had become moribund for projects being executed in a fast-moving environment, like Information Technology, and some change had to come on this front in order to keep PM relevant in those business situations.

But to remove all of the guardrails of traditional Configuration Management/Change Control, in the name of granting the PM more latitude of action, simply invites a management environment where “you’ll never find a more wretched hive of scum and villainy.” (Yeah, that’s from Star Wars. Were you expecting more Shakespeare?)

[i] Retrieved from on January 12, 2022, 16:47 MST.

Posted on: January 12, 2022 08:32 PM | Permalink | Comments (1)

Managing Resolutions Is Like Managing Float

The canned strategies that Work Package or Control Account Managers (WPM/CAM) use when determining how to handle any float associated with their project activities in a Critical Path Methodology (CPM) network are highly analogous to how most people deal with their New Year’s resolutions, proving once again that PM techniques are far more closely associated with real life than their Asset Management counterparts.

Take, for example, the timing of when we begin to pursue our New Year’s resolutions. Many of my past resolutions dealt with diet or exercise regimens, so I’ll use those as comparison points to how WPGs/CAMs manage float. For those PMs who don’t deal with Critical Path Methodology schedule networks on a regular basis, “float” is the amount of time non-critical activities have in excess of their originally estimated durations before a late finish can be expected to cause the entire project to finish late. There are several ways of managing float in an activity, but many parameters go in to informing the best way of approaching it.

PMs who tend to want to begin their activities at the earliest possible opportunity (meaning all predecessor activities are complete, and the resources for the activity are available), should consider the following:

  • If the actual output of the task is a tangible object, and it gets finished early, will it need to be stored somewhere in-between the time it’s ready, and the time when that activity’s successor is ready to receive it?
  • If the answer to the previous question is “yes,” is there a facility or area where this thing can be stored, without cost or penalty? If your project is to add to the population of a zoo, and the acquisition of the tigers activity has some float, you might want to make sure that that procurement activity’s successor, finish the tiger enclosure, is 100% done prior to completing this activity. Putting them in with the great apes would be a really bad idea.
  • Those resources you are tapping – are they also needed in other activities happening at the same time? Few things get uglier in Project Portfolio reviews than the conflicts over resource availability, but one of those things occurs when the other CAMs realize that you are, in fact, in a position to wait a bit before laying claim to said resources.
  • Are there any references to your activity in the risk register (no initial caps)? Not that it matters, I just don’t want to give the risk managers any “I told you so” moments should your activity go long, with a “risk event” having been pinned to it.

Now, let’s contrast these strategies to how we manage our New Year’s resolutions.

  • Did you resolve to actually create an object? If you begin too soon, and finish before, say, Labor Day, your spouse may be led to believe that your objective was too easily attained. Best to wait for a while before beginning!
  • If the answer to the previous question is “yes,” what does that portend for expected follow-on projects? For example, if the object that you made was an archway trellis for your back yard, will the aforementioned spouse also expect a flower garden, or water fountain?  Best to wait until the growing season is over prior to even starting the arch!
  • Your resolutions no doubt require your time and energy. What of the other things that require your time and energy? Why are you spending time and energy at the gym when there are parties to host and attend? Caution with your resource utilization decisions can benefit overall resolution portfolio performance significantly (you can quote this line verbatim to sound like you are truly managing your resolutions).

In those instances where you may be falling behind in attaining your New Year’s resolutions, another PM-themed remedy is available. Whenever a WBS element at the reporting level has an out-of-threshold negative cost or schedule variance, the analyses provided in the Variance Analysis Reports almost never go straight to “poor performance.” Instead, the following are usually cited:

  • Poor original estimates in the baseline(s).
  • Subcontractor unavailability.
  • Material/Equipment/Parts rate changes.
  • Poor or sub-standard conditions (e.g., weather for construction projects).

Did you resolve to lose weight or exercise to get in better shape, but aren’t advancing as you had planned? Consider offering the following explanations:

  • “I didn’t realize that losing one pound per week was considered unnecessarily aggressive.”
  • “The gym I wanted to use isn’t open when I’m available to work out.”
  • “The whole COVID thing has made workout equipment, especially free weights, prohibitively expensive.”
  • “I was going out for a jog this morning, but the temperature is 25 degrees!”

Conversely, if these management approaches to handling your New Year’s resolutions strike you as being inferior to, say, calculating the Return on Investment (ROI) for them, you’re an Asset Manager, aren’t you?

Posted on: January 05, 2022 08:03 PM | Permalink | Comments (1)

Bridging The PM Communication Divide

Waaaaayyyyy before PMI® became a professional association in 1969[i], many large-scale, complex projects were being successfully completed on-time, on-budget, by managers who had an extremely advanced grasp of the field of PM, even if they didn’t articulate their understanding in terms we use today. I could be wrong about this – any day now the Construction Office chamber of the Great Pyramid could be discovered and accessed, with the schedulers still waiting for their early-version Critical Path Methodology software to complete a forward and backward pass on their 20,000-activity network. But my speculation is that these historic PMs would do things like assign a higher priority to time-critical tasks without invoking the term “crashing the schedule.” I’m also fairly certain that, prior to 1823 and Carl Friedrich Gauss’ publication of the monogram Theoria combinationis observationum erroribus minimis obnoxiae, PMs were quite aware of many of the things that could go wrong with their projects, they just didn’t document them with some statistical speculations of their odds of occurring in a “risk register” (no initial caps here, either).

Once PMI® did come into existence, and much of its approach to the management sciences took on a scholastic flavor, the lexicon not only became standardized, it became a bit more academic, a function of applying its wide range of theories across multiple industries. PMs working the American Interstate Highway system in 1958 may have had little in common with those working in the nascent National Aeronautics and Space Administration (NASA), but managers in both organizations would have instinctively known that some activities would have to be completed before others could actually start, and that comparing those activities’ percent complete to their cumulative spent cost and schedule could give them a pretty good idea of how much their work would cost at completion, and how long it would take. They would have understood the basics of schedule logic and cost/schedule performance indicators, even if they didn’t use those exact terms.

And therein lies a problem: many in PMI® today have come to the practice of Project Management on scholastic or theoretical terms, while many others have arrived with a boots-on-the-ground understanding of its precepts. This latter approach is how I swerved into PM. I was working for a Department of Defense contractor that was building a type of advanced communication system. The design and development of this system came with a myriad of research deliverables and design reviews that were described in a document known as the Contract Deliverables Requirements List, or CDRL. Trick was, these deliverables’ due dates weren’t firmly established. They were almost always described as being 90 or 180 days after some other deliverable was submitted, or 30 days prior to one of the design reviews. My title at the time was “Data Manager,” and it was my job to “coordinate” the development of all of these deliverable documents, oversee their progress, and transmit them to their far-flung recipients on-schedule. At the time personal computers were something of a novelty, but I had one in my office, running one of the earliest spreadsheet packages, Lotus 1-2-3. So, I went through the CDRL, one entry at a time, and in the cells I had labeled “Due Date,” would place the equation to add 90 (or whatever) days to that deliverable’s predecessor’s end date. Without having been taught what a finish-to-start link was, or the term “lag,” I ended up constructing a Critical Path network that would automatically re-calculate a myriad of Start and Finish Dates based on the values that were placed into the Today’s Date field, and whichever Review date was considered reliable.  It wasn’t until the Project Controls Analyst on this project saw what I was doing, and told me that I should look in to the Project Management profession that I had any idea that that’s what I had been doing all along.

So, back to the communications gap. Having spent a lot of time around construction and manufacturing PMs, as well as their Agile/Scrum counterparts, I realize they’re discussing the same ideas, just using a different lexicon. So, as a service to GTIM Nation members who may find themselves in a situation where they have to serve as a translator between the Practical and Scholastic-oriented PMs, I offer the following conversion table.




“He’s got a fish in one hand, and a $#!^ in the other.”

“That CAM is in a very poor position to realize his goals.”

“I don’t care if those guys sitting around are assigned to something else – get them to help over there.”

“We may have to pull resources from the non-critical activities, and assign them to this other task.”

“You never know, we could all be run out of here tomorrow.”

“The resource requirement profile for this project is highly uneven.”

“I had a feeling this might happen.”

“There’s an entry in the risk register for this event.”

“I’m pretty sure we can fix it on the flip side, without much fuss.”

“We need to prepare a zero-cost Baseline Change Proposal, and get it in front of the BCCB ASAP.”

“If you’ll stop talking, I’ll give you the right answer.”

“We should abandon the current technical approach, in favor of this alternative.”


This is far from an exhaustive list, but it will suffice for now.

Or, there’s more, but I’m done.



Posted on: December 27, 2021 08:02 PM | Permalink | Comments (0)

“Are There No Workhouses?”

I was reminded of the quote in this blog’s title from Dicken’s A Christmas Carol (that actual line of dialogue is from the ghost of Christmas Present – he’s throwing a paraphrase of one of Scrooge’s previous assertions back in his face) while attempting to get a handle on all of the business model pathologies that have been inflicted by our friends, the Asset Managers, by the acceptance of the axiom that the point of all management is to “maximize shareholder wealth,” with its accompanying metric, the Return on Investment (ROI). Of all of the ironies attached to the ability of this management worldview to misdirect, one of the most profound has to be that the tenets of Project Management actually provide the best remedy, the best hope for those advancements in the management sciences needed in an ever-advancing, technology-driven business world.

The idea that the prominent (if not only) litmus test for evaluating a given business strategy ought to be how it impacts the organization’s equity probably pre-dates Luca Pacioli’s seminal work in bookkeeping, published in the late 1400s[i]. I would go so far as to speculate that the double-entry bookkeeping method, already the basis for assessing profit and, therefore, tax revenue, became truly accelerated into management philosophy preeminence as the industrial revolution spread across the world, necessitating heavier and more complex interactions with the banking and finance sectors. Now, don’t misunderstand: I’m not saying that all, or even most of the theories, techniques and practices emanating from Asset Management arena are invalid, or harmful. What I am suggesting is that, when those theories, techniques, and practices are employed outside of the Asset Managers’ appropriate purview, they create business model pathologies that not only can detract from the organization’s ability to achieve its mission or goals, they can actually harm the organizations’ members, or even the management science realm writ large.

To support this bold assertion, let’s return to A Christmas Carol for Exhibit A. Two “portly” gentlemen are appealing to Scrooge for charity dollars, to help feed and clothe the poor. While not said explicitly, it’s safe to infer that Scrooge refuses them on the basis that (a) the poor have recourse to other, non-charity resources, ones that require no sacrifice on his part (hence the quote in the title), and (b) there’s absolutely nothing for him to gain by engaging in charity. To Scrooge, every shilling donated is a total loss – no return on investment, and a negative ROI. Of course, by the end of the story he has reversed this world-view, but only through the extraordinary intervention of the three spirits.

My next example comes from the publishing industry. It’s been said that Frank Herbert’s novel Dune was rejected by over twenty different publishers before Chilton Books picked it up, and they were better known for printing automobile repair books. While I’m sure that each of those twenty publishers had subject and thematic bases behind their manuscript evaluation process, I’m also pretty sure that the major criterion for accepting or rejecting a given work was its predicted ROI. But this only points to a major failure of the ”maximize shareholder wealth” paradigm, as well as the failure of ROI to return a reliable quantification: there are simply too many variables to recognize, much less accurately quantify.

Besides leading to poor managerial decisions, overuse of Asset Management approaches can introduce business model pathologies into the organization. I had a dear Uncle who had worked as a Vice President at a utility supply company. Most of the employees were paid a regular salary, but the sales staff was paid based on commission. Once, one of the other veeps became upset upon learning that one of the sale staff had received a larger paycheck than the veep. In his mind, his placement in the organization’s hierarchy above the sales person should have precluded this event. My Uncle pointed out that the sales person in question was only paid more because he had brought in more business for the company, which was good for the entire organization. But the thought that human resources ought to be renumerated based on their placement within the organizational structure rather than actual contribution had permeated the company. And when I say that this represents a business model pathology, consider the “remedies” to the perceived problem: either raise the ignorant veep’s salary (a mistake), or lower the performing sales person’s renumeration (a huge mistake).

In contrast, Project Management theory focuses on attaining a specific outcome, accomplishing set scope. To engage in a bit of hyperbole, if the Project Team accomplishes this goal on-time, on-budget, we PM-types really don’t care if they did so by working fewer hours, or if their renumeration was better than our own. Those are elements of Asset Management, with its infernally over-used Return on Investment calculation. In short, as long as we’re attaining scope on-time and on-budget, we’re actually happy that the personnel didn’t have to exhaust themselves in a workhouse-like environment.

So, I’ll pose this question: does pre-enlightened Scrooge present as a Project Manager, or as an Asset Manager?


[i] Wikipedia contributors. (2021, November 24). Luca Pacioli. In Wikipedia, The Free Encyclopedia. Retrieved 19:14, December 13, 2021, from


Posted on: December 14, 2021 09:57 PM | Permalink | Comments (0)

Is Your IT Project Using The Proper Coolant?

The Agile/Scrum Project Management strategies and techniques were developed to address the business model needs specific to information technology (IT) projects, specifically software engineering work. The major driver, of course, had to do with configuration management. Traditional PM techniques for processing baseline changes typically entailed the creation of a Baseline Change Control Board that would meet once per month, and review the baseline change requests’/proposals’ (BCR/BCP) scope variations, along with the accompanying modifications to cost and schedule. One of three outcomes would be produced: the BCR/BCP would be accepted and implemented, rejected, or sent back to its originators with instructions on how it should be modified in order to gain acceptance. If either of the latter two outcomes were to happen to a critically-needed change to the project, the resolution to the subject BCP/BCR could potentially drag on for months, a time interval fatal to all but the most drawn-out of IT projects.

To accommodate the far more fluid and fast-moving IT project configuration management process, three “roles” are defined, specifically:

  • Scrum Master,
  • Product Owner,
  • Development Team,

…with their specific functions and areas of authority spelled out in such a way as to allow for processing baseline changes quickly and efficiently, all while avoiding the outcome of a poor or non-existent configuration management process, the dreaded rubber baseline. There is, however, another aspect of IT Project Management that is also very different from its product or building-oriented cousin, and it has to do with the nature of the Work Breakdown Structure. To make this distinction, I want to propose a mental exercise that includes a water pump, the kind that’s installed on automobiles (well, the ones that burn fuel).

For those of us who haven’t had the experience of having to replace one of these things ourselves, the part is really very simple. It’s usually an impellor and a pully wheel on a shaft, with a housing and a pair of hose flanges in-between. They typically fail when the bearings that hold the shaft in-place wear down, and the pump assembly is no longer water-tight. When it’s working correctly, it pulls coolant from the heat exchanger (the radiator) and pushes it into the engine. From the engine, the coolant returns to the radiator, and the process continues as long as the engine is running. In fact, it’s a little amusing that the pump is still referred to as a “water pump.” These things haven’t been circulating just water for decades now. Indeed, some car manufacturers used to require a very specific coolant formulation (e.g., GM® and “Dexcool”) to avoid damaging the motor.

Meanwhile, Back In The IT Project Management World…

The focus of most IT projects is its eventual end-goal, a computer program. Veteran GTIM Nation members know of my basic Management Information System (MIS) architecture scheme:

  1. The data is collected based on some criteria or discipline,
  2. it is processed into information,
  3. and transmitted to its intended audience in a manner that they can readily understand and use.

The end-product of manufacturing a water pump is, of course, an in-spec water pump. But data is different. An in-spec water pump for, say, a 1998 Cadillac Deville will be an in-spec water pump for its lifetime. For IT projects, though, one of Hatfield’s Incontrovertible Rules of Management (I forget its number) is that all valid management information must have the following characteristics:

  • It must be accurate,
  • It must be timely, and
  • It must be relevant.

Old data can, and usually does, become irrelevant. Depending on the MIS application, this exceeding of the data’s shelf life can be measured in weeks, or days – or, sometimes, just hours. So, in addition to the configuration management challenges inherent in IT work, there’s also the issue that, even when the software’s function is performing exactly as intended, as time goes by the output is not only losing relevance, it may even be becoming misleading. It’s analogous to putting the wrong formula of coolant into your radiator. The water pump may be working perfectly, but what it’s pushing along is actually damaging to your business engine.

All of which brings us back to the WBS problem I referenced earlier. If the intended outcome of the IT project is delivering valid information to decision-makers, then we’re firmly in PM space. However, if the intended outcome is to simply pump coolant between engine components process the data into information, with the actual cooling of the engine validity of that information no longer part of the final scope, we have ventured into process management space, which is very different. Without some capability to ensure that the collected data is accurate, timely, and relevant, the best processors and programs in the world are going to fail to deliver pertinent information. It would be like putting green coolant into a radiator that’s only supposed to have orange.

And that would be bad.


Posted on: December 07, 2021 07:47 PM | Permalink | Comments (0)

"More than any time in history mankind faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly."

- Woody Allen