Listen to the Client – And Then Start With Their Process

Listen To The Client

Really listen. Actively Listen. Hear the Symptoms.

Socratic-ally listen, actively. Listen for the potential Root Causes. If the potential Root Cause is not obvious…

Then Look to the Process

– before running down the rabbit trails of the Enablers. The Enablers of Process.

Socratic-ally ask: is the Process (assuming there even is one) even capable of producing outputs to stakeholder expectations?

Has that ever happened, when was that, and when did that change, and what else changed at the same timeframe, etc., etc. – the whole Problem Solving sequence….

If there isn’t a Process – then start there.

One clue that there is no Process is when people who are asked “What is the Process?” respond with “What day is it?

That means “different Day, different Process.”

No rhyme, no reason.

Similar but different from “Different Day, Same ol’ SH**.”

A Process Exists Within a System – A Set of Processes

Here is my “starter model” for that.

I start with the Department that owns (or should own) the Targeted Process – that Process wherein the Issue lies – the issue being a problem and or an opportunity – often the two sides of the same coin.

I use this to see where the issue(s) shows up – and where they might originate from…

Of course a Department’s set of Processes exists within an Organization’s set of Processes.

And it can be modeled or mapped using various tools/means.

I have been using Performance Modeling the way things are ideal and gaps – not the “blue sky” way they should be – in mapping an Enterprise or Organization or Individual PERFORMANCE since 1979.

And I do it most often by using what some might call the “functional silos” – and the departments with – as my organization scheme. Reflecting the organization chart. My clients are most often in functions with departments versus some process-oriented organization scheme. But I’ve seen that too.

This next graphic traces one (theoretical) branching from the top – to the target.

I have been using a Performance Model format (one of many versions) – versus the Process Map – since 1979.

And yes I appreciate that there are many, many, many versions of a Performance Model. Same with Process Maps.

Here is one early version of the Swim Lane Process Map (with the top stakeholder/Client on top) – a Process Map, ala the late Geary A. Rummler, from my days at MTEC – Motorola’s Training & Education Center (1981/1982) – where I got a chance to work on many different projects with the good doctor. RIP.

However, in my Performance Improvement EPPI Methods – an extension of my ISD Methods (PACT) – I believe that the Performance Model captures more than the Swim Lane Process Map – but that each have their place – depending on the downstream needs and other tools/methods. I almost always use the Performance Model.

Here is a Performance Model example – using the format I settled on in the early 1980s. A lthough the number of R/R columns might vary from project to project, everything else remains the same.

This example is adapted from real work done for a client in the mid-1980s.

Modeling Performance and capturing the details on a Performance Model chart always followed figuring out what the Areas of Performance were.

Here is an example, from the same project in the mid-1980s, of those – the AoPs.

Note: Areas of Performance (AoPs) are similar but different from Major Duties, Accomplishments, Key Results Areas – typically, because typically they have nuanced meanings and conventions to those who use those terms and methods, and that sometimes gets in the way when we first start up.

Back to the Performance Model

For each AoP we start (beginning with the ends in mind) with the Outputs of Performance, not the Tasks.

Then, it comes to establishing the Measures of Outputs (and Tasks at a lower level and of the AoPs at a higher level – as necessary to your downstream needs) – and I use something akin to the Stakeholder Hierarchy (below) to establish who THEY are – those who sets the measures for the outputs for any grouping of performance – and use what they need and want – in establishing their Requirements as the drivers for Measures for each Output.

Once we understand the Outputs and the Required Measures – we can systematically list the Tasks, and then define the current state gaps between Mater Performers’ performance and non-Master Performers’ performance.

And then we can derive the enablers – according to our Project’s downstream needs – perhaps we are redefining the hiring criteria for the Recruiting & Selection systems and functions/departments.

My version of the Fishbone Diagram or Cause and Effect Diagram (more appropriately known as the Ishikawa Diagram) follows.

Taking the one Enabler Category of (Awareness) Knowledge & Skills further – here are the 17 sub-categories of the Enabling K/Ss I would use to systematically derive what the people “gotta know” – to be “able to do.”

And once all discrepancies are uncovered – that are at issue with the Process Not Meeting Requirements – one can look upstream at that Process to see which “Provisioning Systems” feed – with inadequate Inputs – to see why they are not properly aligned with the needs of their Customer – our downstream, targeted Process(es). You can even ask if the Training & Development system is appropriately contributing.

Performance Ain’t Simple

How you get to an Improvement – isn’t best done by taking a WAG (Wild A** Guess) or a SWAG (Scientifically-based Wild A** Guess).

That just leads to waste and then cynicism the next time around.

It takes Real Analysis. Analysis with a high confidence level in its accuracy, completeness and appropriateness to keep everyone – from the client side of an improvement gig – engaged – and even excited – when working on their world of work.

And that’s good for the ISD staff too.

Note – the earliest published articles on an ISD application, and on the analysis methods, were both published in 1984. Links are at the bottom of this post.


The PACT Processes are my ISD – Instructional Systems design processes, methods, tools and techniques – that I have been evolving since 1982 and include Curriculum Architecture design and my version of ADDIE: Modular Curriculum Development.

Down PACT Path 3

CAD – Training Mag – 1984 – 6 page PDF – the first publication about Curriculum Architecture Design via a Group Process – published in Training Magazine in September 1984. Original manuscript (30 pages) – How to Build a Training Structure That Won’t Keep Burning Down.

Models and Matrices- NSPI PIJ -1984 – 5 page PDF – the first publication of the performance and enabler analysis methods for ISD, from NSPI’s (ISPI’s) Performance & Instruction Journal, November 1984.

# # #

Leave a Reply

Please log in using one of these methods to post your comment: 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

This site uses Akismet to reduce spam. Learn how your comment data is processed.