Today I wanted to tackle how project managers and their approach to that role can be seen as boon to teamwork: or conversely be one major reason the team does not work together well. In my experience project management is often viewed by team members not as an enabler, but as some separate and materially unrelated function to the ‘real work’ they need to do. It represents not a valuable facilitator of their work, but rather an attempt by someone in charge to control their work in a negative way. That perception can lead to conflict and resistance to working collaboratively with the PM.
Here’s are a couple of typical situations that show how such attitudes toward the project manager role can occur:
In my first big line management role (managing a hardware engineering group) our company was acquired by another firm. The parent company sent us a present: our very own project manager. He was a very nice guy and very experienced, but he talked about work packets (a term I had never heard); he drew up endless tables, charts, and lists and told us all the paperwork things we “had to do.” It’s not that I thought they were worthless; but his language was foreign; I really didn’t know what to do with all his tools; and they sucked down time to maintain and didn’t necessarily get used day to day. The ones that did look useful I felt I had already done in one form or another. But he wanted HIS form for his use, it seemed. Our conclusion was that he didn’t understand our environment and thus couldn’t really help in any materially way. In fact, we were afraid that keeping him happy would eat up lots of time. So we ignored him as much as possible. And we probably missed the chance to gain some valuable help.
I heard this one from a friend: Everyone in his software group at a database company was intensely involved in their coding. They “never saw” the project manager. In their minds he didn’t have any real visibility into what they were doing, the challenges they faced. One even commented that he could start his own company at work and no one would ever know. This all may or may not have really been true, but it was their perspective, and it led to this logic: If the project manager didn’t know and understand their technical work, he couldn’t understand their issues and thus he couldn’t really have any grounds for any expectation that they would finish on any particular schedule. So they didn’t worry about it. Their global attitude, quoted to a friend over a beer, was “The project manager is a useless appendage.”
Pretty extreme, I know, but it DOES happen out there!
What I wanted to get across in this post is how a project manager can communicate and work with team members in a way that results in the opposite to these two stories: a way that raises team members’ valuing of the project manager’s job and enables effective working relationships with them. Here are two key elements of positive team-work: and they are the RESPONSIBILITY of the PM, in my book.
1) Use Effective Language: The most effective PMs talk to team members in “benefits language”, from the viewpoint of the team members’ work and in the language of their own work processes and concerns, not the formal language of “we already know this is valuable” project management. Look at it from technical team members perspectives, for example: their job is to produce technically-sound designs and implementation that meet requirements; deal effectively with technical risks; find bugs in their work. Of course we know that good project management facilitates all that. But they may well think project management is just scheduling, formal status meetings, budget machinations: ..read: “constraining, non-value-add, time-consuming overhead.” We reinforce this attitude if most of the interaction we have with technical contributors is cursory exchanges about schedules (“what is yours and are you meeting it?”).
Here’s another example of language: If you try to get someone on a team to do risk assessment by saying, “we’re in phase 2 of the project and I need this risk matrix deliverable now,” watch out. You of course know that the process calls for it in phase 2 because you need to uncover risks early. But you didn’t say that. You made what looks to be a bureaucratic request to that technical lead. Suppose instead you had asked for “your assessment of the risks you’re facing, so I can fight for ample time and money to allow you to do some parallel development if need be, based on your take on the risks of the various technical alternatives. It will also allow me to have the information I need to push back on management if they’re asking for too much.” Then you would have couched the management tool in terms that relate to his work and provided him a real benefit. Such language doesn’t guarantee cooperation, of course, but in my experience it makes a big difference in receptivity to a project manager’s requests and a much better basis for building a working relationship.
2) Eradicate Ineffective Practices: Deal with anything that is causing your team members to see project management as ineffective or inefficient, and adapt your project management to fit the situation.
Start with identifying the current practices that they think are ineffective: manipulating schedule programs with no value added; excessive or non-relevant paperwork; going to meetings whose value they don’t perceive. Come up with ways to resolve those issues. Look hard at yourself. Are you asking for things that don’t matter? Are your meetings a mess? Don’t be afraid to be innovative; don’t stick with previous project management approaches if they are causing problems. Can the information exchanges from some of those meetings be handled by email? Are some documents cluttered with boilerplate and could be made much simpler and more approachable?
Then get functional team members to help define “appropriate management” for a particular project. This includes the activities, deliverables, processes, and the amount of formality involved. With them, determine which deliverables are needed for this project, how detailed they should be, how status should be tracked, what should be handled in meetings, etc. One team decided on its own that it had to add more detail to its functional specs, so that latecomers to the project could get up to speed more quickly. Get used to using different life-cycle variations for different types of projects. Let them help create the right workflow and suggest tools. Don’t just give them a process or toolkit dictated from above.
What, you ask, does all this have to do with teamwork? I still maintain as in the earlier posts that strong teams are built one person at a time, and that includes the project manager. I can’t imagine that I’m getting the best contributions and proactive vanquisher behavior from the other team members, if I as PM have in any way been written off as ineffective, unreasonable, clueless, font-of-extreme-overhead, or even just mild versions of same. For all us project managers – how WE work with team members is just as critical to the quality of the overall teamwork as the contribution or lack thereof of any single team member. Language that doesn’t help you keep showing your work’s value, and ineffective practices that the team sees as hindrance rather than help, are two of the most important “working together” areas to tackle to make your PM role relevant and value-adding and make your critical teamwork contribution.
I’ll close with a repeat of the picture of what awesome teamwork “looks like” to me:
- Each Individual: “I take personal responsibility for this team achieving the desired project outcomes, exhibit leadership by suggesting actions and raising tough issues, and proactively help the team operate effectively throughout the project.”
- The team: A group of committed people working together, each of whom is equally “carrying the load” of achieving a successful project, “showing up” in every team interaction, and holding each other accountable rather than assuming the project manager bears sole responsibility for team discipline, deadlines, conflict resolution, etc.
Go team!
If you’d like to read more about the examples of PM resistance above, additional techniques and examples around how to turn around bad perceptions of PM, and how to approach the PM role to get the best respect and cooperation, see my longer discussion of the topic, called Getting Relevant to Get Results, from the ProjectConnections.com site.
Right on, Cinda, you really nailed it!