Structure in Threes: Management Systems

For the record I’m typically for performance based compensation systems.  Maybe because I think you should be focused to perform your role for the best of the company to start with.  I see approaches such as stack ranking, top grading, etc. as creating a cascading effect that has employees and management “game” the system.  The end result is a death spiral where people spend more time looking good than doing good at the expense of the customer and investors.  After reading chapter eight of Rummler’s book reDiscovering Value, I see why and where these systems have gone wrong; basically measuring and rewarding the wrong behavior (local optimization) rather than doing the best to create value across the enterprise.

I’m finding a lot to like about Rummler’s approach towards creating a management system that works:

  • First reengineer the processes cross functionally to enable real value creation
  • Second design a dual management system that focuses on the value creation performance and then resource performance
  • Third design the compensation system weighted towards value creation system performance as top priority

I can see this approach keeping in check the desire to optimize resources in deference to creating value which is what keeps a business in business.

Creating a new Practice/Service: Modern IT Portfolio Management

This morning I started investigating how to structure and document the approach I’ve been developing the past several years on effective and efficient management of IT Resources.  This suggests I create a new Consulting Practice and associated services that comprise that practice.  As I researched how to document the approach and practice I was surprised to find that the majority of the consulting literature that describes designing a practice is more concerned with the management of the practice as a business than the delivery of the approach to the client.  This seemed rather odd till I considered that this area was developed by the management consulting which is more concerned with the management of activities than the execution of actual activities themselves. [a little harsh judgment but if you do the math you’ll find little documentation about this domain compared with management theory and approaches]

That said, this morning I stared at a blank white board and considered using process models as  base.  I had used those to define strategy and marketing processes before which were very similar in how they are performed.  That settled the next item for me to address was getting several terms defined to ensure consistency as I develop both the practice and the book.  With that goal in mind here are the first few terms in my taxonomy with a first draft of definitions to go along with them:


Practice – a set of services assembled to provide a specific benefit or benefits for a client.  The services are delivered through the performance of a specific set of activities as defined by the practice’s methodology.

Service – a ordered set of activities that provide defined benefit for the client. Services are delivered through the performance of a specific set of ordered activities (methodology) that provide artifacts and the desired results for the client.

Methodology – an ordered set of procedures, actions, artifacts (work products and deliverables) that when performed create a predictable and repeatable result that is beneficial to the client.

Artifact –  A physical representation of information or decisions used or made during the performance of an activity. Examples include work products that are used as inputs to an activity, procedures guides, assessment tools, and or deliverables such a status reports, final reports or directives that relate decisions or activities that others will act upon.

Workshop  – Workshops are the primary means to perform the methodology and deliver the service to a client.  A workshop consists of a series of activities, each with an input, exercise, output, and checkpoint.  The input will consist of at least a guidance slide deck and possibly other work products requests for support of the exercise.  These work products may be either client documents to reference or templates the client has been asked to complete prior to the workshop.  During the workshop participants will be asked to perform one to several exercises.  These exercises are designed to transform data into meaningful information, actionable insights or decisions to be later acted upon.

ExercisesExercises are structured tasks the participants are asked to perform that manipulate the data and information.  The objective of these exercises is to transform the data into decisions that support the enterprise’s goals and objectives.  How to perform these exercises is defined in the guidance deck or methodology guide, work instructions for supporting templates and/or user’s guide for tools if used within the exercise.

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.