Portfolio planning: Create storms, not forms

I said some time ago that strategic portfolio management goes beyond what is typically achieved in a project management office (in my 8th "brief tip" for project management). My best attempt at formulating this in a rememberable way comes here: Create storms, rather than forms.

I think better value from a project portfolio can come from creating storms - honest discussions between people that typically own the day-to-day business operations that the projects are about to change - than using very detailed sign off procedures and authorizations. Rather than requiring many people to sign off projects of a certain size, have them take part in the regular meeting that is the only place such projects can be authorized for initiation.

An important outcome of such meetings is which projects not to run and also to create visibility of the most important projects for senior management. Ask top management: "What are your current major running projects and which are the top priority ones?" Getting any kind of stuttering as a response is a big red warning light.

If you just take the form-based "PMO coordination" approach, there is a danger that all projects will just be administred - not prioritized. One useful way of visualizing projects can be as a radar, with distance showing the expected end date and the size of the dots showing the size of the project, possibly with sectors for business units. Over time, some rules of thumbs might evolve about how many major project the organization is able to digest, which types of projects require the most coordination across business units, etc.

A weak point of the method of de-facto giving the line management power to decide which projects to run, is that often only the needs of current customers will be heard. This is similar to Christensen's Innovators Dilemma. You may make your self obsolete through many incremental innovations of the status quo, that by them self make sense - but fail to capture big shifts. This is really a separate discussion, but one solution might be to separate early stage R&D projects both organizationally and from the project prioritization process.

A final word, maybe to avoid any unintended storms (!): Forms can also be useful. The most obvious example I can think of is that a suitable template, or form if you will, can contribute to getting the project owner to think in business case terms when arguing why it is a good idea to run just their project... And PMOs can of course be useful facilitators for the decision process. Also, I am not suggesting to get rid of documentation or preparation for the meetings, but I still think that the main point is valid: Prefer storms over forms, decisions over documentation, and prioritization over administration.