I walked into the business college classroom full of young, serious faces, just as the professor announced “Class, I have a real treat for you today. My former student, Stanly T. Raspberry, who has made a living as a project management investigator since 1998, will be participating in our round-table discussion.”
As my old professor, Noah Tall, strode over to shake my hand, he continued “Stan, these are my graduate students in project management, the ones who either are working as interns for a major company, or else will be in the near future. I’m sure you have a lot to tell them about the real world implementation of the concepts we’ve been covering.”
While I took a seat at the table near the front of the room, I replied “Happy to be here, Noah, though, to be sure, some of the things I’ve learned since graduation might take some of your students by surprise.”
“Well, that’s why I wanted you here. Now, who has a question for Mr. Raspberry?”
One student in the second row held up his hand.
“Mr. Raspberry, what do you consider to be the more important analysis for deciding on which projects to bid, the risk analysis, or the return on investment?”
“Neither is truly relevant” I replied.
Gasps erupted from the room.
“What do you mean, not ‘relevant’?” the original questioner persisted, his voice rising with agitation. Both ROI and the Risk Analysis are key components to portfolio management!”
“No, not really” I deadpanned. “Return on Investment might be useful when deciding on whether or not to procure an asset, and Risk Analysis might tell you when to buy insurance, and how much. But as far as choosing which projects to bid, you have to know what the potential project represents to the market you are targeting, as well as what your competition is doing with respect to gaining or losing ground to you in that market. Neither ROI nor risk analysis can return anything useful for those decisions.”
Looks of bewilderment flooded the faces of the students. Another student held up her hand.
“Mr. Raspberry, is it safer to begin re-assigning project team members when the project is 85% spent, or is it better to wait until after it is 90% spent?”
“Percent spent isn’t relevant to that decision.”
Again, gasps and looks of incredulousness spread through the room.
“Well, what would you base that decision on?” the student asked snarkily.
“You have to know the percent complete of the current project, as well as the extent that the other projects in the portfolio that the peeled-off team members will be assigned to can absorb potential schedule delays.”
“Percent spent, percent complete – what’s the diff?”
“The ‘diff,’ as you put it, is that one is a marginally relevant piece of accounting information, and the other is a vital information element in making informed project decisions, including but certainly not limited to, when to reassign staff.”
Eye rolls and pshaaws replaced gasps and looks of incredulity. From the back of the room, another young man held up his hand.
“What would you consider the best way to prioritize a milestone list? Should it be sorted by earliest-to-latest, by which milestones are accomplished by key personnel, or by which ones are the most expensive?”
“Milestone lists aren’t relevant to scheduled activity priorities. You have to load activities and their durations into a Critical Path Method-capable software platform, and then add in the schedule logic. Have the computer perform a forward pass and backward pass, and return the critical path and levels of float in the non-critical activities. Then you can make an informed decision about task priority, but not until.”
Mocking laughter replaced the eyerolls and pshaaws.
“Listen, people” I began. “There are a lot of analysis techniques out there, but not all of them generate relevant information. In fact, many of them are positively useless, even though they may have been sold to you as vital.”
“Professor Tall, did you say this was one of your students?” a student in the front row demanded.
“Well, yeah, but I didn’t say he was one of my better ones.”
I gave Noah a look, as if to say “Really?”
“Professor Tall” I started, “you said these students were all interns of a major company. May I ask which company?”
“Why, Monolithic Corporation, of course” Professor Tall said pompously, with the students beaming with confident pride.
“I should have known…”
In most professions there are clear indicators when those claiming expertise show themselves to be, in fact, rather inept. An accountant who doesn’t know how to close out a contra account, the project manager who doesn’t know what a cost variance is (no, it’s NOT the difference between budget and actual costs. If you thought so, are you sure this is the website you should be perusing?), or the strategic manager who isn’t aware of their organization’s market share must keep such ignorance secret, or else get educated immediately, les they reveal themselves as doofuses.
The same is true of data managers, or, if your organization has one, Chief Information Officers. Much silliness can enter into the realm of how managing large amounts of data ought to occur, and if those in charge are not, in fact, advanced in their capability, then the entire organization is in the lurch. So, how does one determine if the keepers of the big data know what they’re doing, but in a non-intrusive way? It’s easy – just listen to what those people have to say, and if they commit any of the following follies, be afraid, be very afraid.
The easiest such test might be if the CIO knows the meaning of the word “epistemology.” This word rarely comes up in your normal project team meeting. It refers to the study of knowledge and its limits and, by extension, the nature of information efficacy. If your typical PM or strategic manager (never mind the accountants) don’t know the term, it’s probably no big deal. But if your CIO doesn’t know it, they are most likely deficient in the expertise they need for their position.
The next most obvious indicator is if those in charge of managing, creating, maintaining, or modifying management information systems ever – ever – use the argument “why wouldn’t you want to know that?” Management information systems require time, energy, and resources to set up and operate. If there is no specific demand for a particular information set, then setting up the systems to deliver such information is a waste of those very resources, energies, and time. Even entry-level MIS practitioners ought to know this.
Another clear indicator of bad data management practices infiltrating your organization involves any push to consolidate information streams into a common software platform by invoking the efficiencies of scale argument. In those instances where a variety of home-grown systems have been developed, some of which perform overlapping functions, it’s almost always due to a diversity of needs among the consumers of the information. Unless there’s a clear and compelling reason to force all such information systems onto a single platform (e.g., the general ledger clearly shouldn’t be split), any attempt to do so will come across as heavy-handed and meddlesome. Invoking supposed savings in training costs while managers are in danger of losing the relevant info they need to manage is an unmistakable sign of CIO chicanery.
Also, if your Board of Directors is being informed of goings-on within the organization via an action item list, milestone list, or “performance item” list, then the person(s) supplying this so-called information don’t know what they are talking about. Polls are not legitimate management information systems. Legit MISs have three distinct phases: (1) data is gathered based on a certain discipline or criteria, (2) it is processed into information based on some methodology (e.g., Earned Value or Critical Path), and (3) the information is delivered to decision-makers in such a way that they can readily use it. A poll, on the other hand, is just what the last person who entered data into a central database thought of a particular issue. They’re worthless, and real CIOs would know that.
Finally, authentic big-data managers know that accountants and risk managers want to take over the management information universe, and know how to put such usurpers in their places.
In last week’s blog I discussed the difference between the structure of valid management information systems, and one of the versions of invalid systems, which are essentially polls. This week I want to discuss the middle ground between light and shadow, between science and superstition, and it lies between the pit of man's fears and the summit of his knowledge. This is the dimension of imagination. It is an area which we call – no, not the Twilight Zone! Whoddaythink I am, Rod Serling? It is an area (cue the creepy guitar music) I like to call…
The Management Illusion Zone.
You’re about to meet a project controls analyst, one Mr. Sam Earnest. His project is entering a critical phase, where just one misstep could lead to disaster. He provides one of two competing management information streams, the valid one which could his project to success; the other, a risk management baseline and analysis. Mr. Earnest is about to enter… the Management Illusion Zone.
Scene I: setting, Dirk Bailey’s office.
Bailey: Come in!
Enter: Sam Earnest, Project Controls Manager (who looks suspiciously like William Shatner), and Wanda Devlin, Risk Manager (who bears a strong resemblance to Julie Newmar).
Bailey: Do you two have your monthly reports ready?
Bailey: We’ll begin with you, Sam.
Sam: On your Cost Performance Report, overall you’re okay, but there’s this one task that’s showing both a negative cost and schedule variance. I’ve drilled down through the WBS, and the specific task having trouble is the Finalize Design activity.
Wanda: I performed a risk evaluation of the entire baseline, that task included, and my report indicates that it’s perfectly fine – very little risk, if at all.
Sam: This isn’t about whether or not anybody recognized that it was risky beforehand. This is about what a negative variance will do to the project right now. That activity is on the critical path, with at least a dozen other activities not being able to start until its completion.
Bailey: I’m afraid I’m with Wanda on this one, Sam. What could possibly go wrong with getting the final approval of the design? It passed its preliminary reviews with flying colors.
Sam: I’m not sure, but I’ve heard rumors that its Work Package Manager – Henry Bemis (who, incidentally, looks a lot like the late Burgess Meredith) – spends so much time reading requirements that he isn’t connecting with the right people to get final design approved.
Wanda: The odds of that happening are approximately 700 – to – 1. I’m telling you, I’m looking at the exact same task, and there’s no problem there.
Sam (becoming visibly agitated): And I’m telling you there is! If you guys don’t do something, it’ll wreck the whole project!
Wanda: Sam, relax. We’re all on board the same project team. By the way – how are you coming along with your recovery? Didn’t you have some sort of breakdown six months ago?
Sam (caught off guard): Well, yes, Wanda, thanks so much for bringing that up. I’m getting along fine. Now, back to this variance…
Bailey: It simply defies common sense that something so trivial as getting a final design authorization could endanger the whole project, Sam. It’s really just a formality.
Sam: Formality or not, if we don’t get it squared away, we’re looking at blowing past the project’s early payment milestones.
Wanda: The odds of that happening are…
Sam: How can you possibly compute that?
Wanda: It’s from the Monte Carlo analysis of the baseline.
Sam (becoming more agitated): It makes no difference what kind of formulaic approach you took, if the feeder data represents unquantifiable events! What did you put down as the odds that an internally-approved design wouldn’t get final external authorization until after the scheduled milestone?
Wanda (looking over her reports): We gave that the typical administrative-type odds, 15%.
Sam (almost hysterical from frustration, now): But don’t you see, that’s exactly what happened!
Bailey: Sam, you’re a little too involved here. I think it would be best if you were to be removed from the project, and go someplace where you can rest. Wanda can generate all the management information I need until you’re calmer, more comfortable.
At this, two men dressed in scrubs come in, and take Sam away in a straight jacket.
Narrator: The work of Mr. Sam Earnest has ended now, reporting not only from task through to project, but also from the fear of recurring project breakdown. Mr. Earnest has that fear still... though, for the moment, he is alone in this concern. Happily, his conviction will not remain isolated too much longer, for the project does end up late and overrun, tangible manifestation of the dangers of relying on contemporary risk analysis techniques, even from so intangible a quarter as the Management Illusion Zone.
As ProjectManagement.com transitions from its October theme – leadership – into its November theme – data management – I can’t help but notice that the two have something in common: they fail utterly when they become dependent on polls.
British Prime Minister extraordinaire Margaret Thatcher once said “To me, consensus seems to be the process of abandoning all beliefs, principles, values and policies. So it is something in which no one believes and to which no one objects.” She could not have been more prescient, for if the role of leader could be readily accomplished through a pure democracy, then Rome would have never conquered Athens.
But what, pray tell, does this have to do with data management? Well, a few things. Recall my oft-asserted proposition that the bottom 20% of managers who have access to 80% of the information they need to obviate a given decision will always out-perform the top 80th percentile of managers who have access to only 20% of the information so needed. Now, here’s the second piece of this central puzzle.
All valid management information systems are predicated on this basic structure:
· Raw data is gathered based on some type of discipline.
· It is then processed into usable information based on some type of methodology (for we PM-types, this is almost always Critical Path or Earned Value, but that’s a different discussion).
· This information is then made available to decision-makers in both a timely and intuitive fashion, so that it’s readily actionable.
Graphically, these three steps can be represented as three sequential events.
Conversely, invalid management information systems will often assume the structure of a spider. They appear as a central data repository, surrounded by input/output nodes – essentially, polls, masquerading as legitimate information systems. These are often named action item lists, or milestone performance systems. But make no mistake – they are structurally invalid, and any usable information that comes from them is purely by coincidence, the way a broken clock is accurate twice per day.
These polls are as damaging to leadership as they are to informed management decision-making, if not more so. Leadership based on consensus at least has the quality of representing the desires of the followers, though one has to wonder if, reduced to being directed by polls, Patton’s Third Army would have stormed across the Rhine or have gone back to France for a little extended R&R. On the management information side, though, the backward effects can be even more insidious, since the poll-based systems invariably displace their legitimate cousins. After all, why go through all the trouble of setting up a Critical Path Methodology-capable baseline for a project’s schedule, when taking a survey of the task managers on whether or not they felt they would achieve the milestones they were responsible for can do just as well?
Let’s now return to the desk of the Prime Minister, and that of the Project Manager. The politician has access to opinion polls, the manager can tap into a so-called management information system that is, in actuality, a compilation of the opinions of the team members. In what way are these two decision-makers different? Are they not both presented with a basic choice, of simply selecting the path that the consensus indicates, or else choosing to implement a specific approach to solving the problem(s) before them, regardless of the opinions of those who are – let’s face it – not in a position of leadership?
Next week, in Part II, we’ll discuss feed-forward management information systems, and the level of chicanery that comes in to play with them.
It was yet another cold and stormy night. I was sitting at my desk, reading the etching on the glass of my office door, rotagitsevnI etavirP, yrrebpsaR ylnatS, when a very sinister shadow came across it (the door, not necessarily my name on it).
The knob slowly turned, finally unlatching, and the door’s hinges creaked as light flooded in from the hallway. Backlit in the door was a tall figure, raincoat collar turned up to the point that it almost touched his low-slung fedora.
I put my head on my left hand’s fingertips in exasperation.
“Why does every person who walks through that door ask the same bloody question? Who’s name in on the door you just walked through?”
“And who did you come here to see?”
“And, according to the building’s directory, who occupies this office?”
“Given all that, who do you think I am?”
“I don’t know. That’s why I asked. You Raspberry?”
I knew two things instantly. One, this was not a hit man, at least not a very good one. Two, this guy was not street-wise at all. He must have been sent by my old nemesis, Monolithic Corporation.
“Yeah, I’m Raspberry. Waddayaneed?”
The stranger looked behind and around him prior to closing the door.
“I represent a client who runs a major corporation. Some of our lower-level managers have been disappearing suddenly. At the same time, our market share…”
At this his voice trailed off, as if he were suddenly aware that he was about to divulge something he shouldn’t.
“We shouldn’t have this level of competition” the stranger restarted, with sudden vigor. “We’re the biggest game in town, and these little pipsqueeks…”
Again his voice trailed off, for the same reason. Although I knew which corporation he referenced, I wanted to hear him say it.
“Which corporation do you represent?”
“Why do you need to know that?”
“So I know where to not start looking.”
“I’m not going to tell you that. But I can tell you that you should start looking over at Acme. Here’s a list of names. Good luck.”
“Aren’t you forgetting something?”
“Of course – your retainer.”
The stranger scribbled out a check, tore it out, and pushed it across the desk.
“Alright, then. I never thought I’d do any business for Monolithic, but I’ll get to the bottom of your disappearances.”
“How did you know I was with Monolithic?”
“You just handed me a check.”
“Just a hunch.”
* * * *
I came across some old friends as I pulled into the parking lot at Acme.
“Stanly! How the heck are you?”
“I’m great, Marcus. You sure seem happier since the last time I saw you.”
“Yeah, you know what, I finally got out of that mid-level management position at Monolithic, and took a team lead job here at Acme. I took a cut in pay, but I’m much happier.”
“The short answer is, if you don't recognize merit, the meritorious start to disappear. They were so big, though, that the bad leadership calls will take a while to catch up to them. Here at Acme, if you can deliver, you can move up. We’re a fraction of Monolithic’s infrastructure, but I think we’re going to make some serious inroads into their customer base.”
“You may already have.”
* * * *
I met the Monolithic guy back at my office.
“I still can’t figure out how you realized I was from Monolithic!” he began. “I know I didn’t give myself away! How did you do it?”
“You gave me a check, remember?”
“Are you, by any chance, a senior-level manager?”
“How did you know that?”