In an extract from his book The Project Manager's Toolkit, David
Shailer offers a step-by-step guide to creating perfect project
teams
Behind application development, there lies an often ignored fact:
computers don't produce computer systems, people do. In any kind of
project, people are the most important factor for success. However,
people are seen as the most adaptable resource in a project and,
therefore, anything goes.
Projects, it seems, can run and be staffed by whoever is available
at the time to satisfy the project manager's resource shopping-list
for "two analysts, six developers and two testers".
If the selection of the project team is haphazard, the project has
just incurred a critical, and sometimes fatal, risk. Unless the
project team is comprised of able, motivated individuals, the
project is likely to overrun in terms of time and cost and produce
a lower quality product.
So how should a company-critical project be staffed?
Step 1: Use your best people.
There is a wide productivity gap between the best IT performers and
the average or below average IT performers. It has been asserted
that the top 20% produce 50% of the finished system and the bottom
50% produce only 20%.
If your project is highly constrained by time, cost and quality, be
prepared to pay for the best. So what if they are double the cost,
they will actually do the job you want.
Step 2: Match jobs to skills and motivation.
Realise that managers don't motivate people. People can only
motivate themselves.
Rather than promote people to the level of their own incompetence,
allow people to progress into the area in which they wish to
specialise. This will allow people to maintain high levels of
motivation rather than being swapped to a job they don't actually
want and in which they struggle. The final demotivational blow will
come when they realise they have been "parked" with no possibility
of returning to their old position without loss of face.
It is the combination of skill and motivation that is important.
People become disaffected when they have been stuck maintaining a
system in which they are the only expert.
Step 3: Allow people to grow.
Once people satisfy their basic remuneration wants, they seek to
realise their full potential. A whole range of rewards needs to be
available, which people may select, possibly awarded on a
performance-related points system.
This could mean paying for technical or managerial studies,
providing opportunities to try out new skills/abilities, permit
sabbaticals for work or leisure pursuits. If you don't provide
them, key individuals could take steps to find them elsewhere. What
you have to do is create a climate of opportunity.
The biggest motivation "win-win" is where a person's goals overlap
with the organisation's goals. Individuals want to be associated
with success - a successful, well-run project and implementation is
extremely attractive. Staff will stay for more projects like
that.
Step 4: Build a balanced team.
Since most IT projects require a mix of activities, a team needs to
be a balanced set of skills especially if a large proportion of
them are specialists in their field: customer-facing consultants,
business/system analysts, developers, infrastructure gurus and so
on.
All these skills are in play for most of the project. Without them,
the project is going to be hampered by missing requirements or
scalability or inflexible design.
Also a team needs to be balanced in terms of personality and
temperament in order to promote team working, the sharing of
problems, dispersal of knowledge. Often the skills-mix is attended
to without regard to the personality mix.
Unbalanced teams will become less and less productive as politics
and "turf wars" take over. This leads to increased divisions in the
team.
This effectively dilutes the skills brought to bear across the
whole project as small groups develop their own solutions without
regard to each other.
When the partial solutions are brought together, they may not fit
together very well and there will undoubtedly be gaps - and an
inevitable second round of recriminations as to whose job it is to
fill the gaps.
Step 5: Manage the team mix.
It is extremely difficult to know at the moment of team creation
whether the mix is correct and will be successful - so it needs to
be monitored. Leaving someone on the team who doesn't fit is
eventually counterproductive.
Other team members will resent that no action has been taken and
resent that they have to cover for a non-functioning member. Note
that it is the team's perception of itself that is important here.
There may be some "social animal" members whose major contribution
is holding the team together.
Management may perceive these individuals as non-productive but to
the team, they are highly-valued jokers who keep team morale high -
remove them at your peril.
Changing the constituents of a team needs careful and sensitive
planning. A good manager must be prepared to balance the good of an
individual with the good of the team. If there is a misfit,
acknowledge your own responsibility in the formation of the team
and its continued operation.
In handling the extraction process, give the person "due process":
ensuring confidentiality, fairness and impartiality. Always listen
first before making a final decision.
Conduct a comprehensive fact-find and make sure to separate fact
from opinion. Do not be pressured, take time to "get it right". Let
the person know that you earnestly want the best for the other
person and work hard to find a new role in another area or project
that is a better guarantee of success (ie no pushing the person out
to be someone else's problem).
Finding the right niche for this person may mean beyond the
boundaries of the current organisation. If this is the case, it
should be faced honestly and with integrity. Provided that you aim
at finding what's best for the person rather than what's best for
the company, it can be promoted as a positive development rather
than a negative one.
Need the full toolkit?
The Project Manager's
Toolkit, by business systems analyst David Shailer, contains
practical checklists for systems development. The book is published
by Butterworth Heinemann, tel: 01865-888180 ISBN 0-7506-5035-4