The project manager’s perspective

Why does this matter? Because no two people have the same point of view. It’s impossible to of course. If we think of visually looking at something, you can get right next to someone and see things from almost their perspective but it’s not exactly the same. Their head would have to be displaced for you to see things from where they were. Yet, if we do just that, move their head and move your eyes to the exact spot they were in, it’s already a different time. Time counts too in a perspective. So if we can never see things exactly the way someone else sees them, how do we communicate effectively at all? We can allow for a perspective by declaring our point of view.

In the absence of realizing that everything we perceive comes from our own particular point of view and that our perspective is unique, people are left with saying “That’s the way it is” rather than “That’s the I see it”. Is this just semantics? It very definitely is not. If you say “That’s the way it is” then it allows for no other interpretations. You’ve declared that the universe is that way, there is no other and that’s the end of the discussion. If, however, you say “That’s the way I see it” you’ve made room for at least one other perspective. Someone can now say “I see it somewhat differently”. When this happens, you may be surprised. ‘How could someone interpret this differently?’ you may ask yourself. Your eyes suddenly open as you realize that perhaps there are yet other interpretations which you’ve not considered.

In the world of Project Management, being able to identify a perspective as a perspective is a critical skill. In any project, schedules and scope are often identified by the shortest of descriptions. Four or five words in a schedule may be all the description of scope that a task has. This isn’t any problem if everyone understands the same thing by those four or five words but that’s rarely common.

Much more likely is that everyone who reads those four or five words has interpreted them differently.

“Write process documentation” is a description I saw recently in a project in which we were involved.
· The new consultant read these three words and imagined a document that would be 2 or 3 pages in length. A title and sentence for each element of the process would be plenty, he figured. A total of 4 hours would be sufficient to the task, he thought.
· The project manager envisioned a document of 20 or 30 pages. A page per process would be required and a flow diagram of each process would headline each page. The document would have to go to internal review after one draft and then client review after a second. The work would take about 10 days.
· The client envisioned a manual of about 200 pages. Each process would be a chapter. The flow diagram would headline the chapter, there would be a brief synopsis and then the process would be described in a step-by-step fashion complete with screen shots using their own data. The client expected that this manual would be done naturally as the project evolved, with a new chapter added as each process was created. They saw a review period of 10 days as about right for reviewing the manual once completed.

Needless to say when the documentation was written, everyone was upset. When the project manager tried to describe what they had done, the client was shocked. That wasn’t “proper” documentation, the pm was told. The consultant too was upset. They’d figured the work they would have to do would be a short description. They’d been obliged to go back to each process and design a flow diagram and a lot more detail.

“Create a link from product A to product B” was a description we found in another project recently. Despite the documentation that the client had seen, and a demonstration that they’d attended they were shocked to find out that the link created between the two products needed to be triggered by an action by a user. ‘How could anyone call this a link if it wasn’t “automated”?’ they said. When it was pointed out that the client had both seen the link working and seen the feature description of this link, they explained that they’d assumed they weren’t seeing the whole picture because “of course” any link would be automated, wouldn’t it?

It’s about perspective. Everything we’ve ever experienced adjusts our perspective and if you don’t at least acknowledge that there’s no such thing as an unbiased observer, then what you’re most likely to encounter are problems with scope and problems with estimates.

Project managers hold a pivotal position in the success of the project. Regardless of the level of authority of a project manager, they are virtually always considered a facilitator for the communication between those will do the work, those who will consume what is created and those who will manage the people and the work. Communication skills are critical, of course. But in my opinion, an even more critical skill is being able to identify the point of view from each player in the puzzle. This is partly why Collaboration has been identified as such an important aspect of Enterprise Project Management.

So, how do you mitigate the risks of an inadequate appreciation of perspective? Start by working on your own perspective muscle. Learn to challenge your own “IS’isms”. When someone says “The way that it is, is…” challenge the assertion, even if it’s just to yourself. If you catch yourself saying “That’s the way it is,” work on catching yourself. A book that helped me in this area is from Edward de Bono and is called the 6 Thinking Hats. It’s a classic and is easy to find. The book deals with how to generate creativity and perhaps that’s a good skill for project managers also.

If you’re looking for more practical techniques to avoid the kinds of examples we see above, take a page from the Defense and Aerospace folks. Project Managers who works in those environments have had requirements to include two documents that are essential parts of any mega-project bid. They are the SOW (Statement of Work) and the BOE (Basis of Estimate). They’re the bible for anyone doing project work in these environments because they are a requirement and they identify in much more explicit detail what is meant by the short scope description that we’d normally see in a task name.

In the end, if you’re capable of at least identifying your own perspective when you describe something to someone else and acknowledging that they may have their own perspective, you’ll already be ahead of almost everyone.