Wednesday, June 24, 2015

Now, what is a PMO for?

Where I work we have a PMO; its not called that, which is good, because it's not a very good PMO.

Why not very good?

Because it is an information one way street. We all provide data on our project timing, but never see a consolidated report to enable us to link up projects, reduce redundant deployment of resources and people (note, resources are not people, and vice versa), and generally get more efficient. But it doesn't happen and currently we have three projects doing overlapping data remediation actions using the same big database!

In the old days in my firm we had a more organised system than currently for keeping the execs on top of what was happening. A quarterly report was done in a standard but awkward format (some genius has crafted tables within tables in Word! Not good; and there was no calculation on any numerical or data data) and submitted to an exec meeting.

The report was not as useful as it could be but, at least the executive committee could compare and line up projects with each other, which they did in part, but not thoroughly due to they didn't fully understand any of the projects reported!

A PMO should make connections, bring people together, and overall save money while improving project portfolio returns, otherwise it is just a template shop.

Saturday, June 20, 2015

Guiding Principles 7: Risk management

Enable informed tradeoffs between project and portfolio risks and potential rewards.

Risk management: Enable informed tradeoffs between project and portfolio risks and potential rewards.

It’s right to couple risk and reward. Once goes with the other. But let’s not get led astray by the financial market’s conceptualisation of risk-reward. Across an investment portfolio this works, but the project risk environment is not like an investment portfolio. You can’t sell stock in part of the project and buy a bit of another project to balance the risk being faced. That would just under-resource the first project and head it to failure.

Risks in a project are at the heart of project management. This extends from risks in the project environment (what we normally call risks) to risks created by the project’s organisation. K has a useful post on internal risks that teases out this concept.

Managing risk is not done by dreaming up a list of risk around the table, ‘weighting’ them  -- usually without statistical reference -- and placing them in a matrix. That’s not risk management, that’s a ceremony; but organisations do love their ceremonies, thinking that they achieve something over here in the real world.

The management of risk has to show up on the schedule and budget, and be aligned with the dependencies of WBS elements and have calibrated probabilities attached. This helps structure the project to avoid risk, but also to deal with it when it occurs, even if it is by insurance; and insurance is the last refuge of the scoundrel project director in many contexts.