Archive for the ‘Team management’ Category

Why you should welcome conflict?

Sunday, September 6th, 2009

Most people would say they hate and avoid conflict. In this environment of staff cuts, there are probably a lot of people ducking conflict to keep under the radar. In my experience it’s not conflict, but confrontation that people hate.  The problem with that is they avoid conflict; that’s one straight path to confrontation in my experience. By the time the issue becomes critical – or often, not that issue but another – there are so many frustrations in the emotional saddle bags that situations go from nothing to confrontation like a Ducati on the salt flats.  Handle conflict well and you show up as a valuable employee; handle it badly, and you are part of the problem.

Let me explain why I think these two similar concepts are so different. Confrontation carries with it a winner loser relationship, a sense of battle. Conflict leaves an opening for clarification and resolution. For example, as PMs we often have issues relating to resources. Taking a confrontational approach means everyone who needs the resources decides their need is the most critical, and they all fight over that and the winner gets the resources and everyone else get a problem project. It becomes all about who’s the winner, and not about the project or the project portfolio. Taking a conflict resolution approach means everyone comes to the table to discuss solutions that best serve the project or portfolio. They work together to present recommendations to sponsors and everyone can win.

So, let’s step back into the real world where even I live. The real problem happens when people take a confrontational approach to conflict resolution. Some organizations have a culture of confrontation; the meaner dog will always win. If that’s your organization, play that game, or find a new organization. If you want to make a change in approach and your corporate culture is not junkyard dog, start by putting aside the idea that your needs are more important than anyone else’s.

You want to get to the point where people seek out conflict to resolve. When you get there, or even when you get nearer to ‘there’ than you are, confrontation will die away. Let’s go back to the resource example.

Your project and another project need the same QA resource at the same time to do the same task. Using conflict resolution means, you need to meet with the other PM. Your agenda is to discuss solutions to the conflict. Start with the other PM presenting their issue. That’s right, let them go first; that way you will be able to listen to their issue, paraphrase back and build trust before you state your issues. That means you listen to their needs, ask questions to clarify, and paraphrase from their point of view. It doesn’t mean you sit there nodding while you wait your turn to speak.

When you’ve understood their issue, you present your needs. How much of the capacity do you need; what wiggle room do you have in scheduling; why this QA resource is the only solution, and what is the ultimate impact on your project if you don’t get the resource. A key tip here, is to make sure you talk about the project, not you, and if you can talk about the impact on the organization’s portfolio, or even the business goals if you can. The purpose is not to build a case for how important your project is, but to build the resolution to a bigger goal than just the project.

The next step, after you’ve both laid out the issues, it’s time to look for mutual solutions. Often that’s possible; in fact, you might want to ask the QA resource for solutions, they are closest to the problem, after all. Most of the time, you will find a resolution in that meeting because you have both understood the facts of the problem. Sometimes, though, a problem is tough and will need more work.

The tip for this week: don’t avoid conflict, use this model for resolution

Start by understanding the problem from a project impact perspective

Then meet with the parties involved

Listen, ask questions, and paraphrase to understand the other point of view

Search for mutual solutions – meet as many of the project needs as you can.

Some interesting links

Academic Leadership Support

Mind Tools

Susan B Wilson (no relation)

Maslow’s Hierarchy of needs as a project tool

Sunday, August 9th, 2009

In the eighties, it was fashionable for management teams to go away for retreats to learn the latest managment theory and how to apply it in the workplace to better lead their teams. I’m sure you can guess that after the retreat managers made some efforts to apply the new skills, but life and work got in the way. The latest theory joined the rest of the management flavours of the day, ignored and put on the shelf.  I think that’s a big loss, these theories were valuable and, with a chance to become ingrained, could have helped more companies become more successful.

This blog posting will touch on the theory of hierarchical needs, from Abraham Maslow. There are links below to a few other theories for thought. In short Abraham Maslow theorized that people have certain basic needs that must be met before they can move on.  Here’s what it looks like.

A graphic representation of the priority of needs

A graphic representation of the priority of needs

Looking at this from the top down – just to be different. One day you are sitting there, enjoying the day, thinking big generous trusting thoughts. The world is everyone’s oyster, peace on earth, etc. Suddenly you need to pee; no problem, you go to the bathroom. Problem,  the door is jammed shut. Your priority drops to the next layer, what will people think if you have to go to a neighbor asking to use their bathroom? You shake the door handle again, no luck, drop another level as you start the pee dance. Where are your family, why is the door locked. Drop down again, what the heck are you going to do, why are you living in such a crappy house, isn’t there some kind of standard for bathroom doors? Drop down another level, to heck with the rules, you kick in the door and solve your basic problem.

So, think about how this relates to your project teams. Are you making sure their basic needs are met? Do they have to work overtime to meet deadlines? If so, where do you think their minds are as stomachs start to growl, and they enter work hour thirteen? Once the basic needs are taken care of, you need to ask about the work environment. Is it conducive to work; are your team members confined in stuffy rooms? Do they have a place where they can go to think? Is there enough trust to allow people to take a risk?

At belongingness and love – you don’t have to hug everyone – you need to make sure there’s social interaction; chatting around the coffee station, a football pool, these make for a feeling of camaraderie.  Satisfying the need for esteem comes from recognition activities, interesting assignments, and leadership opportunities.

Getting to the top is a bit different, I believe people take themselves to the top, that’s why it’s called self-actualization; you can’t take them. What you can do as the leader is help take care of the rest of the pyramid and create the possibility for people to get there.

So how does this impact your project? When people are in the lower levels of the pyramid, you tend to get crisis management. People are unsure of the safety and security of their basic needs to do the job – maybe it’s as simple as they don’t understand what the project is trying to accomplish – they take actions to create stability and security. In the belongingness and esteem areas, you have team members helping each other to succeed, and making sure there’s spotlight to share.

It’s well worth reviewing some of the fundamentals of people management theory – I think you’ll recognize so of the aspects of current people management trends there.

Tip, check some of these links out.

Maslow

Herzberg – an interesting idea that explains why money doesn’t always motivate people

McGregor – theory X and theory Y management, different styles work in different environments

Hawthorn – sometimes just paying attention helps

When you put the project first you put the blame game to rest

Sunday, July 19th, 2009

As you execute your project, you will find that things go differently than planned. Do I mean they go wrong? No, things change and to be successful you will need to adapt to the change not try to make the change adapt to you. The project technical processes used to adapt to change are risk management, scope change, and communication planning. Having a good relationship with the team and the sponsor will help you make the most out of change.

Let’s start with the team. Have you ever been on a project where the first risk management strategy is to find out who is to blame? I’ve worked on projects where it seems to be a step in the initiation phase – first figure out the scapegoat group. What happens to the team in this environment? It starts with an expectation that things will go wrong, not that the project will be successful. It puts people on guard, always taking steps to lower their profile. It kills any spirit of innovation, which means no one is likely to offer new solutions to problems. The projects rarely do more than just meet expectations in this type of environment. The lessons learned tend towards, who did it wrong, who should have done something, and every other blame statement you can think of.

If you put the project first, you can focus the team on resolutions. Things always go awry, if you can focus the team on “what happened” and “what do we do to move ahead,” no one takes the blame. Understanding what happened will start the ball rolling towards solutions. If testing failed on a process, it’s not because Joe didn’t create a great process. It failed for a reason and it needs to be fixed. If the client isn’t satisfied with the first iteration of the solution, it’s not because Mary didn’t understand the requirements. They aren’t satisfied, that’s what needs to be fixed. The words you want to hear from your team are, “ABC product isn’t working as expected because of the volume of traffic wasn’t anticipated; here’s the solution.” Definitely not, “ABC product isn’t working because Alan screwed up and you need to fix it.”

Let’s turn our focus to your relationship with the sponsor. If it’s an environment of blame, guess who wears the hair shirt in this relationship – the PM. Your sponsor knows that things change and relies on you to manage that change. So, let’s say your project budget needs to increase because the organization restructured and your key team members are gone. You can complete the work on time with contractors but it’s a 20% increase in cost. Do you say to the sponsor (even subtly) “because you laid off all these people you need to give me a bigger budget.” Or, do you say “Let’s confirm that the project is still active, if so, there are a couple of options. We can keep the same scope and probably hit the date if we hire contractors, it will cost XX. The other option is to reduce scope by XX or extend the timeline.” My guess is the first approach may add your name to the list of people looking for work; the second approach accepts reality and puts the project first with solutions.

It may or may not be reassuring to know this isn’t unique to project environments. Put this search in Google “finding solutions not scapegoats” to find all kinds of examples of this phenomenon.

Tip- I know you don’t really say the second examples, but you might say it in your body language or tone.

Change your project vocabulary

Use, “What happened?” Not, “who screwed up”

Use, “How do you think we can fix it?” Not, “How do we deal with the screw-up?”

Use “How do we avoid this in future projects?” Not, “how do I keep the screw-up off my projects?”

You’ll find people are excited to be on your project and part of a supportive successful environment if you can be successful in dropping blame.

Please visit my website and contact me if you have any questions.

Follow me on twitter

Have a fabulous day