The Politics of Projects

 

A few days before the holiday last week, I came across an interesting article written by Alison Sigmon for Business2Community.com. I liked her perspective when she suggested, "Just as politicians pay close attention and respond to the opinions of constiutents, so must project managers when leading a project. For a project to be successfully delivered, it's critical to get collective action from a group of people who may have very different interests. Easier said than done."

This sentiment might be difficult for grey-haired managers who aren't used to consensus-building as a leadership strategy (I know when I first entered the workforce, I did what I was told because I was told to do it—I just don't believe that is a good long-term leadership strategy). Therefore, when Sigmon suggests, "The key to achieving collective action and creating a sense of belonging among team members is to engage them in playing an active role throughout the project," I agree with her.

I've found that my team is more creative, more productive and arrives at solutions I might never have thought of myself, when I engage them early in the project planning process  and facilitate an environment where they can "own" what they are doing.

"It's been said that people own what they help create, and that means actively engaging team members at regular intervals to provide input and perspective," writes Sigmon.

I think it goes without saying that it would be naive to expect that we will always be able to achieve some kind of consensus. There are going to be times when the project leader has to make a decision or set a course of action—however, I've found those times to be fewer and farther between than I might have thought just a few years ago. Let me suggest a couple of ways to successfully create an environment where team members can "own" their contribution to the project:

1. Invite team members into the planning process—This can sometimes be messy business as "Too many cooks can sometimes spoil the soup," but when everyone owns the plan, everyone owns the project. Scrum teams successfully work together to plan a Sprint, I see no reason why the team can't contribute to building a successful plan regardless of the methodology.
2. Encourage real dialog—I really like the idea of making task "requests" rather than making "assignments." The difference might be subtle, but the idea of a request encourages dialog and captures feedback from team members who can often provide a more complete view of what's happening within the team—including resource availability and timelines that might not otherwise be known.
3. Don't solve every problem, allow the team to come up with solutions—For many of us, it's easy to take all the responsibility for solving every problem that presents itself. Many years ago, a wise mentor taught me that part of identifying a problem is to also identify a few potential solutions along with it. I'm convinced that those closest to the work understand it the best and often have the best solutions. Whenever I'm presented with a problem by someone on the team, the first question I ask is, "How would you solve this?" In fact, I seldom have to ask anymore, most of the time the members of my team now present a couple of possible solutions anytime they come to me with a problem.
4. Never shoot the messenger—Projects are messy and challenging things. Sometimes "stuff" happens. I'm convinced that my team is doing the best they can to achieve whatever objectives are the focus of our current projects. When things go wrong (which they sometimes do) shooting the messenger creates an atmosphere where the team won't identify potential problems early—giving those problems the opportunity to grow into insurmountable obstacles.

None of these suggestions are really anything new. However, as Sigmon suggests, "Consensu won't always be achieved, but ... a project team culture of belonging [can] be experienced within the team."

If you've seen some successes in this regard, I'd welcome your input into the discussion.