Thursday, 13 December 2012

PMO scenario

I went to my first PMOSIG meeting last night. I'm not employed in a PMO, but rather that I am ultimately governed by a PMO.

So I went along out of curiosity.

The meeting was more of a workshop, run by Graham Oakes (@GrahamDOakes) who is a PMO consultant.

The scenario was that we were a team leading a review, and were given an hour to simulate a 3 day review. There were three briefing pages where we got an overview of the Organisation, the people and the project - and then we had to decide who we wanted to interview, what docs we needed, etc.

As soon as we started the simulation, the scenario was abundantly clear. ICT-driven development without user engagement. That old chestnut. So we ran through the thing requesting the Business Case, PID, Comms Plan (no Comms Plan) Risk Register, Benefits Case, etc. Each request yielded a card (or cards) prompting conversation and it was lively.

The project scenario was a real dog. It was sucking up time and effort from all PM resources, it was spiraling out of control and yet the risks, milestones and EV all would look normal to the PMO - unless the surface was scratched.

The interesting thing was that there was a really massive focus on 'is there a valid Business Case?' when it was obvious that even if delivered to time/cost/quality, it wasn't going to ever be accepted by the users, they'd clearly not been properly consulted and there was rumour in abundance.

One of the best comments I remember in for use in this case is "If you're trying to do change based on a user driven problem, speak to the users. If you're trying to do strategic change that is not user driven, speak to the users."

This is real wisdom. Users can make or break any change, whether it is emergent or strategic. If you work in HR and you believe that you can railroad change simply by changing policies, then you are sadly misled - because in this case your Organisation does not work how you think it does.

The truth is that people will be asked to do something and then they'll tend to optimize their own work. You need to reflect and support that. I always like to ask the question "If people here decided to work to rule, what would happen?" - would the place grind to a halt, or could you happily say "bring it on!"?

Sounds antagonistic, but there is a real basic truth in this. Do your processes fit the work, or do you expect people to follow broken processes? In the latter, I believe that your processes will not match the jobs being done. This means that people won't be able to understand how other departments work and how to relate to them or get things done.

So whether we get asked to solve a user problem, or a strategic one the key is to speak to users, find out what's actually being done at the moment, map the processes and then discover how we can change things and what users will accept in terms of change.

Then we can base change on that. But the business case will be much easier to write because we really understand the 'as is' and the 'to be' situations. We can easily articulate the problem and the situation because we actually know what the problem and the solution is!

I was explaining this to someone the other day and they asked me about a project they were working on "So where did this problem come from?" Ultimately the problem in question was strategic, but to choose the right solution they need to find out what the users need and will accept. This obviously takes longer than thrusting change on people, but actually takes less time overall and is more successful because (as Covey said) we "start with the end in mind" - i.e. what does a successful outcome look like, and who will use the products that people produce?

So, back to the PMO workshop. Brilliant and very thought provoking. Thanks to Graham for developing and facilitating the session, to Lindsay Scott (@projectmgmt) for arranging it, and to MMU for hosting it in their fantastic new Business School building.

1 comment:

  1. One of the things I like about the scenario is that I learn new things about the programme every time I run it. (Even though I should know it well, as I constructed it...) It's interesting to see the different perspectives that people bring to it.

    I now see it from the perspective that the organisation started out with 3 projects -- a tactical IT project to consolidate legacy systems and hence reduce IT costs; a tactical organisational change project to consolidate contact centres and hence reduce operational costs; and a strategic project to improve the way it brought new products to market. Each of these projects was probably justified in its own right, and manageable by people within the organisation.

    However, the organisation consolidated the 3 projects into a single programme. This was probably partly because that made the business case look more attractive & hence easier to sell across all stakeholders. But it was also partly due to the ego of some senior managers. And it was actively encouraged by the tools vendors and consultancies involved.

    This created a programme with diverse and partially conflicting objectives (e.g. the goal to deliver tactical cost savings asap conflicted with the goal to build flexibility into product development capabilities). From that unsteady basis, the programme then spiraled out of control. The programme team both lacked the weight of skills needed to keep the programme on course and (due to the tactical urgency of some goals) compounded its problems by making a poor tool selection without sufficient evaluation.

    The challenge for a reviewer is to disentangle such a complex situation in a short time and with limited information. In practice, completely disentangling it is probably impossible. The goal is to get enough insight to recommend useful next steps to start tidying things up.