Introduction to AoPs
When modeling performance, it is critical to establish good Areas of Performance (AoPs) up-front in the process. The AoPs create a configuration—an organizing scheme for the performance data that will be captured on Performance Model (PM) charts.

There are many means/paths to the ends of AoP creation. You, the analyst, can create them, or you can facilitate an Analysis Team in creating them. It depends on your desire to have your customer really own the AoPs versus you the supplier owning the configuration. As long as I can use it for my downstream needs, I would rather that my customers own the configuration of their performances!

Each AoP is then defined further via the Performance Model charts.

A Performance Model (PM) chart is a device that captures specified data in a specific format about human performance within business processes. The example chart below is one of many pages of PM charts articulating the ideal and gap performance of ABC account representatives.

AoP Definition
AoPs are the segments of the total performance. They create a framework for the performance – or the piece parts of the performance – that when all added up, represent the whole job – whether it’s a job, a role, a process, or a departmental function—whatever scope the PM effort is charged to address.

AoPs are more process oriented than content oriented. They reflect major output and task sets.
AoPs need to provide a logical structure for looking at the work performance. A set of AoPs created by one analyst would certainly vary from AoPs created by another analyst for a similar performance—the variation between the background and experience of the facilitator and the team members pretty much guarantees it. There are probably approximately 88 good ways to segment performance . . . and 88,000 bad ways. It’s not an exact science, and it’s rarely easy, but there are ways to make this work reliably with a group.

Creating the AoP Structure/Framework
Creating the AoP framework for analyzing performance is like dividing an elephant apart to study it further. An elephant is too big to analyze all at once. As the saying goes, “Don’t bite off more than you can chew.”

We could break the elephant down into thirds: front, middle, and rear. Or we could divide it by top, middle, and bottom. Or we might divide it into proper scientific classes of anatomy. Or we could focus in on just its front end, or just its legs and feet, or just its skeleton.

What’s correct depends entirely on your terminal objectives that caused your need to analyze the performance elephant in the first place. Our terminal objective is usually to design, develop, and deploy performance-based T&D within our PACT Processes, lean-ISD methodologies.

It’s also critical that your customers perceive the AoPs as appropriate and complete in representing their performance.

How do you judge the appropriateness and completeness of a set of AoPs? As almost always, it depends. It depends on the scope and terminal objectives of your project.

To challenge your first cut at a set of AoPs, ask yourself the following:

• Does it directly conflict with or contradict any other prevailing/established models of the process or performance? Will this politically sell? (We want it to!)
• Do all the tasks and outputs of the process/performer fit within this AoP framework? Are there any missing AoPs? (We don’t want any!)
• Does this AoP framework minimize all overlaps and gaps? Will the same outputs or tasks fit into multiple AoPs? (We want it to be very clean and clear, with no overlaps and gaps, if possible.)

The approach we take in our Analysis Team meetings is to ask the team numerous front-end questions as we waste a page or two of flip chart paper attempting to create some semblance of order out of the many things performers do in their jobs. That gives us “voice of the customer” (VOC).

But what about “voice of the supplier” (VOS)? Do we get a say in the appropriateness or completeness of the AoPs? Yes, we do!

As the T&D supplier, we have to judge the set of AoPs we are to work with in terms of how well this AoP performance framework will allow us to further analyze the performance targeted by our project.

Will the AoP framework assist us in specifying ideal performance, conducting a gap analysis, and then deriving all of the enabling knowledge and skills?

Or will it hinder us?

And finally, will it help us later in our postanalysis efforts to configure and sequence instructional content, detail the design, develop the instruction, pilot-test and update, and then finally deploy performance-based training and development (T&D) that has process performance impact for the good?

Will we end up with a positive ROI and Value Add when the dust settles?

If the AoP framework will help us, cool. If it will hinder us, then start over, even if the Analysis Team loves the nonuseful AoP configuration! This may be difficult to sell, but if we ISD suppliers can’t use it as a means to our ends, what good is it?

Utility of the Analysis Team
If we want our Performance Models to be good, we need to ensure that the framework we start with will serve us well and not lead us inadvertently into a blind alley or deep ditch. We always take our time at the front end of our Analysis Team meetings to warm up to the group and create this framework with their assistance.

The Analysis Team is there to help us help them, not to impede us. If we can’t do our job with the models that they demand we use, they hinder our ability to serve them. We must often sell them on helping us meet our needs as well as meeting their needs. This may take some time at the front end of your Analysis Team meeting.

Get your Analysis Team master performers and subject matter experts engaged in this PM process! They usually do want to play, even if they are resistant at the start. This is their world we are trying to model, and it usually is really important to them to get it right. They simply don’t often know what we are looking for as we start, and it feels awkward to everyone (including you, the facilitator-in-charge).

Going slow to go fast is our motto.

For more, go to http://www.eppic.biz/