Competency Frameworks – How Much Detail is Enough?

J.L. Griffiths, FCMC CTDP

Competency frameworks are a fundamental tool for developing your organization and your workforce. They are a vital part of a competency management SYSTEM.

Yet… they often aren’t used effectively. Complaints run the gamut from “too much detail, too cumbersome, too complicated” to the other extreme “not detailed enough”

Maybe the problem is that people are trying to use frameworks to accomplish things they weren’t designed to address.

How much detail is enough?  The answer is, it depends on who is using the framework and for what purpose.

When designing training from scratch, details are good. Which may be one of the underlying problems with the way frameworks and competency profiles are typically developed.

In Canada, the standard approach for developing frameworks is DACUM (Develop A CUrriculuM), or some variation on that method. The process was designed in the late 1960s by Dr. Donald Glendenning and Larry Coffin of Holland College in Prince Edward Island Canada and has since evolved into a comprehensive model for designing and developing competency-based training. The Canadian Vocational Association, and Dr. Robert Norton at Ohio State University Centre on Education for Training and Employment (CETE), have raised the profile of DACUM internationally, and it is now widely practiced around the world.

Which is great – if the end goal is developing a curriculum. However, for managing competency in the workplace, the level of detail that is produced through a typical DACUM analysis is just too much to be usable for managing competency on the job.  And, since competency profiles and frameworks are often (usually?) developed by HR and/or the training function in the organization, the DACUM occupational analysis document is what is typically produced – and handed to a line manager or supervisor to use when the competency approach is implemented.

We’ve seen quite a few competency programs over the years that were launched with the best of intentions, but that died on the vine because of too much detail.

We’ve also seen others that died because there wasn’t enough detail – although there are fewer of these.

Is there a “Goldilocks” level of detail that can satisfy both the needs of front line supervisors and managers for day-to-day performance management, the needs of the HR function in recruiting people with the right skills and competencies, and the needs of trainers who have to create learning and training programs?

Maybe – but too often a “one-size-fits-all” compromise really amounts to a “one-size-fits-no-one” debacle that winds up serving no one particularly well, and so the competency program slowly withers away, and the legend is lives on in the organizational culture that “this competency stuff is BS – we tried it and it just doesn’t work”.

Maybe the problem isn’t the concept of competency-based approaches or the standard tools – but a misunderstanding of how they can be used, by who, for what – and designing a system that supports multiple use cases.

“Agile” Frameworks

“Agile” competency framework is a term I first heard used by Ken Delve  – a consultant working in the petroleum industry in the middle east – almost a decade ago. The idea is to create competency frameworks that are designed from the outset to be used in different ways, for different purposes, by different people within an organization, and then create a system around them that supports those different contexts. The framework needs to be “fit for purpose” – useful and usable was Ken’s term  –  by a variety of end-users.

How? The secret lies in creating frameworks for the organization that define what competent performance looks like at multiple levels of detail.

That sounds more complicated than it is. Let’s look at how this shakes out for “Joe” (and I apologize to all the Joe’s out there) – a supervisor in a manufacturing plant.

Is Joe a competent supervisor? Well, if we develop some concise statements that answer the question “what is the outcome of Joe’s work when it is performed competently?”, Joe’s manager can look at Joe’s performance on the job and say with conviction “yep… Joe is competent”.  For Joe’s manager, that level of detail is all that’s needed for day-to-day performance management. If we wanted we could even add some additional details at this macro level to create some anchors for both minimally acceptable, and higher/superior levels of performance in the role.

But what if there’s a problem, and Joe isn’t meeting the performance standard? Well, at this level of detail the manager can tell something is wrong, but can’t really help to fix it – other than maybe yelling at Joe to pick up his game – and that’s not overly helpful feedback.

In order to be useful in helping not only identify that competency may be lacking, but also to help address a competency gap, the framework needs to have a “next layer” that breaks Joe’s job up into some broader categories/duties/responsibilities – if Joe isn’t performing adequately, then there will be deficiencies in one or more of these broader categories, and if specific performance statements are attached to these categories, we can diagnose where the problems are that are causing Joe’s performance problem.

In fact, the framework needs to be constructed in a way that lets Joe’s boss “peel back the onion” to smaller and smaller chunks of competency until they can identify the root cause(s) of the performance issue. Then – and only then – can the performance issue be addressed.

So, the key to “agile” frameworks is to define competent performance in measurable terms, from the role/job (at the highest, least granular level), through the underlying duties and responsibilities, to the competencies that underpin these duties, and on to ever more granular levels – if necessary all the way to foundation level skills, knowledge, attributes and transferable meta-competencies that are the necessary building blocks for performance.

But that’s not all. The competency management SYSTEM needs to allow end-users to access competency standards only at the level of detail necessary for a particular purpose.

Too often the framework has performance criteria defined at only one level of granularity (which may not be the right one for a particular use) and the system doesn’t allow users to access and use competency and performance statements at only the level of detail that’s necessary for their immediate purpose.

The key to generating this sort of agile framework and system? Don’t put the creation of the framework (or the system) entirely in the hands of HR, or training departments – start by figuring out how the end-users (managers and supervisors, generally) will need to interact with the information and use it to manage day-to-day performance within their work teams. Work backwards from the front-line to the support functions to make sure that at every level of detail, there’s performance information that can allow diagnosis and prescription.

Designing your competency management system – and competency frameworks – this way takes a bit more up-front effort, but results in a more flexible (ie, ‘agile”) system that will be immensely more useful to the organization.

Previous: Competency 101 – Part 4: SHOW ME THE MONEY!!!!!!

Next: Quality: People Before Process