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

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

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

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

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

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

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

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

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

The Scale of The Problem

I regularly see project management texts discussing character types with respect to project team selection and composition.  For the most part, I believe this is an academic conceit, because it's incredibly rare to have such a large population of team candidates that you can filter on this basis.

If you believe in character types - and some character types don't - there is a piece of information that can inform us of the scale of the problem of premature closure.  In the Jungian character typing system (more commonly known now as Briggs Myers) your character type is identified by a four letter designation of pairs:

E/I  - Extravert / Introvert
S/N  - Sensor / iNtuitive
T/F - Thinking / Feeling
J/P - Judgers / Perceivers

While all these elements indicate something about how you make decisions, it is the final pair, Judgers/Perceivers, which I would like to focus on here.  Judgers make decisions quickly (trusting the Experiential System)…and make up over 87% of executives.  It is these people who will need convincing most that the scope should be properly challenged, that it is a vital and necessary component of the project and a predictor of its success.

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Decision+Styles

The Scale of The Problem

I regularly see project management texts discussing character types with respect to project team selection and composition.  For the most part, I believe this is an academic conceit, because it's incredibly rare to have such a large population of team candidates that you can filter on this basis.

If you believe in character types - and some character types don't - there is a piece of information that can inform us of the scale of the problem of premature closure.  In the Jungian character typing system (more commonly known now as Briggs Myers) your character type is identified by a four letter designation of pairs:

E/I  - Extravert / Introvert
S/N  - Sensor / iNtuitive
T/F - Thinking / Feeling
J/P - Judgers / Perceivers

While all these elements indicate something about how you make decisions, it is the final pair, Judgers/Perceivers, which I would like to focus on here.  Judgers make decisions quickly (trusting the Experiential System)…and make up over 87% of executives.  It is these people who will need convincing most that the scope should be properly challenged, that it is a vital and necessary component of the project and a predictor of its success.

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Decision+Styles

Thinking Systems

This mistake of premature closure appears to be a consequence of the structure of our brains.  Why our brains are structured this way is up to anthropologists to speculate (more stories) -but the process of making a decision appears to be based on two things: Speed and energy conservation.  Researchers affiliated with the Society of Judgement and Decision Making map our thinking into two types: Experiential and Cogitative, also known as System 1 and System 2.

Experiential thinking is rapid, energy efficient and error prone (and makes minimal use of the pre-frontal lobe), whereas Cogitative thinking is slow, consumes large amounts of energy and is more likely to be reliable (and it makes extensive use of the pre-frontal lobe).  It is curious to reflect that our highly enlarged pre-fontal lobes are what make us so different from other animals, and yet we seem so reluctant to use them!

If ever there was a time to ensure that we must use Cogitative thinking, do research, use tools and structure, and ensure we were are correct, it is during the scope definition of a project - so much investment hinges on the scope specification!  So we need to positively encourage the team to hold off their urgency for action, take control of defining the scope, research the needs of the project among the extended stakeholder group, apply thinking tools such as issue decomposition and key questioning, and gain social acceptance for their findings.

— Philip Greenwood

Tags: Project, Leadership, Black, Book, Cogitative+Thinking, Experiential+Thinking, Thinking+Systems

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

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

More on Meaning:...The Frame

As powerful as the story is, the frame is more important.  The frame is the perspective from which the project is viewed, and it is probably the single most influential factor in team motivation.  Let me share some examples; if the project is viewed as:

• A necessary evil - then the likely response is that the work is drudgery, just more work to pile on top of the work you've already got, and therefore something must be dropped off the pile.
• An chance to create a golden future, in which the organisation grows, building security and opportunities for career advancement for all - then the work is challenging but inspiring, and the team will do their utmost to seize every possibility to make it happen.

Or some other examples that sometimes create the subtext to project behaviour:

• A game
• A battle
• An investigation
• A pilot

There is a cognitive tendency called "Framing Bias" - the tendency to use too narrow approach or description of the situation or issue.  There are two types of frames at play here:  The frame of what the project is, and the frame of what a project is: A part of this issue is the problem of how projects are perceived - the usual definition of a project is something like:

• An outcome you're committed to achieving that will take more than one action step to complete.

That's a frame that immediately implies that "On time, on budget, in scope" is the be-all and end-all of the success of a project, and as we all know the opportunities to miss that target are vast.  Furthermore it presumes that we have a precise definition of the outcome, that the definition is correct, that we can effectively forecast the work and duration required to achieve the outcome and that all risks are within the project's control. Talk about a de-motivating frame!

I'd like to propose another definition that I think is more empowering:

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

I think this is a powerful frame for several reasons:

• It's universal - it doesn't matter what type of project you're running, you invest resources with the intention to capture value.
• 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!
• When you take risks you continually assess alternative outcomes for merit. These are "real options" and they have positive inherent value.
• 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!
• 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.
• It embeds the project within the organization, and the portfolio of changes that are occurring inside it and in its external context.
• It also suggests to me that disciplines used in other fields of uncertainty might have some application within projects.
  

How can you detect the team's frame-of-reference?  One way is by listening carefully to the language that they use to describe the project. It will give you many insights.

— Philip Greenwood

Tags: Project, Leadership, Black, Book

More on Meaning:...The Frame

As powerful as the story is, the frame is more important.  The frame is the perspective from which the project is viewed, and it is probably the single most influential factor in team motivation.  Let me share some examples; if the project is viewed as:

• A necessary evil - then the likely response is that the work is drudgery, just more work to pile on top of the work you've already got, and therefore something must be dropped off the pile.
• An chance to create a golden future, in which the organisation grows, building security and opportunities for career advancement for all - then the work is challenging but inspiring, and the team will do their utmost to seize every possibility to make it happen.

Or some other examples that sometimes create the subtext to project behaviour:

• A game
• A battle
• An investigation
• A pilot

There is a cognitive tendency called "Framing Bias" - the tendency to use too narrow approach or description of the situation or issue.  There are two types of frames at play here:  The frame of what the project is, and the frame of what a project is: A part of this issue is the problem of how projects are perceived - the usual definition of a project is something like:

• An outcome you're committed to achieving that will take more than one action step to complete.

That's a frame that immediately implies that "On time, on budget, in scope" is the be-all and end-all of the success of a project, and as we all know the opportunities to miss that target are vast.  Furthermore it presumes that we have a precise definition of the outcome, that the definition is correct, that we can effectively forecast the work and duration required to achieve the outcome and that all risks are within the project's control. Talk about a de-motivating frame!

I'd like to propose another definition that I think is more empowering:

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

I think this is a powerful frame for several reasons:

• It's universal - it doesn't matter what type of project you're running, you invest resources with the intention to capture value.
• 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!
• When you take risks you continually assess alternative outcomes for merit. These are "real options" and they have positive inherent value.
• 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!
• 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.
• It embeds the project within the organization, and the portfolio of changes that are occurring inside it and in its external context.
• It also suggests to me that disciplines used in other fields of uncertainty might have some application within projects.
  

How can you detect the team's frame-of-reference?  One way is by listening carefully to the language that they use to describe the project. It will give you many insights.

— Philip Greenwood

Tags: Project, Leadership, Black, Book

More on Meaning:...The Frame

As powerful as the story is, the frame is more important.  The frame is the perspective from which the project is viewed, and it is probably the single most influential factor in team motivation.  Let me share some examples; if the project is viewed as:

• A necessary evil - then the likely response is that the work is drudgery, just more work to pile on top of the work you've already got, and therefore something must be dropped off the pile.
• An chance to create a golden future, in which the organisation grows, building security and opportunities for career advancement for all - then the work is challenging but inspiring, and the team will do their utmost to seize every possibility to make it happen.

Or some other examples that sometimes create the subtext to project behaviour:

• A game
• A battle
• An investigation
• A pilot

There is a cognitive tendency called "Framing Bias" - the tendency to use too narrow approach or description of the situation or issue.  There are two types of frames at play here:  The frame of what the project is, and the frame of what a project is: A part of this issue is the problem of how projects are perceived - the usual definition of a project is something like:

• An outcome you're committed to achieving that will take more than one action step to complete.

That's a frame that immediately implies that "On time, on budget, in scope" is the be-all and end-all of the success of a project, and as we all know the opportunities to miss that target are vast.  Furthermore it presumes that we have a precise definition of the outcome, that the definition is correct, that we can effectively forecast the work and duration required to achieve the outcome and that all risks are within the project's control. Talk about a de-motivating frame!

I'd like to propose another definition that I think is more empowering:

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

I think this is a powerful frame for several reasons:

• It's universal - it doesn't matter what type of project you're running, you invest resources with the intention to capture value.
• 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!
• When you take risks you continually assess alternative outcomes for merit. These are "real options" and they have positive inherent value.
• 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!
• 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.
• It embeds the project within the organization, and the portfolio of changes that are occurring inside it and in its external context.
• It also suggests to me that disciplines used in other fields of uncertainty might have some application within projects.
  

How can you detect the team's frame-of-reference?  One way is by listening carefully to the language that they use to describe the project. It will give you many insights.

— Philip Greenwood

Tags: Project, Leadership, Black, Book

More on Meaning: The Story...

The human mind has a special relationship with stories; they are our primary sense making mechanisms; they help us find meaning in events, past, present and speculative futures.  People read newspapers for just this reason - journalists take events and make stories out of them (often getting them wrong, or distorting facts to fit a good story structure) giving us the illusion that we understand what is going on.  The vast majority of readers are unaware that this is happening, and take the journalist's views of cause-and-effect as factual; this is how strong the story-making impulse is.

Other evidence of our relationship with stories include the popularity of the movies, in which the industry repeats near-identical stories time and time again; the ever-popular paperback novel; soap operas; theatre; TV dramas; opera; office gossip; ballads; the demand for "case studies" in marketing and text books; business plans and (without apology) project plans.  Every time you say or think "that makes sense", you have accepted a cause-effect relationship, or a component of a story.

The problem is that the story is a two-edged sword: It can be a very influential tool to persuade and motivate people to change their behaviour and actions, but it can also be used to exaggerate the importance of the incidental, the irrelevant, and the self-serving (this relates to Decision Quality, which is covered in a later section).

You can use stories to great effect for team motivation; spending time discussing alternative journeys and outcomes from the project is highly worthwhile.  Spending time discussing one particular storyline may be very useful:  The Monomyth.

The Monomyth is so prevalent in narrative across the world that it seems to be hard-wired into our brains, and it may well influence our personal and team behaviour in subtle and pernicious ways as an unconscious script.  It is also called the "Hero's Journey" and it comprises these phases:

1. A call to adventure, which the hero has to accept or decline
2. A road of trials, regarding which the hero succeeds or fails
3. Achieving the goal or "boon", which often results in important self-knowledge
4. A return to the ordinary world, again as to which the hero can succeed or fail
5. Applying the boon, in which what the hero has gained can be used to improve the world

For a project to run successfully, there are elements of the Monomyth script, whether they are consciously or unconsciously instigated, that we would rather minimise, but which would provide the excitement in a storyline - and possibly the meaning in a project. There are also elements which we would like to exaggerate.

— Philip Greenwood

Tags: Project, Leadership, Black, Book

More on Meaning: The Story...

The human mind has a special relationship with stories; they are our primary sense making mechanisms; they help us find meaning in events, past, present and speculative futures.  People read newspapers for just this reason - journalists take events and make stories out of them (often getting them wrong, or distorting facts to fit a good story structure) giving us the illusion that we understand what is going on.  The vast majority of readers are unaware that this is happening, and take the journalist's views of cause-and-effect as factual; this is how strong the story-making impulse is.

Other evidence of our relationship with stories include the popularity of the movies, in which the industry repeats near-identical stories time and time again; the ever-popular paperback novel; soap operas; theatre; TV dramas; opera; office gossip; ballads; the demand for "case studies" in marketing and text books; business plans and (without apology) project plans.  Every time you say or think "that makes sense", you have accepted a cause-effect relationship, or a component of a story.

The problem is that the story is a two-edged sword: It can be a very influential tool to persuade and motivate people to change their behaviour and actions, but it can also be used to exaggerate the importance of the incidental, the irrelevant, and the self-serving (this relates to Decision Quality, which is covered in a later section).

You can use stories to great effect for team motivation; spending time discussing alternative journeys and outcomes from the project is highly worthwhile.  Spending time discussing one particular storyline may be very useful:  The Monomyth.

The Monomyth is so prevalent in narrative across the world that it seems to be hard-wired into our brains, and it may well influence our personal and team behaviour in subtle and pernicious ways as an unconscious script.  It is also called the "Hero's Journey" and it comprises these phases:

1. A call to adventure, which the hero has to accept or decline
2. A road of trials, regarding which the hero succeeds or fails
3. Achieving the goal or "boon", which often results in important self-knowledge
4. A return to the ordinary world, again as to which the hero can succeed or fail
5. Applying the boon, in which what the hero has gained can be used to improve the world

For a project to run successfully, there are elements of the Monomyth script, whether they are consciously or unconsciously instigated, that we would rather minimise, but which would provide the excitement in a storyline - and possibly the meaning in a project. There are also elements which we would like to exaggerate.

— Philip Greenwood

Tags: Project, Leadership, Black, Book

Ensuring the emotional engagement of the project team

The engagement levels of the project can be assessed by watching their behaviour and emotional tone.  Symptomatically, a highly engaged project team:

• Will use a lot of their discretional time on the project;
• they will explore many facets of the project, rather than just the most obvious elements, and
• they will show strong interest in the developments in areas outside of their own immediate remit, to ensure that their work fits together with their peers. 

In a supportive culture, they will do these things automatically, rather than by direct instruction.  If the background culture of the organisation suppresses these behaviours, it may be necessary to "give permission" - though this should be done in subtle way, in order to avoid reactance.  Reactance occurs when an individual rebels against an attempt to influence them that has become to strong and overt; they react against being manipulated, for its own sake.

When we say "give permission", we don't mean saying "I give you permission to do such-and-such", we mean giving a subtle indication that these things are expected, normal and supported.

In our experience, engagement comes from three sources of motivation:

• Profit
• Experience
• Meaning

"Profit" is the most obvious of the motivators, but is also the most likely to create reactance.  "Profit" can be for the organisation or the individual, or both, and it is most powerful when it is for the individual, and most useful when aligned.  The absence of Profit (or Loss) from a project outcome can seriously jeopardise the project, as team members can extend the duration of the project through non-performance.

"Experience" is the amount or pleasure or pain derived from doing the project.  It can be both positive and negative too - if the team members have to travel for extended periods (when they don't like travel), or if they have to work in a dingy room in the basement, or their involvement draws recriminations from colleagues, their motivation levels will be lowered.  If the team has a comfortable environment and good facilities, respect for their involvement in the project, and the odd phase accomplishment party, then the positive experience will create motivation and team engagement.

"Meaning" is the hardest motivator to define and manage, because it can be very personal.  What one person finds meaningful, others may find abstract or pointless.  A great many people find the benefit of others to be meaningful, especially when it is their family.  This is a topic that worthy of debate and discussion by the team; it tends to layer on top of "Profit" and "Experience", and the discussion can create tremendous team alignment and engagement.

— Philip Greenwood

Tags: Project, Leadership, Black, Book

Ensuring the emotional engagement of the project team

The engagement levels of the project can be assessed by watching their behaviour and emotional tone.  Symptomatically, a highly engaged project team:

• Will use a lot of their discretional time on the project;
• they will explore many facets of the project, rather than just the most obvious elements, and
• they will show strong interest in the developments in areas outside of their own immediate remit, to ensure that their work fits together with their peers. 

In a supportive culture, they will do these things automatically, rather than by direct instruction.  If the background culture of the organisation suppresses these behaviours, it may be necessary to "give permission" - though this should be done in subtle way, in order to avoid reactance.  Reactance occurs when an individual rebels against an attempt to influence them that has become to strong and overt; they react against being manipulated, for its own sake.

When we say "give permission", we don't mean saying "I give you permission to do such-and-such", we mean giving a subtle indication that these things are expected, normal and supported.

In our experience, engagement comes from three sources of motivation:

• Profit
• Experience
• Meaning

"Profit" is the most obvious of the motivators, but is also the most likely to create reactance.  "Profit" can be for the organisation or the individual, or both, and it is most powerful when it is for the individual, and most useful when aligned.  The absence of Profit (or Loss) from a project outcome can seriously jeopardise the project, as team members can extend the duration of the project through non-performance.

"Experience" is the amount or pleasure or pain derived from doing the project.  It can be both positive and negative too - if the team members have to travel for extended periods (when they don't like travel), or if they have to work in a dingy room in the basement, or their involvement draws recriminations from colleagues, their motivation levels will be lowered.  If the team has a comfortable environment and good facilities, respect for their involvement in the project, and the odd phase accomplishment party, then the positive experience will create motivation and team engagement.

"Meaning" is the hardest motivator to define and manage, because it can be very personal.  What one person finds meaningful, others may find abstract or pointless.  A great many people find the benefit of others to be meaningful, especially when it is their family.  This is a topic that worthy of debate and discussion by the team; it tends to layer on top of "Profit" and "Experience", and the discussion can create tremendous team alignment and engagement.

— Philip Greenwood

Tags: Project, Leadership, Black, Book

Project Leadership Introduction

What is the difference between a corporate project that is successful and a project that isn't?  Why do so many projects deliver mediocre results, and others implode in a maelstrom of recriminations?  Our research shows the answer is that some projects are led effectively - the successful ones - but most aren't led at all!  And the difference between the mediocre and a failure is that a significant risk manifested on what would otherwise have been a mediocre project - so if your project is just running along, you are at risk.

We often see projects being set up by senior executives - we'll call them Project Sponsors - and then handed over to less senior executives (who become de-facto Project Managers), who are often drafted from outside the organisation.  The Project Sponsor wants the outcome, is willing to deploy resources to achieving it, and to clear road-blocks for it, but they don't want to commit a lot of time to it - and given that projects are risky, they'd rather be able to distance themselves from the results in case of failure.

Typically the Project Manager gathers a team and then reaches for the tried-and-tested toolset of project management - methodologies, project plans, issue registers, work breakdown structures, reporting, team meetings - quite appropriately, they manage the project, because project management is necessary, and it consumes all their time and attention.  But project management is not sufficient!  Who is leading the project?  And what does it mean to lead a project?

In some organisations there is a Project Leader role defined in a project team.  The Project Leader is typically drawn from the business, and is a key, senior, customer to the deliverables of the project.  This is a step forward, since it shows commitment and demonstrates that the business backs the project from the outset.  However, as the business customer, the Project Leader typically has a full plate running the existing operations - the very operations that need improving!  Furthermore, they are operations oriented people, rather than project oriented people, and while the fields are related, they are also distinct.

Project Leadership is a joint activity, shared between the Project Sponsor and the Project Manager, and the Project Leader (if there is one). But since they are all short of time and focus, we recommend that their leadership is facilitated by a Project Advocate, an expert on conducting projects. The Project Advocate's varied role includes:

1. Ensuring the emotional engagement of the project team.
   
2. Ensuring that the team is aligned to the scope (and scale) of the project.
   
3. Ensuring that the project complexity has been properly assessed, and acted upon.
   
4. Ensuring that an appropriate methodology and approach has been selected for the project and accepted by the team.
   
5. Supporting the investigation and use of specialist tools for the project work.
   
6. Ensuring that the project team structure and scale is appropriate.
   
7. Ensuring that the project's culture is set with high levels of performance expectations.
   
8. Ensuring that all elements of decision quality are properly implemented.
   
9. Ensuring that the project's external communications reflect the right content and tone to the extended stakeholder group at all times, and are congruent with the team's perspective.
   
10. Ensuring that the project is supported outside of the immediate sponsor group.
    Ensuring that the project fits within the organisational programme.

All of these items deal with the project as a human undertaking; they address issues of motivation, engagement, and the impact of cognitive biases (errors in thinking and behaviour that humans make on a systematic basis).

Project leadership is full of paradox:  For instance, you have to be unshakeably confident in your team's ability to deliver, at the same time as demanding the scrutiny of risk factors.  You have to use the full artillery of influence tools to communicate, at the same time as demanding