Friday 2/5/10 time 2:27 PM - Virpi Kanala

	The biggest challenge for a project manager is to get individual experts to work together as a team, says Virpi Kanala.

Product development has traditionally been associated with the development of a physical product. Today, the term is understood in a much wider sense: the outcome can be practically anything, from tangible products to financial instruments, from public services to software that improves corporate processes.

The share of company turnover dedicated to R&D varies from a couple of percent to fifty percent – a figure mainly seen with companies starting up operations. For example, Nokia's R&D expenditure, as quoted in the 09/2009 interim report, was slightly over ten percent of turnover.

Examples of successful product development can be found far and near. One of the most topical is iPhone, bringing huge media attention and enormous profit to Apple. At the time of the last depression in the 1990s, the concept of online banking was launched, which allowed banks to considerably cut their costs. The transfer of banking services to the Internet is a prime example of the "positive" effects of the depression: the tight economic situation forced banks to explore alternative operational models, which led to a downright revolutionary innovation.

Challenge I: The right people

Lying at the core of any successful product development project is a good team. Team members can be in-house or external: the key thing is that each area has a a person in charge who really manages his territory.

The company decides which tasks they wish to keep in-house and which areas require external special expertise. Acquiring external expertise makes sense if product development is starting up in a completely new area or using a new platform – and/or if the expertise will not be needed after the project is completed.

If a project is started in a new area, external support should be sought as early as possible. The later the external professionals come in on a project, the more difficult and expensive it is to correct errors that may have been made. Consultation efforts should be greater at the beginning of the project and smaller as knowledge and expertise accumulate within the organisation.

A project manager is above all an orchestrator – the expertise should come from the team. For a project manager, in-depth expertise can even prove to be a problem: a project manager too knowledgeable about details may easily become swamped by them and lose sight of the big picture.

The larger the project, the more experienced a good project manager should be. A senior project manager can grasp complex entities and find the best solutions for carrying out a particular project.

Being a senior may give you an edge, and so may being an external. If a project manager is a company employee, he may not necessarily be able to sufficiently distance himself from the customary ways of operating to analyse issues objectively. This results in the same formula being used repeatedly to carry out projects of very different nature.

Challenge II: From a group to a team

Probably the biggest challenge for a project manager is to get individual professionals work together as a team. A disparate group should be developed into a team that not only has a common goal but also a common view of how to achieve that goal.

Physical distance may prove a challenge in this processs: people often work at different sites or in different cities or even countries. In this case, communication takes place mainly by email (not spontaneously face to face), and if the time difference is great, you may have to wait until the next day to receive a reply. Getting to know the other team members is also challenging, if not impossible: with all the cost-cutting, travel - having face-to-face meetings and spending free time together – is not really possible.

Disconnection and a lack of relaxed communication show in project progress and sometimes also in the end result. There are delays in schedules, and when people do not know each other properly, the degree of commitment/efficiency also varies.

The minimum requirement for building a team is to arrange kick-off meetings in which team members get to know one another and the project. (If no-one else can travel, the project manager should make an attempt to meet team members personally.) Those who cannot make the meeting in person, can participate, for example, via videoconference.

The kick-off meetings should cover the project objectives, schedules and tools/methods; people and responsibility areas and the terminology used: all team members should speak the "same language".

Challenge III: A realistic project plan

One of the stumbling blocks of project plans is excessive optimism: the time and/or costs required are underestimated. Sometimes the optimism is due to the inexperience of the project manager. Sometimes the culprit is the project owner. Even if the estimate of the project manager was realistic, it simply is not accepted: the same content is required in a shorter period of time and using fewer people/less money.

The excessive optimism leads to a risky project schedule, within which tasks are performed in parallel and with overlapping schedules. When the project manager proposes such a plan, the risks – for example, key people becoming ill – should be marked by using a red "warning flag".

Very often, the steering group accepts the over-optimistic plan and forgets about the warning flags. When some of the risks are then realised, the situation needs to be reassessed and corrective action taken, which easily leads to delays in schedules and usually also additional costs.

Why companies make the mistake of repeatedly relying on over-optimistic project schedules is a mystery. Sometimes it can be intended: making people work harder under higher pressure. On the other hand, companies do not often make in-depth analyses of the success or failure of projects or project plans, let alone analyse them at the management levels. This means they do not learn from mistakes made earlier. Once the project is over, it will certainly be followed by "lessons learned" events, but they will only be attended by project team members.

When senior project managers are included in the making of the project plan – and when their views on the required resources and margins are heard – many unwanted surprises can be prevented.

Challenge IV: Chemistries

A good team spirit – commitment and motivation – has huge significance. When all of the necessary expertise is in place and the team has a common goal and intent, working is meaningful and productive. On the other hand, if the relationship between even two key people is not working or if they are not communicating at all, this can paralyse the entire team.

Swift reaction is needed, because the spirit, commitment and productivity of the entire team are in jeopardy. The project manager should take up the issue with the people concerned and other team members.

Ideally, tensions can be relieved by talking them out. But this does not always work. In situations like this, the only remaining option is to change team members.

Changes in personnel should not be undertaken lightly. However, when the changes are well justified and prepared, out-and-out miracles have been known to happen: what has taken three months to complete with the original set-up, has been managed in three weeks after the change.

Challenge V: Change management

Whatever the nature of the project, there will always be the need for changes. The project plan should also be updated if necessary (with the consent of the owners); the first version is "only" the best first estimate.

Content changes related to project results become topical when people have understood things differently and aimed at a "wrong goal". Sometimes the competence of the team is not up to par, and then the only option is to acquire assistance or complementary competence.

Changes may be required for various reasons and must be allowed for in advance. This means that change processes have to be defined right at the beginning of the project. How are changes introduced? Who accepts them? What has to be done immediately and what in the later phases? How do you sell this idea? What is essential, what is not? What is agreed, what is not? What does it mean, if the project deviates from the original plan?

Changing key people can also succeed, as long as things are handled properly. The change may cause a jolt and slow down project progress for a moment: the new recruit needs a little time for orientation and naturally is not immediately as productive as the previous person. This, however, does not constitute a reason to discontinue the project.

One of the requirements for success is efficient communication of information. This, in turn, will succeed, if processes, tools and documentation are in order. Documentation should therefore be made carefully, as difficult and demotivating as it often seems to be.

Challenge VI: Flow of information

The role of communications is emphasised when people work in different places. Being motivated and working towards a common goal require that the project owner, team members and important collaborators are kept informed about project schedules, changes along the way and achievements. This can be done, for example, in regular meetings and general information sessions, through the intranet and/or newsletters.

The corporate culture and channels available will decide how and through which channels messages are conveyed. Different people will require information from different perspectives, expressed in different terminology and also at different phases of the project. As a rule, you should give too much information rather than too little. The ones that are affected by the change will follow the communications more closely, while others will simply ignore it.

The end users should also be given information about the project and its schedules. This will prepare them for the future, facilitate their orientation to the new practices.

Challenge VII: Manageability

The larger the project, the more numerous the chunks it should be chopped into. For example, it may make sense to chop a two-year project into two, year-long sub-projects. The results of phase one cover a specific part of the content, and the next year-long phase covers the rest of the content. If a team puts in two years of product development without any interim results, the work produced may be completely misguided. There is no point in even trying to fix the world in one go.

Something that has proven to be a good practice is chopping a project into iterations. The project is sold by promising a specific subset of the content during phase one and the total of what the owner originally requested in phase two. The advantages of this method include manageability, minimisation of risk and utilisation of insights. For example, in software and service projects, feedback can be given while the project is progressing and objectives revised according to the experiences gained.

Virpi Kanala
Managing consultant
virpi.kanalamidagon.com