KPIs – Key Performance Inhibitors and a method to transform theses back to Indicators

This month I am dividing my time between several initiatives at work:

  • Technology development activities
  • Process adoption
  • Metrics definition
  • Skills transfer

A rather interesting and eclectic combination of activities. But as I started to ponder these I started to reflect on the metrics definition activities of past and the relationship to other initiatives on my list. My goal is to create a suite of KPIs for my group that is useful in advancing our success. With that premise several things come to mind.

  • KPIs or metrics that truly indicate how the organization is progressing to its goals; rather than those fool us into believing we’re doing well when we’re not
  • KPUs that the organization believes in; that is, we have control in positively effecting these and can relate to achievement of our goals
  • KPIs that are diagnostic; they provide insights to help us determine what we can do better

This is a tall order considering people often are suspicious of how measurements are used. Especially if such has been used in the past not as guidance but justification for other agendas. This typically results in KPIs that are meaningless but always show green, even in the face of disaster. Such have a witnessed before within sales organizations that measured success by size of backlog rather than quality of backlog or customer satisfaction. This eventually became a game of musical chairs with the unlucky sales rep. at the end of the cycle taking the hit for a bad backlog he had nothing to do with.

Based upon such experience, my belief is that KPIs need to be a serious discussion and negotiation between all levels within the organization. Staff must believe that these measurements are able to be influenced by their actions; Management must believe these measurements indicate status of the journey to goal achievement.

These seem simple enough, except that the altitude that each party operates at is different. If you’re a Senior Executive you’re often looking at corporate performance: profit/loss, customer satisfaction, market share, etc. If you’re a programmer in IT you’re focus is on cost and time of delivering an application, response time of system, uptime, etc. This difference in metrics can and often does create misalignment between management and staff.

The results of which is often KPIs become Key Performance Inhibitors as staff become disillusioned with measurements as they can’t relate their measurements with goals management focuses on rather than how their measures relate to business measurements.

This conundrum can be address with a method called Hoshin Planning. Hoshin Planning is nothing more than a cascading set of matrices of goals, strategies, and measurements that relate one altitude of measurements to another. While the technique works well, it does require additional effort between management and staff to be explicit about the goals, tactics and measurements as well as reasonable in setting measures and targets that assignees believe are achievable. This however, is not a simple twenty-minute exercise and like all planning requires constraint revision in the light of new information (i.e., planning forecasts are not accounting transactions).


Structure in Threes: Building vs Planning

One of the problems systemic to the design and planning world is the often famous quote:  “Its done its just a small matter or implementation or programming or etc.”  All too often I’ve seen designers or planner consider the job done once the design is finished.  However, there is often a lot of work to get it accomplished; even it there are not changes to the design.  This got me thinking about the terminology used in regard to projects.  To me implementation take is a larger concept than just deployment which seems to be the typical thoughts around projects, especially in IT.  “The application has been installed we’re done”.  True implementation carries with it both deployment and adoption, anything less is just dumping.

The proposed remedy to this is to have adoption KPIs included in project metrics, not just development cost and schedule.  This would foster a greater concern that what is built is actually used.

Structure in Three: Governance

This week’s research agenda continues on governance and the interfaces of controls with decisions processes for portfolio management.  The further I dive into COBIT 5 the more I like the taxonomy and structure.  While there are gaps, these are explicitly called out in the management guide where research is needed.  Which is interesting as those are the areas I’ve been focused upon, so at some point convergence is likely.  I’ve started to White-Board an assessment tool (MS Access DBMS) which would include COBIT-like concepts yesterday.  As I reverse engineer and rebuild my Access V1 Consultant Workbench (B.A.S.E.) I’ll be adding TIPA & COBIT to the modules I previous built for the platform.  I like using ACCESS more as an intelligence platform that EXCEL due to its ability to build relational models, however, as of late I’m looking at build highbred applications using SharePoint, ACCESS Services and EXCEL.

With more than a few years under my belt in management consulting, methodology and support tools development I have come away with insights on how to make consulting practices more efficient and effective.  B.A.S.E. was developed with that insight in mind years ago.  However at that time management consulting was operated around time & materials billing rather than outcomes, so efficiency and effectiveness in operation was counter to the revenue model.  If it took less time to deliver results to the client you were taking money out of your pocket.  Despite calls for outcome based billing by such notables such as Allan Weiss, Peter Block, and Gerald Weinberg the industry and oddly enough clients still used T&E as the primary billing method.  Which I suppose makes both parties more comfortable and believe easier to contain risk, as time consumption is easier to measure than progress to an outcome.  Just an interesting side-note.

As I continue governance research, the next major area to develop is adoption.  While COBIT 5 describes the change management within implementation, like most other implementation activity very little is defined in this arena.  The majority of efforts listed are on planning the technical rollout and communicating the schedule of such.  From my experience with reengineering processes, such approaches limit effectiveness of change programs.  If left to the end of the lifecycle, stakeholders are suddenly thrust into dealing not only with technological and process aspects but also social and emotional aspects as well.  And as experience has shown experts in the field we continue to ignore, people take longer to change attitudes and behaviors than it takes to implement the technology and define the processes.  The work that John Kotter has accomplished on change management  looks to provide a good base, the next level of development is to move from his strategic framework to create a catalog of tactics and methods to support each stage similar to the business development framework I’ve been recommending to small and medium business colleagues by C.J. Hayden .  End of week I hope to post draft of tactics and methods for adoption stages or find and post a reference by someone else that has already done the research.

Structure in Threes

Spent this morning detailing the book outline.   The two part approach looks like it will work nicely: Part One explaining the concepts to those unfamiliar with the techniques giving a foundation to work with, Part Two providing a step by step methodology and explanation of how to use the templates I’ve created.  From a one and a half page outline the planning effort has yielded five pages of chapter and section objectives with small screen shots of templates to be used and a good start on the bibliography and suggested reading list.  The collection of templates I’ve created in past years that I have to update or clean up is growing rather rapidly, that even before I’ve integrated all of them into a common system.  I’m considering creating a common platform like Azure to be the base to integrate all data.  However, I don’t think Azure comes with my Office365 Small Business subscription, so I may have to use SharePoint and Access Services which is not a significant limitation for now.

In the meantime still working on getting Home Office back in shape, today’s task will be getting some of the library in workable form.  I’ve about twenty stacks of books in front of book cases to reorganize.  Now’s the time I wish I had hired that librarian I was talking to at the library of congress.  –At least the stacks are chunked into useful clusters by the taxonomy I created for quick access.  Glad I sent time years ago researching Ontology, Taxonomy and Semantics; it has really helped throughout the years with research.

Forces that influence increasing IT Economics maturity

The maturity of resource allocation of most IT organizations are typically less than the resource allocation maturity of the enterprises that host these.  This is not a surprising finding given people and groups usually adopt the norms and behaviors of the context they are surrounded by.

For an IT organization to increase it’s Economics Maturity it needs to address the concerns of its host.  This suggests stakeholder analysis and managing expectations is of significant importance, possibly more importance than the level of precision of the actual economic justification.  Texts on decision analysis  indirectly discuss this phenomena.

One strategy to mitigate this issue is to choice the appropriate level of methods for both decision and organizational decision maturity.

Many organizations often in an effort to expedite decisions either choice methods that are too simplistic.  This can result in decisions that don’t address the nuances of the problem or are not repeatable as inputs and influences to the decision are not explicitly, hidden in pockets of subject matter experts or decision makers.  The other alternative are decision processes that are overly complex.  Initially the rational of these complex processes is to provide a comprehensive system for making decisions.  Where this often goes wrong is that the process becomes the standard and dogma for all decisions.  Thus creating a bureaucracy for decisions.

A possible remedy for this unintended consequence is to develop a  series of decision processes at different levels of complexity and guidance as to when to use which.   While it can be argued with the information technology one all encompassing process can be created and automated thereby reducing the overhead in these processes making them easier to execute.  The problem with such a strategy is that it neglects that the decision maker still needs to understand the attributes and variables to make an effective decision.  For a complex decision there are not only multiple variables but typically require time to digest the interaction of variables.  Using a similar process for simple decisions places undue delay.

Another strategy is to create a decision team composed of the stakeholders, guide them through the development of the economics case themselves.  This has several benefits.  First it helps raise the knowledge level of the group.  Second it help build confidence in the methodologies used  as they develop experience.  Third, an open discourse explicitly raises concerns of stakeholders to be addressed.

Implementation, Deployment and Adoption

A few months ago a peer of mine and I took an afternoon to mindmap her presentation on User Adoption.  During that time we realized that the topic was going to require more than one presentation and could fill an entire conference track.  This was her first time on the speaking circuit; actually second as she tagged team with me on one of my sessions a few months before.  But this was her first without training wheels.  I was pleased that her session was well received, actually better than well received; she got applause from the entire audience.   It’s been a few months since and now she’s eager to present at another major conference.   

This brought to mind the topic of adoption on a visceral level.   Initially I had tried to get members of my team to present at conferences.   It had been an uphill battle.  My score at been 0:6.  So I decided to try another tactic.  I figured I’d remove some of the anxiety of presenting by co-presenting; therefore my peer didn’t have to carry the session all by herself.  She had a little bit of nervousness, but, came through just fine.  Nobody noticed or commented on mistakes, she didn’t freeze nor die of fright.

Months later she came to me asking me to help.  She wanted to present by herself at another conference.  She was confident about presenting but unsure about the topic or what to say.   After a few questions back and forth we decided that the topic of adoption would be something she could add value to.  She had previously specialized in change management as part of her career, so adoption seemed like a rich topic.

For her first presentation she decided an overview covering the topic would be of value.  During our brainstorming / mindmapping session thoughts of implementation, deployment and adoption came to mind.  I put these aside till today as I’m poised to work with her again assembling another session for a conference next year where we’ll tagged team again.  But this time she’ll be confident presenting.

The reason I bring this up is often as professionals we confuse implementation and deployment with adoption.   I was after implementation having teammates present at conferences.   My efforts at deployment trying to enlist members resulted in limited success until I changed my deployment methods.  I needed to understand why teammates were hesitant to present.  Once I address their concerns of fear of the unknown I got adoption. 

This was an interesting lesson to relearn.  Years ago I had read an excellent article from Sloan Magazine on Stakeholder Analysis that highlighted for change to be successful you need to address other’s concerns in order to realize your goals