Skills, competencies, and their representation for lifelong learning and employment

Issues and suggestions

Simon Grant, originated 2003-10-18, revised 2005-02-18, links checked 2012-05-25

The challenge

Electronic portfolio (e-portfolio) systems, along with other systems that record personal development, offer to manage information about a person's skills and competencies, partly so that the person can present evidence of those skills and competencies to other people (such as potential employers) who are interested in their presence in the person. (See some e-portfolio definitions.)

These e-portfolio systems can provide, among other services, the support for personal development planning (PDP), which is defined (in the UK) as "a structured and supported process undertaken by an individual to reflect upon their own learning, performance and/or achievement and to plan for their personal, educational and career development". PDP usually includes analysis or audit of skills and competencies, as well as planning for their development.

Work on the portability and interoperability of e-portfolio systems, including records supporting PDP, has brought up the taxing problem of transferring records which have been made in the light of different ways of describing and categorising skills (competencies, etc.)

For example, looking at some transferable or "key" skills at a high level of generality, it is generally quite unclear how much overlap there might be between ICT skills, communication skills, and management skills, or how they relate together. Then, at a more specific level, would any of these include, say, "ability to maintain business relationships by using appropriate language in e-mails"? (or any of the many other things that could be imagined at that level.)

The main scenarios we are imagining which require interoperability (or, put differently, portability) are of learners transferring from one place to another: school to college; college to university; any educational institution to employment; employment back to education, etc. At institution A, the learner may have:

1. recorded details at considerable depth of activities undertaken (whether educational or work-related);
2. done a self-audit of the skills that are featured by institution A;
3. connected the activities and skills up by saying how a given activity may be evidence of a particular skill, into a rich network of evidence.

The activities can probably be transferred without too much difficulty, but, when the evidence is transferred to the e-portfolio system in institution B, it does not automatically connect the activities to the set of skills as defined in institution B. So, from the point of view of the e-portfolio system at B, there would no evidence for any of the "B" set of skills. Whereas in fact much of the evidence will indeed be relevant.

It is also sensible to allow learners to define their own skill categories. This is because they need to categorise their skills in a way that fits their presentation to a future employer, partner, client, institution, etc. whose requirements in terms of skill are likely to differ again from those of the institutions in the way they are categorised.

This is particularly important in view of the 2003 DfES Skills Strategy White Paper, which makes the point that employers' skill needs are of the highest importance. The very beginning of the main report summary states as its aim, paragraph 1:

"The aim of this national Skills Strategy is to ensure that employers have the right skills to support the success of their businesses, and individuals have the skills they need to be both employable and personally fulfilled."

All this means a considerable challenge to full interoperability.

Unfortunately, no quick fixes

Isn't it possible just to agree on a set of skills and standardise on that? If everyone used the same set of skills, surely interoperability would be relatively easy?

The task of selecting a skills framework, and the task of making them interoperable, are quite different, and demand different approaches. Looked at from the perspective of searching for a skills framework, much of the writing in the area is very interesting, makes much sense, and is quite illuminating. Though there are differences in emphasis, looking through anyone's skills or competencies framework can be felt as a generally reassuring and unthreatening activity. We all agree in broad terms about what a skill or a competency is, and which ones are relevant to employment, and probably even which ones are transferable, etc. If there are any disagreements, they appear quite normal in an academic context, and just go to confirming that we are all talking the same general language.

But once one moves to interoperability, the whole picture changes radically. If one cannot decide exactly what skill belongs where in the framework, the whole enterprise is fundamentally compromised for interoperability, because straightforward machine-based rules cannot understand the rich background of discussion and opinion which underlies academic debate. Skills frameworks are either identical, or not: it is as simple as that.

So, though the idea of a standard skills and competencies framework is very attractive, unfortunately it does not pass any kind of reality test. The paper by Tim Oates, referenced below in the DeSeCo material, is a good start to understanding the theoretical problems. In UK practice, all the independent ICT systems which support PDP or e-portfolios, if they go beyond the very simple key skills as defined by the government (through DfES, QCA - see refs) have their own skills or competencies framework. No doubt it is similar in other countries. With a richer government-endorsed framework, perhaps such as the Conference Board of Canada (see ref.), encouraged and supported early enough, there might be a chance of some coherence within limited spheres. But, not only can there be as many skills frameworks now as there are academics to dream them up, but the employment market changes, culture shifts - so any rigid framework will inevitably reach obsolescence.

If there are any doubts remaining, a useful exercise for the reader would be to take any two independently conceived skill or competency frameworks, and map them together precisely and unambiguously, in such as way that the rules for mapping could be given to a machine to do.

Possible solution approaches

1. Standardise a complete set of skills. Even if this were possible in principle, the range of skills and competencies which are of interest to employers and others is vast, and it would take a very long time to reach there. The principle is in doubt as well. Different people and organisations naturally have different ways of looking at things and categorising them, so that they are unlikely to see relevant skills in the same way.
2. It may be possible to define a set of "primitive" or "elemental" skill components at a level at which there is no disagreement about their meaning. More general skills can then be defined in terms of the "agreeable component" skills they comprise.
   This idea is fine in principle, but still needs a great deal of work to make it operational, and even then would need extra work to actualise the interoperability.
3. Essentially do nothing, but allow skills requirements put together in institution A's programme to be represented as if they were user-defined skills in the institution B. This would require a lot of work in manually transferring the relationships to the new set of skills. This is the default solution, if nothing better can be arranged.
4. For each pair of institutions, define a matrix which defines how close each skill term is to each one in the other institution. If this were done, software tools could be created to help the learner convert from the past set of skills to the present one, in a guided way. For instance, when reviewing the evidence for skills in a particular action, if evidence had been linked to the past skills, the system could suggest their replacement by the most closely-related skills in the new set.
5. If the institutions had defined all their skills in terms of a common set of primitives, as in option 2 above, this process of defining the closeness of skill terms could be done automatically.

The relationships between skills

What, then, are the relationship between skills? They could be identical; overlapping; one could contain the other; or unrelated. But more importantly, we can look at the possible implications of one skill on another skill. This could be seen as follows.

1. Skill A implies skill B. Skill in programming Python implies more general ICT skill. This also deals with synonyms: "e-mail" = "electronic mail" = "email".
2. Skill A can be strong evidence of skill B. A system would suggest it as likely, but invite confirmation in case it wasn't right. For example, a managerial skill in one set could be strong evidence of a business skill in another set.
3. Skill A could be weak evidence of skill B. This would happen when the skills are not closely related, but not independent. For example, programming in C and programming in Visual Basic.
4. Skill A and skill B could be unrelated. For example, numeracy and French.

Option 4 is out on its own - if the two skills are unrelated there is nothing more to be said. The various combinations of 1, 2 and 3, separately applying to the relationship of A to B and B to A, define 9 other possible ways in which two skills can relate together. That is 10 in all.

If each skill is mapped in terms of its "agreeable component" skills, one can automatically generate a plausible relationship for any two skills, and this could feed in to the kind of tools that will have to be provided to allow a learner to convert relationships using one skill set to using a new skill set. If no such mapping is there, at least these are categories in terms of which a matrix can be built up manually, to serve the same purposes.

Concluding messages

If this analysis is reasonable, the implications are that:

• developers and vendors of e-portfolio and other systems supporting the analysis and presentation of skills and competencies need to build in the facility for representing user-defined and "foreign" skills (that is, from other frameworks), so that skill-evidence relationships from other systems can be represented within their system.
• every such system should develop tools to allow the conversion of evidence to its own native skill definitions. This will almost certainly have to involve intervention and supervision from the learner, which could be made part of a PDP process. The goal in the design of these tools will be to minimise unnecessary time and effort, and maximise the PDP benefits from the necessary effort.
• there should be an effort to define a fine-grained, comprehensive set of "agreeable component" skills in terms of which all other ones can be defined. This will not be a short process. If at any stage the definitions of some skill or competency components are not agreed, they would be broken down to a lower level at which they were indeed easily agreeable. The general agreeability matters far more than the actual level represented.
• in the meanwhile, resource will need to be allocated to building matrices of relationships between skills in each pair of ICT systems that wants to interoperate, or between which it is desired to pass e-portfolios. The relevant matrices will need to be held either centrally, or within each ICT system.
• each institution should define, perhaps in terms of RDCEOs, the skills in their own set, and publish these.
• PDP programme designers, as well as e-portfolio system designers, should consider other skill sets available, and consider carefully whether they might be able to use skill definitions which are identical to other ones already published, except where they find omissions.

The closer that different system define their skills, the easier it will be for learners to convert between them - but this must not be allowed to detract from their effective use in the actual PDP programmes. Practice will remain diverse, and the concepts to support diverse practice are very unlikely to merge completely.

Links