Sustainability’s Barriers

 

When we’re talking Sustainability (ProjectManagement.com’s theme for April), my first reaction is to recall Carnegie Mellon University’s Software Engineering Institute’s (SEI’s) original Capability Maturity Model®. This model stipulated[i] five “Levels,” with my interpretation of them so:

• Level 1, “initial,” is chaos. Everybody’s doing their own thing, or nothing at all, so that, paradoxically, you can actually have centers of excellence in Level 1 organizations.
• Level 2, “repeatable,” while basic, is fairly universal. Everybody is using the same forms, techniques, and overall strategies as they pursue the targeted enhanced capability.
• Level 3, “defined,” which I equate to “sustainable,” is achieved when the capability being enhanced doesn’t unravel if the heroes who got you this far get hit by the proverbial beer truck. There are enough procedural, training, and shared techniques in-place to ensure the capability survives.
• Level 4 is where you’re just so darn good at this capability that your organization can export it to other, less advanced ones.
• Level 5 (I've never seen anybody get to Level 5) is where you are so advanced at this capability that your organization is routinely discovering solutions to long-endured problems.

Okay, let’s get back to Level 3. Since almost every organization pursuing a more advanced PM capability is enmired somewhere in Levels 1-3, Level 3 becomes something of the brass ring in the Sustainability Sweepstakes. In fact, whenever you hear some new executive assert the idea that he or she will take the organization from Level 1 to Level 4 within a certain span of time (why does eighteen months keep coming up?), GTIM Nation should take it as an automatic sign of cluelessness.

Ennyhoo, we’re trying to get to Level 3, and stay there. Don’t get me wrong – you can get some wunderkinds in the fold, and when they start to export your brilliance everybody has a good day. But that’s kind of rare, even among reputable PM consulting firms. Most orgs would be thrilled just to get to the point where everybody’s pretty much doing the same thing in PM expertise space, and top execs get to host Project Reviews where half the room is speaking intelligently about To-Complete Performance Indices without the other half of the room looking like German Shepherds at a physics conference. So, what’s keeping you from being the champion that gets your organization to Level 3? Some pretty common organizational behavior pathologies, particularly ones that tend to specifically blow up PM initiatives, that’s what. Here’s a partial list.

1. Our friends, the accountants. They don’t act out of malice (well, most of the time) – it’s just that they’ve been taught things that just aren’t so, such as the point of all management being the maximization of shareholder wealth. This little piece of management science misdirection has massive implications, not the least of which is that those management information systems that are designed to provide project performance data are misguided, and will never be as useful as the information already being provided by the General Ledger, in their learned opinion. Since they’ve been trained to believe that this is the case, it will tend to strike them as a waste of time to arrange their chart of accounts to pull actual costs based on the Work Breakdown Structure (WBS). Unless the organization is highly project-oriented (a “strong matrix”), the accountants will be inclined to collect actual costs based on some other structure, like organization. However, no Earned Value Management System (EVMS) can function without actuals being collected (at least) at the reporting level of the WBS, and no project can have its cost performance reliably or accurately measured without EVM. In short, it’s impossible to sustain a PM capability without a bit of cooperation from the organization’s accountants, and, more often than seems reasonable, they don’t have to cooperate.
2. Members of the project team who dislike Project Management Information Systems. As stated above, no project can sustain even a basic PM capability without an EVM. But, even if the accountants are on-board, and willing to provide actual costs at the reporting level of the WBS, there has to be at least a modicum of cooperation from certain members of the project team when it comes to setting up cost baselines, schedule networks, and pulling status each reporting cycle. Much of these steps can be dramatically simplified to make them relatively quick and painless, and even very simple Earned Value systems can generate highly useful and insightful reports. But if, say, Work Package managers (or their functional equivalents) withhold all support, and point to some intellectually vacuous reason such as the supposedly onerous level of participation asked of them that would allow a system to be sustained, the system will unravel.
3. If the sustainable system’s champion seeks to overcome the land mine in #2 above by making project team participation falling-off-a-log simple, thereby removing the “too onerous” objection, there’s still another barrier: the charge that an EVM simple enough to require minimum participation from the Work Package managers can’t possibly provide useful or insightful information about the project’s cost performance, and should therefore be abandoned in favor of the General Ledger (feeding into the barrier from #1 above). This assertion is also false: I have personally set up multiple systems that needed only (a) a time-phased budget (which can be independently derived by spreading the project’s Budget at Completion [BAC] over its period of performance), (b) the project’s actual costs, and (c) an assessment of its percent complete as of the end of the reporting period. Note that both (a) and (b) are usually already available from the General Ledger, leaving only (c) as the totality of the status pull. These systems, as basic as they were, consistently provided early detection of work that was on a pace to overrun, or experience delays, at over 96% accuracy.

But sustainability barriers don’t have to be valid in order for them to be effective.

[i] The Capability Maturity Model: Guidelines for Improving the Software Process, Carnegie Mellon University Software Engineering Institute, Addison-Wesley, 1995, pp. 16.