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.\u00a0 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.\u00a0 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.\u00a0 That perception can lead to conflict and resistance to working collaboratively with the PM.
\nHere’s are a couple of typical situations that show how such attitudes toward the project manager role can occur:<\/p>\n
In my first big line management role (managing a hardware engineering group) our company \u00a0was acquired by another firm. \u00a0\u00a0The parent company sent us a present: our very own project manager.\u00a0 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.”\u00a0 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.\u00a0 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.\u00a0 In fact, we were afraid that keeping him happy would eat up lots of time.\u00a0 So we ignored him as much as possible.\u00a0 And we probably missed the chance to gain some valuable help.\u00a0<\/p>\n
I heard this one from a friend:\u00a0 Everyone in his software group at a database company was intensely involved in their coding.\u00a0 They “never saw” the project manager.\u00a0 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.\u00a0\u00a0 This all may or may not have really been true, but it was their perspective, and it led to this logic:\u00a0 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.\u00a0 Their global attitude, quoted to a friend over a beer, was “The project manager is a useless appendage.”<\/p>\n
Pretty extreme, I know, but it DOES happen out there!
\nWhat 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.\u00a0 \u00a0\u00a0Here are two key elements of positive team-work: and they are the RESPONSIBILITY of the PM, in my book.\u00a0
\n\u00a0<\/p>\n
1)\u00a0 Use Effective Language<\/strong>:\u00a0 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.\u00a0\u00a0\u00a0 Look at it from technical team members perspectives, for example:\u00a0 their job is to produce technically-sound designs and implementation that meet requirements; deal effectively with technical risks; find bugs in their work.\u00a0 Of course we know that good project management facilitates all that.\u00a0\u00a0\u00a0 But they<\/em> may well think project management is just scheduling, formal status meetings, budget machinations: ..read: \u00a0“constraining, non-value-add, time-consuming overhead.”\u00a0 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?”).<\/p>\n Here’s another example of language:\u00a0 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.\u00a0 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.\u00a0 You made what looks to be a bureaucratic request to that technical lead.\u00a0 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.\u00a0 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.\u00a0\u00a0 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.\u00a0\u00a0<\/p>\n 2) Eradicate Ineffective Practices:<\/strong>\u00a0 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.<\/p>\n 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.\u00a0 Come up with ways to resolve those issues. Look hard at yourself.\u00a0 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.\u00a0 Can the information exchanges from some of those meetings be handled by email?\u00a0 Are some documents cluttered with boilerplate and could be made much simpler and more approachable?<\/p>\n Then get functional team members to help define “appropriate management” for a particular project.\u00a0 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<\/em> detail to its functional specs, so that latecomers to the project could get up to speed more quickly.\u00a0\u00a0 Get used to using different life-cycle variations for different types of projects.\u00a0 Let them help create the right workflow and suggest tools. Don’t just give them a process or toolkit dictated from above.<\/p>\n What, you ask, \u00a0does 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.\u00a0 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.\u00a0 \u00a0For all us project managers\u00a0 –\u00a0 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.\u00a0\u00a0 \u00a0Language 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.<\/p>\n I’ll close with a repeat of the picture of what awesome teamwork “looks like” to me:\u00a0\u00a0\u00a0<\/p>\n Go team!<\/p>\n\n
\n