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

Project Dogma?

I saw on a blog somewhere a couple of interesting definitions that have been cropping up in my thoughts recently.

Methodology + Mindlessness = Dogma

Methodology + Mindfulness = Excellence

How many project methodology graduates have been taught to use a hammer, and then see nails everywhere? In fact they lose the ability to see anything else!

Do you see your project through the filters of the methodology you are most familiar with? Can you see your project outside of these filters? What fresh insight might this give you?

- Jason Bates (I'm back)

Tags:
methodology, Project+Management, Perception, Dogma

Have you read it?

Have you read “7 Secrets of Project Leadership” yet?  It’s free, and you can get it at www.realprojectleadership.com !

— Philip Greenwood

Tags: 7+secrets, Project+Leadership

Complexity Blindness

Is the idea of using different strategies for different levels of complexity new to you?  On reflection, I've had remarkably few conversations with clients about complexity-based approaches to projects over the last 20 years. The idea itself is not new.  I've come to the conclusion that there is a widespread phenomenon we might call "simplicity bias" - the desire to see a situation as simpler than it is.  I'd like to suggest some evidence for this assertion:

• The use of simplifying metaphors
• The use of simplifying assumptions
• The simplification of news stories by journalists (the Monomyth again)
• The need to simplify messages for senior executives to win their confidence (they are surely able to deal with complicated messages to have risen to that position!)
• The insistence on applying Best Practises despite their widespread failure
• The insistence of placing the blame on an individual when disasters happen, rather than recognising the systemic causes.

(I admit that you could, alternatively, level the accusation that consultants have "complexity bias" - the desire to make a situation appear more complex than it is, but since I am also arguing that experts are not better at changing organisational systems when they are complex and chaotic, where is the pay-off?)

If we habitually understate complexity, then we must be overstating the effectiveness of competence and expertise.  We must be overstating our ability to plan project activities.  We must also be taking a much bigger risk with large development projects than we might anticipate.  This is the illusion of control.

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Complexity, Chaotic

Time for a revolution in the music industry

A while back I introduced Flo Radio to you as a technique for producing environmental sound to enhance team productivity.  The idea was to use Pandora’s streaming radio site, which allows you to set up “stations” that learn from the listeners preferences. 

Being based in the UK, this morning I received an email from Tim Westergren of Pandora stating that they were about to start blocking transmission to us:

“It continues to astound me and the rest of the team here that the industry is not working more constructively to support the growth of services that introduce listeners to new music and that are totally supportive of paying fair royalties to the creators of music. I don't often say such things, but the course being charted by the labels and publishers and their representative organizations is nothing short of disastrous for artists whom they purport to represent - and by that I mean both well known and indie artists. The only consequence of failing to support companies like Pandora that are attempting to build a sustainable radio business for the future will be the continued explosion of piracy, the continued constriction of opportunities for working musicians, and a worsening drought of new music for fans. As a former working musician myself, I find it very troubling.

“We have been told to sign these totally unworkable license rates or switch off, non-negotiable...so that is what we are doing. Streaming illegally is just not in our DNA, and we have to take the threats of legal action seriously. Lest you think this is solely an international problem, you should know that we are also fighting for our survival here in the US, in the face of a crushing increase in web radio royalty rates, which if left unchanged, would mean the end of Pandora.

“We know what an epicenter of musical creativity and fan support the UK has always been, which makes the prospect of not being able to launch there and having to block our first listeners all the more upsetting for us.”

My opinion:  The music industry, in fact the whole entertainment industry, is like a deer frozen in the headlights of an on-coming truck.  They will shortly become road-kill unless they think through the implications of commodity-priced high-bandwidth communications, pervasive computing, and the virtualisation of content.

— Philip Greenwood

Tags: Flo, Radio

Project Management & Leadership Search Engine

A while back we put quite a lot of effort into this custom Google search engine, and while the traffic has been steadily increasing, it can still be improved...the more people use it, the better feedback we get, the better we can make it!

The link for the search engine home page is here:

http://www.google.com/coop/cse?cx=011867071513363012666%3Atbng4tlbkso

The code for adding the search box to your web page is at:

http://gmodules.com/ig/creator?url=http%3A%2F%2Fwww.google.com%2Fcoop/api/011867071513363012666/cse/tbng4tlbkso/gadget

If there are topics under-represented, or sites that you feel should be included, please leave a message in the comments.

— Philip Greenwood

Tags: Google, Custom, Search, Engine

Ensuring Project Complexity has been Properly Assessed and Acted Upon

We've had an initial look at how we typically understate risks, but there's another question:  Are you implementing into a stable organisation?

It's a bit of a trick question, isn't it?  You'd love to say "yes", but you know the more accurate answer is "no". You know you live and work in an evolving and changing organisation in which any structure that you can clearly perceive is already the past, and what instead matters most may be the "perturbations" on the edge of the current structure, which have the potential to manifest a substantive change.  But will that change your implementation plan?  The temptation to make the assumptions that the organisation is simple, linear, equilibrium-seeking and isolated is extraordinarily strong, because it gives you the feeling of control.  But it is illusory.

For the sake of this discussion, let's define a scale of complexity to describe the organisation as a system (in the engineering sense):

• Simple  - Least complex
• Complicated
• Complex - Learning to predict outcomes is expensive
• Chaotic - Practically unpredictable (but not technically random)

If the organisation was a Simple system, changes would be easy - you would simply categorise the problem and apply a best practise that addressed the issue.  Experience tells me that this works occasionally, usually on a very small scale.  On the other hand, I've seen many implementations of ERP systems trying to apply "best practises". Typically the organisation finds its own approach once the consultants leave.  So once the implementation group exceeds about a dozen, then it is no longer appropriate to describe the organisational behaviour as Simple.

Some organisations can be categorised as Complicated systems.  Such organisations respond well to expert intervention; examples of these organisations are certain kinds of industrial operations.  In these organisations toolkits such as Six Sigma and the Theory of Constraints (Lean) work well.  If the organisation can be disassembled into components, optimized, and then reassembled to create a better functioning whole, then this is the domain you are in, and you should follow the Six Sigma mantra of "DMAIC" - Define, Measure, Analyze, Improve, Control.  But remember that manufacturing and distribution is only a component of what the organisation does, and these tools may not be appropriate elsewhere in the organisation.  And how can you tell in advance whether your industrial operation is suitable for intellectual disassembly?

I hate to think of organisations as Chaotic, because it's possible I'm being led by fashion, however in my opinion most sizable organisations are certainly Complex, and possibly Chaotic in their behaviour.  They respond to changes in ways that aren't obvious.  And when you change a component of the organisation defined by the scope of the project, it has interfaces into the rest of the organisation:  The scope is not the change!

We often hear quoted the idea that "insanity is doing the same thing again and again and expecting different results" - variously attributed to Albert Einstein and Benjamin Franklin.  However, for organisation systems with high degrees of complexity, insanity may well be doing the same thing twice and expecting the same results - because you make the changes at different times, the system you are changing is different!  Because you've already made a change to a part of the system, then the system you are changing is different!  This is the domain for which the famous "butterfly effect" is a metaphor.  Tiny changes in initial conditions may (or may not) yield substantially different end results.

In such complex organisational systems, the expert is powerless, and you are left with testing, piloting, rolling-out and correcting - an organic, evolutionary approach to change, in which you attempt to learn as you go along, but should not be surprised that you fail!

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Complexity, Chaotic

Facebook Spam, Phishing? www.facebook.com.profile.php.id371233.cn

Breaking from the topic of Project Leadership for a moment, I was intrigued to receive this message on Facebook from a friend in London at 5:15 this morning:

lol i cant believe these pics got posted....its going to be BADDDD when her boyfriend sees these- http://www.facebook.com.profile.php.id.371233.cn

If it wasn’t from someone I trust and like to share the odd joke with, I wouldn’t have gone anywhere near it.  But I did.  The link takes you to a page that requests you to log-in to Facebook – and when you do, you go to your home page.  Hmmm….peculiar.  So what’s it all about?

Unless you’re a regular reader of this blog, you’ve probably already tried the link; I think it’s best to change your Facebook password.  This appears to be a spurious log-in page, and it’s possible that it is being used to capture log-ins and passwords – a technique known as known as Phishing.

When I changed my password, I was reminded that Facebook is willing to store credit card details – so there might be financial implications to this Phishing attempt.

If you receive this message from me now, please accept my apologies.  A new year, and a new form of web abuse.  Happy 2008!

— Philip Greenwood

Tags: Facebook, Spam, Phishing, Virus, Trojan

The Scale of The Project

Once the scope of the project has been challenged, socialised and agreed upon, it's time to start estimating the scale of the project.  Clearly, producing a project schedule that significantly underestimates the work and duration of the team will be a suppressive activity.   In fact, due to the aforementioned importance of control in our psyches, a unilateral planning and scheduling activity will be detrimental whether regardless of its quality.  So planning and scheduling must be an activity based on team engagement.

Once again we find ourselves on shaky ground!  If projects can be placed on a scale of certainty - with "concrete" on the one end, where the majority of the project tasks are repetitive and known, and "abstract" on the other, where the project resembles an exploration, it is clear that the frequently proposed technique of "unpacking" the tasks is not universally applicable.

Even for the concrete projects, there is a cognitive tendency called the "Planning Fallacy", which indicates that people underestimate the time taken to complete tasks - people formulating plans typically eliminate factors that they perceive to lie outside of the project, and also tend to discount multiple improbable high-impact risks (since each one is unlikely to happen).  These elements may include things like sickness, vacations, meetings, finishing off old projects, annual review processes, public holidays, departure of key personnel, sudden emergency client needs...

…not to mention the Lake Wobegone Effect:  The tendency to think that our own, current, project team is better than other project teams that have done similar work before - so even with benchmark information for similar tasks, we are prone to make estimating errors with regard to our own teams expected performance.

Clearly it's important to use all the available information to benchmark the activities of the project, but it is also just as important to understand the likely inaccuracy of the schedule, given the risks and certainty level of the project.  Inaccurate estimates of delivery timing make distant resource planning difficult - it's much easier to schedule a vacation than to estimate the implementation date for a complex project - which can often lead to delays in the implementation and further uncertainty.

Again, this is an issue that needs to be raised, carefully communicated, and understood within the team, stakeholders and extended stakeholder groups.

— Philip Greenwood

Tags: Project, Leadership, Black, Book