Location, Location, Location: Does It Matter Where Your Performance Improvement Department Reports?

Download PDF

BPTrends, June 2013

Authors: Alan Ramias, Cherie Wilkins

 

Regardless of your specific focus, if the mission of your group or department is to improve performance of people, processes, technology or functions, you have probably wrestled with the question of where it would be best for you to report. lt’s an interesting question, especially when you consider that most organizations have more than one group whose mission is performance improvement. Over the years, we’ve seen considerable change in the perception of their effectiveness and place in the pecking order of internal performance improvement groups. As a result, we’ve seen performance improvement groups form, grow, merge, split, centralize, decentralize and be disbanded. We have seen highly regarded PI departments integrated into the line business, under the VP of Quality, or HR, or OD, or IT, or Strategy, Or Finance. It begs the question, “Does it matter where your group sits in the organization?”

The major driver of migration has been the changes in perception of where improvement can be most effectively supported. The “lead” role tends to go to the function associated with the greatest organizational leverage. Often this change in perception comes about because the organization has picked up on a fad or trend. So, for a while, the most visible Pl departments we saw were in departments that reported to the VP of Quality; lately they tend to be found under the CIO. This migration of visibility, influence and budget is interesting to watch but it makes it easy to lose sight of two critical points:

First, regardless of who is top dog it usually requires a team of performance improvement specialists with unique and complementary knowledge and skills to bring about any lasting change in performance.

Second, the names change, but in many respects the work doesn’t. We just attach different jargon and biases to the work, including what we call ourselves — Black Belt, Process Consultant, HR Business Partner, OD Consultant, Performance Consultant, Finance Business Partner, Project/Program Manager, IT Business Partner, BPM consultant, and so on. Titles aside, all of these people are trying to improve performance of the business. So what’s the issue with a performance improvement group being in one function or the other? There are issues of client perception, functional bias, and internal completion that need to be dealt with.

To the manager with a performance problem, the world of possible solutions looks like this:
figure1

(for high resolution graphics, please download the PDF file above)

The manager feels he must have an idea of the solution he needs before he can know who to call for help. We know of several performance improvement groups that are imbedded in Training organizations. Naturally, the majority of their requests are still requests for training. Likewise, Process Improvement groups imbedded inside IT tend to only get involved in IT process projects. Some of these groups had their genesis in the departments in which they reside, so it can be an uphill battle to shake their legacy and get clients to view them as performance improvement generalists. Even ISPI, (International Society for Performance Improvement) still (after 15+ years) struggles with the transition from their training roots to a focus on performance improvement, especially anything beyond human performance. And of course, naming of the department can only reinforce client perceptions. Performance, process, and process management are all terms with baggage.

When the performance improvement group is embedded within another function, the biases of that function tend to take over. Ideally, any performance improvement group should remain solution-agnostic, even though they may also be experts in a particular solution. They should be able to diagnose a client request for help and prescribe the appropriate solution or solution set regardless where that solution comes from. Most improvement projects require complex sets of interventions to solve the issue completely. But the IT-embedded groups tend to look at requests in terms of how IT could solve this problem and the HR/OD-embedded groups will focus on human performers, rarely if ever giving IT a second thought.

Last, most organizations suffer from internal competition between all of the groups providing performance improvement solutions. Each one of the specialties has its own front-end needs analysis methodology. Most of them are assessing the need for their solution rather than a more general and agnostic assessment of the performance problem. So now any other performance improvement group is viewed as being a competitor rather than as a partner who can add to an effective, multi-dimensional solution. Fueling this atmosphere of internal competition is the tendency of many leaders to want simple, one-dimensional solutions. Rather than recognizing that complex problems often require complex solutions, senior leaders will cast about for whoever seems to have the silver-bullet answer. The natural response of internal solution providers is to claim they have that single solution.

So where should the performance improvement group reside? In the short term, it really doesn’t matter — it’s about being on the management radar, gaining recognition that you can add value that isn’t structure-dependent. In the long term, it does matter: it’s harder to win budget battles and attract talent if you are buried deep in the structure or have a mission that doesn’t align with your peer departments. One common misperception, however, is that reporting level equals relevance. We’ve seen all manner of desperate political attempts to report in at high levels. More often than not, this distracts from the real determinant of relevance, which is achieving results. A focus on achieving results can conflict with political aims. Central to the credibility of any PI department is the ability to be a neutral “truth teller” even when that’s not what all the senior stakeholders want to hear. The truth can be couched and packaged, but it can’t be lost or so is credibility.

What’s Really Required

 

#1 – A Results Focus
Get out of your domain and put yourself in the domain of the client, mentally and physically. Spend time with your clients, attend their management meetings, listen to the issues they struggle with. What performance they are looking for? Then bring them models and ideas that reflect that you understand their world. Look past the symptoms and off-the-cuff solutions, understand the real issues at play and validate your understanding before making commitments to results and taking action. This is critical to gaining their confidence and a partnering
relationship.

#2 — Solution-Agnostic

Your front-end analysis should not assume a solution. It should be an exploration of all of the variables that impact the desired performance. It should include a look at human and IT performers, processes and organizations. Based on the findings, you can put together the appropriate team to fully address the issue. This will more than likely be a set of solutions, from multiple providers. This is different than asking a good PM to integrate a set of solutions. This is asking for an integrated approach to analysis. The performance department is responsible for seeing that the analysis and design is approached in a holistic and integrated way. This path, however, is not easy. It requires partnerships with others and an ability to head off management’s tendency to want quick, simple, one-dimensional solutions.

#3 — Partnerships with Solution Providers

You must seek to build partnerships with all the solution providers. Everyone needs to operate with a common view of organization — a common process model, a common definition of work and resources. You also need to adopt a common improvement language, to avoid confusion among both the clients and solution partners. And finally, you need to integrate the various methods and tools — no overlaps or unclear connections. You need to figure out how DMAIC works with RUP or Agile, how process maps link to both use cases and SOPs.

And, so we come back to the question of structure. Assuming that you have addressed numbers 1-3, here are three potential structures that we have seen work in a variety of organizations, which solve many of the issues we have discussed:

A Non-Embedded Performance Department

The department takes in all requests for performance improvement help. It performs a solution-agnostic diagnosis and then leads a multi-disciplinary team through solution development and implementation. Okay, yes, this department has to report somewhere, into a party perceived as neutral.

figure2

A Performance Consultant in the Client Organization

The performance consultant takes in all requests for performance improvement help. He or she performs a solution-agnostic diagnosis and then acts as general contractor to assemble the right team of solution providers.

figure3

 

 

A Performance Consulting Community of Practice

Although they come from various disciplines, the solution providers all operate from a common view of the business, have integrated their methods, are using a common approach to analysis that looks at the whole performance system in question and can prescribe any of the specialties as a part of the solution set. They are solution-agnostic performance consultants who aren’t looking for a nail for their hammer and regularly team up with their PC colleagues on projects. There is regular sharing of learning and results.

figure4

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Any one of these structures provides a more client-focused, results-focused way to provide performance improvement to the organization. They do not assume that the client knows what the solution needs to be. And no matter which business fad gets management attention next week, it provides a way to integrate that new potential solution into the portfolio in a way that does not skew or disrupt the delivery of results.