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

Guarantee Project Success 2

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

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

I think this is powerful for several reasons:

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

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

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

— Philip Greenwood

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

Guarantee Project Success

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

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

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

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

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

— Philip Greenwood

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

Guarantee Project Success

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

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

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

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

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

— Philip Greenwood

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

Reductio Ad Absurdum?

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

Team Decision Making: There's No Good System!

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

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

Team Decision Making: There's No Good System!

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

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