“You think you’re some kind of Jedi, waving your hand around like that?”

 

In last week’s blog I discussed environments where Project Teams were compelled to implement various aspects of PM, specifically Earned Value Management Systems, to an exacting standard. These systems, when properly functioning, provide an unparalleled view into the projects’ cost and schedule performance, critical information for both the customer needing to know when the project will wrap up, and at what cost, as well as the contractor seeking to meet those established goals. Project portfolios that consistently (and measurably) perform well will generally attract return business as well as new customers in that particular industry. Poor cost or schedule performance, well, doesn’t.

However, everyone current in the PM industry is well aware that the standards for “doing” Project Management have expanded, sometimes in valid ways, sometimes not. When I attend paper presentations that demonstrate more reliable ways of integrating the time-phased budget as computed by the Critical Path Methodology software package into the platform that processes Actual Costs and Earned Value, I come away believing that such time is well-spent. Conversely, if I’m somehow trapped in a presentation that goes on and on about the “need” to perform Monte Carlo analyses on projects in order to create a risk management plan (no initial caps), I begin to attempt a calculation of the conference center’s ballroom area by counting ceiling tiles, estimating their length and width (thank goodness most of them are perfect squares!), and wondering how much energy would be needed for them to start to fall down into the room, leading to an impromptu evacuation, and testing if I could summon enough of The Force, Count Duku-style, to make that happen.

So, if we’re being Forced (get it?) to “do” PM to a certain level of robustness, what does that entail, exactly? When attempting to answer this question, I think it’s important to keep in mind that common PM-related techniques, such as EVM- or CPM-based reporting systems are components of an overarching business model, whether they are perceived as such or not. Combining these components into a business model without a pre-planned structure is a sure way to drive the organization’s PMO into the ground. For example, Communications specialists will often advise the PMO to include all “stakeholders” in their Project-oriented communications, expanding the list of people who should receive, say, cost/schedule performance reports. If, by integrating the whole engage-all-stakeholders technique into the business model results in, say, competing organizations having access to monthly Variance Analysis Reports (VARs), then such an integration is clearly working against the overall mission of the PMO as well as its owning organization. Why bother to perform competitor/opposition research when their own Communications Managers tell you all about their performance issues?

GTIM Nation is aware of my predilection for basing a nominal PMO’s business model on the axiom Quality, Availability, Affordability – pick any two, and the folly of attempting to deliver all three. I believe that this axiom points to the fact that many business strategies are very capable of conflicting with others, no matter how attractive they appear in isolation. For example, who could possibly be against quality? Or, more specifically, which PMO Director could withstand the charge of allowing a sub-standard system to be implemented for a given portfolio? But that’s the thing – “sub-standard” according to whom? In an organizational environment where there are no external customers demanding strict compliance with overwrought procedures, with multiple small projects in need of just a simple cost/schedule control system, to pursue a supposed high-quality, universally-applied PM information system is not only doomed to fail, it’s actually akin to managerial malpractice.

Which leads me back to another one of Hatfield’s Management Axioms, that managerial leadership is predicated on three central attributes:

• Genuinely caring about the people on your Team. If you don’t care about them, they will tend to not care about you, or your technical agenda.
• Identifying the optimal (or at least workable) technical agenda. Teams hate having to proverbially bark up the wrong tree.
• A demonstrable passion to execute that technical agenda, alone if necessary. A “leader” positioning himself to bail on the scope is apparent to all.

While all three are key to success, in this blog I want to address the second one, identifying the optimal technical approach. One of the definitions of intelligence that I’ve come across is the ability to address novel situations and reach a desired outcome by recognizing similarities in previously-encountered circumstances, and making appropriate similar or adjusted choices. When it comes to PMOs attempting to compel an advancement in Project Management maturity, a real danger arises if that “advancement” isn’t based on the best technical approach for the circumstance. Such an approach has to not only further the PM capability, but flange up nicely with the macro-organization’s existing business model.

Otherwise your implementation strategy is likely to be reduced to waving your fingers in a clockwise direction, and saying “You will collect percent complete data at the reporting level of the WBS.”