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?


  1. Craig,

    it probably won't surprise you that I don't think PM can be separated from the culture of the organization. There has to be alignment between how the organization operates and how people operate and report on a project.

    If you bring someone in from the outside, they will quickly learn that to get things done they have to work within the cultures, norms and processes of that organization. Whatever those processes happen to be.

    I don't think it's the size as much as the organizational outlook that affects its approaches, to PM or anything else.

    To me, work gets done inside an organization. PM is a little bit like weather reporting. It can tell you the temperature, whether it's going to rain or maybe even if there's a catastrophe coming, but a weather reporter cannot change the weather. Likewise, a PM can report on a project, provide insight into what's happening and articulate what needs to happen in order for the project to have the best chance at success, but a PM cannot make a project succeed. They might make it fail, but a PM cannot change the cultures, processes or organizational structures. They must work with methodologies that fit in the organization.

    Certain organizational structures will lend themselves to certain approaches. The PM methodologies stand the best chance of doing what they do best - report, provide insight and articulate needs if they are aligned with how the organization works.

    For example, if the organization is an open source gaming site like IMVU with thousands of users providing hundreds to thousands of updates a day, agile approaches make a ton of sense and provide valuable insight to enable better decision making and provide the greatest chance of success. (http://startuplessonslearned.blogspot.com)

    However, if it is a large company with multiple competing departments and controlled through finance, a more structured PMI/PRINCE2 approach probably aligns better with the organization and will provide greater insight and aid in better decision making and chances of success.

    Warren Buffett has an analogy that I think applies here. If you're looking for an audience, and you advertise that you're having a rock concert, you'll get a particular type of audience. If you advertise that you're having a ballet, you'll get a different type of audience. They're both perfectly good audiences and they will be happy if you give them what they're looking for, but don't advertise that you're having a ballet and then put on a rock concert. You'll have unhappy people. Likewise, a structured command and control organization probably has the best chances of success working with a PMI methodology.

    Misalignment of methods to organizational approaches will lead to frustration not insight, in my experience.


  2. God. I am in the middle of this now.
    What to do?

    Project management challenges existing power structures. The plan challenges hierarchical reporting relationships, if everyone is bound by it.

    Well done, it stops arbitrary project wackiness and 180 degree turns.

    In reality, it's all a bit too much for some organisations.


    Leave. I think is all that can be done. There still seem to be a lot of jobs out there...

  3. Actually I'd never point telco 20000-employee company as a candidate for agile processes. I worked at a vendor side for mobile operators and vast majority of them aren't able to adopt agile techniques. Too much bureaucracy.

    If that's the example of flexible company I can only imagine what you've seen in government.

    About the role of PM, well, it depends much on business environment you work in. A single PM won't change it in any organization bigger than a couple of dozens people, so the only way is to adjust yourself and try to implement small improvements whenever it's possible.

    I've run projects where vague something should be delivered at arbitrary date. I don't consider them as successes but I don't blame myself or my team either. Sometimes it's lose-lose from the beginning and the best you can do is to avoid huge crash even if that means struggling.

    If a customer is forcing to buy ambiguous something with 2-month delivery they set themselves for failure. On the other hand if a vendor signs this kind of contract because salespeople don't give a damn or that's general strategy of the company PM won't change it. He can either take the project as it is or find another job.