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

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

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

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