Some years back I had accepted a job to head up a major program office. It had a huge budget, but no cohesive or even usable cost/schedule performance management system in place, and previous attempts at installing one had failed spectacularly. The fellow I was replacing had a Ph.D. in a technical discipline, but didn’t know a fraction of what he thought he knew about Project Management. The person who hired me asked me to attend a meeting of the Program Controls Office team prior to anyone knowing I was about to succeed this Ph.D., and so I did, but made it a point to sit in the back of the rather large conference room and be as small as I could.
The Ph.D. arrived, and strode up to the white board to draw four red triangles across the top.
“These represent the major milestones this program is on the hook for this fiscal year” he began. “Each of them has several subordinate milestones that are part of its scope” he continued, as he drew a few smaller triangles in a row beneath the first triangles, but in a different color.
“We have to provide status on our progress against these milestones to the customer, but the level two milestones are themselves supported by multiple level three milestones” he said as he drew more triangles along the bottom of the white board, in still yet another color.
“Now, these milestones have some relationships we need to discuss” he continued, in what I perceived to be a somewhat condescending tone. “These level one milestones depend on the level two milestones being completed on-time” he said, as he drew lines between the top-tiered triangles and the mid-level ones. “And the level two depend on the level three” as he drew lines between the mid and lowest-tiered triangles. “In addition, some of these milestones depend on the availability of the same facilities or other specific resources,” which he indicated by drawing lateral lines among the lowest level triangles, but in a different color than the lines indicating the hierarchical scope relationship. “And finally, at each level there are going to be milestones that need to be completed prior to the start of others,” leading to more lines being drawn but, since he had run out of different colors, he re-used the color of the level one milestones (red).
Since I was in the back of the room, I had a good vantage point for evaluating the whiteboard from an overall perspective. It was an incoherent mess, but with the level one milestones being represented in red sitting atop smaller triangles and multiple, crisscrossing lines it kind of looked like an immense serving of spaghetti and meat balls.
“As difficult as it may appear, we have to find a way of capturing the scheduling data for these milestones, and report on them accordingly.”
The room erupted in questions.
“Is there a way of prioritizing the level one milestones?”
“Do all the organizations performing the work on these milestones agree on that prioritization?”
“Are all of the projects involved using Critical Path Methodology software, or even the same package?”
The nature of the questions reassured me that the team I was to inherent in a couple weeks knew their stuff, but I became convinced that their (then) director was clueless.
As the meeting wrapped, an old friend of mine who happened to be on the program controls team invited the Ph.D. to sit with me for a moment to get my input. I had made it a point to not say a thing, but now I was cornered.
“Listen, George (not the Ph.D.’s real name), the relationships you just described are well-known aspects of a schedule baseline. When you say that the level one milestones are dependent on the level twos, and so forth, you are describing a decomposition of scope that’s nominally performed by establishing a Work Breakdown Structure. The description of the need to capture common or shared facilities and resources among the milestones is typically handled via a master resource dictionary. And the need to capture which milestones (he meant activities, but I thought it best to use his lexicon) need to be finished before others can start is quantified using schedule logic. Any CPM software package worth the name will be able to accommodate these parameters, and provide the kind of schedule performance information you are looking for.”
My friend who had put me in the hot seat was gesturing towards me as if to say “What he said!”, but George was having nothing of it.
“We’re already arranging a series of coordinated spreadsheets that list all of these milestones, and the relationships I just discussed. We’ll be able to handle it that way.”
I pretty much knew George would reject anything I had to say, but I felt the need to offer it up for rejection nevertheless. The serving of spaghetti-like diagram that he had drawn on the white board provided clear evidence that he was attempting to deal with PM concepts that he didn’t understand, rendering any attempt to convert those concepts into a workable strategy inchoate at best, and utterly misguided (and therefore wrong) at worst.
On the plus side, the whole episode served as a stark example of how, when authors, paper presenters, and, yes, bloggers push figures or tables that indicate entities, functions, or activities encapsulated in shapes that have lines or arrows in between representing some sort of vaguely-defined relationship, it’s a sure sign that the author has a poor grasp of the concepts underpinning the proposed process or strategy, which in turn means it’s probably going to be, well, wrong.
Another unexpected outcome of the meeting: I had to have Italian food for dinner that evening.
Going back to my Game Theory roots, one of the games that’s often used to model cooperation or defection behavior is Hawk-Dove. Imagine a population of 100 generic birds, who can adopt one of two strategies: the doves forage for food, and consume all they can collect, whereas hawks simply take the food of those doves who are unable to defend it. A fascinating aspect of Hawk-Dove is that the entire population’s payoff is maximized if all of them behave as doves. However, with the introduction of a single hawk, the Nash Equilibrium[i] quickly moves towards a ratio of 25% hawks, 75% dove, even though, again, the entire population’s payoff is maximized if they are 100% dove.
Of course, games like Hawk-Dove are only somewhat analogous to the real-life situations they are intended to model, and it is up to each individual PM to determine just how analogous such insights can be to their particular environs. However, the particular aspects of Hawk-Dove, of the movement of the Nash Equilibrium moving to 25/75 with the introduction of just one hawk, even though the payoff is maximized through 100% dove strategy selection, got me to thinking about a particular binary distinction I’ve often made in this blog about Project Managers, the Processors versus the Performers. In my version of this PM game, the Processors are those PM practitioners who care very much about process, and tend to devote significant amounts of energy and time into ensuring that cost and schedule baselines are properly set up and integrated, that the risk analysis is performed with only the best information available and by recognized experts, that there aren’t too many start-to-start relationships in the Critical Path network, that no more than 5% of the activities have their Earned Value claimed through the Level-of-Effort method … you know the type. But the sure sign that a PM is a Processor is the adherence-to-process behavior appears to (or actually does) take precedence over bringing in the project on-time, on-budget, with all of the scope particulars satisfied. Conversely, Performers devote the lion’s share of their efforts at bringing in the project on-time, on-budget, with all of the scope particulars satisfied, and do not place much emphasis on what others consider to be proper process. Indeed, Performers will often see formal procedures as onerous, and harmful to the attainment of their overall objectives.
Now let’s take a quick diversion over to Organizational Behavior and Performance space. In any meritocracy, the person who shows talent or an aptitude for performing the tasks the organization asks of them will be given tasks with greater levels of responsibility, including leading teams of others so that some level of knowledge/expertise transfer, or training can take place (they don’t call Project Management “the accidental profession” for nothing). In PM space, this typically occurs in one of two ways: the individual actually brings in the work by attracting new clients with their demonstrated level of expertise, or else they are promoted because their abilities are perceived as being advanced by the higher-ups in the organization. In other words, the Performers versus Processors dichotomy is somewhat natural in the way it manifests in the PM world.
Okay, let’s return to Hawk/Dove. In my analogy, the Processors get ahead without actually bringing in projects on-time, on-budget, and yet it seems they are invariably the ones who set policy for the macro organization(s). In this respect, Processors don’t go out and attain credibility by actually being successful PMs – they sort of pilfer street cred by presenting as if they have it, usually through academic qualifications or claimed experience. Conversely, the Performers get ahead by actually being successful managing projects, which often includes knowing which of the organization’s procedures to short-shrift, if not avoid altogether. To continue in the analogy, Performers are “doves,” attaining and collecting successful project completions; whereas, Processors are “hawks,” claiming to have the inside track on how such successes were accomplished in order to convey to others how they ought to, well, perform the function of Project Management. Consistent with the model, organizations are clearly better served if all of their PMs are Performers, since most (if not all) of their projects will come in on-time, on-budget, which is all by itself a source of strength for the Strategic Managers (who are seeking to maximize market share). However, with the introduction of just one Processor, the Performers are forced into a position of having to defend the way they conduct Project Management in those instances where it deviates from the point of view of the Processors. I have no idea how to even approach the calculation of the Nash Equilibrium in this scenario, since the parameters are so numerous, if they could even be quantified at all. But you see my point – with the introduction of just one “expert” in PM who points to anything other than a stellar record of successfully managing actual projects as the basis for their expert status, and the macro organization will begin to drift away from a true meritocracy and towards a perceived-advanced model for conducting Project Management.
So, Where Do The Giant Magnets Come In?
Several guidance-generating organizations actually seek to attract Processors in order to churn out their highly subjective PM procedures, guides, and handbooks. But for organizations that seek to repel these “birds,” some useful strategies might be gleaned from Wile E. Coyote, the cartoon antagonist to the Road Runner from the Looney Tunes and Merry Melodies series of cartoons. Wile E. Coyote employs many devices and strategies for capturing the Road Runner, but always fails (usually spectacularly), meaning that a review of these strategies might provide an excellent primer for actually repelling the birds.
Now we just need the Processors to eat the bird seed with the iron pellets mixed in…
[i] Technically, a Nash equilibrium is a set of strategies, one for each player, such that no player has incentive to change his or her strategy given what the other players are doing. Retrieved from http://gametheory101.com/courses/game-theory-101/what-is-a-nash-equilibrium/ on February 9, 2019, 13:36 MST.
In previous blogs I’ve referred to the old saw, Availability, Affordability, Quality: Pick Any Two. To elaborate:
Another rather inescapable rule of free market economics: the price of an item or service is what aligns supply with demand. When the price of something is allowed to move freely, rare somethings will command higher prices, signaling the macro economy that more of that something is in demand. If there’s an excess, prices will fall, and the macro economy will respond in such a way that the resources used to produce the something could be better directed elsewhere.
Now consider what happens when some outside controlling influence, like government, decides that a certain good or service is “too important” to be allowed to have its price set by something as seemingly arbitrary as supply and demand – in the United States, gasoline in the late 1970s, or health care now. With the price set lower than it otherwise would be by something as arbitrary as bureaucrats, what happens to availability and quality? In most instances, they both suffer reverses from what they would have otherwise attained in a truly free marketplace. In the case of the gasoline shortages during the 1970s, since the artificially capped price of gasoline meant that oil producers could not with confidence make a profit, American oil production actually went down during the period, resulting in more unintended negative consequences to the macro economy. As far as health care is considered, the effects are identical: by employing the political “solution” of artificially holding down prices, there’s an abundance of evidence that both quality and availability are suffering (along with the patients!). Conversely, if those cases where the price is artificially set too high, surpluses will occur as consumers seek viable alternatives. If the something that is subjected to artificially high prices is perishable, massive amounts of waste will ensue – it’s pretty much automatic.
Meanwhile, Back In The Project Management World…
So, what does all of this basic economics have to do with Project Management, specifically? Let’s indulge in a little thought exercise, where we are setting up a PM consulting firm. Our start-up is capitalized, but we’re not rich. Since nobody is going to hire outside PM help that’s not provably advanced, we can’t skimp on the quality aspect of our service; nor will customers be inclined to wait, so our deployable consultants had better be able to arrive on-site relatively quickly, meaning that the availability parameter is already set. Can we, then, expect to be successful if we are charging high rates? Clearly not – as a startup, we’re going to have to come right out of the starting gate offering the full availability—quality —affordability (AQA) trifecta.
For the sake of this analysis, let’s say our new little PM consulting firm does pull off that very trifecta for its first three fiscal quarters, and we’re attracting more customers than we can quickly address. What to do? We will have to select which two aspects of the AQA model we want to maintain, since:
In short, competition in the free marketplace will inevitably force us to decide which one of the two AQA functions we should embrace. There is, however, one aspect that allows an overcoming of these decision-driving factors: technology advances.
Referring back to gasoline prices, an advancement in extraction technology – hydraulic fracturing, or fracking – made so much more crude oil available in the United States that it changed energy prices around the world. Similarly, advances in the Project Management sciences will put those discovering or embracing them into a superior position to consistently deliver a higher-quality service at a more affordable price than the competition, with availability far easier to maintain. That’s one of the reasons I keep harping about the need for the PM community to not only return to performing legitimate management science research, but to shed the vestiges of the more archaic or obsolete aspects of PM.
To summarize, then: any formal guidance that posits a cap on PM budgets – a 5% limit is often bandied about – represents an arbitrary application of pressure on the price of the Project Management role, and is a force pushing any PMO so afflicted towards failure. The solution? I’m not going to offer a solution per se, other than to point out that any organization claiming to produce usable PM guidance that attempts to set a cap on Project Management (or any other function, for that matter) expenses has already exposed itself as being singularly backwards in the realm of basic economics.
Do we really want to accept guidance or advice from those organizations?
The Whippersnappers’ Main Deficiency: They Don’t Recognize When They’re Standing Next To A Flying Monkey
In last weeks’ blog I discussed one of the advantages that PM’s new practitioners (ProjectManagement.com’s theme for January) have, that of being more likely to recognize a simple, direct solution to a complex problem should one be available, analogous to the Scarecrow realizing he can use the Tin Woodman’s axe to discombobulate the Wicked Witch’s castle guards in The Wizard of Oz (1939). But there are two sides to every coin, and the flip side of this one represents a real disadvantage to the new practitioner: They tend to believe the other members of their organization are automatically on their side.
A lot of the material presented in PM coursework, PMP® preparation classes, and PM-themed seminars can be rather sterile. Yes, yes, I know I’ve been advocating for a return to more, well, science-based analysis here in the management science arena, but I also freely admit that there’s a side to what Project Management practitioners do that defies quantification, let alone valid, logical analysis. And the quicker the new practitioner comes to a working knowledge of these more subjective factors, the better off they (and their project teams) will be.
Of course, not all PM curriculum are excessively or unrealistically sterile. Exhibit A is the use of Michael Maccoby’s excellent book The Gamesman[i] , which I have referenced in this blog before. Maccoby posits four archetypal behavior patterns among workers, so:
One of my main takeaways from Dr. Maccoby’s work as it applies to the PM world specifically is the working assumption that, in project teams of any significant size, there is going to be at least one Jungle Fighter. The new project team leader can count on it. The implications here include:
Another landmine that I’ve encountered multiple times in real-life but have never seen addressed in PM literature or paper presentations has to do with the business model pathologies stemming from the teaching of the asset managers’ narrative, that the point of all management is to “maximize shareholder wealth.” Even though this assertion is in sharp contrast to the Project Managers’ goal of completing the customer-defined scope on-time, on-budget, I have yet to read other writers’ work pointing this out. The real-world difficulties that come from this clash of visions is probably most often manifested the first time the new PM approaches her organization’s accounting department with the request to collect actual costs at the reporting level of her project’s Work Breakdown Structure (WBS). The ability to collect actual costs based on the WBS is critical to the creation and maintenance of an Earned Value Management System, the only method for accurately gauging a project’s cost performance. Many of the accountants I’ve encountered, however, will be inclined to (a) maintain that cost performance is performed by comparing actual costs to budgets (which is false), and (b) collect actual costs based on the Organizational Breakdown Structure (OBS), which is, after all, an ordering of the company’s assets. By pushing the asset management narrative, whether through a genuine belief that that’s the way things are done, or due to a more vindictive motive, the information streams that the PM needs in order to make informed decisions are eroded or even prevented outright.
I am, however, at a loss as to how to articulate these two new-PM-practitioner traps without sounding cynical or even paranoid. I mean, “Welcome to the company, new PM practitioner. You should know that at least one member of your project team is going to advance their agenda at the rest of your team’s expense, and the most powerful single group within the company, Finance and Accounting, has been educated to believe that the information you need to succeed is the wrong way of doing business” is hardly a rational-sounding introduction. I suppose I could be a bit more circumspect, as in “beware the enemies within your project team, and those external to the project team, but internal to the company,” but that version is so vague as to sound even more psychotic.
I think I’ll settle for a Wizard of Oz reference.
[i] Maccoby, Michael. The Gamesman: The New Corporate Leaders. New York: Simon and Schuster,1976
Whippersnapper Advantage #23: They Are More Likely To Recognize When They’re Standing Next To A Tin Woodman
In the classic film The Wizard of Oz (1939) there’s a scene that takes place in the Wicked Witch’s castle, where Dorothy, the Scarecrow, the Cowardly Lion, and the Tin Woodman (and Toto, too!) are cornered in the castle’s great room, with halberd-armed guards advancing menacingly towards them. The situation appears to be completely hopeless when the (supposedly brainless) Scarecrow notices that the massive candelabra hanging high in the room is suspended by a rope, and that rope just happens to be secured to a cleat on the wall right next to them. When the Wicked Witch, who is standing on a mezzanine above them, throws the large hourglass to the floor where it explodes, the Scarecrow simply grabs the Tin Woodsman’s axe and severs the rope (he doesn’t even remove the axe from the Tin Woodman’s grasp, or tell him what’s going on), dropping the massive candelabra onto the assembled guards. The protagonists then escape (temporarily) in the confusion.
I was reminded of this scene recently when I was working a little project of my own, restoring a 29-year-old sedan that I use for getting around my far-flung workplace. It has over 200,000 miles on the odometer, and it was looking so ratty that I was concerned my co-workers would take me for a ragamuffin. Here’s a before picture:
So I pulled it into my garage and began working on it, but only after it had been repainted, so:
One of the problems that had been vexing me was that one of the heater control knobs wasn’t working, and my research indicated that fixing the most likely cause involved pulling the dashboard off. After about five hours’ work I finally pulled the dashboard, and accessed the supposedly offending module, only to find it was perfectly okay. With a sense of dread I grabbed the actual knob and checked its underside – its plastic shaft had split, making it unable to move its associated linkage. The replacement knob cost less than $5 (USD), and the effort was nothing more than pulling off the old one and pushing on the new. I can tell GTIM Nation from personal experience that nothing makes reinstalling a car’s dashboard more depressing than the realization it never had to come off in the first place. If only I wasn’t so reflexively oblivious to the simplest, most readily-available solution…
Meanwhile, back in the Project Management world…
Maybe it’s just me (though I don’t think so), but the more education and experience I ingest, the more formulaic my responses become, and it goes beyond the garden-variety overthinking of problems. I’ve noticed this in many paper presentations and PM-oriented articles, as well. It’s not enough that, when the PM practitioner is tasked with setting up a cost/schedule performance measurement system, the one doing the setup is expected to create a cost baseline using only the most recent Master Resource Dictionary in the Basis of Estimate, or that the number of start-to-start relationships in the Critical Path Methodology schedule is kept to an absolute minimum, if not eliminated altogether, no siree. It’s almost become taboo for anyone to attempt a simpler, more direct solution, with such an approach seen as some kind of erroneous deviation from the true Project Management codex. I blame Processors[i] for this state of affairs, even while I freely admit to not being immune from that particular way of thinking.
And it is here that the
Which would probably lead to fewer instances of seasoned PMs feeling an acute desire to take a Tin Woodman’s axe to the dashboard of an innocent 29-year-old sedan.
[i] In previous blogs I’ve made the distinction between Processors and Producers, the former being made happy only if established procedures have been strictly followed, with the latter made happy if their projects actually come in on-time, on-budget.