Elmar Roberg relates a true-life tale of tragic dimensions

Let us be realistic: you cannot create or run an effective P-MO without some people, methods or tools. A P-MO, for the record, can be a portfolio, programme or project management office.

It is the tools that have made it a possibility that we will be able to see enterprise PMOs (EPMOs) a common feature in many organisations in the future. I say “a possibility” because I believe we are still a way off, and how long it will take depends.

We read many stories about successful PMOs and EPMOs, but I do not believe half of them – and that is not merely sour grapes, as you may think after you have read this article.

There are a few research projects that look beyond the marketing gloss and which show that most PMOs (and EPMOs – but this is getting tedious, so I will simply refer to PMOs) suffer from a problem of half-life. Not quite as bad as Copper Cu-61, but a long way from Carbon C-14.

In this article, I will explore a real project that went south quite recently.

I have changed the names because all the actors are people I like and many of them I consider to be friends. So is the sad organisation in which this took place. (In fact, we are mourning the first anniversary of when the project was euthanised.)

I will call it Freedom Frek Ltd (FFL). I will tell you that it is in the financial services industry, is one of the oldest and one of the largest in South Africa.

The project began in the right way (at least, according to the literature). An investigation resulted in a problem statement and the description of some alternatives that were further developed into a recommendation and an implementation road map.

The scope was limited to information technology (IT) or information systems (IS) projects, but it was envisaged that this could be extended to business projects and, ultimately, all projects.

When we started the planning, we estimated that the team who was to do this from the performing organisation side shared almost 150 years of (real) project management experience, with a mix of some substantial failures mixed in with a solid base of notable successes – hardly babies!

FFL, on the other hand, had had a long history of notable successes and systems development disasters (which, sadly, most of the executives had never been a part of, but that is another story) and believed that you kept people on their toes by restructuring every two years.

In the three years before our project, it had done three major project management exercises including portfolio, programme or project management office implementations. I kid you not.

When I was engaged there on the periphery some years before, FFL was using Sciforma’s Project Scheduler 8 (PS/8) and introducing Microsoft Project and building what one could call a second-generation PMO (mainly manual, but using tools to leverage consolidation).

Then followed the retirement of PS/8 and implementation of Microsoft Project, and this was followed by an implementation of IBM’s Rational Project Manager. Each was executed (you choose the meaning) by a different vendor.

And then I was back, this time to lead the foray (as it turned out, but was not planned that way) into MS Project and MS Project Server (EPM).

This was then the fourth attempt in three years.

Which edition of EPM? Ah, good question. Our group had experience on the 2003 edition and had some of the best skills in the country, but FFL was using MS Project 2007. So, it was to be 2007. No problem! (Now, how many times have you heard IT/IS guys say that?)

By now, you know that we were going to implement Microsoft’s EPM 2007.

The scope was divided into nine themes, including the development of practices, governance, categorisation of projects, tool customisation and implementation, and deployment.

After completing the planning and other preparatory work, the project proper was to start on 4 May, and final handover and closure on 28 October (the same year).

Tough schedule. But, hey, we had done this (or similar stuff) before and we were the dream team, after all.

What’s more, FFL had been sold a PMO in a Box. A sort of LEGO® Mindstorm set.

And how long does it take to unpack a box and assemble the pieces?

The completed product had the potential of being a PMO in a Box but, sadly, it was not there yet. Most of the pieces were there, but missed all the glitzy stuff that one would expect in a box. Notably also the build instructions.

One of the first fatal failures was that the customer had not been taken into confidence regarding this. (When I look back, I do not understand why because there was not anything around to compete and the idea is still good.)

But this resulted in some very interesting and undignified ducking and diving when the sponsor started asking to see the box. This became a real bull fighter’s red cape to the proverbial bull.

Another fatal flaw (this time on the customer’s side) was that the sponsor role was rather blurred. The (recently started) enterprise chief information officer (CIO) drove the initial stages and then handed over to the divisional manager, whose responsibilities included the existing PMO.

The responsibility was passed on to a third person – a rather doctrinaire former CIO (who, it turned out, was actually more of a chief technical officer), but a nice guy. (What is irritating is that they were all nice guys!)

The key problem was that the latter could not grasp that this was actually a “repeatable project” with a large research and development (R&D) component.

Significantly, much of the R&D was associated with the decision to go with the 2007 edition of EPM.

What our team was blissfully unaware of, was that significant architectural changes had been made to the technology. In the end, the techies were able to cope with that, but it did not look good.

As you can imagine, trust became a really big problem. It resulted in micro-management by a person who was not competent to micro-manage this type of project. And the more stressed he became, the more he micro-managed.

Then there were recognised issues with organisational project management competence – however, this was not a problem, since it would not affect the project per se.

We planned to implement a mentoring approach and deal with it when the time came. First, though, we needed to get a system in place.

The bigger problem was organisation capability. FFL would have struggled to measure up to Level 2 using any maturity model. There were pockets of competence all over the show, simply not recognised and appreciated by management.

This I would lay at the door of the owners of FFL. The problem, to misquote Napoleon, was of “lions led by asses”. Certainly, it made for a difficult environment.

My response to this was to adopt an Agile approach (Fig. 1 on previous page) – problem: how do you micro-manage an Agile approach?

The key management document that was to drive this project was a Sprint Chart, which defined biweekly milestones with a list of deliverables for each milestone. This was supported by nine project schedules combined into a master schedule, developed from extensive planning activities.

I tried, unsuccessfully, to convince my customer that we had the project under control and that, through the Sprint Chart, he could evaluate our chances of success at each milestone and make decisions accordingly. He was not convinced.

I was told to do whatever was necessary to satisfy the customer, but just how do you do an Agile project according to a waterfall method?

So we entered into a series of pitched battles (all actually in good spirit), which culminated in a showdown on 23 May, where I threw down the gauntlet.

Guess who lost?

That was at around 3 p.m. My customer took himself off to my masters, and the upshot was that at 8 p.m. that evening, I received the news that (with much huffing and puffing) I was off the project and, since I was a contractor, fired – or, as it is more politely known, terminated – and left to lick my wounds (a career first).

The next day, I went in and, after a heart-to-heart chat with my (now ex-) customer who – with much beating of the breast – assured me that we had worked together well and he never anticipated it would come to this, I assisted him to prepare for the weekly progress meeting that was taking place at 8 a.m.

So, what happened then?

My boss and another project manager were brought in to take over. Both people with deep experience.

In addition, the team was boosted with additional people. One of the most capable people I know was brought in to deal with the project manager mentoring.

Certainly, from the supplier side, they bent over backward to rescue the situation and no expense was spared.

Sadly, though, at the end of June my replacements were removed off the premises in a rather undignified manner. My (ex-)customer ended up in hospital with a stress-related illness.

This project had been taken off his portfolio before that, and another person had been appointed as key single point of contact (another person who had been earmarked for the position and whom I had worked with before – very well).

At the end of November, the entire team was instructed to leave the premises, and the project was abandoned.

In the months after that, almost all the players from the supplier side left the company. Some of this was due to the economic situation.

Not all of them had positions to go to.

This, to me, is the worst fallout from the project. The fallout would not have stopped there, particularly at a personal level.

At the beginning, I made a cryptic comment that how long it will take depends – depends on what?

This is a good time to bring in that success/failure factor that appears on every such list: executive support – actually, before they can support, they need to understand – and that is where the problem lay. Most of them did not have a clue. If I had to reveal the identity of FFL, the recent history and financial reports would show that clearly.

A final thought

Map where the current projects lie, and that is what one implements first.

Once implemented, devise a rational plan to take the PMO from the current situation to where it should be. This is likely to be many years of small steps.

Work hard to convince management that the management of projects is a different type of management from the management of routine operations and the management of technology.

And good luck! You will need it. 

Elmar Roberg

E-mail: This e-mail address is being protected from spambots. You need JavaScript enabled to view it