Managing the project team

In this section we cover some tools and techniques for managing the project team.

Team selection

The team is the people who will make the project happen. It is therefore essential that between them they have the right skills and experience for the needs of the project. A team skills matrix is a useful tool to check that the team's skills and experience are right. The sponsor and project manager should look at the skills matrix for their project and ensure that any gaps are filled. Table 2.2 is an example of a skills matrix and the text at the bottom of the table gives further details.

Table 2.2. An example skills matrix
	Project team members
Skills and experience required	Abel	Beth	Cain	Don	Ellie	Fay	Gill	Harry	Indira	Jude
Technical knowledge of the Furtwangler Mk. IX jet engine	x		x			xx	x	xx	xxx	xxx
Technical knowledge of Boltzmann machines and simulated annealing	xxx	xxx	xxx	x	xxx			xx	x	xxx
CAD-CAM operator	xx	xx	xx	x	xxx			xx
Knowledge of the customer organization, processes and culture
Finance and accounting skills							xxx	xxx
Project planning skills				x				xxx	x
Knowledge of how to get things done in our organization		xxx						xxx		xxx
Presentation skills				x		xxx		xxx		xxx
Ability to put people at ease in interviews				x		x		xxx
This example of a skills matrix lists the skills and experience that the project needs down the left-hand side, and lists the members of the project team across the top. Where a team member has a skill or some experience, a single 'x' is entered to show a small degree of skill or experience, and 'xxx' to show a high degree. This matrix shows that this team is strong in technical skills, i.e. the first three rows. The matrix also lists softer skills that will be important to this project, such as being able to put people at ease in data gathering interviews, and it seems that the team is short of these skills. If having only one person, Harry, who is strong in this skill is likely to be insufficient (and look at all the other areas where Harry is the only person with substantial skill), then the project can decide whether to remedy this by training team members listed here or by adding a new team member. There is one area, knowledge of the customer organization, where no-one on the team has any experience this is an area that needs to be fixed.

Human dynamics and soft skills are vital in project management. Every project manager wants the best experts on the team, but what if the best aren't available? And what if the best technical expert is available but only because nobody else will work with them? This is not some fuzzy side-issue that you can ignore. Your team have got to be able to work together, and it is part of your job as a project manager to think about this. If your project team has not worked together before, or if they show signs of not working together well, then you should include team-building in your project plan. The best team-building activities may not be labelled as such.

Is there such a thing as a perfect team member? We might imagine a genius who knows every corner of their technical field, never gets sick, and always files their documents properly. What would you feel like having to work next to this person? Your answer probably reveals much about the sorts of people you like to work with, and so the real answer to the question about the perfect team member is that it depends on who else is in the team. Every project team is different and what is perfect in one will not work in another. So it is neither possible nor desirable to provide precise rules for team selection other than to say that fit with individuals in the team should be a factor.

Some factors to consider with regard to human dynamics and people in projects are as follows.

People like to work with friends, or at least people with whom they have worked in the past. Getting to know new people takes time and intellectual and emotional energy, and most people will save themselves the effort if possible.
An entirely new team in which nobody has worked together before will not work at full capacity until some time after the start.
An established team or group of people may not assist in recognizing skills gaps that require new members to join their team. Use the skills matrix to make sure that you as project manager or sponsor can see skills gaps in the team, and then work out how to sell the idea to the team. You must be prepared to tell the team as a last resort if selling does not work.
The project manager needs to spend time getting to know their team, and the sponsor and project manager need to spend time getting to know each other. Use this time to establish who is who and how people like to work together.
If your project team is widely dispersed then they will probably never really understand how each other works unless you make a special effort to bring them together to work as a group at the start of the project. Bringing together does not have to be physical; it can be by video conferencing or telephone conferencing.
If a team is made up mostly of people who have worked together before, with one or two new faces, then take care to ensure that the new joiners fit. Groups develop their own sub-culture and a new joiner can sometimes break the rules without noticing; this can sometimes lead to rejection of the new joiner unless someone realizes what is going on and intervenes. Rejection can be a matter of subtle group dynamics and it may not be obvious that it has happened. A new joiner may feel isolated and demotivated when it becomes obvious that everyone on the team is friendly with everyone else except them.
A special case of the problem is where you, the project manager, are the new person on an existing team. This is examined in more depth below (see 'Gaining and maintaining authority').
Teams under pressure tend to reach for and adapt the first likely looking solution. If a team has worked together on a similar problem before, they are very likely to revert to their previous solution if they need to save time. Sometimes this is definitely what the project needs, but if not, then altering the composition of the team may be necessary to stimulate new thinking.
Not every project team that has worked together before wants to work together again. If the earlier project has strained relationships then you may be better off not burdening your project with this emotional legacy. Don't assume that all previous experience is positive.

Gaining and maintaining authority

One of the stressful aspects of becoming a project manager is often the idea that you will somehow have to establish authority over people who have hitherto been your peers. 'Won't it be obvious that I know less than everyone else about most of the aspects of the work? Won't they see through me?' Many successful project managers admit that they started with just the same fears. It did not stop them doing a good job.

The good news is that most people will be on your side. Your team want you to succeed because that means project success, which is good for them as well. Most people do not expect you to be an expert in their domain as well as yours after all, they would probably not have been brought into the team unless they had some specialist skills. Furthermore, the performing organization also wants you to succeed and will give support and guidance if you ask for it. Your position as a manager gives you a natural source of authority. The simple fact that you are the manager predisposes people to fulfil your requests you have the weight of convention and organizational protocol behind you. Even friends can usually respond appropriately and professionally when you move into the project manager role as long as you do not give out mixed signals when in the professional setting.

As project manager you have five sources of power:

Legitimate power: this is what the authority that comes from your position as project manager is called. It is your primary source of power in the project.
Reward power: the capacity to grant a reward that someone wants.
Expert power: specialist knowledge that means your opinion carries weight. The importance of expert power varies. In technical and professional domains some degree of demonstrable technical knowledge is essential, and in extreme cases some professions are known for reluctance to be managed by non-members.
Referent power: the power of your personal network. If you are the daughter of the chief executive you will have considerable power in the organization even though you may hold a junior post. By all means use your network to help your project, but beware of using this power in ways that harm others or allow you to short-cut the normal channels. You do not want to acquire a reputation for excessive use of referent power.
Coercive power: in some ways the reverse of reward power it is the capacity to inflict some unwanted outcome on someone who does not do as you wish. Any use of coercive power is likely to destroy whatever enthusiasm an individual may have had, even if it produces the desired action in the short term.

You can either build on your initial advantages, or destroy them (Table 2.3). Common sense usually makes the difference between these two outcomes.

Table 2.3. Maintaining authority do's and don'ts
Do	Don't
Treat everyone as adults. Tell them what needs to be done and why, and let them get on with it. Ask for people's opinions about their area and listen to the answer. Praise good work publicly. Share information about things within and beyond the project. Remember that making people ask for your signature or give you an account of how they spent their time can be a way to subtly remind them who is boss. Ask people to do things in just the same way you would normally politely and professionally. Refer to and be seen with the senior people with whom you have to deal. Respond to bad news by looking for a solution, not a culprit.	Take credit for anyone else's work. Give the impression that you don't trust people by not accepting the professional opinion of people who know more about the area than you. Attack or insult anyone on the team, even if you feel angry about something. Attempt to win favour with the team by breaking confidences with others in the firm. (Can the team then trust you?) Bark orders like a drill sergeant (or a chef de corps de ballet). If you let your fear drive you to this, people might even not take you seriously. Refuse to get involved with group social activities you will be seen as aloof. Shoot the messenger. Use coercive power (not even if they deserve it).

Maintaining your authority as a project manager is essentially the same as in any management function. What is different in project management is that you might have to become very skilled at the basics because new projects, with new teams, will come along far more frequently than they would if you were in a line management position, which means that you may need to keep redefining your authority. Another reason is that project team members may feel that their real manager is their line manager and not you, the project manager. A further way in which project management differs from process or line management is that project management involves more uncertainty about what to do and how to do it.

Projects, by their nature, involve doing things in new ways and some part of the work is likely to go beyond established procedure. The team looks to the project manager to give guidance and set direction under these circumstances, and if they get the impression that you are vague and confused, you will begin to lose credibility. But be wary of being decisive merely for appearance's sake, since this can be equally damaging to your credibility. Your best defence against this is the project plan. If you have thought through all the issues, considered all the possible approaches and planned the project in a way that gives the best balance of risks and progress, then you will already know most of the answers. Refer back to the plan, remind yourself why it was set up this way, and give a clear answer. Project managers who try to work without making or referring to a plan lose credibility with their teams not because the teams pay direct attention to the plan itself, but because the manager appears indecisive and keeps contradicting earlier decisions.

Maintaining authority when you make a mistake

Everybody makes mistakes, even experienced and highly qualified project managers. Sometimes you can recover the situation before anyone notices, but sometimes somebody will realize that they are having to work harder because of a mistake you made. Some people never ever admit that something was their fault, even if it is obvious, and some go so far as to intimidate anyone who dares to point it out or to suggest another way that is clearly better. If you behave this way you will bring about two things: you will eventually erode the morale of your team, starting with the most intelligent, and you will ensure that no ideas other than your own get implemented. Since nobody can challenge these ideas of yours, the bad ones will not be filtered out, and your project will suffer.

If you suspect that this description might apply to you or, more importantly, that your team believes that it applies to you then change your behaviour. The change is easy: all you have to do is to admit that you were wrong once in a while. Try it. You will find that instead of losing respect you gain it, by showing that you are mature enough to take responsibility for your own actions. This does not mean you have to fawn constantly, just that you should not hide behind your managerial power. If you have made a mistake, you might even find it easier to get people to help you out by apologizing and asking for their support than by announcing the extra workload and leaving them to deduce the reasons themselves.

Personal work styles

Your personal style of working will affect the project, as will those of every team member. We all have slightly different styles, which can be modified rather than changed outright. Even without modifying them, being aware of one's own style, and that of others, and knowing how to use them and when to delegate to someone with a better style, is important in project management and management generally. One's personal style is separate from one's skills and knowledge, although it is affected by them and by experience. A style that is amusing and tolerable in a keen 20-year-old can look ridiculous in a 70-year-old, and vice versa.

As an example of how style matters, consider someone who never actually seems to do any work and yet is incredibly productive. Ask yourself whether they have ever produced answers to questions faster than you could have done, just by knowing who to ask instead of trying to generate the answer themselves. This is part of style. If, instead, you are yourself one of the people who always finds the answer through your network, maybe you secretly admire or despise those people who try to work everything out for themselves instead of making use of perfectly good pre-existing information. The point of all this is that different people have different operating styles. They both get results. You are much more likely to have to deal with different styles in cross-functional project management than if you stay within your own domain, as different domains attract different sorts of people.

There are many theories about personalities and people's preferred team roles, but it is sufficient here to point out that these differences are real and can bring down the unwary project manager. Do not assume that everyone works in the same way that you do, and manage the working styles in your team actively. That means choosing the right mix of people and adapting your own style to suit circumstances. One technique that many project managers use is to run a Belbin or Myers Briggs or other personality type assessment exercise at the start of their project. This can serve a dual purpose as a team-building exercise as well as revealing supposed personality types. Many people dislike the idea of these kinds of exercises because they seem manipulative, but if run in the right way they can be very enjoyable. The HR department of the owning organization will often run such exercises if requested.

One way to think of the working style problem is that there are two ways people can spend work time together: either they can be business-like, with a focus on getting the job done ('task oriented'), or they can focus on the person in front of them and deal with the human issues ('maintenance oriented'). Figure 2.5 illustrates the spectrum of these characteristics. In the course of a normal day, or even a single conversation, most people spend part of their time in task and part in maintenance. Maintenance time is the glue that holds groups of people together as a coherent group. By investing time and energy in authentic conversations that touch areas of life outside the immediate task, the bonds that tie the group together are maintained. So as a project manager with a newly formed group, you should expect to have to invest time and energy (maybe even deliberately chosen time outside work hours, as a signal of your commitment to the human side) to get the team together. Once people feel good spending time together it becomes easier for them to talk about task problems and interact effectively without worrying too much about what other people think. Suggestions for improvements are easier to make to friends than to strangers. Some maintenance time after a gruelling period in the run-up to a project deadline is well spent, and will keep the team working for the rest of the project.

Figure 2.5. Personal working styles: task focus, maintenance focus

Some industries seem naturally to attract task-focused individuals, such as securities trading, fighter pilots, high-value sales, pianists, project management, and engineering. Other kinds of work seem to attract both task-focused and maintenance-oriented people: local and central government, law, the stage, and marketing. Just to be clear, it is not a bad thing that government has more maintenance-focused people in it than, say, securities trading. A government in which everyone is task focused to the complete exclusion of being maintenance oriented is called a dictatorship. Projects, and the world at large, need both. (And by the way, in case it is not obvious, projects are best not run as dictatorships either, even in the securities industry.)

Everyone has a natural predisposition towards either task or maintenance activities. As project manager, you need to ensure a balance in your team between task and maintenance orientation. This depends not just on the people, but on the nature of the project. You will also need to adapt your style to match circumstances. When the deadline is looming you and the whole project must be more task focused, so you must have built up enough of a reserve of goodwill through your previous behaviour that you can behave in a directive manner, giving orders with little explanation if necessary. Judge when it is safe to have some fun together and when the team has really got to get down to some hard work, then set an appropriate example.

Socializing

This can be a way to get to know people's personal styles ... and to let them get to know yours, which is just as important. It is good for team spirit to spend time together socializing. Knowing this, the obvious thing to do is to go out for a drink together after work, or, depending on the country and culture you are in, a communal hookah. This is just what friends do together, and everyone will work better together as a result. But don't expect it to be good for everyone. Some people just don't like it: maybe they have family commitments, or they just don't enjoy going to the sorts of places that you enjoy. Sometimes pressing everyone to come along may be counter-productive: nobody can be ordered to have fun. If there are people who are clearly uncomfortable with the suggested outing, it is pointless to insist. Next time, choose a different time or event, and if you must, just make sure that these people get included in group events during work hours.

Morale

Morale is vital to any human endeavour, and the maintenance of morale is one of your main responsibilities as project manager. With good morale in the project team, all kinds of problems and setbacks amount to less than water off a fat goose's back. With poor morale, even the most trivial problem can derail things. People do good work because they want to. It might give them a sense of achievement directly or they might feel good about doing their bit for the team. Poor morale will soon sap your own motivation. Experience shows that the things that build morale are different from the things that can destroy it (Table 2.4).

Table 2.4. Factors that do and don't build morale
Factors that build morale	Factors that do not
A sense of achievement. Shared adversity and struggle. Recognition. Performing work that is in itself satisfying and worthwhile. A sense of responsibility. The prospect of advancement. Learning something worthwhile. A sense of personal growth. Working for and with people one respects professionally. Being entrusted with important information or tasks.	Excessively close supervision that implies a lack of trust. Irrational policies. Frequent change in plans. Time-wasting administrative procedures. Seeing other team members humiliated, or being humiliated oneself. Work that is too easy. A sense of being taken for granted. Feeling that there is no merit in how different team members are rewarded. Romantic or sexual affairs between leaders and team members.

Morale in a project should be managed by using the same basic personal communication tools you use for everything else and especially:

Treat people fairly and use their skills.
Listen to people.
Build your relationship with the person as well as the job function.
Use common sense when deciding the necessary level of project documentation, and make sure that everyone understands why this is necessary and they feel comfortable with it.
Let people know that you notice good work and extra effort.
Make sure that people understand why their task is important.
Show that you trust and rely on the person.
Protect team members from demoralizing uncertainty over the project direction or justification.
Avoid romantic or sexual relations with project team members.

Should you conceal your own morale problems? Both enthusiasm and despair are infectious. A radiantly enthusiastic project manager can energize the team, making everybody's tasks seem easier and more enjoyable. But if you are despairing, be aware that the team will be guided by your attitude. This does not mean that you should ever conceal what is happening: it is essential that everyone on the team understands the facts of the situation so that their own project decisions reflect reality. But it does mean that despondency on your part will be amplified through the team, and will make problems worse.

Supervision, or monitoring and control

The project manager's responsibility to maintain the balance of the time/cost/performance trade-off means that project activities must be supervised. This is also known as monitoring and control, which is a knowledge area within project management that is covered in . Here we introduce certain aspects of monitoring and control that are especially relevant to the personal style and management skills of the project manager.

As project manager, you need to know whether the project is on track with its deliverables, and you will need to intervene if you believe that there is a problem. This amounts to little more than a restatement of the project manager's job title, so why spend time on it here? As is often the case, the principle is easy, but the practical implementation needs care.

Most project managers develop a personal system for supervising activities. Even more, they develop a sixth sense to warn them of when things are about to go off track. Some project managers take a formal approach with a lot of scheduled reporting. Others practise 'management by walking around' that is, just making a tour of the desks of the project team, chatting about whatever they are doing, and following their instinct about who to talk to next. Either approach is potentially viable, but each can be dangerous if they are applied without being adapted to suit individual team members. Some people need more supervision than others, and applying the same process to everyone risks annoying the senior people while leaving the junior people feeling adrift and unsure that their work is useful.

Sometimes, you may have to deal with someone who thinks that they know everything, but whose attitude in fact reveals that they do not even know how much else there is to learn. In these circumstances careful supervision is required to cover the technical gaps, but this individual probably believes that supervision is not needed. Some lateral thinking can help: use the project plan to insert some extra formal quality assurance checks in a way that is less personally threatening than constantly checking up on progress. At the same time, try to pair the individual with a more senior team member so that they can share tasks. This way, day-to-day supervision is delegated.

It is a basic instinct to want to check up on everything as a deadline approaches, just to make sure that it is all going to be alright. This is an excellent habit for a project manager to get into. But don't take it too far. There comes a point when everyone knows what has got to be done, all the inputs are available, and all that remains is to do the work; going round and checking again actually slows things down. The best thing you can do at this stage is simply to clear all the minor obstacles out of the way of the people who will do the work, and let them get on with it. If the person responsible for the last-but-one critical chain activity has to leave the office to get their car serviced, then your best action is not to check their work again, but to offer to take care of the car while they stay and get on with work!

The boundaries of responsibility

You can and should relax sometimes! One of the reasons why project management can be stressful is the uncomfortable feeling that you will be held responsible for other people's mistakes. You are the manager and you are responsible for delivering the project, and the buck stops with you. If someone on your team lets you down then it is still your problem, even when you did everything possible to help that person succeed. A project manager who publicly blames a team member for the delay in delivery looks foolish, so you may end up taking the blame yourself.

To some extent, this tension is a fact of life for any manager and you will have to live with it. But do not ruin your life by letting yourself feel responsible for every mistake that happens. If you have in fact delegated responsibility and authority together, then the person to whom the task was delegated must accept responsibility for the task outcome. If you suspect that an individual has not fully understood that their actions have a direct impact on the customer, then maybe let the person talk to the customer directly or at least take them to a meeting with the customer, so that they can experience the reaction at first hand. In the same way that a good project manager should never take the credit for somebody else's good work, you should find a way to allow team members to feel the negative consequences of their actions as well.

Top of Page