Our chart shows one team leader for simplicity. There could be many, both amongst the IT team and the business users. Typically each team leader might look after a team of 6 to 8 people - maybe more, maybe less. What does a team leader do?
Detailed planning. Produce the task-by-task, day-by-day plan for each of their team members and liaise with other team leaders to ensure teams' plans interlock. In large projects a member of the project office may facilitate this plan interlocking but beware, the plans must remain the property of the team leaders: if the plans are the project office's the team leaders may not be quite so committed to achieving them.
Control and report team's progress. The team leader manages and reports upon the work of his team. We will cover the mechanics of this in the chapter on tracking, controlling and reporting.
Ensure the quality of the team's output. In much the same way that the project manager will be held accountable for the quality of the project's outputs, the team leader will be held accountable for the quality of his team's outputs. Neither diminishes each team member's quality accountability as we shall see in the quality management chapter.
Technical leadership. IT team leaders usually provide technical leadership, guidance and coaching to more junior team members. User team leaders similarly may have greater business experience than their team members. A good team leader will develop the skills of his team members, support and encourage them.
Later chapters will cover the mechanics of estimating, risk management, planning, tracking and so on. Whereas in a small project the project manager will do all of this himself, in larger projects the team leaders do much of it, so in a sense the next several chapters explain many of the tasks a team leader would perform.
The role title project leader is sometimes used as an alternative to team leader (and even sometimes as an alternative to project manager). In large projects, beneath the project manager may be one or more project leaders and beneath them team leaders. And even sub team leaders below them. It just depends on the scale of the project. Apparently the project team that built the biggest of the great pyramids was around 13,000 strong (peaking at 40,000 - and you thought your project was big!) and had a project organisation that any project manager today would recognise: sponsor, project director, sub-project managers, team leaders, sub-team leaders and tightly knit teams doing the actual work. Project management is not a new invention. How did they manage it without Prince2 and MSP?
Team leaders manage the work of their team. Team leading is a good first step on the project management ladder. You will learn much more about managing projects by being a team leader in a large project than you will by managing a small project - you will get experience of many more control processes because many of those processes simply aren't needed in small projects.
We mentioned in the previous chapter the benefit of UFD design team members being present in requirements definition
sessions, and technical designers participating in the user functions design step. Ideally The UFD design team members
will go on to become the team leaders in the technical design, build and test steps: this gives real continuity and
carries the understanding of the users' requirements right through the project's life.
(Not shown on the chart). This is a member of the project team who ensures that appropriate quality checking
activities are included in the project plan and that the team perform these tasks properly. This role will
be defined in the quality management chapter as will the role's position in the organisation chart.
Even the lowliest team member has some part to play in the management of a project:
The extent to which a team member can contribute to estimating and planning will obviously depend upon their
experience, but the team leader (or project manager in a small project) should involve all team members in planning. This not only exploits their knowledge and experience but helps get their buy-in and commitment to the plan: it's their plan, not one imposed upon them from on high.
This is not a project role yet line managers - the managers who own the people working on the project - can have a big influence on the project's chance of success.
Put negatively, if a line manager has agreed that one of his people can work full time on the project for, say, the first two weeks of June but when June comes around he reneges and doesn't make the person available, that could cause major problems for the project. If June is eight months away from the project's delivery date it's hard for business managers who have little or no experience of projects to believe that this can possibly have any significant impact on the project. But non-availability of that person could have severe knock-on effects to the project schedule, and if that sort of thing happens repeatedly the project will be in trouble.
So, being positive, what should line managers do?
Commit resources. At the start of each project stage line managers commit, in writing, to release people - where possible named individuals - full time or part time at specified times. This implies thorough planning by the project manager and usually involves a good deal of negotiation.
Make people available as committed. Don't renege!
Manage careers. If a line manager makes someone available full time for six months to work on a project he nevertheless remains that person's line manager and must keep in contact with them. Ensure they don't feel cast out, assure them there is a job for them to go back to when the project ends. Manage their career.
Reward project work. When a person's project assignment finishes reward them for that project work. For example, if they spent half of their time over the past year on a project or projects, half their appraisal should depend upon how well they did that project work. But how does the line manager know how well his people have performed on projects? He asks the project manager.
This is a classic symptom of a project-based culture. A person has a career or line manager who manages them as a person but does not manage their work. He rents them out to projects and appraises them on feedback from project managers and others.
Think about this from the project manager's perspective. Everyone working on your project team knows that their next appraisal, and maybe pay rise, depends upon what you say about them to their line manager. Do you now have some power and influence over those people? You bet. Some of the project team members might even work for another company - you should have the same arrangement with their line managers.
This implies that at the start of a project stage the project manager must not only agree roles
with everyone on the project but must also get their line managers to agree to base those
people's appraisals on his feedback. This implies a lot of up-front work by the project manager.
Which in a nutshell is one of the secrets of project success: a lot of up-front work.
One could list a dozen or more further project roles: risk manager, test manager, project accountant,
technical architect but since these are special cases of management roles and/or specialist team member roles
we will not clutter up the works by listing them though we will allude to some of them subsequently.
For example, the test manager gets a mention in the quality management chapter.
...next
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium
www.hraconsulting-ltd.co.uk
Home Sitemap Contact Us Project Management Articles Project Management Book