This month’s Guest Blogger is Alexandra Chapman of Totally Optimized Projects. She’ll be exploring different ways of looking at your projects to optimize the outcomes and she kicks off with a piece that looks at project mental models.
We shall start our journey to enlightenment with a fable – one quite well known.
The old goldfish meandering around the goldfish bowl passes the two young goldfish. “Morning all,” he says. “How’s the water?” The young goldfish flap a greeting and then swim on. After a few moments, one turns to the other and asks, “What’s water?”
It is a lovely metaphor which illuminates how something becomes so pervasive that it ceases to be seen, and yet it has such enormous influence.
“But”, I hear you ask, “what has this got to do with projects?” The water we don’t see relates to our mental models of what projects are. And these mental models greatly influence how we conduct projects and thus the results we achieve.
When I started my career in banking IT in the late ‘70s, it was the era before project management was adopted in business as the formalised discipline that it is today. In that time, if you wanted the new-fangled Accounts Payable package installed, management hiked someone out of Accounts area and said, “Go do it”. I remember well when few used project management methods and concepts. The plan was usually a long, complicated to-do list, and perhaps a hand-drawn Gantt Chart if we were sophisticated. Microsoft Project was not even a concept. When we finally managed to debug the Accounts Payable software package so that it worked, we delivered the project over-time and over-budget.
It was during this era, that formal project methods and disciplines were gradually adopted – rightly so – to improve the management processes for projects. The changes aimed to give certainty to management on project activities and status. That evolution continues today with Agile methods.
We adopted the methods and approaches from the construction & engineering industries where they were developed. We applied them to new types of projects – IT software projects, organisational transformation projects, strategy-driven business initiatives, et al., without being conscious that we were also adopting all the mental models of “what is a project” that underpinned these methods.
The problem is, while these project mental models work OK when building a bridge or a road, a house or multistorey office building, they don’t work well for other projects which have different characteristics. The mental models that underpin project methodologies work well for construction projects only because construction projects have a set of characteristics, which are a particular subset of those in the broader project domain.
The relationship of construction projects to software/strategy execution projects is a bit like that of Newtonian Mechanics to Quantum Mechanics. That is, when you are moving below the speed of light, Newtonian Mechanics are a reasonable proxy for Quantum, but not when you approach it.
In the same way, construction project metal models cause enormous problems when applied in the broader domain, because of increased complexity, uncertainty and degrees of freedom. If we wish to improve the performance of projects, we need to change some of our mental models and how we implement these models into project methods and discipline. But first, we have to understand what these mental models are.
We have to examine the water in which we swim.
Let me start by harnessing the collective mind of the internet to pose the question “What is a project”. There are plenty of well-accepted definitions – a simple search on the phrase will show these. Let’s try answering the question in a slightly different way.
Say you are Chief Customer Officer. One of your operational areas is a large support group for a complex software product. Each year as the months progress, the way customers are greeted also changes. The usual greeting of “Good morning, how can I help” changes in late November, to “Merry Christmas”. Staff get a screen pop-up to remind them of the change. It’s all very straight forward and implementing it is very much part of business-as-usual operations.
Your team have done some analysis, that shows a particularly complicated issue generates a large percentage of the calls. They identified that changing the sequence in which the customer service operators ask diagnostic questions can halve the time taken to resolve the customer’s problem. But many customers lack the knowledge to answer the questions correctly so CSO’s will need to share a link with the customers so they can check the customer’s hardware directly. That will require new software.
At what point does implementing some new software and training the CSOs cease to be part of business-as-usual operations and become a project? It will likely be determined by such questions as:
- How many staff need to be trained – 5 or 500?
- How complex is the software?
- How long does the training take?
- Does the changeover need to be “big bang” or can it be implemented incrementally?
- How much will it cost?
- Do we need to get customer’s agreement?
- In that case, do the legal people have to get involved?
- Etc etc
In our example above, depending on the answers to the questions, the “New Diagnostic” could well be a change undertaken as part of normal day-to-day activities. But if the scale, or complexity, or the unknowns, or the time needed, or resources and funding required, increase beyond a certain point, then perhaps this change will no longer fit within the normal operational tempo, and we decide to tackle it as a “project”.
Once we are in the Project domain
Mental models become critical to how we go about the project:
- When does the project finish?
- When does the project start?
- How do we discover what we need to do?
- How do we break up the work into deliverable chunks?
- What sequence do we undertake the tasks?
- How do we schedule them?
And finally, and most importantly, how do we measure success?
In the next post, we will discuss in detail about construction projects and the mental models that have come from these. We’ll compare construction projects to those in the business and strategy domain to see what works. We will discuss “Turn-Key” as the model for when a project ends, and learn why it does not work well for most projects.
Is Co-founder and co-creator at Totally Optimized Projects. Her mission is “to leave a legacy of tools for clear thinking and for solving complex problems, and to see TOP adopted as a global movement.”
Early in her career in the 1980s, she was an IT Projects guru implementing enormous banking software packages for Australian and UK banks. Profoundly frustrated at the way the IT-centric way projects were undertaken, she switched to strategy execution in 1988 after completing an MBA at Cranfield School of Management.
In 2007, she sketched the first version of the Value Equation™ diagram on a whiteboard.