A good friend who shall remain anonymous deploys projects for a large IT organization. Recently, as often happens, our conversation strayed into “work” topics. This time the subject became her Program Management Office, or PMO, with which she was greatly annoyed.
“The volumes and volumes of reporting and paper my PMO demands have become completely unwieldy ”… “What’s worse is that, after all the hours the different measurements, trackers, logs and reports take nobody looks at them, much less management!” It appears Line of Business managers were now asking for reports additional to PMO reporting so they would be relevant, thereby increasing time demands on project managers.
It was not always like this. When the PMO first came into being in that company, about a decade ago, it was well received and immediately successful. Projects back then were just “stuff that needed doing”. No standards, no templates, no regular reports. Some project managers were more skillful than others, and they got better promotions. But with the PMO, all projects began to be more successful. Common reporting began. Tracking progress began. Unsuccessful projects were reshaped or cancelled. A few years later unfortunately, PMO demands had snowballed , and many new rules for projects had questionable value.
Last year, for example, their PMO had issued the mandate that the time units for all projects had to be “days”. Any project artifacts not in “days”, had to be edited and re-published using “days”. Every estimate, every schedule, going back a year. The reason was that the PMO felt it was pivotal to link all project schedules such that they could be rolled-up into one grand, “master schedule” for the whole company. My friend was aghast. “Hundreds of [obviously unpaid] hours required of project managers to retrofit project documentation, and for what?” … “Show me a single management decision that was made or changed from rolling up these collective schedules. Does any manager even look at these rolled-up figures…? She had a point.
So it is critical that management in our PMOs remain vigilant. It is important that they stay relevant and engaged, so they don’t take the PMO in questionable directions. PMOs are a natural source of change in the organization. If they cannot effectively introduce important changes, who will? Here are a few recommendations for PMO management:
Identify And Rank Problem Areas
The PMO and its management should be able to articulate at any given point which are the company’s pain points they are solving. What areas in their projects need improvement? What is their ranking? Is it profitability? Is it resource utilization? Then introduce new changes slowly, careful of correlating them with expected business benefits everyone (or at least senior management) considers strategic .
Seek Feedback From Experienced PMs
More managers could take advantage of the knowledge their more experienced resources have. Who better to evaluate what works or does not work in projects than the people who have been deploying them for customers, for years? All too often a good solution has been crafted by those in the front lines, but the problem remains unresolved because no one has asked those with first-hand knowledge what a good approach might be.
Retire Tools That Do Not Work
Finally, PMO management needs to be courageous enough to alter, or retire altogether, tools that are not producing expected business benefits. Maybe the tools take too long to deploy. Maybe they place additional hours of burden on project managers. Implementing a project is tricky enough, so let us try to not give project managers, additionally, the PMO Blues.
