22
Int. J. Data Mining, Modelling and Management, Vol. 2, No. 1, 2010
A team building and team update system in a projectised organisation scenario Pasquale De Meo, Diego Plutino, Giovanni Quattrone and Domenico Ursino* DIMET, Università Mediterranea di Reggio Calabria, Via Graziella, Località Feo di Vito, Reggio Calabria 89122, Italy E-mail:
[email protected] E-mail:
[email protected] E-mail:
[email protected] E-mail:
[email protected] *Corresponding author Abstract: In this paper, we propose a system for the management of team building and team update activities particularly suited in a scenario where projectised organisations operate. Our system is characterised by three important features that appear particularly relevant in this scenario; specifically: 1 2
3
it defines and uses a model to uniformly represent and handle expert skills it is highly distributed and, therefore, is tailored to the typical organisation of the current job market where projectised organisations are intermediating most job positions it considers not only experts’ technical skills, but also their social and organisational capabilities, as well as the affinity degree possibly shown by them when they worked together in the past.
In this paper, we first describe our system in all details; then, we present the results of some experiments devoted to evaluate its performance; finally, we compare it with some related systems already proposed in the literature. Keywords: team building; team update; projectised organisations; curriculum vitae models; expert skill representation; data modelling; data management. Reference to this paper should be made as follows: De Meo, P., Plutino, D., Quattrone, G. and Ursino, D. (2010) ‘A team building and team update system in a projectised organisation scenario’, Int. J. Data Mining, Modelling and Management, Vol. 2, No. 1, pp.22–74. Biographical notes: Pasquale De Meo received his Laurea degree in Electrical Engineering from the University of Reggio Calabria in May 2002 and his PhD in System Engineering and Computer Science at the University of Calabria in February 2006. His research interests include user modelling, intelligent agents, e-commerce, e-government, e-health, machine learning, knowledge extraction and representation, scheme integration, XML, cooperative information aystems, folksonomies and social internetworking. Diego Plutino received his Bachelors in Telecommunications Engineering from the University of Reggio Calabria in July 2007. He is holding a Master in Telecommunication Engineering at the University of Reggio Calabria. His research interests include user modelling, intelligent agents, knowledge extraction and representation. Copyright © 2010 Inderscience Enterprises Ltd.
A team building and team update system
23
Giovanni Quattrone received his Laurea degree in Electrical Engineering from the University of Reggio Calabria in July 2003 and his PhD in Computer Science, Biomedical and Telecommunications Engineering at the University of Reggio Calabria in February 2007. His research interests include user modelling, intelligent agents, e-commerce, machine learning, knowledge extraction and representation, scheme integration, XML, cooperative information systems, folksonomies and social internetworking. Domenico Ursino received his Laurea degree in Computer Engineering from the University of Calabria in July 1995. From September 1995 to October 2000 he was a member of the Knowledge Engineering group at DEIS, University of Calabria. He received his PhD in System Engineering and Computer Science from the University of Calabria in January 2000. From November 2000 to December 2004 he was an Assistant Professor at the University Mediterranea of Reggio Calabria. From January 2005 he is an Associate Professor at the University Mediterranea of Reggio Calabria. His research interests include user modelling, intelligent agents, e-commerce, knowledge extraction and representation, scheme integration and abstraction, semi-structured data and XML, cooperative information systems, folksonomies and social internetworking.
1
Introduction
In the last years, job market and job organisation have undergone deep changes. In this scenario, one of the most relevant novelties was the proliferation of projectised organisations. Projectised organisations derive their name from the fact that they direct their efforts to do project work. Generally, a projectised organisation performs many projects (or subprojects) under the request of public or private firms; a project, in its turn, can be simultaneously performed by many projectised organisations, each responsible of a subproject. This way of operating, which leads to the transfer of some or all business activities of an organisation to external providers, is often known as outsourcing. This phenomenon has become a key element to provide competitive advantage to a business and is notably growing because it allows a firm to lower its costs and to manage a highly qualified human capital. Projectised organisations are often very large; their branches are distributed on national, continental and world basis and, at the same time, are connected each other in such a way as to cooperatively satisfy the exigencies of the whole organisation. In this context, experts are mostly recruited by these organisations that send them to their final customers to run specific project tasks. It often happens that an expert recruited by a branch is sent to another branch of the same organisation (possibly located in another country) to work in a project for the final customer. In addition, in many cases, it is possible to see that experts belonging to different projectised organisations work together in the same project of interest to a final customer. In the field of information and communication technology, consulting firms show an organisational model which is very close to that of projectised organisations. It is clear that, in this scenario, all activities cannot be centred on involved organisations, but they must be organised around projects. Project leaders enjoy a great
24
P. De Meo et al.
deal of authority and responsibility; in addition, they have at their disposal refined systems in charge of tracking work progresses and costs. In this scenario, the activities related to team building (i.e., the task of constructing a group of experts capable of handling and executing a project) and team update (i.e., the task of modifying the structure of a team in order to either substitute an expert leaving it or to improve its performance) play a crucial role; however, they are particularly difficult and delicate to be handled. Specifically, there are at least three main challenges to face. The first challenge regards the highly distributed context in which projectised organisations operate. In particular, branches belonging to different sectors are almost independent each other since they generally search for experts with different skills and, in any case, they often follow different market policies, typical of the sector where they operate. An analogous reasoning is valid for branches (possibly operating on the same sector) working on different regions or on different countries. In this last case, it could happen also that labour laws are different and these last clearly influence the branches’ way to operate. This problem becomes even more complex if experts of different projectised organisations are enrolled to work together in a project for a final customer. In this case, each organisation handles its experts on its own and do not allow the other ones to interfere in its decisions; only the final customer has a certain possibility to influence them. Clearly, a certain level of central management, especially among different branches of the same organisation, is necessary, especially if these branches belong to the same country; for instance, if a branch B1 needs an expert with some specific skills and another branch B2 has this expert and he/she is free at that moment, it is desirable that the expert is moved from B2 to B1. Another (loose) form of central management is that performed by the final customer when many projectised organisations work in one of its projects. The second challenge concerns the need of a standard formalism to represent expert skills and capabilities; in fact, if projectised organisations and/or their final customers use different ways to represent the skills of available experts and/or the skills desired for a project, then the comparison of experts and the matching between their skills and project requirements may become difficult and unclear; as a consequence, there is a high risk that constructed teams are not adequate for the projects assigned to them and, consequently, that final customers will be unsatisfied. The third challenge regards the type of expert skills to consider when a team is built. In fact, if a team must be flexible and can be composed by experts belonging to different projectised organisations and, possibly, coming from different countries, then technical skills, even if extremely important, cannot be the only criterion for choosing its members. In fact, other skills, such as social and organisational ones, appear equally important. As a confirmation of this claim, it is currently well-known that a team wholly composed by technically talented experts is often characterised by a negative form of competition because its components tend to assert themselves each other by nature; this fact creates stress among them, lowers the quality/frequency of their interactions and, ultimately, deters them to achieve the goals for which the team was built (LaFasto and Larson, 2001). On the contrary, if a team is harmonious and each member gained esteem from the other ones in previous working experiences, it is possible to expect that it will better accomplish assigned project goals. This paper focuses on these issues and aims at providing a contribution in this setting; in fact, it proposes a system that supports team building and team update activities for
A team building and team update system
25
large projectised organisations. Specifically, in the scenario into consideration, large projects must be executed. Each project is handled by a project leader and consists of many tasks; the various tasks of a project are executed by experts possibly belonging to different projectised organisations. Our system uses suitable profiles to describe technical, social and organisational skills of experts. In order to derive the entries of our expert profiles, we analysed the structure of various curriculum vitae (hereafter, CV) models [specifically, the British CV (McGee, 1999), the USA CV, the Indian CV, the CV model proposed by the European Community (Europass, http://europass.cedefop.europa.eu) and, finally, the CV model proposed by the HR-XML Consortium (http://www.hr-xml.org)]; this analysis led us to define an expert profile capable of well representing and handling his/her technical, social and organisational skills. By symmetry, a project is represented as a collection of tasks; each task is described by a profile indicating the technical, social and organisational skills it requires to an expert if he/she wants to be eligible to execute it. Finally, for each pair of experts, our system registers the affinity degree showed by them in the projects where they worked together in the past. Each time a new team must be built for handling a project, our system generates a set of potentially adequate teams. Candidate teams are constructed on the basis of project tasks’ requirements, as well as of technical, social and organisational skills of available experts. Two different methods have been defined for the construction of candidate teams; each of them privileges some aspects (e.g., fairness, efficiency, etc.) over the others. Once candidate teams have been constructed, our system selects, among them, that showing the highest value of internal cohesiveness. Our system is also capable of supporting team update activity; the algorithm underlying this task performs those updates that tend to optimise team performance and cohesiveness. Our system is capable of facing all the three challenges mentioned above. First, its architecture is modular and the various modules can be handled by different (and, in some cases, competing) organisations; this feature makes our system well-suited to operate in a largely distributed scenario, as that we have described above. Specifically, our system associates a module (called expert handler) with each expert and a module (called project handler) with each project; all these modules communicate with a team building handler and a team update handler. Team building handler has a reactive behaviour because it is activated when a project leader requires the construction of a team. Team update handler is both reactive and proactive; in fact, it can be required to perform a team update when this is strictly necessary (e.g., when an expert leaves a team); however, it can also proactively suggest a team update when it found that a new expert is available for a project and that he/she can improve the adequacy of the team currently assigned to the project without lowering the corresponding cohesiveness. The highly distributed architecture of our system makes it capable of facing the first challenge mentioned above. The exploitation of the features of various CV models to construct a model to represent expert and task profiles favours a uniform representation of both the skills owned by experts and those required by project tasks. Interestingly enough, thanks to the choice of using already existing CV models, skill representation adopted by our system is derived from real life. This choice allows our system to face the second challenge mentioned above. Finally, in order to determine the adequacy of an expert for a task, our system examines not only the technical skills of the expert and the technical requirements of the
26
P. De Meo et al.
task, but also the corresponding social and organisational skills and requirements. In addition, it does not necessarily select the team showing the highest technical adequacy with the project into examination; by contrast, it selects, among those teams which satisfy the project’s technical minimal requirements, that showing the highest internal cohesiveness. This last is measured on the basis of the behaviour shown by each pair of experts when they worked together in the past; in this way, in the construction of a team, the presence of persons who showed collaborative relationships in past projects is favoured, whereas the presence of persons who showed conflicting relationships is avoided. This behaviour allows our system to face also the third challenge mentioned above. The outline of this paper is as follows: Section 2 illustrates some popular CV models that have been considered for the definition of expert and task profiles. Section 3 illustrates how experts and projects are modelled in our system. Section 4 introduces parameters for measuring the adequacy of an expert for a task, the affinity between two experts and, finally, the cohesiveness degree of a team. The architecture of our system is described in Section 5. Sections 6 and 7 focus on team building and team update activities. Section 8 reports the experiments that we carried out to measure the performance of our system. Section 9 compares it with other related ones. Finally, in Section 10, we draw our conclusions.
2
An overview of CV models
In this section, we provide an overview of some models for representing the CV of a person. They have been strongly considered by us in the definition of our model for representing expert profiles. In our analysis, we focused on the typical structure of CVs used in UK, USA, India and the European Union; we considered, also, the CV model proposed by the HR-XML Consortium (http://www.hr-xml.org), a no-profit organisation involved in the development of tools to support human resource management in a variety of processes like the creation and the management of CVs, the management of payroll information and so on. A standard British CV (McGee, 1999) usually includes the following information: 1
contact details (e.g., address, phone number, e-mail address, personal website)
2
a personal and short profile of the candidate; this should be purely factual, i.e., it should be free of any opinion about his/her quality
3
a reverse chronological list of the candidate’s work experiences; for each job experience, the CV should illustrate the candidate’s role(s) and achievements
4
a reverse chronological list of the candidate’s education and training achievements; this list should include the candidate’s academic qualifications and professional certificates
5
personal details of the candidate (e.g., his/her birthdate, gender, driving license and so on)
6
a (optional) list of hobbies and interests.
A team building and team update system
27
In USA, the term ‘CV’ is often used only in the academic domain and the concept of CV, as it is intended in European countries, corresponds to the concept of résumé. Generally, a US résumé includes the following sections: 1
contact information
2
a list of objectives; for instance, a possible objective could be to obtain a permanent job position
3
a list of professional experiences, generally reported in a chronological order; for jobs requiring very specialised employees, these professional experiences can be reported in a functional order
4
a list of educational experiences
5
a list of foreign languages; usually the candidate specifies the knowledge level (advanced, intermediate or beginner) for each language and points out if he/she can translate, speak or write
6
a list of personal information, such as hobbies or interests.
In USA, employers are under legal obligation to be fair and to not discriminate against applicants because of their gender and race. As a consequence, unless appropriate and relevant to a specific job, a US résumé should not store information about gender, race, religion or marital status. Indian CV includes the following information: 1
contact details
2
a list of career objectives; specifically, the candidate should specify his/her professional goals and how they are linked to the goals of the company he/she would like to be hired; in addition, he/she should mention his/her potential strengths and should indicate the responsibility he/she is willing to handle
3
a list, in chronological order, of academic and educational skills
4
an indication of the native language and a list of foreign languages he/she knows; for each language, he/she should indicate the spoken and written level of proficiency
5
a list, in chronological order, of past and current employments; this list should include, for each job, its location and the candidate’s role.
An Indian CV must not contain information about birthplace, race and religion. The European Commission has promoted the Europass CV (Europass, http://europass.cedefop.europa.eu). It aims at providing people with tools and services capable of making their skills and competencies clearly understood in different countries in such a way as to support them to enrol in education or training programmes, to look for jobs or to get experience abroad. The main sections of a Europass CV are the following: 1
the expert’s personal information (i.e., his/her surname, first name, address, telephone, fax, e-mail, nationality, birthdate and gender)
28
P. De Meo et al.
2
his/her job target or occupational field
3
a list of his/her job experiences; for each experience, he/she should indicate dates, occupation or position held, main activities and responsibilities, name and address of employer, type of business
4
a list of educational/training experiences
5
a list of technical, social and organisational skills and competencies acquired by him/her in the course of his/her life or career, but not necessarily covered by formal certificates and diplomas
6
a list of information that he/she evaluates as relevant (publications or research, membership of professional organisations, military information, marital status, contact persons or referees)
7
a set of annexes that he/she can attach to his/her CV.
HR-XML Consortium (http://www.hr-xml.org) developed a library of XML schemas to represent a CV. The main components of HR-XML CV are: 1
the candidate’s contact details
2
the desired career path or professional objectives
3
a list of past and current employments
4
a list of academic degrees
5
a list of certifications and other qualifications
6
a list of foreign languages
7
a list of honours and awards.
One of the strength of the model developed by HR-XML Consortium is the usage of XML. Thanks to this choice, a candidate can produce a single file, in compliance with a suitable XML schema, to represent his/her competencies and desires. After this, various XSL style sheets may be applied to the source file to produce different versions of the CV. Moreover, if an individual is willing to apply for multiple positions referring to multiple companies, he/she can suitably instruct a processing tool by indicating what skills must be included in the current CV version. After this, the CV-processing tool generates the final CV depending on the received instructions. It is worth pointing out that, recently, HR-XML Consortium has defined a working group to link Europass specifications to its ones. The CV analysis described above has been considered to define a model for an expert profile. This model, described in Section 3.1, summarises the contribution provided by each standard. In addition, we recognised the strengths of the choice of XML performed by HR-XML Consortium and, then, decided to handle both expert and project profiles by means of XML technology.
A team building and team update system
3
29
Modelling experts and projects
3.1 Expert profiles In our system, a suitable profile is associated with each expert. As previously pointed out, we have derived this profile by examining various CV models currently exploited in organisations throughout the world. The profile EPi associated with an expert Expi can be represented as a tuple EPi = PSeti , TSSeti , SSSeti , OSSeti , where:
•
PSeti denotes the set of personal data of Expi , such as his/her social security number, surname, name, birthdate, birthplace, gender, nationality, telephone numbers, e-mail addresses and so on.
•
TSSeti represents the set of technical skills and competencies acquired by Expi (for instance, a technical skill may be ‘Java network programming’). An element TSik ∈ TSSeti is represented by a pair TSNameik , TSValueik , where TSNameik
is the name of the skill, whereas TSValueik is a number, in the real interval [0, 1], assessing the proficiency level of Expi in TSik . •
SSSeti indicates the set of social skills owned by Expi . These skills refer to the
aptitude of Expi of living and working with other people (for instance, a social skill might be the ability to adapt to multicultural environments). An element SSik ∈ SSSeti is represented by a pair SSNameik , SSValueik , whose semantics
is the same as that we have seen for TSik . •
OSSeti denotes the set of organisational skills associated with Expi . These skills
refer to the aptitude of Expi of coordinating and administrating people, projects and budgets (for instance, an organisational skill might be the ability to plan new activities or relieve stress at work). An element OSik ∈ OSSeti is represented by a pair OSNameik , OSValueik , whose semantics is the same as that we have seen for TSik .
3.2 Project profiles In our system, the concept of project plays a key role; it has been formalised in such a way as to make team building and team update activities precise and, at the same time, clear and easy. Specifically, a project Pr can be represented as a set of tasks TaskSet = {Task1 , Task 2 ,K ,Taskm } . A task profile TPj
is associated with a task Task j ; TPj
TPj = TID j , ReqTSSet j , ReqSSSet j , ReqOSSet j , where:
is a tuple
30
P. De Meo et al.
•
TID j is a code identifying Task j .
•
ReqTSSet j denotes the set of technical skills and competencies required
to perform Task j . An element ReqTS jk ∈ ReqTSSet j is represented by a pair ReqTSName kj , ReqTSValue kj , where ReqTSName kj is the name of the
technical skill, whereas ReqTSValue kj is a number, in the real interval [0, 1], specifying the lowest level of proficiency that an expert must have for performing Task j . •
ReqSSSet j represents the set of social skills necessary to perform Task j . An element ReqSS jk ∈ ReqSSSet j is represented by a pair ReqSSName kj , ReqSSValue kj , whose semantics is the same as that
we have seen for ReqTS jk . •
ReqOSSet j denotes the set of organisational skills necessary to perform Task j . An element ReqOS jk ∈ ReqOSSet j is represented by a pair ReqOSName kj , ReqOSValue kj , whose semantics is the same as that
we have seen for ReqTS jk . In order to support the reader, in Table 1, we report all the symbols exploited throughout the paper, along with the corresponding meanings. Table 1
The symbols used throughout the paper along with the corresponding meanings
Symbol
Meaning
Expi
An expert who can be enrolled to work for a project
EPi
The profile of Expi
PSeti
The set of personal data of Expi
TSSeti
The set of technical skills and competencies acquired by Expi
SSSeti
The set of social skills owned by Expi
OSSeti
The set of organisational skills associated with Expi
TSik
An element of TSSeti
SSik
An element of SSSeti
OSik
An element of OSSeti
Pr
A project
TaskSet
A set of tasks associated with a project
Task j
A project task
31
A team building and team update system Table 1
The symbols used throughout the paper along with the corresponding meanings (continued)
Symbol
Meaning
TPj
The profile of Task j
TID j
The code identifying Task j
ReqTSSet j
The set of technical skills and competencies required to perform Task j
ReqSSSet j
The set of social skills necessary to perform Task j
ReqOSSet j
The set of organisational skills necessary to perform Task j
ReqTS jk
An element of ReqTSSet j
ReqSS jk
An element of ReqSSSet j
ReqOS jk
An element of ReqOSSet j
( ) φ (SS , ReqSS ) φ (OS , ReqOS )
The technical correlation between TSik and ReqTS jh
The organisational correlation between OSik and ReqOS jh
ψt ( Expi , Task j )
The technical adequacy of Expi for Task j
ψt ( Expi , Task j )
The social adequacy of Expi for Task j
ψt ( Expi , Task j )
The organisational adequacy of Expi for Task j
Adq (Expi , Task j )
The adequacy of Expi for Task j
Af fD ( Expi , Expl )
The direct affinity between Expi and Expl
Af fI ( Expi , Expl )
The indirect affinity between Expi and Expl
Af f ( Expi , Expl )
The affinity between Expi and Expl
scilk
A number denoting how much Expi and Expl positively interacted in
φt TSik , ReqTS jh s
k i
o
k i
h j
h j
The social correlation between SSik and ReqSS jh
their k th project
W (k )
A function that determines the weight associated with scilk
Collil
The set of experts who collaborated with both Expi and Expl
NPil
The overall number of projects on which Expi and Expl worked together in the past
Sil
The weighted sum of the scores scilk obtained by Expi and Expl in their past collaborations
ExpSet
A set of experts composing a team
32
P. De Meo et al. The symbols used throughout the paper along with the corresponding meanings (continued)
Table 1 Symbol
4
Meaning
Chv (ExpSet )
A function which receives ExpSet and returns a number stating the corresponding cohesiveness
EPD
The expert profile database
AM
The affinity matrix
TPD
The task profile database
EIH
The expert interface handler
EH
The expert handler
TH
The task handler
PH
The project handler
TBH
The team building handler
TUH
The team update handler
Support parameters
4.1 A parameter for measuring expert-task similarities In this section, we introduce a parameter capable of measuring the adequacy of an expert Expi (having a profile EPi ) for a certain task Task j (having a profile TPj ). This parameter plays a key role in this reference context (Xidonas et al., 2009). Adequacy depends on three factors, namely the technical, social and organisational capabilities of Expi . We first introduce three functions for measuring these factors and, then, we show how the adequacy of Expi for Task j can be computed. The technical capabilities of Expi for Task j
can be computed by means
of a function ψt . In order to illustrate this function, it is necessary to preliminarily introduce a function φt , called technical correlation. Specifically, let TSik = TSNameik , TSValueik
be
a
ReqTS jh = ReqTSName hj , ReqTSValue hj
(
The technical correlation φt TSik , ReqTS jh
(
φt TSik , ReqTS jh
)
⎧TSValueik ⎪⎪ = ⎨ρ ⋅TSValueik ⎪ ⎪⎩0
technical
skill
of
TSSeti
and
let
be a technical requirement of ReqTSSet j .
) between TSik and ReqTS jh
is defined as:
if C ts = true if C ts = false and C tg = true otherwise
(1)
33
A team building and team update system
Here: •
ρ is a coefficient belonging to the real interval [0, 1].
•
C ts a Boolean condition which is true when sem TSNameik , ReqTSNamehj = true
(
and
TSValueik
≥ ReqTSValue hj ;
)
in all the other cases
C ts
is false. The function
sem (a , b ) is a Boolean function that receives a pair of strings a and b and returns true if and only if:
•
1
a and b are equal
2
a is a synonym of b.
(
)
C tg is a Boolean condition which is true when gen TSNameik , ReqTSNamehj = true
and TSValueik ≥ ReqTSValue hj ; in all the other cases C tg is false. The function gen (a , b ) is a Boolean function that receives a pair of strings a and b and returns true if and only if a represents a more general concept than b.
In order to verify if a and b are equal, sem applies the Porter algorithm and performs a stemming activity (Baeza-Yates and Ribeiro-Neto, 1999). In this way, it can compare the roots of the involved strings and, therefore, it can obtain more accurate results. A more complex activity is necessary for allowing sem to check if a is a synonym of b. In fact, in this case, sem relies on the usage of O -Net * (O*NET – Occupational Net, http://online.onetcenter.org/). This is one of the main data sources about occupational information; it identifies knowledge, skills and abilities required to perform a certain task and provides a hierarchical taxonomy defining the set of occupations across the world of work; such a taxonomy is periodically revised to keep up with the changing occupational landscape. Various approaches have been proposed in the literature to check if two concepts are semantically related by inspecting a taxonomy. A first class of approaches (often called edge-counting) models a taxonomy as a tree; a node of this tree represents a concept, whereas an edge linking two nodes indicates a superordination relationship between the corresponding concepts1. Edge-counting approaches compute the length of shortest path linking a pair of nodes a and b; the smaller this length is, the more similar the corresponding concepts are. A widely acknowledged drawback of edge-counting approaches is that they rely on the hypothesis that all taxonomy edges have the same weight. Such a hypothesis is often disproved in real taxonomies (Resnik, 1999). To overcome this drawback, other approaches, inspired to information theory, have been proposed. They use a taxonomy and associate a probability p (c ) with each concept c stored therein; p (c ) indicates the probability of encountering an instance of c in a document. A large size corpus is required to correctly compute concept probabilities. For instance, the approach of Resnik (1999) used the Brown Corpus of American English, a large collection of texts containing about 1,000,000 words; text genres range from news articles to science fictions. For each noun n appearing in the corpus, the concept c in the taxonomy corresponding to n was identified and n was counted as an occurrence of c. The probability p (c ) of c was computed as the ratio of the number of
34
P. De Meo et al.
nouns associated with c and the total number of nouns in the corpus. Clearly, the larger the corpus size is, the more reliable the corresponding probability computation will be. Among the approaches based on information theory, one particularly adequate for sem is that described in Lin (1998). In this approach, the similarity between two objects is measured as the ratio of the amount of information needed to state their commonalities and the amount of information needed to fully describe them. Such an approach is particularly fascinating because it is universal, i.e., it is not tied to a particular domain and does not make any hypothesis about the nature of the objects to compare. In addition, experimental results indicate that the similarity evaluations carried out by it are strongly related with human judgments. The function gen is quite easy to be implemented. In fact, it needs to inspect the hierarchical relationships in O -Net * to immediately verify if a string a denotes a more general concept than a string b. As for our definition of the function φt , it is based on the following intuitions: •
If TSNameik perfectly matches with (or is synonymous of) ReqTSName hj and TSValueik is at least equal to ReqTSValue hj , φt returns TSValueik (that measures
how much TSik is adherent to ReqTS jh ). It is worth pointing out that the choice to
(
set φt TSik , ReqTS jh
) to TSValueik
and not to one, in case C ts holds, is explained
by the advisability to determine not only if TSik is adequate for ReqTS jh , but also how much TSik is adequate for ReqTS jh . In fact, an organisation clearly prefers to
assign a given task to the expert having the highest skills necessary to face it (if all the other underlying constraints are satisfied) in such a way as to optimise its human
(
resource investment. If φt TSlk , ReqTS jh
) would be set to one (instead of to
TSValuelk ) for all the experts Expl such that TSValuelk ≥ ReqTSValue hj , then
all the differences among the various experts would be flattened (contrarily to what generally happens in the organisations); as far as this fact is concerned the lower ReqTSValue hj is the more pronounced this flattening process will be. •
If TSNameik is more general than ReqTSName hj and TSValueik is at least equal to ReqTSValue hj , φt returns ρ ⋅TSValueik , with 0 < ρ < 1. ρ was introduced to favour those experts who exactly know a skill required by a task w.r.t. those ones who have a generic knowledge of the topics required by the task itself. To better clarify this concept, consider a task requiring the knowledge of ‘JSP’ and assume that an expert, say Expi , owns this skill, whereas another expert, say Expl , owns the skill ‘Java’. In this case, Expl is somewhat eligible to carry out the task into consideration, but Expi appears much more adequate than Expl ; ρ has been introduced to encode this reasoning; in fact, it allows that exact match and synonym relationships between the skills of an expert and those required by a task are privileged over generalisation relationships.
35
A team building and team update system
It is worth pointing out that φt can be also nicely defined by means of implication operators as follows:
(
φt TSik , ReqTS jh
)
(
)
⎧C s → φ TS k , ReqTS h = TSValue k t i j i ⎪ t ⎪ s g k h = ⎨¬C t ∧C t → φt TSi , ReqTS j = ρ ⋅TSValueik ⎪ ⎪¬C ts ∧ ¬C tg → φt TSik , ReqTS jh = 0 ⎩
(
)
(
(2)
)
Another nice way to define φt exploits fuzzy logic operators. Specifically, let
(
)
(
)
μ1 = sem TSNameik , ReqTSName hj , μ2 = gen TSNameik , ReqTSName hj , μ3 = ρ, μ4 =
(
TSValueik
≥ ReqTSValue hj
)
and
μ5 = TSValueik
be five fuzzy expressions;
let AND (resp., OR) be the AND (resp., OR) Zadeh operator defined as
( μΑ AND μΒ ) = min {μΑ , μΒ } ( resp., ( μΑ OR μΒ ) = max {μΑ , μΒ })
then
(
φt TSik ,
ReqTS jh
(
(Zadeh, 1965),
) can be defined as:
)
φt TSik , ReqTS jh = ( μ1 OR ( μ2 AND μ3 ) ) AND μ4 AND μ5
(3)
Starting from φt , the function ψt (called technical adequacy of Expi for Task j ) is defined as follows: ψt ( Expi , Task j ) =
∑
ReqTS jh ∈ReqTSSet j
{ (
maxTS k ∈TSSet φt TSik , ReqTS jh i
i
)}
ReqTSSet j
(4)
The output of ψt belongs to the real interval [0, 1]; the higher it is, the more adequate Expi will be for Task j . The formula for ψt can be explained as follows: in order to be executed, a task Task j requires a set of skills; an expert Expi can execute Task j if he/she has skills related to those required by Task j . For instance, in the context of software firms, a requirement of Task j could be the knowledge of an object-oriented language and an expert Expi could own more skills (for instance, the knowledge of Java, the knowledge of C++, the knowledge of C#) to satisfy this requirement. Formally, given a specific skill ReqTS jh required by Task j , Expi could own more skills TSik1 ,K ,TSikv capable of
(
)
(
fulfilling ReqTS jh . The values of the functions φt TSik1 , ReqTS jh ,K, φt TSikv , ReqTS jh could be exploited to assess the contribution that the possession of provide to the fulfilment of
ReqTS jh .
TSik1 ,K ,TSikv
)
could
These numerical values must be suitably combined
to obtain a unique aggregated value. For this purpose, we adopt an optimistic view and use the max function as aggregation operator. Conceptually, this is equivalent to say that if Expi owns multiple skills capable of satisfying ReqTS jh , then the selected skill will
36
P. De Meo et al.
be that in which he/she shows the highest proficiency level. For instance, in the previous example, if ReqTS jh represents the knowledge of an object-oriented language, then the selected skill for Expi would be that language, among Java, C++ and C#, best known by him/her. This reasoning is repeated for all the skills of ReqTSSet j and allows ReqTSSet j numerical values to be obtained. These values are, then, averaged and the obtained value represents the technical adequacy. Observe that both the features and the behaviour of ψt (in particular, its attempt to match expert skills and task requirements) are closely related to those of the matchmaking approaches (Dumas et al., 2004; Kaufer and Klusch, 2006; Pastore, 2008; Sioutas et al., 2008; Kuster et al., 2007; Balke and Wagner, 2004; Maamar et al., 2004; Straccia et al., 2009; Colucci et al., 2007). These approaches have been largely studied in the literature. They generally operate on web services and aim at finding the best available matches between demands and supplies in such a way as to find the most suitable services for a requester. Usually, they accept a string of keywords and return those web services whose name or description contains accepted keywords. In an analogous fashion, it is possible to define the social correlation function φs , the organisational correlation function φo , the social adequacy function ψs and the organisational adequacy function ψo as follows:
(
φs SSik , ReqSS jh
(
)
φo OSik , ReqOS jh
⎧SSVavlueik ⎪⎪ = ⎨ρ ⋅ SSVavlueik ⎪ ⎪⎩0
)
ψs ( Expi , Task j ) =
ψo ( Expi , Task j ) =
if C ss = true if C ss = false and C sg = true otherwise
⎧OSVavlueik ⎪⎪ = ⎨ρ ⋅OSVavlueik ⎪ ⎪⎩0
∑
ReqSS jh ∈ReqSSSet j
(5)
if C os = true if C os = false and Cog = true
(6)
otherwise
{ (
maxSS k ∈SSSet φs SSik , ReqSS jh i
i
)}
(7)
ReqSSSet j
∑
ReqOS jh ∈ReqOSSet j
{ (
maxOS k ∈OSSet φo OSik , ReqOS jh i
i
)}
ReqOSSet j
Here: •
C ss (resp., Cos ) is a Boolean condition which is true when sem(SSNameik , ReqSSNamehj ) = true (resp., sem(OSNameik , ReqOSNamehj ) = true)
and SSValueik ≥ ReqSSValue hj (resp., OSValueik ≥ ReqOSValue hj ); in all the other cases, C ss (resp., C os ) is false.
(8)
37
A team building and team update system
•
C sg (resp., C og ) is a Boolean condition which is true when gen(SSNameik , ReqSSNamehj ) = true (resp., gen(OSNameik , ReqOSNamehj ) = true)
and SSValueik ≥ ReqSSValue hj (resp., OSValueik ≥ ReqOSValue hj ); in all the other cases, C sg (resp., C og ) is false. Also, the characteristics and the underlying philosophy of ψs and ψo are closely related to those of matchmaking approaches. As previously pointed out, the adequacy Adq ( Expi , Task j ) of an expert Expi for a task Task j
is a function of ψt ( Expi , Task j ) ,
ψs ( Expi , Task j )
and
ψo ( Expi , Task j ) . There are many possible ways to define this function. In particular,
one of these consists of defining it as a conjunctive aggregation of ψt , ψs and ψo and by requiring that all the corresponding skills must be owned by Expi to at least some degree. In order to satisfy this last requirement, it is possible to exploit t-norms. A t-norm is a binary operation used in the context of probabilistic metric spaces and in multivalued logic, especially in fuzzy logic. A t-norm is a function T : [0, 1] × [0, 1] → [0, 1] which satisfies the following properties: •
T (a , b ) = T (b , a ) (commutativity property)
•
T (a , b ) ≤ T (c , d ) if a ≤ c and b ≤ d (monotonicity property)
•
T (a , T (b , c ) ) = T ( T (a , b ) , c ) (associativity property)
•
T (a , 1) = T (1, a ) = a (the number 1 acts as identity element)
•
T (a , 0) = T (0, a ) = a (the number 0 acts as null element).
t-norms frequently occur in several disciplines of mathematics, since the corresponding class contains many familiar functions. Well-known t-norms are the following: •
⎧⎪min{a , b} if max{a , b} = 1 T 0 (a , b ) = ⎨ otherwise ⎪⎩0
•
T1 (a , b ) = max{0, a + b − 1}
•
T 2 (a , b ) = a ⋅b
•
T 3 (a , b ) = min{a , b}.
Given any t-norm T , the following inequality is always valid: ∀a , b ∈ [0, 1] → T 0 (a , b ) ≤ T (a , b ) ≤ T 3 (a , b )
(9)
By exploiting t-norms, the adequacy Adq ( Expi , Task j ) of Expi for Task j can be defined as:
38
P. De Meo et al.
(
(
))
Adq ( Expi , Taskj ) = T ψt (Expi , Taskj ) , T ψs ( Expi , Taskj ) , ψo ( Expi , Taskj ) (10)
where T is any existing t-norm. As previously pointed out, the adequacy defined by this function is not ‘compensative’. In fact, even if we choose to use T 3 , which is the largest existing t-norm, a quite poor evaluation for one factor (for instance, social skills) cannot be compensated by the evaluations of the other factors (for instance, technical and organisational skills), even if these last were very high. A completely different way to define Adq ( Expi , Task j ) consists of exploiting a ‘compensative’ function in such a way that a poor evaluation of one factor can be compensated by possible very high evaluations of the other ones. A reasonable ‘compensative’ function is the weighted mean. In this case, Adq ( Expi , Task j ) would be defined as: Adq ( Expi , Task j ) = α ⋅ ψt ( Expi , Task j ) + β ⋅ ψs ( Expi , Task j ) + γ ⋅ ψo ( Expi , Task j )
(11)
where the sum of the weights α, β and γ must be equal to one. We have chosen to adopt this last function for the definition of Adq ( Expi , Task j ) because, in our opinion, the adequacy defined by it fits very well the characteristics of the current projectised organisations. In fact, differently from classical work scenarios, characterised by a very static work organisation (where people always perform the same tasks), projectised organisations are very dynamic; the teams built for a project are generally heterogeneous and can change frequently over time, depending on the organisation’s exigencies of optimising the assignments of its human resources to the various projects it handles. This very flexible context requires a flexible management of both experts and the corresponding task assignments. A function like a t-norm for the definition of Adq appears too rigid to handle such a scenario. In order to better understand this fact, assume that an expert must be chosen for a very technical task in a project. Assume that the technical adequacy ψt and the social adequacy ψs of a candidate Expi are very high, whereas his/her organisational adequacy ψo is low. A definition of Adq based on t-norms would lead to discard Expi for the task into consideration, which is probably a wrong choice if we consider that this task is very technical and that the technical adequacy of Expi is very high. A function like a weighted mean is more adequate for the definition of Adq in this context since it would compensate the low values of ψo for Expi with the extremely high values of ψt and would not lead to discard Expi , differently from what it would be performed by an Adq based on t-norms. Clearly, it is important that the compensation capability of ψt , ψs and ψo is not excessive. In our case, this is guaranteed by the definition of the functions φt , φs and φo which return zero if the corresponding correlations are lower than a minimum threshold (thus, making a compensation impossible), as well as by a suitable definition of the values of the weights α, β and γ in Adq .
39
A team building and team update system
As for this last problem, we performed some experiments to set the values of α, β and γ (see Section 8.3). At the end of these experiments, we obtained that the best configuration for them is α = 0.50, β = 0.25 and γ = 0.25.
4.2 A parameter for measuring expert-expert affinities In this section, we define a parameter measuring the affinity of two experts, i.e., their agreement in working together on the same project. In order to compute this parameter, we borrowed some ideas from reputation and trust metrics. Specifically, we considered some ideas at the basis of the SPORAS system (Zacharia et al., 2000), since they are widely applied in the reality. In SPORAS, human or artificial agents start with a minimum and conventional value of reputation. Each time two agents interact, each of them provides a feedback which the system uses to update the reputation of the other. Our approach for the computation of the affinity of two experts operates as follows. Let Expi and Expl be two experts working together in the same project. Assume that, once the project terminated, the project leader is in charge of assigning a score scil to them; this score is a number, belonging to the real interval [0, 1], denoting how much they positively interacted in the fulfilment of project goals. The affinity function Af f takes a pair of experts Expi , Expl as input and returns a number in the real interval [0, 1] as output. Since the affinity of two experts can change over time, Af f must consider the whole history of experts’ past interactions. Let NPil be the number of times Expi and Expl worked together in the past. In order to compute Af f ( Expi , Expl ) , three main cases should be considered: •
Direct interaction. This case happens if Expi and Expl worked together at least
once in the past and, then, NPil ≥ 1. Since we have a first hand information about
the past cooperation of Expi and Expl , we call direct affinity ( Af fD ) the function
assessing their affinity in this case. In the computation of the direct affinity of two experts, it is reasonable to assume that their latest interactions are more relevant than the oldest ones. This intuition can be formalised by associating a weight to the score scilk assigned by the project leader to Expi and Expl during their k th interaction; this weight should increase as long as the number of projects goes on. For this purpose, we used an approach based on the reinforcement learning theory (Mitchell, 1997) to compute the direct affinity Af fD between Expi and Expl ; specifically, Af fD is defined as:
∑ W (k ) ⋅sc (Exp , Exp ) = ∑ W (k ) NPil
Af fD
i
l
k =1 NPil
k il
(12)
k =1
Af fD ( Expi , Expl ) ranges in the real interval [0, 1]. In equation (12), W (k ) is a
function that determines the weight associated with the scilk scores. Observe that
40
P. De Meo et al. W (k ) depends on the order, instead of on the time, of the interactions between Expi and Expl . This choice has been made to avoid an excessive penalisation of the
oldest interactions between Expi and Expl w.r.t. the most recent ones, especially in those cases when a long time interval exists between these interactions. If some interactions between Expi and Expl overlapped in time, their order is determined by the timestamp when they started. We adopted a linear function for W (k ), i.e., we defined W (k ) = k in such a way as to obtain a linear decay between the old interactions and the new ones. Clearly, if necessary, a different definition of W (k ) could be adopted; for instance, W (k ) = log (k ) could be chosen if a lower penalisation is desired, whereas W (k ) = k 2 or W (k ) = k 3 could be adopted if a higher penalisation is chosen. •
Indirect interaction. This case happens if Expi and Expl never worked together
in the past and, then, NPil = 0. In this case, since we cannot handle a first hand information of the cooperation of Expi and Expl , we call indirect affinity Af fI the function assessing their affinity. In order to determine the value of Af fI , we borrowed some concepts derived from social networks field to compute the similarity between two nodes. Specifically, if we indicate by
{
}
Collil = Expq ∈ ExpSet NPiq ≥ 1 ∧ NPql ≥ 1 the set of experts who collaborated
with both Expi and Expl , then the indirect affinity Af fI between Expi and Expl is computed as:
Af fI ( Expi , Expl ) =
∑
⎛ Af fD ( Expi , Expq ) + Af fD ( Expq , Expl ) ⎞ ⎜ ⎟ Expq ∈Collil ⎝ 2 ⎠ (13) Collil
In other words, for each expert Expq ∈ Collil who worked with both Expi and Expl , the average of the direct affinities Af fD ( Expi , Expq ) and
Af fD ( Expq , Expl ) is computed. All the averages, thus, obtained are, in their
turn, averaged to obtain a unique value belonging to the real interval [0, 1]. •
No interaction. If NPil = 0 and Collil = 0, / then we have neither a direct nor an indirect information to compute the affinity between Expi and Expl ; in this case, we set this affinity to zero. Such a choice (analogous to the corresponding one of SPORAS) is compliant to what happens in real cases. In fact, if two experts never worked together and they are ‘junior’ (and, therefore, they worked in a small number of projects and collaborated with a small number of experts), a human resource manager usually prefers to assign them to different projects and to avoid the construction of teams with many novice components who do not know each other.
By putting together all these considerations, we obtain the final formula for affinity:
41
A team building and team update system ⎧Af fD ( Expi , Expl ) if NPil ≥ 1 ⎪⎪ Af f ( Expi , Expl ) = ⎨Af fI ( Expi , Expl ) if NPil = 0 and Collil ≠ 0/ ⎪ if NPil = 0 and Collil = 0/ ⎪⎩0
(14)
Af f belongs to the real interval [0, 1] and is symmetric w.r.t. Expi and Expl since Af f ( Expi , Expl ) = Af f ( Expl , Expi ) .
Interestingly enough, Af fD (and, indirectly, Af f ) can be used to control the exploration/exploitation trade-off typical of reinforcement learning (Mitchell, 1997). We recall that, in a reinforcement learning scenario, an agent has to exploit what it already knows in order to obtain reward, but it also has to explore in order to make better action selections in the future. Neither exploitation nor exploration can be performed alone. The agent must try a variety of actions and progressively favour those appearing the best. In our case Af fD considers the past interactions of two experts and progressively refines the value of their affinity degree. In this way, it becomes more and more capable of indicating if two experts are affine (and, therefore, it is worthwhile that they work together) or, conversely, if they are not affine (and, therefore, it is better to put them in different teams). If we consider the whole set of experts, Af f becomes more and more capable of deciding how to organise them in teams. It clearly emerges, from this reasoning, that Af f is capable of partly controlling the exploration/exploitation trade-off in the reinforcement learning scenario underlying our system.
4.3 A parameter for measuring the cohesiveness of a set of experts The overall affinity of two experts is the core for the computation of the cohesiveness degree associated with a set of experts and, consequently, for the computation of the cohesiveness of a team. For this purpose, it is possible to define a function Chv that receives a set ExpSet of experts and returns a number, in the real interval [0, 1], stating the corresponding cohesiveness. Chv considers all pairs of experts that can be constructed from ExpSet and suitably combines the corresponding overall affinities. A possible way to combine these affinities could consist in averaging them. Due to the symmetry of the function Af f , the overall affinity between two experts Expi and Expl can be considered only once; therefore, it is possible to examine ExpSet ⋅ ( ExpSet − 1)
pairs instead of 2 consequence, Chv can be defined as follows: Chv (ExpSet ) =
∑
i =1.. ExpSet −1
∑
ExpSet ⋅ ( ExpSet − 1)
l =i +1.. ExpSet
Af f ( Expi , Expl )
ExpSet ⋅ ( ExpSet − 1)
pairs.
As
a
(15)
2
The average function generally provides a reliable estimation of the cohesiveness of a team and appears well-suited for Chv in most cases. In some situations, it could be necessary a more restrictive definition of Chv ; for instance, if a team must consist of
42
P. De Meo et al.
experts coming from different projectised organisations, if it must operate in a very stressful scenario with very strict deadlines, then if two of its members are conflicting, their conflict could easily propagate to the whole team and the project could fail. In very critical scenarios, it would be better to adopt a more restrictive definition of Chv which sets to zero the value returned by this function if there is a pair of experts showing an affinity lower than a certain threshold, independently of the affinities of the other pairs of experts. In all the other cases, Chv would be set to the average function, as in equation (15). By contrast, if a team is composed exclusively by members belonging to the same projectised organisation, if the scenario in which it operates is not stressful and the deadlines are distant, then if only two members of a team show quite a low affinity whereas the other ones appear very cohesive, it could be possible to adopt a less restrictive definition of Chv , for instance, a definition which applies the average function but does not consider, in the computation of the average, the highest and the lowest affinities among pairs of team members. We have chosen to use the definition of Chv provided in equation (15). However, a user is allowed to choose one of the other two function definitions if he/she considers it more adequate to his/her application scenario. Equation (15) shows that Chv strongly relies on Af f . As a consequence, Chv is mainly based on pairwise interactions between experts. Observe that, in principle, the interaction between two experts might be influenced by the presence or the absence of a third expert (this fact is widely common and investigated in game theory). However, in our application scenario, the presence of third experts cannot be considered since, even in those cases in which the presence of a third expert, say Expm , might highly improve the interaction of two experts Expi and Expl , if Expm does not own the skills necessary to satisfy the requirements of the tasks to handle, he/she cannot be inserted in the corresponding team. However, we observe that there is a case in which, even if indirectly, we consider the role of a third expert in improving the interaction of Expi and Expl . This happens when NPil = 0 and Collil ≠ 0; in fact, in this case, Af f ( Expi , Expl ) = Af fI ( Expi , Expl )
[see equations (13) and (14)]. This case is useful in that it considers the role of all the experts who worked with Expi and Expl and, at the same time, the corresponding computations are limited within the function Af f and cannot lead to the insertion, in a team, of experts who do not own the skills necessary to satisfy task requirements.
5
System architecture
The architecture of our system is shown in Figure 1. It refers to a scenario in which p projects must be handled by n experts (possibly enrolled from different projectised organisations); each project is uniquely assigned to a project leader who is in charge of insuring the fulfilment of its goals. Each project leader can simultaneously handle more projects. In addition, in compliance with the definition of project that we have provided in Section 3.2, we assume that each project consists of a certain number of tasks. As shown in Figure 1, our system requires the presence of two databases, namely:
A team building and team update system
•
43
The expert profile database (hereafter, EPD ); it stores both expert profiles and a
support data structure called affinity matrix (hereafter, AM ). AM is an n × n matrix; its generic element AM [i , l ] consists of a pair NPil , Sil , where: 1
NPil represents the overall number of projects on which Expi and Expl worked together in the past
2
Sil stores the weighted sum of the scores obtained by Expi and Expl in the
past; in other words, Sil =
∑
NPil k =1
W (k ) ⋅ scilk .
EPD is implemented by means of the XML technology.
•
The task profile database (hereafter, TPD ); it stores the profiles of the tasks associated with the projects into consideration. Analogously to EPD , also, TPD is implemented by means of the XML technology.
Figure 1
Architecture of our system (see online version for colours)
The handlers operating in our system are the following: •
The expert interface handler (hereafter, EIH ); there is an EIH for each expert supporting him/her in the insertion/update of his/her profile.
•
The expert handler (hereafter, EH ); it is associated with EPD and is in charge of handling all activities someway concerning the access to the corresponding data.
44
P. De Meo et al.
•
The task handler (hereafter, TH ); it is associated with TPD and supports all activities someway concerning the access to the corresponding data.
•
The project handler (hereafter, PH ); it is devoted to support all activities concerning the management of a project. Specifically, given a project, it allows:
1
the insertion of data about it
2
the activation of either the construction or the update of the corresponding team
3
the registration, after its execution, of the affinity scores for each pair of experts belonging to the corresponding team (see Section 4.2)
4
the registration of the new skills earned by each expert during its execution
5
the update of the proficiency level of each expert for those skills acquired or improved by him/her during its execution.
•
The team building handler (hereafter, TBH ); it is in charge of building the best team for a new project. The algorithms implemented by TBH to carry out its activities are illustrated in detail in Section 6.
•
The team update handler (hereafter, TUH ); it is in charge of incrementally updating a team for a project. It can be required to perform a team update by the corresponding project leader, via the associated PH , when it is necessary to carry out some modifications on an already existing team (e.g., when an expert leaves it and it is necessary to find another one who substitutes him/her). However, TUH can also proactively suggest a team update when it has found that a new expert is available for a project and that he/she can improve the adequacy of the team currently assigned to it without lowering the corresponding cohesiveness. The algorithms underlying TUH are illustrated in detail in Section 7.
In order to describe the behaviour of our system, two possible operating scenarios, namely the construction of a new team and the incremental update of an existing one, must be considered. In the first scenario, the behaviour of our system is as follows: at the beginning, a project leader activates the corresponding PH and provides it with information about the new project and the corresponding tasks. The PH sends task information to the TH which is in charge of storing it in TPD. After this, the PH activates the TBH to construct a team for the new project. The TBH first activates the EH and requires the profiles of the experts who could be involved in the project; then it activates the TH and requires the profiles of the project tasks into consideration. After this, it applies the algorithms described in Section 6 and constructs a team for the project. Finally, it sends its results to the project leader via PH . At the end of the project execution, the project leader is required to fill a form in order to assign an affinity score scil to each pair Expi , Expl of team members. The form that the project leader must fill contains the following questions:
45
A team building and team update system
1
Did Expi and Expl share information each other?
2
Did the presence of Expi (resp., Expl ) support Expl (resp., Expi ) to better reach his/her goals?
3
Were the work styles of Expi and Expl similar or, at least, compatible? Were Expi and Expl capable of effectively smoothing possible work style differences?
4
Were the characters of Expi and Expl similar or, at least, compatible? Were Expi and Expl capable of effectively smoothing possible character differences?
5
Did Expi and Expl show listening capability and empathy each other?
6
Did Expi and Expl show a collaborative and friendly behaviour?
7
Was Expi (resp., Expl ) open to unsolicited ideas and opinions of Expl (resp., Expi ) ?
The project leader is asked to answer each question by assigning a score in the integer interval [0, 5] to it; scil is obtained by computing the average of these scores. Scores are used to update the affinity matrix AM stored in EPD. The update of AM is carried out as follows: let Expi , Expl be a pair of experts; let scilnew be the score that the project leader assigned to Expi , Expl let AM
old
[i , l ] =
NPilold ,
Silold
(resp., AM
new
after the project termination;
[i , l ] = NPilnew , Silnew ) be the entry
of AM before (resp., after) the project execution; the values NPilnew and Silnew are computed as follows: NPilnew = NPilold + 1
Silnew = Silold +W ( NPilnew ) ⋅ scilnew
(16)
Once AM has been updated, the project leader must fill a last form to specify, for each expert, the skills acquired or improved by him/her during the project execution. This information is stored in the EPD via PH and EH . As far as the second reference scenario is concerned, three possible situations might occur, namely: 1
an expert leaves a team
2
a new expert is available and his/her skills are particularly adequate for one or more project tasks
3
one or more tasks must be added to the current project.
The first and the third situations make the current team obsolete; in these cases, TUH is activated by the project leader; its behaviour is, therefore, reactive. By contrast, the second situation does not necessarily impose a team update; in fact, it requires a study to verify the advantages and the disadvantages arising by the team update; in this situation, TUH shows a proactive behaviour since it activates the verification specified above when it recognises the availability of a new expert.
46
P. De Meo et al.
Observe that this team update problem might be seen as a special case of the team building problem examined above; as a consequence, it would be possible to determine a new team configuration by ignoring the existing one. However, in a real scenario, when a team is updated, managers try to minimise the modifications on task assignments; in fact, modifications are performed only if they are strictly necessary or if their advantages significantly exceed their disadvantages. This behaviour is explained by the following reasons: 1
the network of human relationships established among team members is a value added that improves the overall team performance
2
during the execution of his/her task, an expert generally improves his/her level of expertise/knowledge in the skills associated with the task itself; these expertise/knowledge improvements are not fruitfully exploited if a completely new team would be created.
The reasons illustrated above led us to define suitable policies for incrementally updating a team, instead of reactivating a team building task. Each time a team must be incrementally updated, our system behaves as follows. First, TUH activates TH and requires information about the tasks of the project into consideration; after this, it activates EH and requires information about both those experts already assigned to these tasks and those ones currently eligible to be aggregated to the team. Once all profiles are available, TUH applies the algorithm described in Section 7 and performs the team update activity. Finally, it sends obtained results to the project leader via PH .
6
Team building activity
Our team building approach receives a project consisting of a set TaskSet ={Task1,K,Taskm} of m tasks and a set ExpSet = {Exp1 ,K , Expn } of n experts such that m ≤ n . It returns a team represented as a set of m pairs of the form Expi , Task j , indicating that the expert Expi has been assigned to the task Task j . The team building problem could be represented as an optimisation problem. For this purpose, we start by representing a team Teamk by means of an array T ; each element of this array is associated with an expert of ExpSet . Specifically, T [Expi ] = Task j if Expi is assigned to Task j in Teamk ; it is set to NULL otherwise.
After this, we introduce the team adequacy function (hereafter, T Adq ) to evaluate the overall adequacy of a team Teamk in facing a set of tasks. T Adq is defined as follows:
∑ T Adq (Team ) = k
m u =1
Adq ( Expku , Taskku m
)
(17)
T Adq ranges in the real interval [0, 1]; the higher it is, the more adequate Teamk will be for TaskSet . In the following, whenever necessary, we use the notation T Adq (T )
47
A team building and team update system
(resp., Chv (T )) to denote the adequacy (resp., the cohesiveness) of the team represented by the array T . A first formulation of the team building problem as an optimisation problem would represent it as an optimal assignment problem (Cormen et al., 2001). In this case, a bipartite graph is defined; its nodes represent experts and tasks, respectively; its edges denote task assignments; specifically, there is an edge for each pair Expi , Task j such that Expi ∈ ExpSet and Task j ∈ TaskSet ; the weight of this edge is equal to Adq (Expi , Task j ). The optimal assignment problem requires to assign exactly one expert to each task in such a way that the sum of the weights of selected edges is maximised. Such a formulation is appealing for some reasons: 1
it models the team building problem in a rigorous but intuitive fashion
2
there are efficient (and off-the-shelf) algorithms to solve the optimal assignment problem (think, for instance, of the Hungarian method that can be executed in time O (n 3 )) (Galil, 1986)
3
the function to optimise coincides with the T Adq function introduced above.
However, this formulation is not suited for our goals. In fact, as pointed out in the Introduction, expert technical skills cannot be the only criterion to form a team; indeed, also team cohesiveness should be properly considered. This implies to consider, in the model described above, not only edges linking experts with tasks, but also edges linking experts each other. The result is that the support graph is no longer a bipartite graph. If we want to consider also team cohesiveness in our problem, it is necessary to find and optimise a function f which combines adequacy and cohesiveness. The simplest function having these characteristics is the weighted mean: f (λ, T ) = λ ⋅T Adq (T ) + (1 − λ ) ⋅Chv (T )
(18)
Here, λ is a real number in the interval [0, 1] which tunes the weight of T Adq and Chv. With the support of this function, the team building problem could be formalised as: max λ ⋅T Adq (T ) + (1 − λ ) ⋅Chv (T ) s.t.
experts (T ) = ExpSet null (T ) = n − m
(19)
T [i ] ∈ TaskSet ∪{NULL}
i = 1..n
T [i ] ≠ T [ j ]
i = 1..n
Here: •
the objective function has been illustrated above
•
the first constraint specifies that T has an entry for each expert of ExpSet ; the function experts indicates the experts associated with the entries of T
•
the second constraint specifies that exactly m experts have a task assigned to them; the function null indicates the number of experts not assigned to any task
48
P. De Meo et al.
•
the third constraint specifies that each expert has associated either a task of TaskSet or the NULL value
•
the fourth constraint specifies that the same task cannot be assigned to two different experts.
From the analysis of equations (1) to (15), it is easy to check that the objective function of this problem (and, therefore, the problem itself) is not linear and extremely complex (think, for instance, of functions Af fI , underlying Chv , and φt , φs and φo , underlying Adq ). This problem is well-defined. In fact, a feasible solution of it can be obtained by randomly selecting m entries of T and by assigning exactly one task of TaskSet to each of these entries; the remaining n − m entries are set equal to NULL. Since there
exist
( nm )
possible configurations for T , f is defined only over a finite number of
configurations of T and, then, it achieves its maximum for one of these configurations. This implies that the problem always admits a feasible solution. Despite its compactness and elegance, this formulation of the team building problem presents some issues. First of all, we have already seen that it is not linear and the objective function is extremely complex. Moreover, it is discrete and this makes its management extremely more difficult. In fact, a naive way to find a solution could be obtained by computing the value of f over all possible configurations of T ; this implies the necessity to check
( nm ) = O ( 2m )
possible configurations. This naive way becomes clearly unfeasible when the number of involved tasks is a bit large. In this last case, iterative techniques should be adopted (Bertsekas, 1999); however, these techniques could return a suboptimal solution. Moreover, they generally allow the maximum error in the objective function to be specified; however, the smaller this error is the higher the number of required iterations will be. In the worst case, they could require a time comparable with that required by the naive technique. Actually, the main drawback of this optimisation problem is that it is extremely rigid and potentially incapable of fully capturing the scenario into consideration. In fact, as we have seen in the Introduction, the best way to construct a team in the reality consists of determining the set of candidate teams suitable from the technical adequacy point of view and, after all, these teams have been constructed, of choosing the most cohesive one. The best way to proceed is, therefore, a two steps technique which cannot be modelled by an optimisation problem. The optimisation problem presented above implements a one-step technique and returns the team that optimises the weighted mean between technical adequacy and cohesiveness. This does not exactly model the two steps real way of proceeding and, moreover, creates a problem in the tuning of λ; in fact, if λ is high (resp., low), then the technical adequacy is much more (resp., less) important than cohesiveness. In addition to this, it appears impossible to find a value of λ valid for all team buildings; on the other side, it appears impractical to activate a tuning of λ for each team building. All these reasonings led us to define a team building approach that is simpler from a theoretical point of view but, on the other side, appears more adequate to capture the real way of operating in the team building scenario. Our approach consists of two main phases:
A team building and team update system
49
•
Phase 1. A set CandTeamSet of m candidate teams is constructed. This activity is performed by considering how much the technical, social and organisational skills of each expert match with the corresponding requirements of the tasks of TaskSet ; in this activity, the Adq function (see Section 4.1) plays a key role. The construction of CandTeamSet is described in detail in Section 6.1.
•
Phase 2. The teams of CandTeamSet are ranked according to the corresponding T Adq s in a descending order. After this ranking activity, the top-k teams are selected and put in a set TopCandSet 2 .
Then, the cohesiveness function Chv (see Section 4.2) is computed for each element of TopCandSet . Finally, the team having the maximum cohesiveness is selected; if two or more teams have the same maximum cohesiveness, then one of the teams having the maximum T Adq is randomly selected among them. It is worth pointing out that the team selected at the end of this phase is not necessarily that having the highest value of T Adq , among those of TopCandSet . This choice allows the third challenge specified in the Introduction to be faced; in fact, it favours the construction of harmonious teams where each member is esteemed by the other ones and, in its turn, esteems them.
6.1 Construction of the set of candidate teams The construction of CandTeamSet is performed by a function CandTeam whose pseudo-code is shown in Figure 2. CandTeam receives a set TaskSet of m tasks and a set ExpSet of n experts. It uses the following, auxiliary, data structures: •
a Boolean array BusyExp; it has n entries, each corresponding to one expert of ExpSet ; BusyExp[i ] is set to true if Expi has been already assigned to a task; it is set to false otherwise
•
a Boolean array AssignTask ; it has m entries, each corresponding to one task of TaskSet ; AssignTask [ j ] is set to true if an expert has been already assigned to Task j ; it is set to false otherwise
•
an integer array AuxTeam ; it has m entries, each corresponding to one task of TaskSet ; AuxTeam[ j ] is set equal to i if Task j has been assigned to Expi ; if Task j has not been assigned to any expert, AuxTeam[ j ] is set to –1
•
a set TeamSet storing the set of all already generated candidate teams.
Initially, all entries of BusyExp and AssignTask are marked as false, all entries of AuxTeam are set equal to –1 and TeamSet is empty. CandTeam assumes that all tasks are logically organised into a ring configuration in such a way that each task represents a node of the ring. Moreover, a token is exchanged by the tasks of the ring; at a given time it is assigned to exactly one task.
50
P. De Meo et al. The function CandTeam
Figure 2
function CandTeam (TaskSet : a set of m tasks, ExpSet : a set of n experts) return a set of m candidate teams var BusyExp : an array [1Kn ] of Booleans; AssignTask : an array [1Km ] of Booleans; AuxTeam : an array [1Km ] of integers; TeamSet : a set of teams; j , k , CurrTask : an integer in the interval 1..m ; i , ExpBest : an integer in the interval 1..n ;
begin TeamSet ← 0; / j ← 1;
while j ≤ m do begin for i = 1 to n do BusyExp[i ] ← false; for k = 1 to m do begin
AssignTask [k ] ← false;
AuxTeam[k ] ← −1; end;
CurrTask ← j ; repeat
ExpBest ← arg maxi :BusyExp[i ]= false {Adq (Expi , TaskCurrTask )}; BusyExp[ExpBest ] ← true;
AssignTask [CurrTask ] ← true; AuxTeam[CurrTask ] ← ExpBest ;
CurrTask ← Successor (TaskSet , ExpSet , BusyExp , AssignTask ); until m iterations have been carried out;
TeamSet ← TeamSet ∪ AuxTeam ; j ← j + 1; end; return TeamSet ; end
CandTeam works in an iterative fashion; specifically, it performs two main (and nested) loops. The external loop consists of m iterations. At the j th iteration, CandTeam assigns the token to Task j and activates an internal loop. At the beginning of this loop, all
experts are considered free, i.e., no expert is assigned to a task and no task is assigned to an expert; moreover, the current task CurrTask (i.e., the task for which an expert must be found) is set to j . After this, CandTeam assigns to the current task the expert who
A team building and team update system
51
best fits its requirements, i.e., the expert who shows the highest adequacy for it; let ExpBest be the selected expert. Then, BusyExp[ExpBest ] and AssignTask [CurrTask ] are set to true and AuxTeam[CurrTask ] is set to ExpBest . At this point, CandTeam activates the function Successor to select a new task among those not assigned to any expert. Successor receives the set of free experts and the set of tasks not currently assigned to any expert. It returns the next task for which an expert must be selected; this becomes the new current task for the next internal iteration. Since Successor plays an important role, it is described in detail in Section 6.1.1. Now, CandTeam repeats, for the new current task, the operations outlined above for the previous current task. All these activities must be repeated m times, i.e., until an expert has been assigned to each task of TaskSet . At the end of m internal iterations, AuxTeam is complete and, therefore, it is inserted in TeamSet . After this, the token is passed from Task j to Task j +1 and a new candidate team is constructed. For this purpose, all elements of BusyExp and AssignTask are set to false, all elements of AuxTeam are set to –1 and the external loop is reactivated. After m external iterations, m candidate teams have been constructed and inserted in TeamSet , CandTeam returns this set and terminates.
6.1.1 The successor function In this section, we illustrate the policies adopted to determine, during the construction of a candidate team, the next task for which an expert must be selected. For this purpose, we have defined the following, alternative, policies: •
Egalitarian. This policy relies on the assumption that all tasks are equally relevant to fulfil project goals and, therefore, they should have the same chances in the selection of the expert best fitting their requirements. As a consequence, the successor Task jnew of a task Task curr is sequentially determined as j new = ( j curr + 1) mod m. j
In order to understand the full democracy of this approach, consider that CandTeam constructs m teams and that the construction of the j th team starts from Task j . As a consequence, a task Taskk is the first one to choose its expert
during the construction of the k th team; it is the second one during the construction of the (k − 1)th team, and so forth, until it is the last one during the construction of the (k + 1)th team. •
Hyper-efficient. This policy relies on the observation that, often, some of the tasks of a project are specialised and only few qualified experts can handle them. If these experts are assigned to generic tasks in advance, then the overall team performance would be negatively influenced.
The algorithm operates by sorting all free tasks in a specific order in such a way as to allow specialised tasks to choose their experts earlier than generic ones. This order can be defined as follows: let FreeTaskSet (resp., FreeExpSet ) be the set of tasks (resp., experts) not yet assigned to any expert (resp., task); let Task j be a task of FreeTaskSet and let Exp jmax and Exp jsubmax be the experts of FreeExpSet
52
P. De Meo et al.
showing the maximum and the submaximum adequacy for Task j . If
Adq ( Exp jsubmax , Task j ) is significantly lower than Adq ( Exp j max , Task j ) ,
then Task j would be significantly penalised if Exp jmax is not assigned to it. On the basis of this reasoning, the task of FreeTaskSet which would receive the highest penalisation is the task Taskk such that the difference
Adq ( Expkmax , Taskk ) − Adq ( Expksubmax , Taskk ) is maximum; this is exactly
the task selected by Successor if the hyper-efficient policy is adopted. From the previous descriptions, it is possible to observe that the hyper-efficient policy always privileges the most specialised tasks, which can be handled only by few specialistic experts. This trend appears even more pronounced when specialised tasks are not the most relevant ones in their projects. As a consequence of its behaviour, the hyper-efficient policy, if compared with the egalitarian one, produces a smaller number of distinct teams; moreover, these teams tend to be quite similar each other since there is a group of tasks that tend to be assigned to the same experts in all possible teams. The reduction of the number of distinct candidate teams reduces, in its turn, the probability that teams characterised by the highest cohesiveness belong to the set of candidate teams constructed by applying this policy. As a consequence of this reasoning, the hyper-efficient policy appears the most suitable one in those contexts where team adequacy is much more important than team cohesiveness; by contrast, in contexts where team cohesiveness is more relevant than team adequacy, the egalitarian policy should be preferred.
7
Team update activity
A team update is required when it is necessary, or highly convenient, to carry out some modifications on an already existing team. It should be performed in such a way as to satisfy the following requirements: •
•
The structure of a team should be preserved as much as possible; this implies that: 1
the number of experts added to or removed from a team should be minimised in such a way as to preserve the network of human relationships previously constructed among team members
2
the number of experts moved from a task to another within the same project should be minimised in such a way as to preserve the knowledge/experience that each expert acquired by performing his/her task.
A new free expert should not be privileged w.r.t. already existing team members. In other words, a free expert can be added to a team only if: 1
there is a task of the corresponding project not currently assigned to anyone
2
there is a task of the corresponding project assigned to a not particularly adequate expert and the overall team cohesiveness, after the expert substitution, does not decrease.
A team building and team update system
•
53
The required computational effort should not be prohibitively high.
Before illustrating our team update approach, we recall that the events possibly triggering it are the following: 1
an expert leaves the team
2
a new expert is available and his/her skills are particularly adequate for one or more tasks of the project assigned to the team
3
one or more tasks must be added to the project assigned to the team.
Our purpose is to define an approach general enough to uniformly facing all the three events outlined above and, then, to specialise it to all of them. Preliminarily, we point out that, if we accept a slight constraint relaxation and handle the addition of t tasks by applying t times the procedure concerning the addition of one task, case 3 can be reconducted to case 1; in fact, when a new task is added to a project Pr , we have that all but one tasks of Pr are already assigned to an expert, and this is exactly the scenario considered by case 1. As a consequence, in the following, we shall analyse only cases 1 and 2. Our approach is based on the local search paradigm (Kleinberg and Tardos, 2005); it is implemented by a function called TeamUpdate. This function receives: •
the team Teamcurr to update
•
the set ExpSet of experts who are either free or assigned to some tasks of Teamcurr
•
the set TaskSet of tasks that must be managed by the team to update
•
a threshold thT Adq , stating the smallest increase of T Adq required to consider an optional team update worthy to be executed (see below)
•
a positive integer, Maxchange , stating the maximum number of changes the project leader is willing to accept3
•
an integer case whose value indicates if TeamUpdate has been triggered by case 1 or by case 2 described above.
TeamUpdate exploits also some support variables, namely: •
Teamcand , denoting a candidate team
•
T Adqcurr (resp., T Adqcand ), indicating the T Adq of Teamcurr (resp., Teamcand )
•
Chvcurr (resp., Chvcand ), denoting the cohesiveness of Teamcurr (resp., Teamcand )
•
Countchange , indicating the number of iterations (see below).
TeamUpdate implements a hill climbing meta-heuristics (Russell and Norvig, 2002). Hill climbing is an optimisation technique. It starts with a random (and potentially poor) solution and iteratively makes small changes to this solution in such a way as to improve
54
P. De Meo et al.
the value of the objective function. It ends when no further improvements are possible or when a certain number of iterations has been already performed. Hill climbing suffers from some drawbacks. Specifically: 1
it can be ‘trapped’ into local maxima
2
it suffers from the ‘plateau’ problem, i.e., it could not work if the function to optimise is ‘flat’ in some parts of the search space; however, this last problem can be avoided by applying a random restart strategy, i.e., by randomly changing the starting point of the algorithm and by running it again.
However, in spite of this drawbacks, this heuristics presents some interesting strengths in our context; specifically: 1
it is quite fast
2
it starts from a good initial solution which coincides with the team to update
3
local maxima can generally be accepted in our context in that the maximum technical adequacy is not the only criterion for updating a team; as a matter of fact, our update activity tries to obtain a good trade-off between technical adequacy, team cohesiveness and the number of changes to be brought in the team.
TeamUpdate operates as follows. It constructs a new candidate team Teamcand by applying on the team to update a suitable operation aiming at producing the highest increase of T Adq . Available operations are two, namely internal swap and external swap. •
Internal swap (or task reallocation) is implemented by the internal swap function (ISF ). It receives the team to update and constructs the candidate team by swapping the tasks assigned to two experts of the team to update. Specifically, for each pair Expi , Expl of experts of the team itself, ISF constructs a new team il Teamcurr , by swapping the tasks assigned to Expi and Expl , and computes
il il ΔT Adqint = T Adq (Teamcurr ) −T Adq (Teamcurr )4 . After this, it chooses as
il . candidate team that team associated with the maximum positive value of ΔT Adqint
•
External swap (or expert replacement) is implemented by the external swap function (ESF ). It receives the team to update and constructs a candidate team by substituting an expert of the team to update with a free expert of ExpSet . Specifically, for each pair Expi , Expl of experts such that Expi belongs to
the team to update and Expl does not belong to this team, ESF constructs il a new team Teamcurr , by substituting Expi with Expl and computes
il il ΔT Adqext = T Adq (Teamcurr ) −T Adq (Teamcurr )5 . After this, it chooses as
il . candidate team that team associated with the maximum positive value of ΔT Adqext
At the beginning, TeamUpdate connsiders the value of the variable case.
A team building and team update system •
55
If case = 1, then the structure of the team to update must be necessarily modified. Let Taskk be the currently free task. For each free expert Expi , TeamUpdate i constructs a new team Teamcurr , by assigning Expi to Taskk in the team to update, and computes the corresponding team adequacy. After this, it chooses as the new Teamcurr that team producing the maximum value of team adequacy.
At this point, Teamcurr is complete and, therefore, the most important requirement has been satisfied. However, it appears interesting to verify if some other changes can be performed on it in such a way as to increase its team adequacy without decreasing its cohesiveness; clearly, the number of these changes should be less than or equal to Maxchange . For this purpose, TeamUpdate first sets T Adqcurr equal to T Adq (Teamcurr ) and Chvcurr equal to Chv (Teamcurr ); after this, it performs a loop; during each iteration of this loop: 1
It applies ISF (resp., ESF ) on Teamcurr to determine the maximum increase of team adequacy that could be obtained by an internal (resp., external) swap; let ΔT Adqint (resp., ΔT Adqext ) be this value; let ΔT Adq be the maximum between ΔT Adqint and ΔT Adqext ; the team corresponding to ΔT Adq is chosen as the candidate team and is assigned to Teamcand . If ΔT Adqint = ΔT Adqext , then the team returned by ISF is preferred to that returned by ESF ; this choice is explained by the requirement that the number of experts added to or removed from a team should be minimised in such a way as to preserve the network of human relationships previously constructed among team members.
2
It computes the team adequacy T Adqcand and the cohesiveness degree Chvcand of Teamcand .
3
It verifies if (T Adqcand −T Adqcurr ) > thT Adq and, simultaneously, Chvcand ≥ Chvcurr ; in the affirmative case, Teamcurr , T Adqcurr and Chvcurr are set to Teamcand , T Adqcand and Chvcand , respectively.
This loop terminates when, during one iteration, Teamcurr does not change or when Maxchange iterations have been already made. After the end of this loop, TeamUpdate returns Teamcurr and terminates.
•
If case = 2, then TeamUpdate first computes the team adequacy T Adqcurr and the cohesiveness degree Chvcurr of Teamcurr . After this, it applies ESF on Teamcurr . Let Teamcand be the candidate team returned by ESF . TeamUpdate computes the team adequacy T Adqcand and the cohesiveness degree Chvcand of Teamcand ; after this, it verifies if
56
P. De Meo et al. (T Adqcand −T Adqcurr ) > thT Adq and, simultaneously, Chvcand ≥ Chvcurr .
In the affirmative case, TeamUpdate sets Teamcurr , T Adqcurr and Chvcurr to Teamcand , T Adqcand and Chvcand , respectively. After this, it activates the loop described for the previous case6. At the end of this loop, TeamUpdate returns Teamcurr and terminates.
8
Experimental results
In this section, we describe the main results of our experimental analysis. Specifically, in Section 8.1, we provide some details about the prototype implementing our system and introduce the parameters exploited to evaluate its performance. In Section 8.2, we study the impact of team size on expert satisfaction. In Section 8.3, we analyse the accuracy improvements obtained by considering social and organisational capabilities, in addition to technical skills. In Section 8.4, we illustrate the impact of team changes on customer satisfaction. In Section 8.5, we analyse the expert occupational levels achieved by our system. Finally, in Section 8.6, we verify if our system is able to produce proposals that are acceptable in practice.
8.1 Prototype description and performance parameters Our prototype was implemented in Java. In our experiments, TBH and TUH operated on PCs equipped with a 3.4 GHz CPU and 1 GB of RAM; all the other handlers were installed on PCs equipped with a 2.6 GHz CPU and 512 Mb of RAM. The set ExpSet of experts participating to our tests consisted of 100 elements. It was partitioned in five classes, called expertise classes, namely EC h , h = 1K 5, according to their expertise level, in such a way that ‘low’-indexed classes were associated with junior experts whereas ‘high’-indexed classes comprised senior experts. Expert distribution was as follows: ten experts belonged to EC1 , 20 belonged to EC 2 , 40 belonged to EC 3 , 20 belonged to EC 4 and, finally, ten belonged to EC 5 . The number of technical skills owned by an expert ranged from eight to 13; the number of both social and organisational skills related to an expert ranged from three to six. The problem of accurately evaluating the performance of a team is quite complex and has been widely studied in the past according to different perspectives, such as that of social psychology (Coutts and Gruman, 2005), organisational psychology (Drach-Zahavy and Somech, 2002), group dynamics (Fraher, 2005), organisational research (West, 2003) and so on. We borrowed some of the ideas rising from these disciplines and highlighted four issues to investigate; these are: 1
role assignment: roles (and, in our case, tasks) should be matched with experts in such a way as to bring out their skills, past experiences and personal traits
2
supportiveness and human relationships: according to West (2003), supportiveness is the ‘aspiration to help others succeed’; supportiveness and, more generally, strong human relationships established among team members play a key role in the creation of a positive climate in a team and can significantly contribute to the team outcomes
A team building and team update system
3
adherence to business goals: expert performance should be compliant with the expectations and the objectives of the customers who commissioned projects
4
effective use of human resources: task allocation policies should achieve a twofold goal: specifically:
a
team leaders should progressively involve young experts in more and more complicated projects in order to both support their professional growth and train them to adequately cope with everyday challenges imposed by work environment
b
competencies and skills of veteran experts should be exploited to their full potential.
57
In order to evaluate the first two aspects mentioned above, it is necessary to assess how an expert perceives his/her role within a team and whether he/she is satisfied of human relationships established with his/her teammates. In order to perform this evaluation, we applied the methodology described in LaFasto and Larson (2001). Specifically, given a project Prk and the corresponding team Teamk , each expert Expik ∈ Teamk was asked to fill an appraisal form; this was exploited to obtain a coefficient called expert satisfaction ESik , belonging to the real interval [0, 1] and indicating how much Expik felt himself/herself comfortable in joining Teamk . After this, the values ESik were averaged to obtain the average expert satisfaction AESk as (Chang et al., 2008):
AESk =
∑
Expik ∈Teamk
Teamk
ESik
.
As for the evaluation of the third aspect mentioned above, given a project Prk and the corresponding team Teamk , we asked the customer who commissioned it to specify a coefficient, ranging in the real interval [0, 1] and indicating how much he/she was satisfied with the objectives accomplished by Teamk . This coefficient is called customer satisfaction and is indicated by CSk in the following. Finally, in order to evaluate the fourth aspect mentioned above, it is necessary to assess how human resources are assigned to projects and whether some experts are underutilised/overutilised. In order to perform this evaluation, we considered four occupancy classes; specifically, the first (resp., the second, the third, the fourth) class OC1 (resp., OC 2 , OC 3 , OC 4 ) contained those experts involved in less than 25% (resp., at least 25% and less than 50%, at least 50% and less than 75%, at least 75%) of the projects. This classification led us to define a further parameter called expert occupational level (hereafter, EOL ); specifically, given an expert class EC h and an occupancy class OC g , EOLhg indicates the fraction of experts of EC h belonging to OC g .
58
P. De Meo et al.
8.2 Impact of team size on AES In this test, we aimed at studying the impact of team size on AES . In Figure 3, we plot the values of AES achieved by our system when the egalitarian and the hyper-efficient policies are applied and team size ranges from two to 507. From the analysis of this figure, we observe that, for both the egalitarian and the hyper-efficient policies, AES achieves its best values when team size is less than 15; in fact, if team size exceeds this value, then AES starts to decrease. Figure 3
Impact of team size on AES (see online version for colours) 1
Egalitarian HyperEfficient
0.9
Average Expert Satisfaction
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
5
10
15
20
25
30
35
40
45
50
Team Size
This behaviour is explained by observing that if a project consists of a little number of tasks, it is likely that the most appropriate expert can be selected for each of them. This implies that experts composing constructed teams are likely to be satisfied of the roles they have received and, then, the resulting AES is quite high. As long as the number of tasks (and, then, the corresponding team size) grows, some experts are compelled to perform the tasks which do not perfectly match with their skills and personal traits. This determines a decay of their satisfaction and, ultimately, a decrease of AES . This analysis allows us to conclude that small teams must be always preferred to large ones because, in this case, experts can be more easily assigned to the tasks they actually desire and, moreover, interpersonal communications and human relationships are strong; interestingly enough, this result confirms those illustrated in LaFasto and Larson (2001). As a consequence of this analysis, if a project is too big or too complex, it may be convenient to split it into two or more subprojects in such a way as to construct smaller and more cohesive teams.
59
A team building and team update system
8.3 Impact of technical, social and organisational skills on AES and CS In this section, we analyse how the usage of technical, social and organisational skills in the computation of the adequacy of an expert for a task impacts on AES and CS . Recall that the weights of technical, social and organisational skills on the computation of this adequacy are determined by three parameters, namely α, β and γ (see Section 4.1). In order to carry out this study, we ran our system according to three different configurations; specifically: 1
we considered only technical skills (this is equivalent to set α = 1, β = 0 and γ = 0)
2
we considered both technical and social skills (specifically, we set α = 0.67, β = 0.33 and γ = 0)
3
we considered technical, social and organisational skills (specifically, we set α = 0.5, β = 0.25 and γ = 0.25).
Figures 4, 5, 6 and 7 plot the variation of AES and CS against the number of projects carried out over time for both the egalitarian and the hyper-efficient policies. Figure 4
Variation of AES against the number of projects carried out over time (egalitarian policy) (see online version for colours) 1
Average Expert Satisfaction (Egalitarian policy)
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
α=0.5; β=0.25; γ=0.25 α=0.67; β=0.33; γ=0 α=1; β=0; γ=0
0.1
0
0
5
10
15
20
25
Number of projects
30
35
40
60
P. De Meo et al.
Figure 5
Variation of AES against the number of projects carried out over time (hyper-efficient policy) (see online version for colours) 1
Average Expert Satisfaction (HyperEfficient policy)
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
α=0.5; β=0.25; γ=0.25 α=0.67; β=0.33; γ=0 α=1; β=0; γ=0
0.1
0
0
5
10
15
20
25
30
35
40
Number of projects
Figure 6
Variation of CS against the number of projects carried out over time (egalitarian policy) (see online version for colours) 1
Customer Satisfaction (Egalitarian policy)
0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2
α=0.5; β=0.25; γ=0.25 α=0.67; β=0.33; γ=0 α=1; β=0; γ=0
0.1 0
0
5
10
15
20
25
Number of projects
30
35
40
61
A team building and team update system Figure 7
Variation of CS against the number of projects carried out over time (hyper-efficient policy) (see online version for colours) 1
Customer Satisfaction (HyperEfficient policy)
0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2
α=0.5; β=0.25; γ=0.25 α=0.67; β=0.33; γ=0 α=1; β=0; γ=0
0.1 0
0
5
10
15
20
25
Number of projects
30
35
40
These figures indicate that both AES and CS grow when the number of projects already carried out increases. This trend can be explained by considering that our system needs a certain number of projects to ‘learn’ the profile, the behaviour and, more in general, the features of an expert, and to adapt its task assignment activity to them. In other words, the approach to problem solving of an expert is very difficult to be evaluated since it derives from the interplay of various components (e.g., cognitive, motivational, social and so on); in addition, it frequently relies on a ‘guess-and-check’ methodology (Chakravorty et al., 2008); in fact, it often happens that an expert carries out some actions to solve a problem and, if they are not successful, he/she learns new topics to fill his/her cultural gaps, and/or collaborates with his/her colleagues to generate a further solution that is subsequently tried. As a consequence, if a sufficient number of projects has not been considered, our system does not completely learn expert profile, behaviour and features and, consequently, its evaluations are likely to be imprecise; this implies that the subsequent team building task returns not extremely satisfying results, and this explains why, when the number of already considered projects is low, both AES and CS are not particularly high. By contrast, after a certain number of projects, our system has learnt expert profile, behaviour and features; this implies that it has got an objective assessment of both the skills acquired by experts and their human relationships; this explains the substantial increase of both AES and CS that can be observed in Figures 4–7. A further interesting trend emerging from Figures 4–7 is that an approach taking technical, social and organisational skills into account is better than one based only on technical and social skills that, in its turn, is better than one exclusively relying on technical skills. This points out that social and organisational aspects play a key role in
62
P. De Meo et al.
team building; they allow the formation of a team spirit, as well as a more effective assignment of roles and responsibilities among team members. Clearly, the price to pay for achieving this improvement is quite high (Hefke and Stojanovic, 2004); in fact, it is necessary to carefully monitor and analyse experts’ problems and expectations. In addition, this monitoring process must be permanent, due to the frequent changes of both experts’ profiles and companies’ business plans. Finally, data produced by this monitoring process must be stored and managed by means of suitable support data structures. In our system, the benefits of using social and organisational skills outweigh the costs mentioned above. This depends on the fact that these costs are quite limited in our scenario; in fact, an initial (and quite rich) information about experts’ skills and competencies can be derived from their CVs; moreover, each time a project terminates, data about involved experts can be easily updated by the corresponding project leader.
8.4 Impact of team changes on CS In this section, we analyse the impact of the number of team changes on CS . In order to carry out this analysis, we considered 30 teams, each formed by 25 experts. For each team Teami , we performed a loop consisting of 25 iterations; during the j th iteration, we applied the team update algorithm with the assumption that the maximum number of allowed changes Maxchange was equal to j and we asked the corresponding customer to specify his/her CS value before and after team update; we denote by CSibj and CSiaj these values, respectively. After this, we computed ΔCSij = CSiaj − CSibj
and we
averaged these values on available teams in such a way as to obtain: ΔCS j
∑ =
30
i =1
ΔCSij
30
.
In Figure 8, we plot the values of ΔCS j against Maxchange (i.e., j ) when this last parameter varies from one to 25. Figure 8 suggests that few changes to a team produce a slight increase of CS . In fact, our approach modifies the structure of a team only if this modification is necessary or if it leads to an increase of the corresponding team adequacy without lowering the corresponding team cohesiveness. In this case, the ‘injection’ of new experts feeds and enlarges the variety of the personal traits and the technical competencies living together in a team. The different perspectives and standpoints of new experts enhance team vitality and creativity, and, ultimately, contribute to making its activities more effective. Clearly, if few experts join a team, the ‘innovations’ that can be brought by them are necessarily limited; this explains why ΔCS is limited. On the other side, many changes to the original team structure have harmful impacts on CS . This depends on two main reasons; the former is that the substitution of a significant share of experts could weaken interpersonal dynamics existing in a team and, when this fact is perceived by the customer, it could lead to a decrease of CS . The latter reason is that many projects are often ‘one-off’, in the sense that involved experts are required to manage ‘non-repetitive’ and ‘non-standard’ tasks. In this case, it is necessary
63
A team building and team update system
an active involvement of experts on a continuous basis and the knowledge/experience gathered by each expert on his/her task is often more valuable to the project goals than his/her technical competencies. In this scenario, the replacement of an expert already belonging to a team with a newcomer would be negatively evaluated by the customer and this would lead to a decay of CS . Figure 8
Variation of ΔCS against Maxchange (see online version for colours) 0.4
0.3
0.2
ΔCS
0.1
0
−0.1
−0.2
−0.3
−0.4
0
5
10
15
20
25
Maxchange
A good trade-off between the need of injecting new experts in a team, on one side, and preserving social relationships and past experiences of its members, on the other side, can be derived from Figure 8; specifically, this figure indicates that a ratio of Maxchange to team size equal to about 0.258 ensures the highest increase of CS .
8.5 Analysis of the EOL achieved by our system In order to analyse the EOL achieved by our system, we applied it on 40 projects and we considered both the egalitarian and the hyper-efficient policies; after this, we analysed the composition of each obtained team according to the expertise level of its members; the corresponding results are reported in Figure 9. This figure suggests that the more proficient an expert is, the higher his/her occupancy level will be. Clearly, this trend is more marked if the hyper-efficient policy is adopted; as an example, consider the experts belonging to EC 4 (and, therefore, having a high expertise level); we can observe that, if the hyper-efficient policy is adopted, about 90% of them belong to OC 4 (and, therefore, are involved in at least 75% of projects); this percentage decreases to about 60% if the egalitarian policy is chosen.
64
P. De Meo et al.
Figure 9
EOL against expertise level of team members for the egalitarian and the hyper-efficient policies (see online version for colours)
90 80
Expert Occupational Level
Eg: Egalitarian policy HE: HyperEfficient policy
OC1 OC2 OC3 OC4
100
70 60 50 40 30 20 10 0 Eg
HE
EC1
Eg
HE
EC2
Eg
HE
EC3
Eg
HE
EC4
Eg
HE
EC5
Expertise Level
In our opinion, this experiment is particularly important and very close to real scenarios. In fact, in real contexts, determining the ratio of junior experts to senior ones for a team is quite a delicate task since, in this activity, it is necessary to carefully balance the economic ambitions of the projectised organisations and the customer demands. Indeed, from the organisation standpoint, junior experts should always work side-by-side with senior ones in close-knit project teams; in this way, they can learn a craft by means of an informal apprenticeship, whereas senior experts can receive a significant assistance in some tedious and ‘routinisable’ activities (e.g., in data gathering tasks). This process is known as firm leverage (Meister, 1997); it is not only a means for transferring the knowledge acquired through years of experience from senior experts to junior ones, but is also an effective means for a projectised organisation to make money. In fact, a projectised organisation makes profit by maximising the gap between the fee rates charged to its customers and the salaries paid to its experts; the daily fee rates required for senior experts are often no more than two or three times greater than those of junior ones, whereas the salaries of senior experts often differ from those of their junior colleagues by much larger multiples (Oxford Said Business School, http://www.sbs.ox.ac.uk). On the other hand, customers are often sceptical about paying significant fees for services provided by recent graduates. In addition, they are inclined to assign some of their activities to an external organisation only if it can guarantee that the professional profiles of its experts are enough to deliver high value services. From this reasoning, it is clear that customer and firm exigencies are often conflicting and a trade-off is necessary. As far as this aspect is concerned, the egalitarian policy prevents senior experts from being involved in an excessive number of projects and, then, allows a certain share of junior experts to be hired; this ultimately favours projectised organisation leverage. As a consequence, the egalitarian policy best fits the standpoint of
65
A team building and team update system
the projectised organisation. On the contrary, the hyper-efficient policy tends to construct teams whose ratio of junior experts to senior ones is quite low and, then, it is more suited to meet the customer standpoint. In real cases, if a project is at the forefront of technical knowledge and the customer is willing to generously pay experts, the hyper-efficient policy should be prioritised over the egalitarian one. By contrast, if a project does not require a high creativity and innovation degree, and deals with some well-known and familiar problems, the egalitarian policy appears to be the best choice.
8.6 Comparison between the proposals of our system and those produced by a human expert The aim of this experiment was to verify whether our system is able to produce proposals that are acceptable in practice, possibly even better than those returned by a human expert. In this experiment, we asked the support of four project leaders; in particular, we assigned to each of them five small projects (composed by less than 15 tasks), five medium projects (whose number of tasks ranged from 15 to 30) and five big projects (consisting of more than 30 tasks). After this, for each project Prk : •
We asked the corresponding project leader to select, by his/her own and without the help of our system, the team TeamkPrL that he/she considered the most suitable to accomplish the tasks of Prk .
•
We ran our system (with both the egalitarian and the hyper-efficient policies) to automatically build the team TeamkSys that it considered the best one to accomplish the tasks of Prk .
•
We asked the corresponding project leader to compare TeamkPrL and TeamkSys . Specifically, we asked him/her if, in his/her opinion, TeamkSys would have accomplished the tasks of Prk better, in the same way or worse than TeamkPrL .
Obtained results are summarised in Tables 2 and 3. In these tables, rows are associated with small, medium and big projects, respectively; for each of these project classes, we report how many times a team returned by our system has been judged, by the corresponding project leader, worse, equivalent or better than that previously constructed by himself/herself. Table 2
Comparison of the teams built by our system (by means of the egalitarian policy) with those returned by the human expert
Projects size
Worse
Equivalent
Better
Small projects
4
15
1
Medium projects
4
12
4
Big projects
3
11
6
66
P. De Meo et al.
Table 3
Comparison of the teams built by our system (by means of the hyper-efficient policy) with those returned by the human expert
Projects size
Worse
Equivalent
Better
Small projects
4
15
1
Medium projects
3
14
3
Big projects
2
12
6
Before analysing these tables, we point out that, clearly, if we consider the time necessary to produce their results, our system shows a performance much better than that reached by the project leader (generally, of some orders of magnitude). However, this is not sufficient to certify its suitability; in order to claim that it is suitable in practice, it is necessary to verify that the teams it builds are at least equivalent (with some possible exception) to those returned by the project leader. The analysis of Tables 2 and 3 allows us to conclude that our system is able to build teams very adequate in practice and, in some cases, even better than those produced by a project leader. It is worth noticing that our system obtains the best results for big projects. This can be explained by considering that, in order to manage a big project, a project leader must handle a large amount of information, which could become hard to be really managed by human mind. In this scenario, it could happen that he/she does not consider some piece of available information and this fact could lead him/her to build a non-optimal team. Clearly, a software system is much more capable of handling large amounts of information than a human person and, therefore, could return teams even better than those obtained by the project leader. As for medium projects, we can observe that the solutions proposed by our system are generally equivalent to those returned by a project leader; in some cases, they are worse and the same they are better. Also in this scenario, our system is very useful since its results are comparable with those of the human expert, but it is much quicker than him/her. As for small projects, the teams built by project leaders are sometimes better than those produced by our system. This behaviour can be explained by the fact that, in such a case, the information that a project leader must handle is quite limited and can be easily managed by his/her mind without missing any piece of it. In this case, clearly, the results he/she can produce are very satisfying and often better than those returned by a software system. Moreover, in this scenario, the time necessary to him/her for producing his/her results is limited. However, it is worth pointing out that, also in this case, our system is generally able to build adequate and satisfactory teams; this is confirmed by the fact that, over 20 teams, for both the egalitarian and the hyper-efficient policies, only four of them have been judged worse than those built by the project leader.
9
Related work
In this section, we compare our system with some related ones. In this activity, we borrow some of the ideas presented in Colucci et al. (2007) and classify team building approaches in three categories, namely:
A team building and team update system
1
commercial
2
ontological
3
non-ontological.
67
In the following sections, we highlight the main innovations introduced by our system w.r.t. each of these categories.
9.1 Comparison with commercial approaches Many IT companies developed software systems capable of managing human resources within a firm. For instance, HP developed CONNEX (Becerra-Fernandez, 2000), conceived to build a network of experts to catalogue and locate the intellectual competencies of a firm. Microsoft developed Skill Planning und (and) Development (SPuD) (Penuel and Cohen, 1999); this system can identify both the skills required for a job and the training courses an employee must attend to attain those of them that he/she does not already own. Bozz, Allenn & Hamilton (BA&H), a leading management- and technology-consulting firm, developed Knowledge OnLine (KOL) (Becerra-Fernandez, 2000), a software platform that supports software consultants to work in a collaborative fashion. Commercial approaches (CAs in short) to team building show some interesting features. For instance, they use rich experts’ profiles containing a summary of their knowledge, skills, affiliation, education and interests. In many cases, CAs are components of more sophisticated systems conceived to handle the human and the intellectual capital of a firm (e.g., they are able to analyse how compensation programmes influence expert performances) (Feng and Burkhauser, 2009). However, they show some drawbacks (Colucci et al., 2007; Hefke and Stojanovic, 2004; Sure et al., 2000). Specifically, they do not take organisational and social skills of an expert into account. In addition, the main goal of most of them is to match each job with the expert best fitting it, rather than to build a cohesive team. Furthermore, as observed in Sure et al. (2000), since expert profiles are generally registered in relational databases, expert search activity is equivalent to formulate suitable SQL queries; this is unsatisfactory when a (possibly approximate) semantic matching, rather than a (possibly exact) lexical one, is required; with regard to this aspect, we point out that exact lexical matchings may imply a low flexibility degree in the selection of experts and do not bring out the human capital of a firm. Our approach introduces some novelties to overcome these drawbacks. In fact, it jointly considers technical, organisational and social skills of involved experts to assess their adequacy for involved tasks. Moreover, the team building strategy underlying it does not identify only one team for a project; in fact, it builds several teams, each capable of accomplishing project goals; this guarantees the possibility to have a pool of candidate teams and to select that team of the pool which maximises further positive features (e.g., internal cohesiveness). Finally, in our approach, team cohesiveness plays a key role; as a consequence, a team constructed by it does not necessarily include the most talented experts, but it surely includes the most amalgamated ones, among those who can accomplish project tasks. This method agrees with the suggestions provided in LaFasto and Larson (2001) where it is shown that a collective performance depends not only on
68
P. De Meo et al.
the quality of individuals, but also on their capability of identifying a common goal, as well as on their availability to work in such a way as to accomplish this goal.
9.2 Comparison with ontological approaches Ontologies and semantic web technologies have been widely applied in the field of human resource management [e.g., to model competencies (Harzallah et al., 2002) or to support e-recruitment activities (Mochol et al., 2007)]. Specifically, in Colucci et al. (2007), a description logics-based matchmaking approach to team building is presented. In Straccia et al. (2009), the authors suggest to automatically perform a matchmaking process between available candidate profiles and vacant job positions according to mandatory requirements and preferences provided by a recruiter. For this purpose, they apply an approach to identifying the top-k queries. In Hefke and Stojanovic (2004), the authors use ontologies to model human resources within a company; in this case, team building task is reconducted to an ontology querying task. In Fraganidis and Mentzas (2007), the authors describe a system that helps human resource managers to assess employees’ performances, to determine their missing competencies and to build personalised learning paths. In Sure et al. (2000), a system using ontologies to derive implicit knowledge about employees’ skills is proposed; this knowledge is used to match employees with tasks. We can recognise two main similarities between our system and ontological approaches (hereafter, OAs). First, both of them provide holistic approaches to team building because they consider not only experts’ technical skills, but also their organisational and social capabilities (Hefke and Stojanovic, 2004). Second, both of them aim at generating a space of candidate teams, instead of processing one task at a time and matching it with the most adequate free expert, without considering if this last is the only one that could perform another free task. OAs are very refined; for instance, they are capable of inferring if an expert has gained a specific competency, without requiring his/her self-assessment or external ratings from a project leader (Sure et al., 2000). In addition, if a task cannot be completely assigned to an expert, they can decompose it in many subtasks and can assign each of them to an expert (Hefke and Stojanovic, 2004). Finally, they are able to deal with scenarios in which information about experts and tasks is incomplete (Colucci et al., 2007). Paradoxically, OAs’ high refinement level is also their Achilles’ heel. In fact, the process of acquiring knowledge about a domain and designing and populating the corresponding ontology is time expensive and error-prone (Becerra-Fernandez, 2006; Hefke and Stojanovic, 2004). A deficiency in the support ontology may lead to incomplete and wrong answers to the project leader’s requests; this situation may become frustrating for him/her since he/she must guess on his/her own what is wrong in returned answers (Hefke and Stojanovic, 2004). Our system introduces some novelties w.r.t. OAs. In fact, like the approach of Becerra-Fernandez (2000), it uses keyword mechanism to describe both expert skills and task requirements. In addition, it uses a function sem , capable of determining if two strings semantically indicate the same skill, and a function gen , capable of determining if one string is semantically more general than another.
A team building and team update system
69
A further significant novelty of our system regards the fact that past expert interactions play a key role in team building activities and are a leading criterion in the selection of the final team among the candidate ones; this does not happen in OAs which are not provided with tools to register and exploit the quality of past expert interactions. Finally, our system supports team update activities; thanks to this functionality, it can help a project leader to both restore a previously constructed team, when a component leaves it, and to estimate whether a change in an already complete team has a positive impact on its performance.
9.3 Comparison with non-ontological approaches Non-ontological approaches (hereafter, NOAs) to team building are based on specific techniques, like data mining (DM ) or multi-agent systems (MAS ). Examples of DM -based solutions for team building are described in BecerraFernandez (2000), Biesalski (2003) and Veloso et al. (2004). Specifically, the approach of Becerra-Fernandez (2000) uses clustering algorithms to group experts into homogeneous classes, each representing the set of potential candidates to a particular task. The approach of Biesalski (2003) uses text mining techniques to extract and classify expert skills from natural language sentences. Finally, Veloso et al. (2004) describes a team building approach based on the usage of association rules extracted from the activity log file associated with a project. DM -based approaches present many interesting features. For instance, they provide sophisticated techniques to assess the performance of an employee and determine his/her professional maturity; this implies a reduced necessity to rely on employee’s selfassessment or on project leader’s ratings and, ultimately, reduces the subjectivity of human evaluation. In addition, they can easily group experts into clusters; in this way, it is possible to create a structured expert catalogue that can be used in team building activity. Despite these interesting features, DM -based approaches show also some severe limitations. First, data regarding employees and tasks are generally stored in plain text documents and, then, most of classical DM -based approaches cannot be applied on them, since they have been generally designed to operate on highly structured data (Becerra-Fernandez, 2006). Second, DM -based approaches generally use support data structures (e.g., trees) to describe the internal competencies of an organisation; in order to build and update these structures, it is necessary a strong expert intervention; this makes these approaches quite expensive. The main novelty of our approach w.r.t. DM -based ones is that these last often act as expert locator systems, i.e., they identify the knowledge required to perform a particular task and return a list of experts capable of accomplishing it. By contrast, our approach uses information on technical, social and organisational skills of experts, as well as information about past expert-to-expert interactions, to build a team whose members are not only technically adequate to perform the tasks assigned to them, but they are also prone to share their knowledge and to operate in a collaborative fashion in such a way as to increase team cohesiveness.
70
P. De Meo et al.
As for MAS -based systems, we cite Software Agents for Mediating Business Activities (SAMBA) (Mehandjiev and Odgers, 1999) and Multi-Agent System for e-learning and skill management (MASEL) (Garro and Palopoli, 2003). SAMBA has been conceived to support team members to schedule their activities, to submit a request (e.g., a day-off or an overtime) and to handle the effects of the corresponding answers. MASEL helps human resource managers of a company to measure experts’ training needs and to create personalised learning paths according to these needs. SAMBA, MASEL and our system aim at enhancing social interactions among the actors of an organisation (e.g., team members or human resource managers). However, our system introduces also a significant novelty w.r.t. the other two ones because it also uses parameters related to experts’ social and organisational skills, as well as to past expert-to-expert interactions, to determine the team showing the highest cohesiveness among its members.
10 Conclusions In this paper, we have proposed a new system aiming at handling team building and team update activities in projectised organisations. Our system uniformly represents and handles expert skills by means of a suitable profile derived from the examination of various CV models. Moreover, it is highly distributed and, therefore, is particularly adequate to the typical organisation of the current job market where projectised organisations are currently intermediating most job positions. Finally, it considers not only technical skills of experts, but also their social and organisational capabilities, as well as the cohesiveness possibly showed by them in the past. In this paper, we have illustrated our system in detail, we have presented various experiments devoted to measure its performance and we have compared it with other related ones from the literature. As for future work, we plan to integrate our system in a more complex enterprise resource planning (ERP) system capable of fully bringing out the human capital of a firm. Specifically, we would like to design tools for identifying and tracking ‘high-potential’ employees; this would support firm managers to implement career advancement plans and training courses in such a way as to prepare talented junior experts to assume leadership roles. In addition, we aim at designing a performance-oriented compensation process, i.e., an incentive mechanism that stimulates employees to achieve ambitious business goals in such a way as to receive proportionate rewards. For this purpose, we plan to integrate our system with sophisticated machine learning techniques, like the Q-learning algorithm (Mitchell, 1997) and Bayesian data reduction (Kline and Galbraith, 2009). A further research direction is represented by the usage of self-organising maps (SOMs). An SOM is an artificial neural network trained by means of an unsupervised learning algorithm; it performs a mapping which associates points of a high-dimensional space with points of a low-dimensional space (e.g., a bi-dimensional grid). SOMs are able to preserve proximity relationships among objects; this means that if two objects of a high-dimensional space are close, then their mappings in the low-dimensional space are close too. This allows SOMs to efficiently and effectively cluster objects of a highdimensional space by avoiding the curse of dimensionality problem.
A team building and team update system
71
In our scenario, we may gather data about the individual performance of an expert and his/her collaboration degree with other ones. These data are particularly rich and complex and, then, they contribute to defining very detailed expert profiles which can be graphically depicted as points of a multidimensional space. Next, we can train an SOM to map these data onto a bi-dimensional grid in such a way as to cluster them. This activity is useful to a human resource manager for identifying groups of related experts (e.g., groups of experts showing similar capabilities), which plays a crucial role both in team building and in team update activities. A further advantage is that SOMs allow relationships among data to be graphically depicted and this is useful to derive hidden knowledge patterns. This feature could play a relevant role in team building. In fact, the project leaders of a big projectised organisation could gather over time data about the performances of various teams and the management of human resources within teams. For instance, team performance data may indicate information like the productivity and the profitability of a team, whereas parameters about human resource management (often called ‘HR functions’) may indicate information like the compensation of team members, the availability of training courses, the presence of bonuses/benefits and so on. SOMs could be used to determine if there exists a link between team performance data and HR functions in such a way as to answer questions like: are there in ‘good teams’ patterns regarding HR functions which are absent in ‘bad teams’? What are the HR functions which most contribute to differentiate the performance of good and bad teams? Are there human resource management practices common to all good (resp., bad) teams?
References Baeza-Yates, R. and Ribeiro-Neto, B. (1999) Modern Information Retrieval, Addison Wesley Longman. Balke, W.T. and Wagner, M. (2004) ‘Through different eyes-assessing multiple conceptual views for querying web services’, in Proc. of the International Conference on World Wide Web (WWW ‘04), ACM, New York, NY, USA, pp.196–205. Becerra-Fernandez, I. (2000) ‘The role of artificial intelligence technologies in the implementation of people-finder knowledge management systems’, Knowledge-Based Systems, Vol. 13, No. 5, pp.315–320. Becerra-Fernandez, I. (2006) ‘Searching for experts on the web: a review of contemporary expertise locator systems’, ACM Transactions on Internet Technology, Vol. 6, No. 4, pp.333–355. Bertsekas, D. (1999) Nonlinear Programming, Athena Scientific, Belmont, Massachusets, USA. Biesalski, E. (2003) ‘Knowledge management and e-human resource management’, in Proc. of the International Workshop on Knowledge and Experience Management (FGWM 2003), Karlsruhe, Germany, pp.167–172. Chakravorty, S.S., Hales, D.N. and Herbert, J.I. (2008) ‘How problem-solving really works’, International Journal of Data Analysis Techniques and Strategies, Vol. 1, No. 1, pp.44–59. Chang, T., Liao, J. and Wang, X. (2008) ‘The effect of team-based performance appraisal on knowledge sharing: constructing and verifying an influencing model’, International Journal of Data Analysis Techniques and Strategies, Vol. 1, No. 2, pp.153–172. Colucci, S., Di Noia, T., Di Sciascio, E., Donini, F.M. and Ragone, A. (2007) ‘Semantic-based skill management for automated task assignment and courseware composition’, Journal of Universal Computer Science, Vol. 13, No. 9, pp.1184–1212.
72
P. De Meo et al.
Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2001) Introduction to Algorithms, The MIT Press. Coutts, L.M. and Gruman, J. (2005) ‘Social psychology applied to organizations’, in Applied Social Psychology – Understanding and Addressing Social and Practical Problems, SAGE Publications, Inc. Drach-Zahavy, A. and Somech, A. (2002) ‘Team heterogeneity and its relationship with team support and team effectiveness’, Journal of Educational Administration, Vol. 40, No. 1, pp.44–66. Dumas, M., Benatallah, B., Russell, N. and Spork, M. (2004) ‘A configurable matchmaking framework for electronic marketplaces’, Electronic Commerce Research and Applications, Vol. 3, No. 1, pp.95–106. Europass, http://europass.cedefop.europa.eu/europass/home/hornav/Introduction/navigate.action. Feng, S. and Burkhauser, R.V. (2009) ‘Generalised percentile ratios as robust measures of labour earnings inequality’, International Journal of Data Analysis Techniques and Strategies, Vol. 1, No. 2, pp.117–125. Fraganidis, F. and Mentzas, G. (2007) ‘Ontology-based competency management for corporate e-learning’, in Competencies in Organizational E-Learning: Concepts and Tools, Chapter XV, pp.311–324, Idea Group. Fraher, A.L. (2005) Group Dynamics for High-Risk Teams: A ‘Team Resource Management’ (TRM) Primer, iUniverse, Inc., Lincoln, NE, USA. Galil, Z. (1986) ‘Efficient algorithms for finding maximum matching in graphs’, ACM Computing Surveys, Vol. 18, pp.23–38. Garro, A. and Palopoli, L. (2003) ‘An XML multi-agent system for e-learning and skill management’, in Proc. of the International Conference on Agent Technologies, Infrastructures, Tools, and Applications for E-Services, NODe 2002 Agent-Related Workshop, Springer-Verlag, Erfurt, Germany, pp.283–294. Harzallah, M., Leclere, M. and Trichet, F. (2002) ‘CommOnCV: modelling the competencies underlying a curriculum vitae’, in Proc. of the International Conference on Software Engineering and Knowledge Engineering (SEKE’02), ACM Press, Ischia, Italy, pp.65–71. Hefke, M. and Stojanovic, L. (2004) ‘An ontology-based approach for competence bundling and composition of ad-hoc teams in an organisation’, in Proc. of the International Conference on Knowledge Management (I-KNOW’04), Graz, Austria, pp.126–134. HR-XML Consortium, http://www.hr-xml.org/hr-xml/wms/hr-xml-1-org/index.php?language=2. Kaufer, F. and Klusch, M. (2006) ‘Wsmo-mx: a logic programming based hybrid service matchmaker’, in Proc. of the IEEE European Conference on Web Services (ECOWS 2006), Zurich, Switzerland, pp.161–170. Kleinberg, J. and Tardos, E. (2005) Algorithm Design, Addison Wesley, Thousands Oaks, California, USA. Kline, D.M. and Galbraith, C.S. (2009) ‘Performance analysis of the Bayesian data reduction algorithm’, International Journal of Data Mining, Modelling and Management, Vol. 1, No. 3, pp.223–236. Kuster, U., Konig-Ries, B., Stern, M. and Klein, M. (2007) ‘Diane-an integrated approach to automated service discovery, matchmaking and composition’, in Proc. of the International Conference on World Wide Web (WWW ‘07), ACM, Banff, Alberta, Canada, pp.1003–1042. LaFasto, F.M.J. and Larson, C. (2001) When Teams Work Best, Sage Publications, Inc. Lin, D. (1998) ‘An information-theoretic definition of similarity’, in Proc. of the International Conference on Machine Learning (ICML ‘98), Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, pp.296–304. Maamar, Z., Kouradri, S.M. and Yahyaoui, H. (2004) ‘A web service composition approach based on software agents and context’, in Proc. of the International Symposium on Applied Computing (SAC’04), ACM Press, Nicosia, Cyprus, pp.1619–1623.
A team building and team update system
73
McGee, P. (1999) Writing a CV That Works: A Concise, Clear and Comprehensive Guide to Writing an Effective CV – Second Edition, How To Books Ltd. Mehandjiev, N. and Odgers, B. (1999) ‘SAMBA: agent-supported visual interactive control for distributed team building and empowerment’, BT Technology Journal, Vol. 17, No. 4, pp.72–77. Meister, D.H. (1997) Managing the Professional Service Firm, Free Press, New York, NY, USA. Mitchell, T.M. (1997) Machine Learning, McGraw-Hill, New York, NY, USA. Mochol, M., Wache, H. and Nixon, L. (2007) ‘Improving the accuracy of job search with semantic techniques’, in Proc. of the International Conference on Business Information Systems (BIS 2007), Lecture Notes in Computer Science, Springer, Poznan, Poland, pp.301–313. O*NET – Occupational Net, http://online.onetcenter.org/. Oxford Said Business School, http://www.sbs.ox.ac.uk/news/archives/Main/FT+ Mastering+Strategy+article+Lessons+from+professional+services+firms.htm. Pastore, S. (2008) ‘The service discovery methods issue: a web services uddi specification framework integrated in a grid environment’, Journal of Network and Computer Applications, Vol. 32, No. 2, pp.93–107. Penuel, B. and Cohen, A. (1999) ‘Coming to the crossroads of knowledge, learning, and technology: integrating knowledge management and workplace learning’, in Sharing Expertise: Beyond Knowledge Management, pp.57–76, MIT Press, Cambridge, MA, USA. Resnik, P. (1999) ‘Semantic similarity in a taxonomy: an information-based measure and its application to problems of ambiguity in natural language’, Journal of Artificial Intelligence Research, Vol. 11, pp.95–130. Russell, S. and Norvig, P. (2002) Artificial Intelligence: A Modern Approach, Prentice Hall, Inc., Upper Saddle River, New Jersey, USA. Sioutas, S., Sakkopoulos, E., Drossos, L. and Sirmakessis, S. (2008) ‘Balanced distributed web service lookup system’, Journal of Network and Computer Applications, Vol. 31, No. 2, pp.149–162. Straccia, U., Tinelli, E., Colucci, S., Di Noia, T. and Di Sciascio, E. (2009) ‘A system for retrieving top-k candidates to job positions’, in Proc. of the International Workshop on Description Logics (DL 2009), Oxford, UK. Sure, Y., Maedche, A. and Staab, S. (2000) ‘Leveraging corporate skill knowledge – from proper to ontoproper’, in Proc. of the International Conference on Practical Aspects of Knowledge Management (PAKM 2000), Basel, Switzerland, pp.22.1–22.9, CEUR-WS.org. Veloso, M., Jorge, A. and Azevedo, P. (2004) ‘Model-based collaborative filtering for team building support’, in Proc. of the International Conference on Enterprise Information Systems (ICEIS 2004), Porto, Portugal, pp.241–248. West, M.A. (2003) Effective Teamwork, Blackwell Publishing, Oxford, UK. Xidonas, P., Ergazakis, E., Ergazakis, K., Metaxiotis, K. and Psarras, J. (2009) ‘Evaluating corporate performance within the frame of the expert systems technology’, International Journal of Data Mining, Modelling and Management, Vol. 1, No. 3, pp.261–290. Zacharia, G., Moukas, A. and Maes, P. (2000) ‘Collaborative reputation mechanisms for electronic marketplaces’, Decision Support Systems, Vol. 29, No. 4, pp.371–388. Zadeh, L.A. (1965) ‘Fuzzy sets’, Information and Control, Vol. 8, No. 3, pp.338–353.
74
P. De Meo et al.
Notes 1
We recall that a concept a is superordinate to a concept b if a is more generic than b.
2
Here, k is a fixed threshold; its default value is set to 0.25 × CandTemSet ; however, the project leader can modify this value in a friendly and guided fashion.
3
In the prototype implementing our approach, thT Adq and Maxchange can be specified by the project leader by means of a suitable wizard.
4
il could be also negative. Observe that ΔT Adqint
5
il Clearly, also ΔT Adqext could be negative.
6
Since a change has been already made on Teamcurr , the maximum number of iterations for this loop is Maxchange − 1.
7
8
It is worth pointing out that the choice to set the maximum number of experts for a team to 50 was made to model real contexts better; in fact, in real life, if a project is too big, it is divided into quite independent subprojects and a team is built for each of them. Recall that team size is equal to 25 in Figure 8.
