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.