An Old Insight Revisted: Competencies are not jargon or buzzwords

During one of my total reengineering projects I happened upon one of the major problems with most BPR/M projects.  One you redesigned the processes and activities you needed to assign people to accomplish the tasks.  The problem was most of the job descriptions were so vague and vacuous that anyone could reasonably apply or they were so specific and jargon filled that even the person already successfully doing the role would not recognize it as their role.  It was clear from the role descriptors management had not seriously worked with the Human Resource department to really define what was needed to be successful.

I could understand this, most management are focused on day to day operations, their individual scorecards and the latest crisis they have to manage.  Which yields the ever famous “I don’t have time to sharpen my saw, I have to cut down all these trees syndrome”.

However, being brought in to reengineer the business function I had the luxury or rather the insight to know reengineering was more than moving boxes around a flow or org chart.  When I had taken on the engagement I had included time to redesign the roles also that supported the process.

In that effort I was fortunate enough to find HR staff willing, enthusiastic and actually surprised that I was reaching out to them as part of the team.  “Usually, we’re asked to the table to formalize the description to search for, not design the job…”   We had a few weeks –this was a long engagement—to discuss how to partition the work and what would make a person successful in each role.  From these discussion and further research I built an MS Access Database that related Process, Deliverables and Outcomes with Competencies.

The term competencies is a loaded word within several communities as the lack of it has a negative inference.  In the context I use, the term competency is simply a configuration of elements that enable one to execute an activity.  The model I built into the Access database is fairly simply in concept:

One or more competencies are needed to perform an activity or task.  Each competency has three components:

  • Knowledge
  • Skill
  • Behavior

Partitioned this way one can separate buzzwords from defining what a person must have to accomplish a task.  The toughest part to measure objectively, Behavior, is still one I’m working on.  This still seems to be in the realm of an experienced HR professional or Recruiter –their secret sauce if you will.  I can define some but mainly capture what a great HR professional can relate after discussing the components of the role and process.   After six of these large scale reengineering engagements I’m confident the model has proven out.

I plain of include a more detail discussion of this insight in the Org Design book now in works.


About briankseitz
I live in PacNW in a small town and work for Microsoft as a Enterprise strategy and architecture SME. I enjoy solving big complex problems, cooking and eating, woodworking and reading. I typically read between 4-8 business and technology books a month.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: