Falling (back) in Love with the Future

I don’t know when I lost it, but I think I lost my way.  Somehow I lost my love of the future.  I became content to just be neophilic – to love the new.  If I was to put a date on it, I would say that some time in 2001, I stopped thinking about wonderful, possible, futures.

I was reading this free e-book: Life…what a concept!!!  Here’s the recipe:  Get a group of big-brained scientists who work at the leading edge of their diverse but related fields, put them on a farm retreat for a couple of days, give them license to speculate about the future, and publish the conversation.  It’s fascinating (and sometimes challenging) reading, and as I was reading it I realised I’d found my optimism again...welcome, old friend.

It’s published by Edge, and there’s much more on thier site to stimulate the grey matter.  Enjoy!

— Philip Greenwood

 

 

Tags: Life, Optimism, Future

Falling (back) in Love with the Future

I don’t know when I lost it, but I think I lost my way.  Somehow I lost my love of the future.  I became content to just be neophilic – to love the new.  If I was to put a date on it, I would say that some time in 2001, I stopped thinking about wonderful, possible, futures.

I was reading this free e-book: Life…what a concept!!!  Here’s the recipe:  Get a group of big-brained scientists who work at the leading edge of their diverse but related fields, put them on a farm retreat for a couple of days, give them license to speculate about the future, and publish the conversation.  It’s fascinating (and sometimes challenging) reading, and as I was reading it I realised I’d found my optimism again...welcome, old friend.

It’s published by Edge, and there’s much more on thier site to stimulate the grey matter.  Enjoy!

— Philip Greenwood

 

 

Tags: Life, Optimism, Future

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

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

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

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 that decisions are based exclusively on facts.  You have to behave in a completely straight-forward way, at the same time as being acutely aware of organisational politics. You have to nurture the culture of the team…

— 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 that decisions are based exclusively on facts.  You have to behave in a completely straight-forward way, at the same time as being acutely aware of organisational politics. You have to nurture the culture of the team…

— Philip Greenwood

Tags: Project, Leadership, Black, Book

Flo Radio Part 2 - The Real Deal

A while ago I published a blog piece on the use of sound in the office environment to enhance productivity - and a link to a Pandora radio station I created called Flo Radio.  I know quite a few people now listen to the station, and I’ll keep on refining it because…I like it .  But I’m an interested amateur where environmental sound is involved…

Yesterday at the London Ecademy BlackStars networking day, Julian Treasure gave me a review copy of his book “Sound Business”.  I first met Julian last week; he’s the chairman of The Sound Agency, and we had a long discussion about obscure ‘80s and ‘90s music.  I read his book overnight last night, and Julian is the real deal.

The book is packed with insights about how we perceive sound, how we relate to sound and how we can use it effectively to enhance performance, revenues, quality and workplace mood. 

The book comes with a CD with examples – including a set of loop tracks for working and relaxation.  Try them in your home office – try them with your work teams.  Put them on low in your meetings – notice how the mood changes.

— Philip Greenwood

P.S. The CD content is for personal use only – you’ll need to contact the Sound Agency to discuss commercial applications.

Tags: Environmental, Environmental+Sound, Sound, Music, Birdcall, Effectiveness, Efficiency

Flo Radio Part 2 - The Real Deal

A while ago I published a blog piece on the use of sound in the office environment to enhance productivity - and a link to a Pandora radio station I created called Flo Radio.  I know quite a few people now listen to the station, and I’ll keep on refining it because…I like it .  But I’m an interested amateur where environmental sound is involved…

Yesterday at the London Ecademy BlackStars networking day, Julian Treasure gave me a review copy of his book “Sound Business”.  I first met Julian last week; he’s the chairman of The Sound Agency, and we had a long discussion about obscure ‘80s and ‘90s music.  I read his book overnight last night, and Julian is the real deal.

The book is packed with insights about how we perceive sound, how we relate to sound and how we can use it effectively to enhance performance, revenues, quality and workplace mood. 

The book comes with a CD with examples – including a set of loop tracks for working and relaxation.  Try them in your home office – try them with your work teams.  Put them on low in your meetings – notice how the mood changes.

— Philip Greenwood

P.S. The CD content is for personal use only – you’ll need to contact the Sound Agency to discuss commercial applications.

Tags: Environmental, Environmental+Sound, Sound, Music, Birdcall, Effectiveness, Efficiency

The Big Idea 2007

You can be happy at work.

(Just in case you haven’t heard.)

Unfortunately it’s not my idea, but it is being popularized by Alexander Kjerulf, who calls himself the Chief Happiness Officer.

Mr Kjerulf has written a book on the subject, called “Happy Hour is 9 to 5: How To Love Your Job, Love Your Life and Kick Butt at Work”, and also “The Happy at Work Manifesto” (free down load).

Apart from the fact that I agree with him, I’d like to point out ‘policy’ 11:  “I do my best work when I’m happy – When I’m happy I’m engaged, motivated, committed, more creative, less risk-averse, more service-minded and more productive”.  Does this sound like something you want for your team?

Great!  But not so fast, slick.  Here’s another recent book:  “Stumbling Upon Happiness” by Daniel Gilbert – an extraordinarily well informed study of how we deceive ourselves about happiness.  My three line synopsis:

1) We’re not very good at remembering what made us happy, so

2) We’re not very good at predicting what will make us happy, and

3) We often pretend we were happy when we weren’t because of societal norms.

So you’re not going to get much insight about nurturing happiness from your team’s answers to your questions about happiness.  But, according to the Hawthrone Effect, the act of asking may just inspire them to be more engaged, motivated, committed, more creative, less risk-averse and more service minded.

Sound familiar?  It turns out that the Big Idea 2007 has its roots in the Big Idea 1932.

— Philip Greenwood

wikitags : [[wiki:beaufortes:happiness]]

Tags: Hawthorne+Effect, Happiness

The Big Idea 2007

You can be happy at work.

(Just in case you haven’t heard.)

Unfortunately it’s not my idea, but it is being popularized by Alexander Kjerulf, who calls himself the Chief Happiness Officer.

Mr Kjerulf has written a book on the subject, called “Happy Hour is 9 to 5: How To Love Your Job, Love Your Life and Kick Butt at Work”, and also “The Happy at Work Manifesto” (free down load).

Apart from the fact that I agree with him, I’d like to point out ‘policy’ 11:  “I do my best work when I’m happy – When I’m happy I’m engaged, motivated, committed, more creative, less risk-averse, more service-minded and more productive”.  Does this sound like something you want for your team?

Great!  But not so fast, slick.  Here’s another recent book:  “Stumbling Upon Happiness” by Daniel Gilbert – an extraordinarily well informed study of how we deceive ourselves about happiness.  My three line synopsis:

1) We’re not very good at remembering what made us happy, so

2) We’re not very good at predicting what will make us happy, and

3) We often pretend we were happy when we weren’t because of societal norms.

So you’re not going to get much insight about nurturing happiness from your team’s answers to your questions about happiness.  But, according to the Hawthrone Effect, the act of asking may just inspire them to be more engaged, motivated, committed, more creative, less risk-averse and more service minded.

Sound familiar?  It turns out that the Big Idea 2007 has its roots in the Big Idea 1932.

— Philip Greenwood

wikitags : [[wiki:beaufortes:happiness]]

Tags: Hawthorne+Effect, Happiness

Power Tips & Strategies for Mind Mapping Software

I seem to be blogging on mind map subjects a lot at the moment – and perhaps you’re asking “what has all this got to do with Project Leadership?”

Power Tips & Strategies for Mind Mapping Software

I seem to be blogging on mind map subjects a lot at the moment – and perhaps you’re asking “what has all this got to do with Project Leadership?”

Why Project Leadership Books Suck!

Seeking inspiration for this blog, I’ve been re-reading all the books in my library on Project Leadership, Project Management and Leadership.  I’ve come to a few startling conclusions:

• There are surprisingly few books specifically on the subject of Project Leadership.  I find this odd because Project Leadership is a practical application of leadership.  Perhaps it’s easier to write about leadership in an abstract way than deal with the practicalities?
• There’s even less content than you might expect in those books on Project Leadership that do exist – a lot of duplication, and a lot that is impractical. Specifically:
• There’s an awful lot of writing about character types. Although it’s interesting, in the real world it’s an irrelevant distraction. You never get the choice of your own behavioural inclinations, and you rarely get enough choice of team members to select on this basis. (Caveat for clarity: You always get the choice of your own behaviour and any suggestion that you don’t is sheer manipulation!)
• None of the books talk about leadership from the perspective of enhancing team behaviours and performance.
• Their treatment of how to deal with organisational politics is feather-weight!
• None of the authors on Project Leadership have been prepared to level criticism at traditional Project Management.  The strongest criticism I’ve found is that it is necessary, but not sufficient.

My main conclusion is that you can’t learn Project Leadership from any of these books!  It’s like trying to learn to swim by reading about dolphin behaviour and hydrodynamics.  Maybe we need to start writing!

Perhaps, dear reader, you can tell me: What do you think needs to be included in an effective Project Leadership Development tool?  What form should it take?

— Philip Greenwood

Tags:  Project, Project+leadership, project+management, book+review, Leadership, Management, team, teamwork, teaming, team+behaviour, team+behavior

How Rational Are We?

Many valuable project team behaviours have, at their core, a requirement to accept ambiguity for extended periods. For instance, a project leader must simultaneously reconcile an unshakable confidence that the project will succeed with the recognition that their team, being only human, are flawed in their beliefs, research techniques and decision making processes.