Integrated Management Systems

I've been doing some work recently for a client to implement an Integrated Management System. "What's that?" I hear you say... Contrary to what you might expect, it's not a computer system - it's a system in the style of a Quality Management System like ISO9001, or an Environmental Management System like ISO14001. The IMS takes the common parts of systems like these and creates a uniform approach across the organisation. (The standard we were using is PAS99:2006.) The team created some quite pithy insights to explain it to the really busy client personnel (and I mean REALLY BUSY!):

"A way to communicate 'how we do things around here'" "A way for the Senior Management to communicate their expectations." "A way to ensure the equitable satisfaction of all stakeholders as the business grows and evolves."

The components are simple:

1 - Communicate expectations from a very senior level executive. 2 - Create a formal process and organisation by which the IMS will be governed. 3 - Create a framework for its content that allows people to find what they need. 4 - Figure out what content should be included. 5 - Divide-up ownership of the content, to ensure it is created by the right people. 6 - Create an over-arching review process to ensure that the IMS content is integrated across functions 7 - Implement a document management system that allows broad read-only access to documentation, and limited publication rights (OK, there is a computer system component). 8 - Launch. Re-launch. Re-launch. etc.

Yes, you guessed it, the hard part is getting the organisation to accept it, adopt it and provide the content. I'll blog a little more on this in future, as there's some neat content insights I want to share...what goes in it, and how to organise it. -- Philip Greenwood

Stage Gate Dramas

Each time I reach a stage gate, in the usual melee of near misaligned leadership, I find myself wishing I'd asked some questions earlier. I thought I'd share some of them - a kind of catharsis, if you like:

• Who makes the decisions around here?
• How are decisions made around here?
• Who is the design authority?
• Do you understand the commercial impact of this decision?
• Who is going to bear the cost of this change?
• How will you know when we're ready?
• How will we know when we're ready?
• What happens if it doesn't go to plan?
• And who will do that?
• Will you included that in the ... log?

Can you hear yourself asking any of those at just the right point? Maybe next time I start a new stage, I'll reflect on this post and ask them earlier!

UPDATE: On reflection, and in response to some comments along the lines of 'you should know better than to leave it this late', I realised that I do know better, and I do ask these questions much earlier! Perhaps the real answers don't reveal themselves until they are tested? (Particularly the first few questions).  Is there a more artful way of revealing the answers?  Yes there is - it's much less transactional...that will be the subject of another post...

Thanks to Denis in particular for prompting this update.  Sorry I didn't publish your comment, but I do value it!

-- Philip Greenwood

Ensuring that the team is aligned to the scope of the project

I'd recommend Daniel Gilbert's book "Stumbling On Happiness" to anybody. It's an easy read, it's extensively researched, and I found his conclusions to be profoundly affecting. On the topic of project leadership, there's one specific insight of his that I want to share:

"The fact is that human beings come into the world with a passion for control, they go out of the world the same way, and research suggests that if they lose their ability to control things at any point between their entrance and their exit they become unhappy, helpless, hopeless and depressed"

So what is the impact of writing a scope document and then handing it down to the project team? You are removing control. You might be lucky…they might look at the scope document and say, "Wow! I wish I'd written that!", but it's more likely that they will have a mixed, less enthusiastic, reaction to how they are going to spend the next year of their lives.

It's tempting to say that you should allow the project team to challenge the scope, but that's really not enough. Most organisations have a culture that supports (if not rewards) "keeping your head down" and accepting authority, so you actually need to encourage challenging the scope. Furthermore, in the early days of a project the desire to get started, and deliver results quickly, will often lead the team to try to accomplish the scope challenge in a few hours. This is called "premature closure", and it is probably the most expensive mental mistake that we humans make.

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Scope

Guarantee Project Success 2

I suggested in my previous blog piece the idea that a powerful definition of a project would be:

“A project is the way that an organization takes a risk”.

I think this is powerful for several reasons:

1. It’s universal – it doesn’t matter what type of project you’re running, you invest resources with the intention to capture value.
2. It formally acknowledges uncertainty – every project has it, but most teams are in denial about the extent of it. For instance, enterprise transformation projects are very often a process of discovery, rather than the execution of a set of pre-defined steps – yet I seem them planned-out like concrete projects all the time!
3. When you take risks you continually assess alternative outcomes for merit. These are “real options” and they have positive inherent value.
4. It creates a tacit permission to consider course changes during the project if new outcomes are perceived.  The selection of these outcomes would still be considered success!
5. A thorough consideration of project domain complexity will reveal that we tend to vastly over-simplify our approach to them.  The definition suggests the proper appraisal of the project’s complexity is necessary.
6. It embeds the project within the organization, and the portfolio of changes that are occurring inside it and in its external context.

It’s unusual to discuss risk-taking, rather than risk-management.  Most project management tools are risk management tools, focusing on minimizing risk for a single course of action, a single outcome.  Risk taking is another art entirely.

I’m sure I’ve got more to say about this subject – until next time!

— Philip Greenwood

Tags:  Project+success, Project+failure, Risk+management

Guarantee Project Success

One of our successful adwords campaigns has this headline, but I confess it troubles me a bit.  Is it possible to guarantee project success?  I think it is, but it depends on your frame of reference.  If you define a project as something like:

“A project is any outcome you’re committed to achieving that will take more than one action step to complete.”

Then you’ve set yourself up for a very binary pass/fail criteria, and your next action is going to be running to the Gantt chart.  I’ve been contemplating the experience of leading and running projects, and I’d like to propose what I believe to be a much more powerful definition:

“A project is the way an organisation takes a risk.”

I want to leave this idea with you – to gestate – and I’ll be exploring it over my next few blog pieces to see where it leads me.

— Philip Greenwood

Tags: Project+success, project+failure, risk+management

Reductio Ad Absurdum?

This question has been playing on my mind:  If stories are the most effective tool of influence, but are an inefficient way to communicate facts, what kind of communication style is most effective in today’s “attention deficit” business world?  So for an experiment, let me try out a communication style:  The “reduced” story line.

Team Decision Making: There's No Good System!

Looking at Jason’s posting on Cognitive Bias, I find myself inspired to write about team decision making processes.  Why?  It seems to me that the people who are cerebral enough to internalize the implications of this list are also unlikely to be the talkative or assertive ones in meetings.

Here’s a summary of the categories of team decision processes: