Over the last three years of helping clients implement competency management frameworks, we inevitably begin with the same question: “how do we construct and categorizes our competency library?” This is a great question, one that touches every point of the competency management business process. This question also doesn’t have one single correct answer, as it is dependent upon the company and business process. However, there are five important items to consider when making this decision. It is important to note that maintaining a competency catalog is an evergreen process in an often changing, dynamic business environment.
Before diving into these considerations, let’s define the type of competency management covered. Technical competencies – the entirety of assigning, assessing, and tracking the knowledge, skills, and experience required to perform specific activities. Whereas, softer leadership competencies do not require such a detailed structure.
Competency library example
Example of a functionally driven competency catalog. This model could be built out with additional location nodes to satisfy unique local requirements.
The most basic principle of constructing a competency library is navigation, or the ability for administrators and end-users to easily find individual and groups of competencies. Keyword searches are also useful but rarely provide the content of a structural view. Ensure your competency groups follow a sound naming convention and that the parent-child hierarchical structure follows a consistent logic.
Who owns the competencies from a business process and administrative perspective? Grouping these competencies together in ‘for like’ groups based on ownership will give the owners greater visibility into their competencies, giving them the ability to make decisions and their administrators the ability to action them.
Types of competency/assessment
From an administrative perspective, you will need to consider how competencies are going to be assessed. Some of the technical competencies may follow a one point proficiency scale (competent vs. not yet competent) whilst others utilizing more of a development model with a four or five-point proficiency scale (Aware, Basic, Skilled, Expert). Perhaps some of the competencies will be satisfied purely through training, and no knowledge/demonstrated assessment is required. These decisions all play into the structure of your competency library. Group competencies that follow different assessment processes should not be cataloged within the same parent group.
You may be wondering how end-users are going to interact with the competencies once they are assigned. End-users generally interact with competencies through the assessment process. The assessment process would be directly affected if competencies are assigned to the user without being constructed in a logical manner, with users not knowing which competencies to focus on at a given time. Sorting or prioritizing competencies and groups within the library with this in mind can help to add focus and clarity to the user’s assessment process. Perhaps the end-user should focus on the safety-critical competencies first. Or, maybe the competencies are assigned to new starters as a part of the onboarding process. Also, do they need to be assessed in some general competencies first in order to get them on to the job quicker? The prioritizing of a user’s assessments and therefore workload can be supported by your competency library construct.
Commonality of Competency
A big red flag when building your competency library is creating too many duplicate competencies. This is often the case when you include location too high up in your competency library hierarchy. If a competency looks and feels the same as another these should be consolidated into a single object and moved to a more global or functional group. From my perspective, this is the most important consideration when building a competency library. The ability to reuse the same competency impacts both the mobility of your workforce and global analytics and these are often the drivers to initiating a competency management process in the first place. Leadership in one location or division should be able to perform a talent search against a set of competencies and expectations and find all people who fulfill these requirements, and this is tough to achieve with duplicate competencies. Having said that, specific local requirements are, of course highly important which are often imposed through regulation. There just needs to be a balance between the common and the specific. Striking this balance could be as simple as assigning a common set of competencies per job role, with specific local add-ons when required.
There is no magic bullet to creating the perfect competency library. They should be constantly evolving and are a balance between competing requirements. However, with some thought, the structure of your library can drive value into your competency management program.