Introducing programme management

I joined a high-profile project to transform the ways of working in one of the organisation’s functional areas. An initial scoping exercise had been used to identify a number of workstreams. Teams were set up and the programme commenced. I joined after the programme had been running for a couple of months. The Programme Director had realised that an effective Programme Management Office function was needed.

Workstream leaders were by and large functional specialists rather than project managers. They were protective of their autonomy. They tended to see their workstreams as independent projects rather than part of an integrated programme. They had been running for a while without a programme plan, without clearly defining outputs, and without trying to understand dependencies. Consequently they saw my attempts to put these in place as unwelcome distractions and as threats to their autonomy. They were more concerned about the immediate demands of delivery .

Actions

I led two initiatives to break the deadlock. The first was to define all the ‘products’ for each workstream. That moved the focus of attention. It had been on the activities themselves, and moved to the end-result of each activity instead. With that in hand, we put the programme on hold for two weeks while we held a ‘re-boot’ exercise with all the workstream leads. During the re-boot, we defined a consensus view of what the overall programme was seeking to achieve. Using the products as building blocks, we started to build a dependency map on which a more robust programme plan could be based.

These exercises produced some heated discussions and did not resolve all the programmes issues. However, they did provide a basis for constructing a plan that all could buy into and feel some ownership of.

Key success factors

  • If something is not working be prepared to take radical action
  • Be very clear about the minimum level of control you need and why
  • Build control through clear and manageable steps