In the book The Fifth Discipline, Peter Senge identifies five core disciplines required of a learning organization: personal mastery, shared vision, mental models, team learning, and systems thinking. From the perspective of the nimble project manager, a project environment is the ultimate learning organization—and Senge’s disciplines provide an easy-to-use and robust conceptual framework for approaching every project. Over the next few articles, I’m going to discuss how each of these core disciplines plays into the skills that define the nimble project manager.
Although no single discipline is more important than any other, one logical place to start exploring these ideas is with the concept of personal mastery. The word mastery derives from the Sanskrit word mah, meaning greater. Mah is also the root of the French word maitre, which means proficient or highly skilled. To the nimble project manager, the concept of personal mastery translates into a complex weave of self-knowledge, the cultivation and refinement of a wide number of skills, and the personal commitment to support a similar growth in others.
Conducting a personal SWOT review
Our starting point is self-knowledge. So it makes sense to begin with a SWOT review—an assessment of our strengths, weaknesses, current opportunities, and a determination of what situations in our life are bringing out the worst in us, both professionally and personally (threats). We’ve all done SWOT reviews on projects, but in this case, we’ll be turning the lens on ourselves.
Once you’ve done this (and I wouldn’t spend more than two hours doing it), the next step is to question why you’ve classified your strengths and weaknesses as you have. A couple of key questions arise: Who are you really? How valid is your determination of your strengths and weaknesses?
Who are you really?
A CEO I worked for many years ago helped distill the concept of personal mastery when he said to me, “You can try to get me to change my habits and my quirks, but it’s a waste of time trying to get me to change my character flaws.” We can all sand the rough edges and stop saying things that people find annoying, but we can’t fundamentally change who we are. From the perspective of the nimble project manager, this is a perfectly acceptable constraint. After all, one of the key components of nimbleness is an ability to maximize the return based on the real situation. Nimble project managers know that they’re not perfect, and the folks on their team aren’t perfect, but they also know that everyone is capable of effective contribution.
The ability to accept what is fixed and change what is mutable is one of the most important skills a nimble project manager has. It’s the basis of all risk management and the secret to issue management. It’s the fundamental understanding that allows the PM to appropriately staff the project team with the right people. So it only goes without saying that this ability to see things for what they are becomes especially profitable when turned toward oneself.
Evaluating strengths and weaknesses
So how do you tell the difference between a personality trait or a less-flattering character flaw and a simple weakness that can be fixed? A good place to start is with a personality profile. Myers-Briggs, social styles, and the enneagram all offer views of the personality factors that people present to the world.
The Myers-Briggs typology assigns a combination of four paired attributes to a person: Extrovert/Introvert, iNtuitive/Sensing, Thinking/Feeling, and Judging/Perceiving. The social styles model breaks people’s preferred approach to working with others into four styles: Driver, Expressive, Amiable, and Analytical. And the enneagram has a complex model of eight types with subpersonalities.
None of these models is the perfect answer to the questions of “Who am I?” and “What are my strengths and weaknesses?” But such models can provide some important insight into our innate comfort zones and where we may have to stretch occasionally to be successful.
An example from my own experience came from a class I taught several years ago. During one session, I explained the Myers-Briggs typology. A student came up to me later and said, “You’re a T, most of the people in the class are Ts, but I’m an F and you’re not speaking in my language. Too much head and not enough heart.” In the language of personal mastery, what I’d been told was that I had a strength called Thinking/iNtuition, which enabled me to translate amorphous “knowing” into clearly articulated words and concepts, but I had a blind spot that needed work: the ability to take that knowing and communicate to someone who was looking for something other than an intellectual discourse.
The project context
In the world of software and NPD project management, the nimble project manager is usually surrounded by INTs—Introverted, iNtuitive Thinkers. This shifts the communication difficulty I faced in my class to the dilemma of an Extrovert (which most nontechnical PMs are) communicating with an Introvert. If we assume for our purposes here that we are all Ts (Thinkers rather than Feelers), the best definition of an Extrovert is someone who needs external feedback to clarify his or her thoughts. An Introvert, on the other hand, takes in external data and clarifies by measuring it against his or her internal process.
In a project setting, this difference means that meetings are the perfect tool for Extroverts to work things out, and they can be a perfect forum for Introverts to convey their well-thought-out and well-reasoned ideas. The problem is that Introverts and Extroverts automatically have a different rhythm for the number of meetings they need and want and different goals for what should be accomplished in the meeting.
By understanding the difference between Extroverts and Introverts, the nimble project manager is freed from having to push a one-size-fits-all solution on the project team. Functional teams (usually a group of Extroverts) can schedule as many meetings as they want or need to think out loud, while the development team members can sit in their cubes, collaborating when they need to through Web-based discussion threads. Meetings where both groups need to be present (status meetings, etc.) can then be conducted with a middle-ground goal in mind. Less frequency or shorter durations and clearly defined agendas actually tend to keep both groups happy.
The key to this discussion is that a strength and what may appear to be a weakness can be flipsides of the same coin and can be maximized or minimized based on circumstances. A senior VP at an engineering and construction firm brought this message home to me one night at a meeting when he was advising project managers to make sure they included “a fuzzy thinker” on their staff to be successful. In Myers-Briggs language, that translated to the statement “Make sure that you have at least one NP (iNtuitive/Perceiving) on your staff instead of just all those SJs (Sensing/Judging) you normally have.”
Since software projects tend to have a plethora of NPs, it took me a minute to realize that his root advice was to staff at least one or more persons on the project to compensate for the blind spot that all teams naturally seem to have. In software projects, this often translates to making sure that there are QA people (often SJs) who are involved throughout the project and with sufficient status and inclusion to be able to offer their own unique perspective.
Assessing opportunities and threats
The second part of our personal SWOT analysis involves analyzing our opportunities and threats. In the case of the nimble project manager, an opportunity is defined as a working environment where success is possible. A threat is defined as a project where personal failure is probably inevitable. A current mythos circulating in our community suggests that a good PM can manage any type of project. For the nimble project manager, this statement is effectively false, even if it might be literally true in its most narrow construction.
For example, I’ve learned that I have the highest probability of success with rapid, mission-critical projects, where the desperation factor keeps the political and procedural game-playing at bay. I often end up coming in to turn around projects that are about to fail—or killing the ones that just won’t die. Other project managers I know are outstanding at three-year projects with incredibly complex plans and a team numbering in the hundreds. One of the key components in personal mastery is having the wisdom to recognize where we excel and having the strength of ego to understand that there are times when someone else really can do it better than we can.
The concept of personal mastery requires that we look at what we do well and maximize our opportunity to share those skills in the right circumstances. It also demands that we be honest about both our zones of rigidity (our fish-out-of-water circumstances) and our weaknesses, and that we avoid the one and develop compensatory techniques to mitigate the effects of the other.
It should be obvious to everyone that this discussion of personal mastery has completely avoided focusing on issues such as how to build a better risk plan or complete a more accurate schedule. Personal mastery does include the cultivation of top-notch skills. But the secret of developing those skills involves having the self-knowledge to identify the skills that will naturally make up the nimble PM toolkit and which skills need to be acquired or hired to compensate for blind spots.
Making it happen
Personal mastery isn’t something that’s achieved overnight. But by making the commitment to conduct a personal SWOT and investing the time to gain the language of self description (Myers-Briggs, social styles, enneagram)—as well as by relying on sound PM practices, such as keeping a project journal and doing personal project post-mortems—the required discipline to develop and maintain personal mastery can become second nature for any nimble project manager.