Practice Network: Final Thanks and Thoughts on Implementation

Scott L. Martin
Payless ShoeSource


This is my final column for Practice Network.  I would like to thank our editor, Laura Koppes, for this opportunity and for her support over the last few years.  I would also like to thank all the practitioners who have contributed to this column.  Your insights certainly contributed to the practice of organizational psychology.

In my first column I indicated that our work has three fundamental phases:

1. A needs analysis or diagnosis of the problem or objective
2. The development and implementation of a solution or intervention
3. An evaluation to determine whether the intervention effectively addressed the problem or objective

At that time, my view was that we focus a bit too much on developing and implementing solutions (Step 2) and that we would be better served by focusing more on needs analysis (Step 1) and evaluating our interventions (Step 3).

I’ve changed my thinking.  I believe it helps to split Step 2 above into two steps and view our applied work in four phases:

1. Needs analysis
2. Developing the solution
3. Implementation
4.  Evaluation

I continue to believe that developing solutions (Step 2) is our strength and that our expertise applies to many different types of solutions such as competency models, performance management systems, and learning programs.

I continue to believe we have some opportunity for improvement regarding needs analysis (Step 1) and evaluation (Step 4). In terms of needs analysis, I found our seasoned practitioners (those having more than 10 years of experience) to be excellent.  However, it seems our less seasoned colleagues tend to get caught up in technical jargon, models, and solutions, rather than starting by truly immersing themselves in the business and problem to be solved.  I recall Rich Klimoski, my primary professor at Ohio State, sharing something along the lines of “You need to know a lot about an organization to build a good survey.”  It seems a similar comment applies here.  You need to know a lot about a business to improve its performance.

In terms of evaluation, I think we clearly have the skills to do this effectively.  It seems our challenge here is to apply the appropriate amount of rigor for the situation.  There are probably interventions in which the impact is fairly evident without elaborate evaluation efforts.  On the other hand, there are probably significant and/or innovative interventions that deserve more attention than we typically provide. 

My main learning from working on this column is that implementing solutions seems to be our most significant opportunity for improvement.  Seasoned practitioners mentioned, for example, performance management systems that were not being properly used 5 years following implementation, survey programs that had inconsistent follow-up and gained little traction, and training programs that made little or no effort to be sure that behavior actually changed on the job.

Why the Implementation Gap?

I’m not entirely sure why we have such difficulty implementing our solutions, but I offer two thoughts:

1.  Implementation is generally not that difficult from a conceptual or intellectual standpoint.  I think we tend to be clear and creative thinkers, and implementation is not viewed as particularly interesting so it receives less attention than it might deserve.
2.  The behavior we are generally trying to change is significant and difficult for our customers.  In addition, we are often trying to impact hundreds or thousands of people across many departments and locations.  Thus, we are talking about a lot of “back-breaking” work.

Thoughts for Improving Implementation

Below are a few thoughts that may help implement our solutions.  I have not repeated many of the widely recognized practices such as gathering customer input from all stakeholders, careful planning, lots of communication, and providing user-friendly training and reference materials.

Design simple solutions. We have a tendency to design innovative and comprehensive solutions.  I think this is a function of our training and capabilities and is largely commendable.  However, we should focus more on the ultimate objective of our work and recognize that “more is not always better” for our customers.  As an example, I was involved in an effort to upgrade a talent management and succession planning process, and one of the changes was to replace open text boxes with drop down boxes to capture strengths and opportunities for each executive.  In theory, this was an excellent idea.  It should have made it easier for users and easier for HR to identify common development needs across the entire organization.  In practice, the drop down boxes failed.  Raters wanted more flexibility in documenting strengths and opportunities, and they were accustomed to using the open boxes.  We ended up returning to open text boxes.  This is a minor example, but it should highlight how a minor design issue can get in the way of a much broader objective of developing talent.

Pretest anything new.  Consistent with best practices in product development, we should see first hand how our ideas will really work with end users.  It would be helpful to identify a few typical users, along with those we suspect may have the most difficulty, and observe them as they attempt to use our proposed process from beginning to end.  For instance, if we’re implementing a new performance management process, we might fly to Omaha and observe the regional manager as she completes the process for her 20 direct reports.  This should allow us to work a lot of the bugs out of the system.

Pilot anything new.  We should then implement the entire process in one or two departments or locations.  We might not select the most difficult or mission critical area, but we probably shouldn’t restrict our pilot to HR either.  We want to select a unit that will generate good insights on how the process is actually going to be used by the masses.  Of course, the trick is to be aggressive in soliciting feedback and using it to really improve the intervention.

Conduct follow-up checks.  Surveys and data audits are helpful, but it’s also important to have the designers and other members of HR periodically walk around to observe and discuss how the system is being used.  This should probably occur more frequently following the launch of a new process but should occur to some extent over the life of a program.  Things can change, for better or worse, over time.  Again, it’s important to approach this process with a bias toward corrective action.  When we learn that a customer is not using our system as planned, we should focus on revisiting our processes and resources rather than blaming the user (e.g., “I can’t believe George wasn’t capable of accessing the system.”).

My suggestions probably mean it will take longer to implement new initiatives.  In today’s fast-paced environment, this may make us appear slow and unresponsive.  However, I think this will actually improve our speed of achieving the intended objectives.  I believe the above suggestions will increase the number of times our customers say, “I can’t believe how HR improved the effectiveness of our business with the XYZ program.”

Again, my sincere thanks to everyone involved in this column.  I have enjoyed working with you.