The discipline of shared vision focuses on what thoughts and concepts managers share with their teams. Here's a look at two major perspectives on the concept of shared vision.
The discipline of shared vision, as outlined Peter Senge’s book The Fifth Discipline, moves us into the realm of group process. With shared vision it no longer matters what we think but what thoughts and concepts we share with the team. In other words, shared vision is the point where we actually harness the horses so that we can get some work done.
Previous articles in this series
The first four articles in our exploration of Peter Senge's core disciplines discussed personal mastery, the concept of mental models, and systems thinking:
"Develop 'personal mastery' for effective project management"
"How to understand the bias of mental models"
“Understanding your mental models can help sharpen PM skills”
"Adopt systems thinking strategy to boost project success"
In this article, I’d like to explore two different perspectives on shared vision. The first is the explicit concept of shared vision that focuses on capturing, communicating, and reconciling our goals and our methods for achieving those goals. The second perspective is that all organizations have an implicitly shared vision, which manifests itself as what is most often referred to as the corporate culture. In addition, this implicit shared vision influences, at a significant level, how we manage our projects.
Beginning with the concept of explicitly shared vision, in order to create and effectively benefit from a shared vision, the following strategies are required:
- The ability to create or elicit the initial vision
- The ability to translate that vision into the physical activities required to achieve it (using systems thinking)
- The ability to articulate and sell this vision to others as either the right or best way to reach the goal
- The ability to hold true to the essence of the vision when reality changes the plans
Creating the initial vision
If the initial vision isn’t completely prepackaged in the head of the project sponsor, there are two ways to create it. The first and preferred alternative is by asking the right questions at the first meeting of your steering committee—or at what I often call my first Joint Application Development (JAD) session. The second alternative, for nimble project managers operating in stealth mode, would be to have a series of meetings with the appropriate individuals and elicit the information by practicing a technique called “long earlobes.”
This initial meeting with the stakeholders is intended to accomplish the following four items:
- Get answers to the Five Whys.
- Establish the boundaries of the project (what is in and what is out).
- Establish metrics for measuring success.
- Produce a one- or two-page scope or charter document.
If you are in a stealth project management environment, you will need to accomplish this by asking the right questions of your sponsor. Remember that subtlety is important in a stealth environment, and you will need to ask the Five Whys with an understanding that you might be rebuffed at any time. Your fallback position will be to present the questions as a way of defining risk.
When I started my career, my job was to talk to engineers and ask them all sorts of seemingly nosy questions about what they were doing, how long it was going to take, and how they could be sure it would all work when they were finished. As a young woman with no technical background, I was told by my boss to be prepared for a high noise-to-signal ratio in my initial interviews and the trick I needed to learn was what he called “long earlobes.” Back in the late 70s I didn’t know that what he was really advocating was a combination of active listening and reading body language. I also didn’t understand that it’s basic human nature to want to have others understand us and that if we give people enough time and safety they’ll always reveal their underlying mental models. Given these facts of human nature, even in stealth mode you should be able to elicit a solid vision statement from your stakeholders.
Translating the vision
This is the easy part of being a nimble project manager. We know what we’re supposed to do, and we can now gather our team around us and figure out the specifics of getting it done. At this stage we view the problem with our systems thinking hat on. We need to double-check that we have the problem scoped correctly, that we are clear about the way things are connected in feedback loops, and that we’re not falling victim to the archetypal mistakes of shifting the burden or exceeding the limits of growth. We also need to make sure that we align our project approach with the prevailing implicit vision of the company culture (which we’ll discuss later in this article).
Selling the vision
This is one area where many project managers stumble. We get too caught up in the day-to-day management of the details of our project and don’t spend enough time selling to our constituents. On small IT projects this may not be a fatal mistake; as project size increases, this one factor alone can determine the personal success of the project manager. I don’t think there’s a lot of need to stress the mechanics of selling the project: Status meetings, e-mails to stakeholders, and a well-designed and informative project Web site all are things that will help.
What is probably more important to discuss at this point is how to deal with the guilt of feeling as if you’re not doing anything constructive for your project if you’re out pressing the flesh. Most nimble project managers come up through the ranks being very visible and very involved with their team. They concentrate on selling and aligning the vision downward and sideways. The problem is that as the importance and visibility of the project increase, the selling needs to be focused upward and sideways, and that means that there is less time to be involved in the details.
Holding true to the vision
From the perspective of the nimble project manager, the art of holding true to the vision comes down to the decisions that you make when you’ve just suffered a sneak attack from Mr. Murphy. The average nimble project is designed to take the crises of the day completely in stride, but what happens when something goes seriously wrong? Even if you have a well-articulated risk plan, you are faced with the fact that you are absolutely going to have to move one of the three legs of the triple constraint and somebody is going to blame you for the fact that things have changed.
Inexperienced project managers usually try to ignore the situation, or they ask for more time and more money to cover them while they scramble to recover. The nimble project manager calls an immediate time out and is willing to objectively look at the situation by asking the following questions:
- Is the goal of the project still important and aligned to company strategy?
- If we were starting this project today, would we be developing this product?
- What are the business implications of the project being late?
- What are the business implications of the project costing more?
- Can we reduce scope and still meet our success criteria?
The key here is that the project is based on the vision of delivering a product that meets or aligns with certain goals. It is the vision of the product that is of primary importance and not the vision of the project. The nimble project manager understands this and is therefore always able to entertain the notion that there could come a time when the only right answer is to cancel the project.
Up to this point we have reviewed in detail the four aspects of building and maintaining an explicit shared vision on a project. The next element of shared vision we need to examine is one that will influence everything we do but that is rarely articulated.
Implicit shared vision
Back in the 80s I was first exposed to the concept of company cultures through the work of Kennedy and Deal. I had just moved from a culture that was the epitome of “tough guy macho” and I was struggling to adjust to a culture that defined the “work hard/play hard” ethos.
Most of the work that has been done on corporate cultures centered on matching culture to business objectives in order for the company to thrive in its marketplace. From the perspective of the nimble project manager, our only goal is to establish what the culture is and then determine how we can best manage our projects without violating any unwritten rules.
In Figure A, I’ve included three of the most common culture models as well as what I call the nimble PM culture model. All of these models vary slightly based on specific points they’re trying to make, but for the most part they’re remarkably similar (though only Kennedy and Deal acknowledge a risk-oriented culture).
The nimble PM model says cultures are either “I-centric" or “we-centric." In the I-centric culture, adopting the archetype of project manager as benevolent dictator works perfectly with the team. They’re programmed to accept it, and most of us are programmed to operate that way (at least if our earlier training was in a power-based culture). In a collaborative culture, the project manager’s job becomes that of obtaining consensus, and what power there is must be shared with some or all members of the team. At the furthest extreme of the we-based model you will find the concept of self-directed or leaderless teams.
The second component of corporate culture is the rule vs. achievement culture. The average nimble project manager should be able to operate quite well in any culture that aligns itself along the achievement axis. Nimble project management has as its primary mental model an achievement-based underpinning. The trick for the nimble project manager is how to survive and be successful in cultures that align with the rule-based axis.
In a company that is aligned with the power/rule quadrant, most project managers will find that they have almost no influence on how their project gets done. The team and the stakeholders will all be looking to do things first the way they’ve always been done and second the way the “power holder” says they should be done. In a collaborative/rule-based culture, the nimble project manager will be confronted with “meetingitis,” analysis paralysis, and lots of people saying that their opinions are not being taken into account.
We should take a short time-out here. If you’ve read the previous articles on mental models, my last statement should be an obvious example of where my own mental model of the world (which stresses flexibility of means and primacy of results) has caused me to present a situation in the negative rather than in neutral or positive terms. What we learn from practicing the disciplines of mental models and shared vision is an understanding that some of our biases are very deeply held. In fact, some of these biases define the very nature of our personality structure. As we said in our discussion on personal mastery, knowing that we have these biases doesn’t mean that we have to change. It simply means that we need to understand them well enough to be able to modify our behavior when required.
Managing a nimble project, then, in either of these two environments involves accepting the validity of the culture as an implicitly shared vision. It absolutely doesn’t matter that the project might take longer and cost more than you think it should. It doesn’t matter that you might have to fill out what you consider a few extra reams of unnecessary paperwork. If you accept that the culture is right, you are then free to see what latitude you might be allowed within it.
I’ve found that power/rule cultures often tolerate what I refer to as the loyal opposition. When IBM acquired the company I worked for, I quickly learned that while 95 percent of everyone followed the rules in IBM, outsiders were kept on board to do those things that were too risky and too crazy for the others to handle. From the perspective of the nimble project manager, it is critical at the outset of a project in this type of culture to be clear why you’ve been chosen to run it. If the answer is that it’s because management thinks you’re crazy enough to risk failure in order to do something impossible, then you should find that your executive sponsor will give you the explicit authority to break the rules (which usually means to conduct a low-ceremony, rapid-results project that flies under the radar of the rest of the company). If the answer is that the project is a mainline project and you’ve been assigned through luck of the draw, then minimal compliance and a respectful attitude should keep you enough on the right side of the culture to allow you build a slightly more nimble project team.
The absolutely hardest culture to be nimble in is the collaborative/rule-based culture. Forget any concept of quick and dirty or the cheapest price and the shortest time frame. In these cultures the journey is much more important than the destination. I once had a discussion with a client where we had a $35 million difference between doing the project their way and doing it on an accelerated basis. I simply couldn’t bring myself to understand that in their minds all those meetings and weeks of indecision were simply a cost of doing business. With the advantage of hindsight, I can safely offer the nimble project manager a few suggestions for surviving this type of culture:
- View your role as project manager as chief salesperson of the overall vision.
- Be visible and never be too busy with the project to sell the vision.
- Break the project into multiple sequential phases.
- Limit detailed planning to the current phase.
- Establish review committees and hold frequent meetings.
- Remember consensus rules.
Up to this point, we’ve explored the concept of both explicit and implicit shared vision. In the case of an explicitly shared vision, we’ve discussed how to articulate it, sell it, and maintain it. An implicitly shared vision (i.e., company culture), on the other hand, isn’t something we can shape or influence quite as easily. Before we leave the topic of shared vision, it is important to take another look at the entire concept of project management itself (as we did in the article on Mental Models). I can say with absolute certainty that we as a project management community do not share a single unified vision of what we should be doing as project managers, let alone how we should be doing it. For every e-mail I read from a project manager complaining that his organization is populated by hide-bound cretins who want the PM to waste precious time filling out paperwork, I can point to another e-mail from a project manager complaining that his organization is totally hostile to any sort of project management process at all and that even filling out a scope document would get pushed back.
What I hope I’ve been able to show in this article is that while any good project manager can articulate the project vision; the nimble project manager has developed the conscious ability to tailor that project vision into a language or context that can be accepted as congruent with the company’s implicitly shared vision.