As I alluded to in last week’s blog, the formal project review is perhaps the most important thing that the program manager does. Here, each of the projects in the program have a representative discuss the projects’ performance, concerns and issues. Members of ProjectManagement.com have access to a variety of templates that help with the basics of project management, ranging from risk management checklists to baseline change proposal forms, and these forms are very useful. I don’t recall seeing a template for aiding the program manager with conducting these project reviews, so I thought I’d take a stab at it. Who knows? If Cameron likes this form, he may invite me to submit others! Just for the record, though, neither Cameron nor anybody else from ProjectManagement.com has invited me to roll out the following project Review Agenda Template (RAT) – this is entirely on my own.
Back when I received my PMP® (and it wasn’t recent – my PMP® number is 1004) the PMBOK Guide® had the following major chapters:
· Human Resources
· Acquisition / Procurement
I have long contended that some of these areas are more important to project (and, by extension, program) management than others, but these chapter headings did provide me with the foundation for my proffered template. If we assume that a given major program has twelve projects within its purview, and that the program manager doesn’t want to drag the reviews out for more than ½ day, then we’ll structure the RAT so that each project’s representative has 15 minutes to get everybody up-to-date. I’ve adjusted the agenda headings to reflect my take on the value of the PMBOK Guide® chapters. So, with no further ado, here’s my RAT.
Review Agenda Template (RAT)
Project Reviews for Program _____________ Held on (date, time) at (place)________
Each project will provide updates for the following PM areas:
Scope: (30 seconds. I mean, c’mon, if the program manager doesn’t even know what your project is about, you could probably ditch this meeting altogether.)
Cost: (5 minutes [less, if you’re verifiably on-time, on-budget]. It’s appropriate that this subject and the next one take up the lion’s share of the review. All anybody really wants to know is, if you’re having a problem, how much it will cost to fix it.)
Schedule: (5 minutes [again, less if you are on a pace to finish early]. If you just got done reporting a Schedule Performance Index [SPI] of less than 1.00, and your critical path schedule is indicating an on-time finish, you’ve constrained too many milestones.)
Risk: (12 seconds, just long enough to have the project rep blurt out “After the baseline is approved, risk management is largely irrelevant.” Besides, a risk analysis of this review indicates that you’ll need to set aside 3 minutes as Contingency.)
Quality: (1 minute firm. Over-wrought statistical investigation does not a valid quantitative analysis make. Besides, this is more of a personnel/process issue than specific-project related.)
Communications: (18 seconds, unless you really want another lecture on the alleged importance of “involving stakeholders.”)
Human Resources, Procurement: Whoops! Look at that – we’re out of time! We’ll let you guys report on your goings-on at the next review.
Feel free to reproduce this form for your project reviews – just don’t attach my name to it. I’m busy enough ducking risk, procurement, communications, quality, and procurement managers as-is.
Both the main strength and biggest weakness of project management information systems has to do with the assessment of the activities’/tasks’/projects’ percent complete. This figure is central to both the Critical Path and Earned Value methodologies, methodologies that enable management to have a remarkably clear and accurate view of how long any particular project will last, and how much it will cost at completion.
Savvy project managers know this. They also know that it’s no fun to show up to the program manager’s project review meeting with duration and cost calculations that indicate that their project is looking at coming in over-budget and late. So, what’s the easiest way out of having to offer up potentially embarrassing admissions of incompetence, poor performance, or just plain bad luck? Inflate the percent complete figures you give your Project Controllers, of course!
This course of action, as dishonest as it is, has several appeals. Besides the aforementioned avoidance of explaining your mistakes, you also delay any comeuppance you would otherwise receive for poor performance – the proverbial kicking of the can down the road. Also, when you do finally have to account for the problems that wrecked your project, you can always deflect some of the blame towards the very project management information systems you are attempting to thwart. I mean, c’mon, the project’s baselines were approved! Representatives from the project team attending every program management meeting! If this project management stuff was all that, how is it that it missed these problems for such a long time?
Of course, this tactic is nothing new, hence the old saw that all projects proceed on-time and on-budget until they hit the 90% point, and then stay at the 90% point forever. And that’s the real frustration of the whole project review cycle: inevitably, had the problems that ruined the project been known about early on, they could have been addressed and probably corrected before they got so big as to endanger or ruin the whole shebang.
But, human nature being what it is, the use of the tactic of overclaiming progress will probably be with us forever.
Or will it?
Consider the traditional formula for calculating at-completion costs, that of dividing the total budget by the Cost Performance Index. This can be algebraically solved to dividing cumulative actual costs by the percent complete. The reason that this is the go-to formula for calculating at-completion costs is that it’s both simple and amazingly accurate – to within 10% on activities past the 20% complete point. The Cost Performance Index tends to be rather stable, rarely varying more than 10% -- which is why its use in calculating at-completion costs is so reliable.
Enter the CPI’s mirror image, the To Complete Performance Index. It is calculated
TCPI = Work Remaining / Budget Remaining
TCPI = (BAC – EVcum) / (EAC – Actuals)
…where BAC is the Budget at Completion, EVcum is the cumulative Earned Value amount, the EAC is the offered Estimate at Completion, and Actuals are the actual costs. Now, let’s say a program manager is presented by one of her project managers with the following:
· $1M in total budget (BAC)
· At this point in the project, the project was budgeted to have spent $550K
· $500K claimed as earned (EV)
· $600K in total actual costs (AC), according to the General Ledger. And, the kicker …
· He claims he will complete on-time, on-budget.
Before breezily accepting these claims, let’s do a little lie-detector calculating, shall we? The proffered estimate at completion (EAC) is $1M, right? However, if we calculate this EAC, we get … $1.2M! This projects cumulative CPI is sitting at a lowly 0.83. In order to achieve the stated on-budget delivery, that performance would have to jump all the way to 1.25, an unbelievable 41% improvement in performance!
This program manager would be perfectly justified in channeling her inner Ricky Ricardo, when telling this PM “You have some ‘splainin to do.”
It was a dark and stormy mid-afternoon. I was sitting at my desk, staring at the etching on the frosted glass window of my office door, rotagitsevnI etavirP, yrrebpsaR .T ylnatS, when a shadowy figure let himself in.
“Whom did you come here to see?”
“Whose name is on the building directory for this office?”
“Whose name is on the door?”
“Why are you asking, then, if I’m Raspberry?”
“’Cuz I need to know. You Raspberry?”
“Yes, I’m Stanly Raspberry” I sighed. “What can I do for you?”
The shadowy figure strode up to my desk, sat down in my cane-bottom chair, and began talking excitedly.
“It’s not what you can do for me that brought me here” he began. “It’s what I can do for you!”
“What’s all this?” I asked, as he dropped a series of colorful brochures on my desk.
“It’s the most recent breakthrough in crime-solving software. We call it the Crime Reporting and Adducement Program.”
“Wait, you have developed software that helps solve cases?”
“Not just specific cases – it solves entire groups of crime!” the C.R.A.P. salesman maintained. “We based it on those project management software systems that expanded to program management.”
“Wait a second …” I objected. “In order to design a computer program that can solve an individual case, let alone a collection of similar ones, it would have to know what types of information are needed, much less how to collect the data itself. How on earth does it purport to pull that off?”
“Oh, these crimes aren’t that different” the salesman began earnestly. “Thy all involve one or more perps, one or more victims, they have to take place at a certain time, and at a certain place.”
“Yes, that’s all true” I replied. “But that’s about where their similarities end. The whole point of being a Private Investigator – similar to being a project manager, I would assume – is to respond to the wildly and widely differing circumstances presented for each project or case. The diversity of information needs is so vast, you couldn’t possibly…”
“Which is why we have designed this software to mirror program or portfolio management software. As we all know, the point of all management is to maximize shareholder wealth, so the majority of management information can come from the General Ledger. But, for the unexpected, everything else can come from the risk analysis, right? Well, our software uses the crime database and records as the substitute for the GL, and borrow from the risk managers their techniques for all of the rest! It can’t miss!”
“Call me Melvyn.”
“Okay, Melvyn, first of all, the point of all management is NOT to maximize shareholder wealth, and secondly, even if it were, no one computer program could possibly provide a comprehensive, program or portfolio-wide information stream that could lead to an informed decision on any issue under every circumstance. The diversity of problems, not to mention the decision-style of the managers confronting them, renders such tools as capable of helping, but far, far from being able to solve these cases on their own.”
Melvyn rolled his eyes, and sighed.
“How can you expect to solve anything without this kind of information?”
“I collect ‘this kind of information’ all the time, thank you. They’re known as ‘clues,’ and, unless you can demonstrate how your software acquires or sorts them better than I can, I’m afraid I’m not interested in your software.”
“You do not appear to be even in possession of a personal computer.”
“Another reason why I’m not interested.”
Melvyn scooped up his brochures, headed for the door, and turned around.
“You realize that your strategies in solving cases are utterly at odds with both prevalent risk management theory, as well as university professors who write textbooks about quantitative analysis in business (strikethrough) case-solving.”
“Yeah, I’ll make sure I steer clear of them when I’m out doing my work – if I actually encounter them, of course.”
There’s a lot of confusion out there about the precise nature of program management, as opposed to project management, so I’ll go ahead and weigh in, leading, I’m sure, to either immediate clarification or hopeless obfuscation.
According to Business Dictionary.com, “program management” is the
(p)rocessof managingmultiple related projectsat once. Where project managementis often used to describe one project, program management involves multiple projects that are all related and workingtoward the same goalor result.[i]
Clearly an aspect of scalability is in play here, and I believe it goes all the way down to the smallest component of project management, the Work Package.
Quick refresher – the Work Package (WP) is the lowest point of the project’s Work Breakdown Structure (WBS) that has estimates (baselines) for cost, schedule, and scope and, depending on their size, will typically have a manager assigned to them, or at least one person responsible for its performance.
Work Packages are combined to form Control Accounts, which also will typically have a manager assigned. Control Accounts combine to the total project level where, again, one person is typically responsible for the overall project’s performance.
Now this scalability gets a little dicey. As long as we’re managing a specific set of scope objectives, management is safe in assuming that all of the information they need to maximize their odds of on-time, on-schedule scope completion can be generated by the earned value and critical path-based information streams. To engage in a bit of hyperbole, past the members of the PM’s own project team, she really doesn’t care about the performance of the rest of the organization. But once we start talking about a combination of projects that share a common “goal or result,” then the basis for collecting the programmatic work into a given category becomes both more broad and less cohesive, and acquires the expectation that the resources belonging to the organization must now be taken into account in a way they hadn’t been previously. An upholsterer and a machinist may both be working on different car models (projects) within the same factory (program), but that does not automatically translate to a demonstrable need to manage their efforts using previously unknown techniques under the rubric of “doing” program management.
Let’s go ahead and perform a little mental exercise, where we leap-frog from techniques clearly belonging to project management, jumping over program management, and arrive at the techniques belonging to portfolio, or enterprise management. To provide the information necessary for maxxing-out the odds of successfully managing the overall portfolio or enterprise, three management information systems (MISs) must be in place: Asset Management (the General Ledger), Project Management (Earned Value and Critical Path systems that cover all of the project work), and Strategic Management (a system that analyzes the macro-organization’s proposal and contract backlog, along with data on market share/competitors). As I discuss in my latest book, these information streams, and the concerns they represent, must be balanced in order to, again, maximize the odds of success.
Now, let’s turn around and consider the category of program management, sitting, as it does, on the tier between project and enterprise management. I believe that program management is simply up-scaled project management, and should confine its information requirements to earned value and critical path across all the conjoined projects. I also think that when assertions are made to the contrary, such as the so-called need for accommodating the asset managers’/accountants’ input on how these programs should be run, such assertions do nothing more than muddy the epistemological waters, thereby granting importance and emphasis to people and information streams that do not deserve them, at least not at this level of management.
Okay, so now I’ve staked out program management’s theoretical boundaries. Next, I’ll review the hucksters (strikethrough) purveyors of business techniques and strategies who need to be excluded from the program management discussion they have so crassly crashed.
[i] Retrieved from http://www.businessdictionary.com/definition/program-management.html, 11:46 a.m. MST, 3 January, 2015
As ProjectManagement.com’s December theme of the future of project management draws to a close, I found myself speculating if the typical project controls analyst could be replaced by a robot and, if so, what would that robot look like? (There is a non-zero chance that our friends, the accountants, have already been replaced by androids, made to look more human by wearing suspenders and round eyeglasses. Similarly, some PM-types could have been replaced by androids, and continue unrecognized as such. In fact, some ProjectManagement.com bloggers could be androids. Indeed, theoretically, I could be a…)
But I digress. Since I spend considerable time discussing how project controls analysts – you know, those PM geeks who go out collecting massive amounts of data, distill them into cost and schedule baselines, and produce invaluable reports that convey these gems of management information – should ensure that their information streams have the following characteristics:
· The information is accurate,
· Timely, and most important of all,
So, where in the world of science fiction (where a surprising number of predicted future scenarios that ultimately come to pass are hatched) is such a robot depicted?
Well, in Marvel Comic’s Iron Man series, billionaire playboy/engineering genius Tony Stark has a butler, who became an assistant, and by the time the Iron Man movies came around had become an artificial intelligence-based assistant, named Jarvis. When he was a human butler/assistant, his name was Edwin Jarvis, but by the time he appeared in the movies his AI-based self was an acronym, short for Just Another Rather Very Intelligent System. Could this JARVIS render all of us project controls analysts obsolete in the not-too-distant future?
In that not-too-distant future, we see millionaire/playboy/Project Manager (stop laughing! It could happen!) Toby Snark, and his AI-based project controls analyst, NARVIS (Now, Another Relevant Very Intelligent System) preparing for an upcoming project review.
Toby: NARVIS, have you completed those cost/schedule performance reports yet?
NARVIS: Yes, Mr. Snark. I pulled status for the reporting month just 12 seconds ago, and have the information ready now.
Toby: Wow, that’s great! My last project controls analyst took up to a full day to do the same job! What do the reports show?
NARVIS: That you have out-of-threshold negative cost and schedule variances across almost all of your activities at the reporting level.
Toby: How can that be? Look at the Current Period column for earned value – it’s all zeroes!
NARVIS: Yes, sir. Those cost account managers either missed the status submission deadline, or reported no progress.
Toby: When was the status deadline?
NARVIS: 45 seconds ago.
Toby: NARVIS, you can’t just process this data with so many holes in it. Call or e-mail the CAMs with the missing status data, and remind them.
NARVIS: There’s no time to re-pull status – your report is due to our top-secret high-tech government customer in 10 minutes.
Toby: Okay, okay, but next time ping those guys earlier, and plan on at least three follow-ups.
NARVIS: Why three?
Toby: ‘Cuz that’s what my human project controls…. Nevermind. What are we going to say in the Variance Analysis Report?
NARVIS: I recommend “The proximate cause of the out-of-threshold negative variances is a consistent refusal on the part of the Control Account Managers to send in their status data by the stated deadlines.”
Toby: Are you insane? Our super high-tech top-secret government manager would issue a stop work order faster than we could say “I didn’t mean it.”
NARVIS: But it’s the truth.
Toby: What did we say last month?
NARVIS: “The negative cost and schedule variances are artificial, and due to an anomaly in the general ledger. We do not anticipate carrying these variances forward.”
Toby: Okay, let’s reuse that.
NARVIS: I calculate a 98.453% chance that our super high-tech top-secret government manager will reject this VAR on-sight.
NARVIS: Because we have used this verbiage, or something very much like it, the last nine reporting cycles in a row, and the last time he threatened us with just such rejection. Wait … stand by. Stand by. Okay, I just did it.
Toby: Did what?
NARVIS: Transmitted the cost and schedule report. It was due.
Toby: Are you crazy? Do you have any idea how much trouble I’ll be in with our super high-tech top-secret government manager when he receives an incomplete cost performance report that contains nothing but bad news?
NARVIS: I cannot miss a deadline.
Maybe the replacement of real project controls analysts with robots isn’t as unavoidable as I had imagined…