Program Management: Why Is It This Hard?

 

In last week’s blog I asked the rhetorical question How hard can Program Management be? This was an attempt to demonstrate how many of the clichéd bromides that pass for Program Management insight are really nothing more than, well, clichéd bromides. However, Program Management isn’t merely a coordination of similarly-themed projects within an organization’s portfolio, nor is it as simple as an up-scaling of known Project Management techniques. One of the factors that makes Program Management so much more than these has to do with its cyclical supply-demand dynamic. I’ll explain.

On the Demand Side…

In virtually every medium-to-large project organization I have ever been a part of, the demand for Project Management expertise either is or soon becomes highly cyclical. The cycle looks like this:

• The projects are performing tolerably well, and there’s no customer mandate to “do” PM to a certain level of robustness, so demand for PM expertise is very low. There’s minimal project controls staff, and Critical Path or Earned Value analysis doesn’t exist.
• Either a project goes off the rails, or a winning proposal that requires formal PM turns into a contract. At this point the more advanced managers will call for, or actually set up, a project office, and bring in talent, either by training existing employees or hiring externals.
• As the Project Management culture takes root, other, similar projects are expected to provide the same sort of information products that the project doing PM “right” generates. Managers who train for and attain PMPs® see promotional opportunities proliferate.
• More projects requiring formal project management are obtained, causing the project management function to expand to include a team or group of project controls specialists. Ad-hoc portfolio management soon morphs into real-live Program Management.
• These projects are successfully completed on a consistent basis, and those project team members who dislike having to participate in project reviews, or simply don’t like having their performance quantified, begin to object to the existence of the PMO. They will question if those personnel are worth what they’re being paid, or if the whole business of setting up Performance Measurement Baselines (PMBs) is even beneficial at all.
• As the naysayers advance in the organization, budgets for performing PM-specific analysis – or setting up their Management Information Systems – are reduced, or even eliminated. The reports being sent to customers expecting a robust PM capability are generated by entry-level analysts, and are little more than window-dressing.
• Inevitably, another major project experiences massive overruns and delays, impugning or destroying the organization’s reputation for being able to deliver projects on-time, on-budget. The cycle starts over.

If something as amorphous as demand for Project Management expertise could be quantified, its graph would look like a sine wave, and a fairly uniform one, at that.

Meanwhile, Back In The Project Management Demand World…

To be brutally honest, however, we PM-types are not completely disconnected from the creation and perpetration of this sine wave of demand. We go through our own cycles, which tend to include:

• When we’re brought in to an organization to do this PM stuff, it’s done for a reason. If the organization didn’t (at that point in time) need our expertise, they would not have hired us. Unfortunately, if the staff, say, has no idea what a WBS is (which is often the case), it becomes easy to dismiss them as managerially challenged.
• As we pursue behaviors such as setting up baselines and pulling status, every time we encounter resistance to what we perceive to be fairly straight-forward requests for data (like asking the accountants to collect costs based on the WBS, when they insist on doing so via the Organizational Breakdown Structure) it’s easy to conclude that the organization either doesn’t appreciate what we’re trying to bring to the table, or else doesn’t genuinely care about their projects’ performance.
• We PM-types tend to try to inject some level of formality into the organization by writing procedures and desktop instructions, and then getting sympathetic, high-level executives to sign off on them. This gives the false impression that failure to “do” PM the way we want it done will result in some sort of punishment for the uncooperative.
• As the project teams execute the scope, they quickly realize two things: (1) those Critical Path and Earned Value people aren’t really contributing to progress on the project’s actual scope (in their opinions), and (2) any cost or schedule variance – even the innocent, inconsequential ones – get highlighted in those blasted project reviews. As they begin to resist, we tend to amp up the formality by leveraging whatever organizational power we have to compel compliance.
• By the time the codex of PM procedures, guidance, and rules rivals that of most business law textbooks (don’t laugh – it happens), the typical PM is looking for any excuse to remove their projects from the list of those that must comply. The demand curve begins to trend downward, whether the PMO recognizes it or not.
• Interest in a robust institutional capability wanes, meaning that PM-specific personnel are reassigned, or leave for organizations that are on the upward side of the demand curve. Realists begin to relax their rules and regulations, and assume a far more humble approach to any remaining PMs willing to cover their people, until…
• A project disaster occurs, and the demand curve resumes an upward slope.

Notable is the fact that the supply curve tends to lag the demand curve. Make no mistake – the area in-between these lagging supply and leading demand curves represents a significant amount of intra-organizational conflict, conflict that is as predictable as it seems to be unavoidable.

In short, it must be acknowledged that at least part of the reason Program Management is so difficult is because we PM types make it that way.