Managing Project Team Members

Author: Neville Turbit

Overview

There have been hundreds of articles written about managing project teams. Many cover the same ground. Unfortunately, many also fail to differentiate between line management and project team management. They expect the same rules that apply to a staff member in a line role apply to a person on a project team. This article discusses the unique needs of a project team member and offers some suggestions as to how a team may be managed.

Differences

I mentioned there was a difference between a project team and a departmental role. Here area a few of those differences:

The project team has a start and an end in terms of time. There is an end focus to be maintained
The participants come to the team from different skills and experiences. They are not a group of people with the same technical training and career background
Processes are not as defined. Many processes will need to be invented
The leader of the team – the project manager – may not be a subject matter expert. He or she may not be an expert on the business area or the technology
There is a higher level of uncertainty around projects. Not everything is as predictable as in a line function.
This leads to constant changes of direction as uncertainty is clarified. Some things that were assumed to be true will be false. Unforeseeable things will suddenly pop up. Directions will change. People will have to be flexible.
There is inevitably more stress in a project – much of it caused by the uncertainty inherent in designing and building something new. Wading through the options trying to select the best solution.
Often people are supposed to participate in a project when in reality they do not have the time to do both their day job, and the project work

The Environment

A project environment is usually:

Higher pressure and more stressful than a line role
Less certain
Requires more flexibility
More transient in terms of developing relationships
Requires problem solving and creative skills

The Usual Problems

It is not hard to see the sorts of problems that are likely to arise.

People unclear of what their role is
Frustration from constant changes of direction
Loss of perspective. We will never climb the mountain
Lack of availability of key personnel
Splintering of the team into small groups who work independently and at cross purposes to each other
Never enough time to get the work done
Burn out as the project progresses. People being asked to do more and more when their productivity is falling through overwork.

Setting up the Team

The starting point for a project team member should be no different to the starting point for a new employee. Most organisations have some sort of induction program for new employees even if it is only sitting with the person they are replacing for a few days.

A project should be no different. How the person is integrated into the team will have a significant impact on how they see themselves in relation to the team. If they are put in a corner and asked to design a database, they will not feel committed to the team. If they are introduced to all the team, given a full briefing on the project, work with a number of people to understand the purpose of the project, they will be more committed. Not only that, they will have a better context to design their database. They will be more likely to ask questions. In short, they will do a better job.

Roles and Responsibilities

Defining roles and responsibilities is critical where people are in a new environment. Basically you take all the work and divide it up amongst various people. It solves two problems:

Two people trying to do the same job because they think they are responsible. Often leads to aggravation and a breakdown in working relationships.
Things falling between the cracks. Everyone thought it was someone else who was responsible.

Once defined, they need to be discussed with the team, and adjusted if necessary. Preparing a document and emailing it to team members does not provide understanding. It needs to be talked through. As the project progresses, they should be re-visited to ensure they are still current.

Project Direction

What is the outcome you are trying to achieve with this project? How will the organisation be different when the work is successfully completed? Just because you understand it, does not mean the team does. Get the sponsor to talk to the team about why the project is being undertaken and how it will change the organisation.

One project I was involved in was in the hundreds of millions of dollars. I asked the sponsor to brief the major participants in the project about the outcome. He was reluctant and finally I badgered him into spending an hour with the team. These were his words.

“I had been through all this at our annual planning exercise so I saw it as being a waste of time. All I wanted to do was get through it as quickly as possible and get on a plane out of there.

About 15 minutes into the presentation I noticed a lot of talking going on and thought they were loosing interest. I though, “Great! I can make it even shorter.”

Then I started to hear comments like “That’s what he meant when he was talking about …..” and “Now I see what he has been trying to do”

Frankly I was amazed. Why had they not seen where I was trying to take the organisation? It was in the corporate plan.”

Eventually the discussion went 3 hours. He cancelled his flight and stayed overnight continuing in the morning in a more broad ranging discussion on the views of his executive team. He told me afterwards it was the most important meeting he had attending in two years. For the first time his Executive Team had a chance to see his vision, and they had a chance to add their views. They all said the annual planning exercise was primarily “fill in the template” and argue for your departmental budget. During this workshop they talked themselves into the same direction.

That taught me a lot about having an interactive session with the team to discuss the outcome. In fact I tend to do it regularly to ensure we are all still pointed in the same direction. In the heat of a project, it is easy to loose direction.

Managing Workload

My tendency is to throw out the corporate rulebook for working conditions. It is inevitable that people will be asked to go the extra yard. There needs to be a balance in how the organisation rewards them. For this reason, I suggest that there is flexibility in working hours.

Some people like to start early and finish late. Others are the opposite. As long as it does not adversely impact the project, I encourage them to work their own hours. If working from home makes sense, let people do it.

On one project, there was a period when people were working weekends. As they were not being paid for it, and were not given time in lieu, some people were working 7 days straight and often more. I introduced a planning day. I would nominate particular people to do some planning – from home for a day.

I never actually asked for any deliverables. When someone tried to find them, I would say they were on a planning day. For months we got away with it. People were given an unofficial day off and it not only gave them some time to catch up with the rest of their lives. It was a secret that helped bond the team. Often being part of a secret brings people together.

Extra Rewards

Being appreciated helps maintain your enthusiasm. Get the sponsor to go out of his or her way to congratulate people. Something as simple as tickets to a movie for the family, or a taxi voucher to get home late at night makes people feel valued.

Family Support

The pressure and stress of a project does not stop when you walk out the corporate door. It spills over at home – particularly if you are not there much of the time. Telling your partner how important your work is, is another way of saying “Spending time at work is more important than spending time with you.” Do something for the family be it a “planning day”, picking up the bill for a visit to a restaurant, or even a letter from the Sponsor thanking the partner for their patience during the project.

Escalation Path

Problems are bound to arise that are unable to be resolved within the team. They might require a level of authority beyond that mandated to the team. It may be that the solution causes two solutions to be put forward that are equally supported.

The situation should be foreseen and a plan put in place to address the problem.

It is sort of like a disaster recovery plan. A DR plan is created because, in the heat of the moment, nobody wants to decide all the things that need to be done. It is better to have a plan or process to follow rather than have to both invent and implement a plan. So with escalation. Developing a plan for escalation means there is a clear expectation set that if something cannot be resolved, we will react in this manner.

An escalation process has two clear benefits:

It ensures problems are addressed quickly because everyone knows what to do
It sets authority levels and people understand who is making decisions

Individual Skills

I once ran a project where one junior business member was an excellent documenter. She was not recruited for that skill, but she was good at it, and what’s more, loved doing it. We re-wrote the roles and responsibilities to ensure she was responsible for all documentation.

We could have said that she was responsible for contributing to the requirements and not used her documentation skills, but it was far more productive to let her do what she liked to do. Others hated documentation. They could now get on with doing extra work in providing requirements to cover her role.

The lesson is to look for skills people have, and exploit those skills. Just because they have a particular role, does not mean it cannot change to utilise their strengths. On the other side of the coin, it might change to avoid their weaknesses.

You need to seek out the strengths in people. On another occasion I was running a big data cleansing project for an insurance company. I had about 50 temps working for me. Many were back packers traveling in Australia and looking for a few months work. One girl came to me and suggested that part of the process could be speeded up if they had a spreadsheet to do some complex calculations. She started to explain the concept in terms that indicated she knew what she was talking about.

I stopped her and asked her what her background was. She told me she had just graduated from Oxford with honours in Computer Science. When I asked her how long to develop the spreadsheet she told me 2 to 3 days to develop, test and deploy. I gave her a laptop and sent her away for a few days. When she returned, she became our trainer, and the spreadsheet saved us months of work. We even gave her a raise. Not bad for a back packer.

Team Interaction

I have always liked the concept of starting the week with a team meeting that everyone must attend. Usually I start with an overview of progress then go around the table getting everyone to discuss what they have planned for the week. It achieves a number of things:

It makes people focus on their goals for the week. In fact they get into the habit of last thing on Friday, looking at their work for the following week
It gives them a sense of commitment. They have stated their goals, and next week they will have to explain why if they were not met
It alerts me to problems
It enables people to see how the work of other people may be impacted by what they are doing
It brings out issues between different project team members
It is a chance to set action items and follow up the following week.

I always try to keep it light. A bit of chat about the weekend and personal issues makes it seem like we are a group of individuals rather than robotic zombies. It is also useful to buy some coffees or snacks.

One thing I do avoid is to get everyone in early to have the meeting. If 8:30 is the normal start time in the organisation, that is when the meeting starts. If you call everyone in at 7:30 it sets the scene as being yet another overhead. Yet another task above and beyond the call of duty. The whole mood of the meeting is one of stress and formality rather than one they look forward to.

Another must do is to have an agenda, and minutes. If you create action items, make sure they are documented in the minutes. Make sure there is an agenda item to review action items so people don’t forget about it. Also make sure the agenda goes out Friday morning so that people have time to complete the action items they forgot about. Similarly the minutes need to go out on Monday afternoon.

Conflicts

They are bound to happen. Hopefully the steps above will avoid many of the conflicts. When they do happen, there are a number of ways to resolve them. Here are a few techniques:

Get the two people together and identify the issue. Get them to agree who is responsible for making the decision. Ensure that person is present (it may be one of the protagonists). You can then make a decision.
Surprise them by asking each person to state the case for the other. For example if Person A thinks the screen should be blue and Person B thinks it should be red, ask Person A to state the strongest case possible for red, and Person B the strongest case possible for blue.
Talk to the people individually. Ask whether it is an issue with the person or with their view on a particular topic. It may be both. If it is an issue with the person, ask them to list five things they dislike and five things they like about the person. Suggest they focus on the things they like, rather than don’t like.
In the situation above, where it is a dislike of the person, ask why they need to like the person they are required to work with? We all work with people we don’t particularly like. Why is this different?
It is usually that the other person has a quality that is exactly opposite to one of our own stronger personality traits. If we are outgoing, we might find a retiring person difficult. If we are social, we might find the unsocial person difficult. If we are innovative, the conservative irritates us.

Talk to both parties and suggest they can benefit from their differences. Their natural tendencies may in fact be a weakness. Sometimes too much conservatism is as dangerous as too much innovation. Ask them to consider each issue in terms of how much innovation or conservatism is required. Accept they may have a predisposition at one end of the scale and be a little more flexible.

Talk to their close friends and ask how the problem can be resolved. Sometimes a close friend will either provide a solution, or talk to the person and convince them to be more compromising.
Status is often an issue. I want to be seen to be the person making the decisions. Perhaps it can be a division of decision making. One person makes the decisions about A and the other about B. This may require the project manager to do some quick realigning of the project but I have seen it work.

Conclusion

This topic is endless. In fact there may be a part 2 in the near future. There is no single way for a project manager to manage people. Trying to learn the right way is a waste of time. What you need is a collection of techniques and tricks to use, and the wisdom to know which one to use when. The project manager with only one solution will soon hit the wall.

Each solution needs to be evaluated within the corporate environment and within the context of the project. If there is one overriding thing to remember it is this. You are dealing with people, not machines. People are unpredictable, influenced by things completely outside your control, and come with their own agenda. You need to be patient with them and get to know why they are as they are. Only then can you hope to guide them to achieve the goals of the project.