As a child, I hated having to eat broccoli. The only way I would ingest that foul weed was to put butter, salt, or cheese sauce on it, and even then, I had to be coerced or bribed (“No dessert unless you finish your
Meanwhile, Back In The Project Management World…
My regular readers are well aware of one of my favorite bifurcation distinctions, that of processors and performers. In the Project Management realm, the easiest acid test here is:
With this distinction in place, what is to be said of the typical Project/Program Management Office, particularly since most PMOs are founded in the first place in order to bring some level of transformation to the macro organization in PM space? Sadly, most of these PMOs tend to be staffed by processors. How do I know? Just look at their behaviors. Do they not generate guidance documents, get these documents signed by upper management, and attempt to modify the way the project teams approach and execute their projects by the threatened implication that, by failing to obey every aspect of the dopey guidance documents, the project teams are disobeying upper management (and, therefore, should not get dessert)?
It could be worse.
And if you think this particular strategy is both invalid and highly off-putting, consider all of the organizations that crank out their own versions of how PM ought to be performed, but have nothing at all to do with your specific team or company. To engage in a massive bit of understatement, projects are different. The same team putting together, say, a petaflop-capable supercomputer will employ techniques and management strategies that are so unique to that scope that virtually any generalization about how projects ought to be managed will include at least a couple of strictures that not only fail the relevancy test, but would be profoundly backwards. But you can bet that some processor somewhere on the list of “stakeholders” that “must be engaged” will cite the extraneous requirement as proof that the supercomputer team is doing something wrong, and ought to be chastised (at least) for pursuing their scope in such a way that the processor finds insufficient.
But back to the PMO charged with transforming the macro organization. If the processors’ efforts at compelling transformation via procedures and guidance can be safely assumed to be
Performers, in my experience, are more intricately aware of the axiom that Project Managers ought to always begin with the end in mind. Okay, so, what’s the end product here? If you said “transformation of the organization,” you are stilled mired in the processors’ approach. The correct answer here is “to place into the hands of the decision makers accurate, timely, and relevant information that will maximize the odds of their completing their projects successfully.” Such information is gold to the performers, and some suspender-clad, Harry Potter-style-eyeglasses-wearing processor tut-tutting about how all PMs should be forced to ingest and act upon a comparison of the Basis of Estimate to the line items in the General Ledger are anathema to them.
Is there any cheese sauce, or maybe ranch dressing?
This being the case, the optimal approach for the PMO to bring a PM transformation to the macro organization would be for the PMO to offer a variety of Project Management information products to the diverse project teams that would need them. Based on the axiom I wrote about a few weeks ago, these products would reflect the “Quality, affordability, availability: pick any two” reality by making (1) quick-and easy PM information products affordable and readily available, (2) high-level PM information products readily available for a price, AND (3) high-level PM information products at an affordable price, if the project team can wait for them. In this way the various project teams can select the profile that best suits their particular needs, free from the kibitzing of processors, ensconced in their cubicles, turning out their opinions on how everyone else ought to be doing Project Management.
That this performers’ approach to transformational Project Management is patently superior to the typical processors’ strategy is readily revealed with one simple mental exercise. Ask yourself, as the PMO Director, do Team Leaders come to you for PM-typical performance information, or do they seek to have you tell them how they ought to be managing?
Once the project teams begin to freely engage your PMO’s services, just watch, because an actual macro organizational transformation is about to begin. They won’t accept your veggie trays unless they include broccoli…
Do you want to have your organization undergo a Project Management transformation? I mean, do you really, really want your organization transformed in PM space? Well, I have great news. I know of a series of tactics that are part of an overall strategy that will, without fail, transform your organization in this area. I have never seen it fail, and am only too happy to provide it to my readers.
Before I provide this can’t miss “solution,” I want to reference Captain Tom Schorsch of the United States Air Force, and his Capability Immaturity Model[i], as the basis for knowing at what rate the transformation is taking place. The Levels of the CIM are as follows:
I’m sure you have noticed that, unlike the Carnegie-Melon Capability Maturity Model®, Captain Schorsch’s version “advances” in negative increments. There’s a reason for that. Keep these levels in mind as we review the strategy and accompanying tactics of this can’t miss approach.
First, name the person who is in-charge of your Project Management Office or PM Implementation effort one who is familiar with the basics of PM, and who has supreme confidence in their efficacy. This person should believe that no assertion that appears in the PMBOK Guide® can possibly be mistaken, misguided, or not to be universally applied, and each and every part of the current crop of PM literature must be observed in its totality. After all, the head of the PMO must be the face of coerced implementation. Sure, parts of the organization will bristle at, if not push back on, some of the new mandates coming from this person and the PMO, but these people must be assumed to be ignorant at best, subversive to the legitimate PM agenda at worst.
Next, staff the PMO with former accountants and administrators who have recently attained their PMP® certifications. Experienced PMPs® will have lost the enthusiasm for relentless compelled universal implementation, and might actually tend towards picking and choosing which aspects of current PM guidance would be best at achieving their ends, and which techniques should be done lightly, if at all. For guaranteed PM transformation, this will not do. It all has to be implemented, with no exceptions.
Don’t forget to document all of these demands into some sort of officially approved procedure, signed by the highest levels of management. For good measure, have every member of the PMO become familiar with the potential penalties awaiting any Project Manager found to be in violation of approved procedures, and the precise manner in which these penalties may be executed.
Now, as these early tactics are rolled out, the various project teams will attempt to opt-out of compliance with the procedures. Some of the counter-strategies involved include:
The transformation will be underway! How can you tell? Well, those projects that had previously had a basic (or even medium) level of PM expertise will either now be struggling with the additional costs it takes to comply with the new
“But Michael!” I can hear GTIM Nation exclaim, “this is not the transformation I was seeking! I wanted more advanced PM capability, not a regression!”
Yeah, well, I promised a “transformation.” I didn’t guarantee which direction it would go. Besides, the tactics I listed seem to be fairly commonplace. I didn’t invent them, I simply listed them.
[i] Wikipedia contributors. (2017, November 29). Capability Immaturity Model. In Wikipedia, The Free Encyclopedia. Retrieved 01:25, May 13, 2018, from https://en.wikipedia.org/w/index.php?title=Capability_Immaturity_Model&oldid=812639060
One of my favorite movies is Mel Brooks’ Young Frankenstein (1974). I especially liked the scene where Gene Wilders, Marty Feldman, and Terry Garr are sitting down to a meal after having failed (they believe) to bring the monster to life. As they’re eating, the monster, very much alive but confined to the examination table in the cellar laboratory, lets out a grunt that Dr. Frankenstein mistakes for Igor’s vocal appreciation of the food.
“I didn’t make a yummy sound, I just asked you what it is.”
“Well, if you didn’t make a yummy sound, and you didn’t, then who…?”
In a flash the three realize that the monster must have made the sound, and rush to the laboratory to confirm it.
Meanwhile, Back In The Project Management World…
There’s this Project Management transformation (ProjectManagement.com’s theme for May) myth that I would love to overturn, but it’s fairly well entrenched. It goes something like this: the Project Management “expert” is brought in to the organization to transform it from a bunch of people completely bereft of PM techniques or strategies to one where even the lowest-level of management/leadership regularly, even casually discusses things like scope creep or variance analysis. This expert does so by employing one or a combination of the following tactics:
The myth to be overturned is that these tactics work. They don’t, particularly and especially if we’re talking about organizational transformation on a scale analogous to bringing
So, What Does Work?
The most transformational strategy that I’ve encountered that works on a consistent basis has to do with getting really simple. An exec who had been transferred to head an organization that had dozens of small projects – in the $80K to $250K (USD) range – had no idea how all of these small projects were performing, as their Project Leaders had escaped any accountability or reporting responsibilities because their projects were “too small for Project Management.” He called me in to see if I could help. I told him I thought I could, but first I had to abandon virtually all of the recommendations from the conventional wisdom. A junior project controls specialist was supposed to support me, but he ended up instead arguing with virtually every decision I made.
My first step was to ascertain exactly what kind of cost/schedule reporting would make this exec confident that he had a handle on all of these projects. He selected an XY chart format, with the Cost Performance Index (CPI) tracked on the X axis, and the Schedule Performance Index shown on the Y axis, with the size of the projects’ bubbles indicating total budget. It’s a neat little report, really -- at a glance, anyone can tell if the status of the projects reporting, so:
The beautiful thing about this report is that it only needed, technically, three pieces of data, two of which were already available via the General Ledger:
As my project controls “support” person constantly
At the first project review, the XY/Bubble charts, nicknamed “Bullseye Charts,” were projected up on the conference room’s screen. Each Project Lead was asked about their status, particularly the ones in the lower left-hand quadrant. Those who failed to respond to the percent-complete data call were admonished by the executive, and never did so again (“It’s a simple data point! How hard can it be?”). After a few explanations about how the data was being processed into this performance information, the PLs understood what was happening, and why.
At the second project review, none of the PLs failed to send in a percent complete estimate. Some had clearly attempted to game the system, as their bubbles hugged the Cost Performance Index axis. These were told to knock it off, as their attempts to game the new performance measurement system were plain for all to see (“I said it would be simple – I didn’t say it would be stupid.”). Those in cost performance difficulties would discuss possible sources of informal changes to the scope – classic scope creep – and their attempts to reduce or eliminate it. Others would engage it what can only be described as variance analysis, and at a fairly sophisticated level. Again, none – none of these people had ever had formal PM training. They simply began to adopt its lingo when intelligently addressing project performance issues.
By the third project review, discussions easily transitioned to venues for modifying the baselines, tapping available reserves, and using demonstrated superior performance to attract similar work. They had actually transformed into a fairly sophisticated bunch of PMs, almost by accident, and within three months’ time.
Hearing their suddenly PM-focused discussions was the yummiest sound I’d ever heard, and I didn’t even have to rush to the laboratory to confirm that the transformation had taken place.
As I’m sure anyone who’s ever launched, headed up, or even participated in a Program or Project Management Office knows, there are hundreds of things that can derail your efforts, and bring your PMO crashing down in ignominious defeat. Elements that are outside your organization, inside your organization but outside the PMO team itself, or even within the PMO represent existential threats that can spell ruination, and dealing with them, or even recognizing them in time to attempt a counter-strategy is extremely tricky. If only there were a proven technique, something that, on its face, utterly and graphically contradicts the majority of the anti-PMO narratives that are constantly popping up and needing to be refuted, then the typical PMO would at least have a fighting chance of establishing the value of its generated information streams.
Well, good news, my fellow PMO aficionados!
This technique exists, it’s extremely simple to implement, and it absolutely drives a goodly share of your opponents to a place where their ignorant, nefarious motives in opposing you can be easily laid bare. I’ve seen this technique rescue failing PMOs, and secure needed status for upstart ones. It is singularly effective, and in such a dramatic manner as to be analogous to the one weapon that can kill various monsters, such as werewolves or vampires, the Silver Bullet.
“Enough already!” I can hear Game Theory In Management nation yelling. “What’s the technique?”
Why, it’s a lowly histogram.
With the same ears with which I heard the “What’s the technique?” question I just heard a collective groan. How can a simple histogram overcome these anti-PMO monsters? I’m glad you asked.
You don’t actually need to use a histogram for this particular information stream, but I’ve found it the most easily understood by execs who are either (a) not very good at interpreting complex management information products, or else (b) have the attention span of a typical executive, which is about 10 seconds. If you don’t make your case inside of ten seconds, your odds of having your version of the story resound in the board room are quickly reduced to nil. So, make your case effective, and to do this often requires a hard-to-ignore graphic, like a histogram.
Our magic histogram will be divided into months along the X axis, and will have three bars per month:
Generally speaking, these three bars may very well track within 5% of each other for the majority of projects’ life spans. But, when they do vary, it’s invariably in such a way as to demonstrate the value of the PMO in blatantly unequivocal terms.
This is because the projects that turn into disasters will have the following characteristics:
The calculated EAC is a uniquely Earned Value-ish concept, and tends to be exclusively within the PMO’s domain. The Cost Performance Index (CPI) is the amount earned (BCWP) divided by the amount spent (ACWP). Divide this number into the budget at completion, and you have an EAC that’s accurate to within 10 points (once the project has cleared the 15% complete mark). In other words, this simple technique will notify upper management of pending project management train wrecks far sooner than any other method.
If the PMO’s got it, it needs to flaunt it.
By plotting this calculated number and showing it in a histogram that also shows the projects’ budget and “official” EAC, an unmistakable pattern emerges. The budget bar remains fairly steady (unless an approved Baseline Change Request is processed), and both or either of the “bottoms up” estimate or the accountants’ estimate will tend to mirror the total budget. It’s basic human nature for the former, and the utter lack of reliability of the technique for the latter. But, for those projects that are headed for difficulty, the calculated EAC bar will jump higher than the other two bars, and will tend to stay noticeably above them for reporting cycle after reporting cycle. By the time the troubled project’s troubles are so obvious that they can’t be explained away any longer, the calculated EAC will have been not only flagging the overrun, but demonstrably quantifying it rather precisely. This is at the same time as all of the other “information” streams have been saying, essentially, “nothing’s wrong here – we’re doing fine!” The only time the bottoms-up or accountants’ version of the EAC even begins to report accurately is when the overrun can no longer be hidden, and by then it’s too late for executive action that maybe, just maybe could have averted the disaster, if only they had been notified earlier.
I’ve employed this technique on a few projects (!) that accurately predicted multi-million-dollar overruns, and the response was always the same. Early on the members of the failing project team would vehemently denounce the technique, claiming (absurdly) that their “bottoms-up” EAC must be considered authoritative. The upper-level managers would receive the histogram with alarm, but actually be mollified by the troubled projects’ managers into disbelieving the calculated EAC. After a few reporting cycles with the delta between the “bottoms-up” EAC and the calculated version remaining significant (or even growing), the PMs would employ some desperation tactic, like filing a get-well Baseline Change Proposal (BCP), or tapping project reserves, but the inevitable conclusion would become plain for all to see: the calculated EAC had the story right, all along, and everyone else had it wrong.
And now, for the piece de resistance…
If the first Silver Bullet didn’t kill the monster, try this one: it’s another histogram, except this time each month has a single bar, the calculated Variance at Completion (VAC) amount. Take all of the projects in the portfolio, and calculate their EACs. Subtract this figure from the total budget (BAC), and then sort them from lowest number to highest. The result is a chart that ranks the projects, in order, from most troubled/highest projected overrun to healthiest/highest underrun. For good measure, color the overrun bars bright red, and the underrun bars green. This report will drive the managers of the troubled projects bonkers, but it’s pure gold to your organization’s executives.
Did I say pure gold? No, rather, pure silver, as in Silver Bullet.
[i] Make sure the colors of the histogram’s bars have high contrast. I like to use gray for the total budget, orange for the bottoms-up EAC, and either bright green or blue for the calculated EAC.
*…with apologies to (the real) Ira Levin.
It was another dark and stormy night. I was staring at the stenciled letters on my frosted window office door, ylnatS yrrebpsaR, etavirP eyE, when my secretary called out “Goodnight, Stanly. I had better get paid tomorrow, or else!” I pulled a whiskey bottle and shot glass out of my lower desk drawer, when the phone rang. It was Charlie Gumshoe, from the PM police department.
“Stanly! I need you to get over to the Stepford Robotics Corporation first thing tomorrow morning.”
“Why? What’s going on?”
“We’re not sure. They’ve got some weird connection with Monolithic Corporation. We think Monolithic is supplying them Project Management Office personnel, in exchange for some robotic welding machines.”
“What’s wrong with that?”
“Nothing on its face, but we believe that Monolithic is attempting to flood the marketplace of PM ideas with their own cliched approaches, which would inject a whole range of irrelevancies into the discussion. If they get new tech companies like Stepford parroting their particular version of Project Management…”
“I hear you. How will I get in?”
“We’ve arranged for you to assume an alias and join an Independent Cost Evaluation team on a State contract that shouldn’t have anything to do with Monolithic. Your new name is Ira Levin.”
“You mean like the author?”
“Whoa, that didn’t occur to me until just now, but that’s kind of funny, isn’t it? Just in case a Monolithic employee is there, do you have some kind of a disguise?”
* * * * *
As I took my visitor’s badge from the receptionist at Stepford Robotics, I saw that the rest of the team had assembled in the foyer. We headed off together to the large conference room where the review materials were waiting for us in binders. As we opened our binders, the male project team member began presenting the basics of the scope, cost, and schedule baselines, short bios of the project team, etc. Another oddity: every single member of the project team was born in 1990 but hailed from all over the globe. Along about the beginning of the third hour, they began to discuss their risk management plan.
“Are you kidding me? You guys actually spent time on a risk management plan?”
“Risk management is integral to successful Project Management!” they all said, in unison.
Again the project team stared back and forth at each other, their eyes darting about, their heads going through small but jerky motions. The lone male spoke up again, his voice creepily even.
“There are many sources for this assertion, most of them respected professional associations and scholastic venues. Would you like a precise listing?”
“No, thanks. I know the academic world loves this stuff. I’m just surprised that a high-tech outfit would engage in it. Just spare me the whole business about how ‘risk management’ also involves ‘opportunity management,’ because of ‘upside risk.’”
“But that is so!” they all exclaimed, again in unison.
One of the project team who, it seemed, had been staring at a point approximately three feet in front of her face, suddenly spoke up.
“You do not look like Ira Levin.” Thanks, Charlie, I grumbled.
“The author?” I replied. “No, I don’t, but I never claimed to be him.”
She turned her head back to looking straight in front of her. The male project team member continued.
“We have a complete list of the project’s stakeholders, and will be communicating with them thoroughly throughout the project.”
“Do any of these stakeholders have connections to your competitors?”
The entire project team turned to glare at me as the presenter spoke up.
“Engaging stakeholders is integral to successful Project Management!” he asserted.
“Yeah, so is keeping tech advances out of the hands of your rivals. You can bet that they will be attempting to gain such knowledge, by secondary or tertiary means, if necessary. So I’ll repeat my question: have you vetted these ‘stakeholders’ to see if they have any connections to your competitors?”
The brunette who had been staring at a point three feet in front of her replied.
“Two on the list of stakeholders are related by marriage to one of our main competitors. Another is a second cousin to a common supplier.”
“How did you know that?”
She slowly turned her head to look at me.
The presentation continued.
“We will be updating the resource dictionary used for creating the cost baseline every twelve hours.”
I interjected. “What good does that do you? I mean, after the cost baseline is approved, why do you need twice-daily updates to the resource dictionary?”
“Accurate original estimates are integral to successful Project Management!” they all said, again in unison.
“That’s the third time you all have used that specific construction, that something is ‘integral to successful Project Management.’ Who told you that?”
“Our Monolithic Corporation programmers … we mean, mentors!”
The cat was out of the proverbial bag. Monolithic and Stepford had collaborated to create a PMO staffed entirely of androids, programmed with the unsupported conventional hokum that often masquerades as legit PM. At this point the brunette spoke up again.
“Without the goatee, Mr. Levin looks just like Stanly Raspberry, the famed Project Management detective.”
The androids were slow to move, but the members of the review team who worked for Monolithic tried to grab me before I could get out the door.
“Raspberry!” they cried. “Get back here!”
“Escaping is integral to successful life-living!” I shouted over my shoulder as I raced my convertible out of the parking lot.