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.

About Us
Comments