27 April 2009

Capability first, methods second

I’ve worked in three different kinds of organisations I’d like to tell you about. Two of them ‘got’ project management, one didn’t. All three can be said to be largish, with more than 20,000 employees.

The first was a market driven company that developed products for customers and also developed back office and sales support tools for its staff. The second was a large and slow moving company that had an absolute passion for control and discipline. The third was an organisation that didn’t really know what it wanted beyond the whims of the leadership team.

Each of these suits a different style of project management.

The first example was a telco during the deregulation of telephony and the growth of internet products, the second was a bank during a time of increasing competiton and shrinking margins and the third is the public sector.

Each of these organisations had different goals. The telco’s main goals were market share through product innovation and trying to keep revenues ahead of costs. The bank’s goal was cost minimisation and risk minimisation while maintaining market share, and the government's goal is risk minimisation and stability.

These goals had a strong influence on the organisation’s culture.

When looking around at the project challenges these organisations faced the things that stood out was that the telco and bank were mainly about optimising project processes. They also had pretty good strike rates across their project portfolios. The government didn’t.

You could say that the telcos are ripe candidates for the fast to market values of the agile pm crew, or that the bank is a great candidate for PMI style thought-through project plans and disciplined, but expensive, execution. You could also guess that a very process oriented approach to projects like PRINCE2 would suit governments. It strikes me though that PRINCE2 and it’s cousins transform much of what a PM does into a spectator at a train wreck.

I want to try to not just sedge the government and it’s organisations because they are full of talented and good people. But they have an almost insurmountable obstacle between the way they operate today and the project management business of getting things done.

Government departments are bureaucratic. But so are banks.

The bank I worked at for example was a CMMI level 5 organisation. It knew paperwork and process like I know the back of my hand.

Governments on the other hand are real bureaucracies: The kind that work at stopping things from getting done because that means change. In government the propensity to fail conservatively is taken to new extremes. People actively set up networks to help them stop change from succeeding.

Take, for example, Sir Humhrey.

So, while much of the project management methodology discussions focus on fast to market agile versus the integration benefits of planning, the big question for many of us is; what do you do if your client organization has no project management maturity whatsoever?

For example, what is the purpose of a well thought through plan if it has no forum for base-lining and no discipline around change control?

What is the value of budgets and schedules when the sponsor simply wants an undefined “it” done by an arbitrary deadline?

What should the project manager's role be in this context?

These question has been with me for a while, and has most recently been stimulated by ongoing discussions at blogs such as Herding Cats, Inquiries into Alignment, Project Shrink and Noop.

What are your thoughts?

Search This Blog