People Issues

In order to succesfully execute software development projects, three equally important factors are critical. These are often stated as three P's: Product, Process, and People.

All project managers know that if the requirements/needs are not clearly defined and understood there is a great risk that the project will fail. Most project managers are also aware that if the development processes they use to develop a product are not appropriate, there is also a great risk of project failure. However, only few take active measures in order to secure that the people who take part in the product development process possess the right qualifications - and in particular: whether they are able to work productively together to bring about the project results.

At Brüel & Kjaer as well as in my previous employments I have been responsible for a number of product development projects, and I have worked on projects to improve software development processes. On all of these projects I have had ample opportunity to see what happens when proper interaction and collaboration among the project participants has been insufficient. I have therefore also been interested in improving the interaction and collaboration among people on project teams. The results of my activities on people issues will be presented below. The results of the other process improvement projects can be found via the main page.

Team Building

Project managers seldom have the opportunity to pick the persons for their project team. Normally it is a question of which people can be reassigned from other projects. It is very seldom that a team is composed from specific knowledge of whether the participants will be able to work together in a productive way.

It is therefore extremely important that you take steps to ensure that the team will get to know each others strengths and weaknesses through proper team building. To this aim I have found the Belbin team role concept [1] very effective. The quickest way to get information on the concept and the team roles is via the Belbin Associates' home page.

As a part of any project initiation (and in case of critical changes on the team) I recommend that each project participant get an assessment of their Belbin team role profile. This can be done in several ways - one of them is via Belbin Associates' home page. During the team building a profile of the team as a whole can be drawn using only the two-three most preferred roles from each participant. This way you will get a clear picture of the strengths and potential weaknesse of the team. You then discuss what the team can do to build on the strengths and reduce the weaknesses.

The best result is of course obtained when the atmosphere on the team is so open that all participants will show their 2-3 most preferred roles to the other members on the team so that the collaborative strengths of each member as well as the potential conflicts between participants can be discussed. However, I strongly advise against full openness about all details in each person's profile. It is not needed to draw the picture of the team profile, and it will also intrude on the individual person's privacy.

One way of presenting the team's (as well as an individual person's) profile is the following:

Normally the ME role is shown separately (e.g. not in the diagram) as it has no immediate "counterpart". I prefer, however, to draw the ME role as a circle in the diagram so that you can compare its strength to the other roles.

I can assist as a facilitator on team building activities where the interaction and collaboration of the team is uncovered through the use of the Belbin team role concept. In this context it should be mentioned that I am Belbin Team Role accredited.

Return to top of page.

Typical Profiles in Teams

Over the years I have had the opportunity to collect team profiles from a number of team building events in different project groups. When I compared the participants' Belbin profile across teams I have realised that certain patterns exist for different professional occupations like: Developers, Testers, Project Managers etc.

I report here on some patterns I have seen for four professions: Developers, Project Managers, Testers, and Test Managers. As all of these professional groups participate in development projects it is only natural that the Implementer role (the applier) appears as the most preferred role in all four professions.

For both Developers and Testers the second most preferred role is: Team Worker (the supporter). This role, however, is not very frequently preferred by the two manager groups. In stead the two manager groups both have as their second most preferred role: Shaper (the driver), which is not a very frequently preferred role among Developers and only preferred to some degree by Testers.

The third most preferred role by Developers is: Plant (the theoriser). However, this is the least preferred role by their Project Managers. Conversely the third most preferred role by Project Managers is: Resource Investigator (the lookout for opportunities), which is the least frequently preferred role of Developers, and one of the least frequently preferred roles of Testers.

The third most preferred role of Testers is: Completer Finisher (the perfecter), which is the least frequently preferred role among Test Managers, the least but one preferred among Project Managers, and also not a very frequently preferred role among Developers.

None of the four professional groups has as frequently preferred role the Monitor Evaluator role (the impartial judge). A fifth professional group has this role as its most frequently preferred role: the quality assurance and quality controllers in the organisation.

The conclusion is that all professions are necessary in order to make a project succesful and that quite naturally a number of conflicts may arise because the professions have different preferences. A correctly performed team building is therefore of utmost importance to avoid problems and achieve success.

The above comparison is based on the original eight-role Belbin model, where the Specialist role didn't exist. Of course it is not possible to know how the Specialist role will change the above observations.

Return to top of page.

Personal Influence

My experience from many years of work on process improvements in companies have taught me that processes and people issues play only a minor role in the mind of managers - both individual project managers as well as higher levels of management. A person responsible for processes therefore doesn't have the same posibilities to manage projects through the regular project management techniques based on power over the project resources. In stead it is important as a process manager to be able to use techniques that can get results through influence.

Bent Adsersen and I have combined our experiences from a long life as process consultants with techniques from Belbin and Satir into an interactive full day workshop titled: "Increasing Your Influence in the Organisation" [2]. At the workshop the participants will have opportunity to work with techniques that can increase their influence in the rest of the organisation. The workshop was given for the first time at EuroSTAR 2000 in Copenhagen and repeated at EuroSPI 2001 in Limerick.

Testers' position on development projects (as well as in the company) is very similar to people working with process improvement. Therefore it is interesting to study an example of how they can get more influence with developers. Brian Marick has written a good paper [3] on how testers can work effectively with developers on a project.

Return to top of page.

Seminars and Presentations

I give presentations on the Belbin team role concept [1] anywhere between 45 minutes and 2 hours depending on the need, and I facilitate team building activities where the team interaction and collaboration is uncovered through the use of Belbin's team roles.

Bent Adsersen and I also give a full day workshop titled: "Increasing Your Influence in the Organisation" [2]. The workshop was designed to be held at public conferences and seminars, but it can equally well be used at training events in test groups, and process and quality departments in a company.

Return to top of page.

Home Page -
Hjemmeside - mail@ottovinter.dk