Peter Senge’s book The Fifth Discipline identifies five core disciplines required of a learning organization: personal mastery, mental models, shared vision, team learning, and systems thinking. Senge’s disciplines provide an easy-to-use and robust conceptual framework for approaching every project.
In my last article, we looked at personal mastery. In this article, I'm going to discuss how the core discipline of mental models plays into the skills that define the nimble project manager.
At the turn of the 15th century, prevailing wisdom said the earth was flat and, if you sailed too far to the west, you’d fall off the face of the earth. For the average person of the era, there was nothing wrong with this assumption. Most people never journeyed more than 20 miles from their homes, so whether the earth was flat or round didn’t matter.
This assumption is a classic example of a mental model as described by Senge, who wrote that our mental models are "deeply ingrained assumptions, generalizations, or even pictures and images that influence how we understand the world and how we take action." For project managers, mental models influence the manner in which we choose to run our projects.
The mental models of project management
The first place to begin in any discussion of mental models is with a look at our mental model of project management itself. There is a deep-seated belief in the software community that much of the conventional wisdom surrounding project management today simply doesn’t apply to software projects. Standing on the sidelines, it appears that there are two camps holding down either side of our bell curve. On one side is the "Establishment" with a mental model of the world that states that things are innately orderly and, with good planning and tight controls, everything will go smoothly. On the other side are the "Murphyites" (as I call them), who have a mental model that states things are innately complex and chaotic and that planning beyond the basics is simply a waste of time since things are going to change anyway when Murphy's Law comes into play.
If we pick someone from each camp and give them a project to manage, it will quickly become apparent that they’re going to take different approaches right from the beginning. The Establishment project manger will spend as much time as necessary and humanly possible in defining every task and every possible risk. He or she will also develop a Gantt chart with thousands of line items; every resource will be assigned and leveled and then the schedule will be baselined. Our Murphyite PM, on the other hand, will have a simple list of deliverables in Excel, and resources will be assigned to tasks based on e-mail and phone calls.
If we now introduce a significant snag, we can also see where both of the mental models fail to flex (i.e., compensate) appropriately. Our Establishment project manager will quickly find that the multithousand-line Gantt chart and a project team that is looking for minute direction have become an iron cage. The overhead of change at this point becomes costly (redoing the multithousand-line Gantt chart), and it’s easier and more effective to just take the slip or add more people and try to make it up (ignoring the downsides of the mythical man month) than to try to rethink the game plan. On the surface, our Murphyite PM appears to be in better shape—after all, he just moves some things around to solve the problem. But, in truth, he’s now switched over to his preferred operating style of continuous crises management, and he's rapidly heading down the slope of continuous schedule slip.
Both these cases represent the extreme, but they happen so often that it's clear that these mental models heavily weight both ends of the spectrum. Senge bases much of his work in this area on the research of Dr. Chris Argyris, who contends that we all have two mental models in conjunction with any specific situation: our espoused model and our model-in-use. Essentially, a majority of project managers espouse the belief that the world is an orderly place, and if they were only capable of planning more thoroughly or controlling more strongly, their projects would succeed. When circumstances (like reality) prevent them from following their espoused model, they either muddle through as best they can and feel guilty about not doing it right, or they default to the other end of the spectrum and their model-in-use becomes crisis management.
I believe this phenomenon is at the heart of both the statistics on project failure (such as Standish Group’s landmark Chaos Report from 1995) and the current challenge to prevailing wisdom being made by software-centered project managers. So, if we abandon both the linear approach to project management and the chaotic approach, what assumptions would underpin our new mental model? From the perspective of the nimble project manager, the mental model of choice is the one that says things are messy around the edges, and the messiness is an inherent part of the system. The nimble project manager also incorporates into his or her mental model the basic premise that a complex adaptive system (i.e., our project) is very sensitive to initial conditions and that it’s vital to begin any project from an initial area of order.
If the term initial area of order sounds similar to the established perspective of "plan, plan, and plan some more," let me emphasize the dissimilarities. The established perspective focuses on working out the detailed actions that need to be taken to reach the destination where, as the new paradigm (or nimble) perspective emphasizes, you eliminate all obvious problems and acquire the flexible resources and tools necessary to deal with whatever unforeseen events arise. Another way of looking at these two models would be to say that the established model uses the front end of the project to define everything down to the level of pseudocode and then assumes that the actual development can be shipped to a third party, who then executes as instructed; the nimble perspective, on the other hand, spends the front end getting the right team of functional experts and talented developers together so that the real needs can be solved as they emerge.
The mental model of nimble project management
Nimble project management is based on the mental model that states all projects are nonlinear complex adaptive systems. As a result, the nimble project manager would approach a project making the following assumptions:
- It’s appropriate to invest the time upfront to understand the goal of the project without needing to plan every step along the way.
- Nothing makes up for, or replaces, good people—staffing is everything.
- It’s imperative to create a project structure that facilitates good communication—opportunities need to be communicated as well as risks.
- Nimbleness requires knowing when a situation needs to be controlled and when it needs time to evolve.
- All projects are unique in some way. Investing the time upfront to understand the uniqueness helps establish the initial area of order.
Flexing the model
Mental models are by nature conservative, even for the most nimble of us. In fact, this phenomenon is so strongly a part of us that we have jokes about it: "When the only tool you have is a hammer, every problem looks like a nail" and "A consultant is just a solution in search of a problem" are just two of the most common.
So if we all have mental models that create a bias in our thinking, what can we do about it, especially since rigid thinking and nimbleness don’t go together? We might consider adding one more attribute to our list that says: Nimbleness requires considering the impossible, the improbable, and the unlikely as a matter of course.
The second thing we can do is create a culture of creativity on our projects. Of everything I’ve learned over the years, this suggestion has probably been one of the most helpful. So, with that said, let’s get down to specifics:
- Get the project off to a good start. Traditionally, kickoff meetings have given us a forum for sharing the vision and creating a basis for future communication between extended team members; but a kickoff meeting can also offer the opportunity to establish creativity and out-of-the-box thinking as central tenets of the project. While every project manager will need to adjust this concept to his or her own style and comfort level, I would suggest replacing the “team building” exercises you might have considered with exercises in creativity. Michael Michalko’s book, Thinkertoys: A handbook of business creativity, Edward de Bono’s books on thinking, or any of Roger von Oech’s books on creativity can all offer suggestions on specific exercises.
- Incorporate time near the end of your JAD (joint application design) session to ask the “what if we’re wrong” question. There are techniques we’ll be discussing in the next part of this series that should help keep everyone’s mental models visible during the JAD session. But I’ve found that deliberately and consciously turning the problem on its head is well worth the time and effort. If you are tempted to cut this step as a purely intellectual exercise, I would recommend against it. In my experience, this exercise always results in identifying high-level risks you would have missed, even if it doesn’t cause you to substantively change your assumptions.
- There is another reason to incorporate this question into your JAD session. It also serves to give the loyal opposition legitimacy. While no project can afford to have team members who are trying to steer the project in conflicting directions, it is very valuable to create a situation where dissenters can be comfortable that their viewpoint has been heard and, if circumstances start to trend in their direction, that they have a forum for bringing it up (usually as a potential risk item).
- Make sure someone in the project management structure has time to listen to people. Creative ideas or contrarian ideas can be risky for the individual proposing them. Having guaranteed access to someone in a position of authority who will at least listen to them and give them a fair hearing keeps people incentivized to keep thinking.
There is an emerging paradigm of project management that is potentially much better suited for the reality of software-centric projects. Accepting this new mental model lets project managers change how we manage our projects (or, in many cases, heave a loud sigh of relief that we’ve been doing it right all along) and start adding a few new techniques to our strategy. The complexity comes from the fact that all mental models (even nimble ones) need to be examined and questioned on a routine basis.
In the next article in this series, we’ll continue this discussion by examining how to reconcile conflicting mental models and how to make sure that our own mental models don’t become stagnant.