Following on from the article outlining my five Project Action Principles, this article expands the third Principle:Use vivid and graphic models for all project concepts, and constantly validate and update those models. Invest the time to share and align these models with project participants. Constantly refer to the models to embed them into everyone’s planning and thinking, forming a resilient master-plan for project outcomes.
Also see “Additional Resources” at the end of this article for detailed strategies and techniques.
What is the secret to ‘herding cats’?
One of the biggest challenges to successful project delivery is aligning the actions and decisions of our extended project team to the end goals.
The difficulty in getting people aligned and delivering to a common goal is often emphasised by the phrase “herding cats”. This is a reference to the impossibility of getting a group of cats to do the same thing at the same time, as cats are independent, mobile and easily-distracted.
A lot of project management articles offer you the secret for ‘herding cats’.
But the secret is not to herd the cats!
The secret is to get all the cats to want to work in the same way at the same time.
How do you do that? By building, verifying and reinforcing shared mental models.
What are shared mental models?
Firstly, “models” are theories or generalisations of the real-world that are simplified versions of a concept, phenomenon, relationship, structure, system, or an aspect of the real world. .
“Mental models” are:“the simplified, highly personalised representations, assumptions and ideologies that we all carry in our heads, which make up our own particular version of reality” (Chris Harris 2003)
And with this, “mental models” enable individuals to:“make inferences and predictions, to understand phenomena, to decide what actions to take, to control its execution, and above all to experience events by proxy” (Wikipedia)
If individuals have “shared mental models”, then they will tend to make decisions and respond in similar ways.
The power of shared mental models
You are probably already aware that your brain is an amazing pattern-matching engine that operates continually in the conscious and subconscious mind. These engines help subconsciously filter all the information we are overloaded with on a daily basis so that our conscious mind can cope without being overwhelmed. For the most part, we don’t notice this happening in the background.
Our mental models help the filters look for specific things. An example, if you want to buy a Red Mercedes-Benz of a particular model. As you think about this car, you use an existing (or create a new) mental model for that car. What happens is that you will start noticing this particular car everywhere.
So “herding cats” becomes achievable, if you create common models in the cats’ minds that serve the project (e.g. goals, standards of behaviour, processes, definitions of quality and so forth). Once these are shared in the conscious and sub-conscious minds of the extended project team, the extended project team will converge its behaviour.
When used correctly, the mental models of individual team members (when common across the team) provide a resilient and powerful framework that facilitates aligned behaviour. Mental Models provide a common interpretation and prioritisation scheme.
On the other hand, dissonance or disagreement in the mental models of the team is a huge blocker to aligned behaviour.
Verification of mental models
Given that the success of your project is dependent on the models that you instil, it is obviously critical that you set up them correctly.
As the models are introduced and reinforced in the project team, it is critical that the project manager and the team members (in the ideal situation) constantly seek opportunities to test that the models are aligned.
Fortunately, common learning theory comes to our aide here because the same processes that are used for teaching new skills can be used to introduce and reinforce mental models, which includes a verification process.
The primary emphasis of verification is to ensure that the models are built into every process of the project execution and used in every interaction. This way the models constantly reinforced and the project manager has the opportunity to test whether the participating team members are still aligned to the model.
Representations of models
Obviously we’ve been talking about mental models, but we don’t yet do Extra-Sensory Perception ESP or mind-reading very well. As part of the reinforcement process, you need representations of the desired models in actual real-word artefacts like documents, presentations, videos and so forth.
In order to make your models easily understood and easy to verify, we again need to take into account of well-researched information theories about the human brain.
Based on the ample research available, the basics include considering your target audience, the message that you want to convey, and structuring the models in multiple ways.
Research suggest that we understand information in the following order:
- Written text
Therefore as far as possible, you should construct your model representations in graphical form, such as diagrams, charts, process flows, sketches, and even cartoons.
But also make sure that these models (at least the most critical ones) are created and repeated in multiple forms.
And don’t fall into the Project Manager’s habit of over-working or over-engineering the model representation: its 80/20 optimisation time again. You need to capture the most important aspects of the model in compelling and repeatable formats, not every single nitty-gritty detail, where you lose the wood in the trees.
Using models in your projects
Models can be created to represent every aspect of the project. The overall goal is to “modelise” every stage of the project and every discipline (i.e. business, technical, and operational).
Once established, models are both durable and resilient because they act as the unconscious guide to team behaviour.
Here are some examples:
- Customer Value Proposition: of course the key to the project’s success. It can be represented in many ways, e.g. “Lean Business Canvas”, or a schematic of a typical use case, or the Superset venn diagram.
- Solution Context Diagram is the most useful project model and relates to the entire solution. It simply defines the “as is” version and the “to be” version of the project.
- Organisation chart or a Stakeholder Matrix is a model of the organisational relationships and accountabilities.
- Project Schedule is a model of action to be done and completed over time.
- Financial Budget is a model of financial resources allocated to different areas, activities, and timings.
Each model representation needs to be as simple as possible but provide the right amount of information for the task to be completed and understood. The diagrams can be dense with information, but not details.
Don’t be restricted to “standard” views of the world. For example, there are many different ways to represent a schedule than using a Gantt chart. A representation of the model that works with your team is the best representation,
As project manager, you need to facilitate the use of models at every stage of the process, and with every interaction. As I mentioned in <link>Article about Project Action Principle 1</link>, every interaction needs a model to help facilitate an outcome.
If you initiate the interaction, you should make the model visible when you are talking about a topic. When others want to talk to you about something, you need to provide, or ask for, a model that will help.
If there isn’t a model available, either sketch one on a piece of paper or whiteboard.
Pick some of your most powerful models (e.g. the Customer Value Proposition or the Solution Context Diagram) and have them enlarged and printed in A1 or A0. Post them on the walls
You should consider opportunities to create video displays.
The mental models of individual team members provide a resilient and powerful framework to forge a shared understanding of their place and role to the end goal.
As a project manager, you need to decide what you prefer: team members who automatically and unconsciously adapt to remove blockages or they raised those blockages mechanically as issues to be resolved through a project processes. Or even worse, their assumptions are never challenged and unknowingly proceed down incorrect pathways until costly mistakes are made.
The individualism and experience of each team member can add value to the overall project, but how they interact to develop the shared mental models will ultimately affect project success.
Failure to recognise this and you will be forever explicitly dealing with the project entropy as consequences.