And I love your notion of patterns (and your diagram). I think with experience we do develop patterns, and making them explicit is at least part of the goal of my series).

Cammy, I’m sure I’ve more to say on the subject, just not every Monday, rather I’ve exhausted the original series of topics I wanted to cover. I’ll pipe up again, be sure of it. :)

http://www.xpconcept.com/profile_patterns.jpg

I think it depends on the organization, but where I work the HPT/I model for problem and gap identification along with solution recommendation is in the Analysis phase. If you have some time you might find value in attending our annual HPT conference: http://www.uscghpt.org.

You raise some really salient points, Clark. It’s uncanny how close your weekly dispatches are to discussions we’ve been having over the past months.

Recently, I’ve tried to push a new situational process concept. I love patterns and see a lot of potential value in a shared pattern language and field library. The concept I’ve proposed is a mapping between a problem or performance profile and a pattern or selection of patterns that have worked in similar situations. I say situational because no one process shell works in every situation. I’ll describe what I mean below… Hopefully better than I’ve been able to describe to staff ISD’s that respond with ‘uh, wut?’ and blank stares.

First, I’ll say that the ADDIE model works in every situation if one thinks of it correctly. I think the ADDIE model encases all of the possible phases one could undertake when establishing a solution. However, the model may appear as AD(esign)IE, or AIE. I think we get so wrapped around the DD that we often neglect the other phases.

If we minimize A, then we miss our opportunity to challenge the assumptions, to collect all of the ‘natures’ and establish an aggregate profile and subordinate profiles that would strengthen the case for the solution. If we ignore A than we’ve missed our chance to provide the best investment and in many cases the right KSA solution (if a KSA solution is even necessary).

Some place the alignment in the Analysis phase… Alignment is a process, not an event. If we don’t all ride in the same balloon basket then we have no recourse when the SME wants to bring lions and elephants, nor when the customer wants to start shooting holes in the balloon.

Most organizations tend to almost completely ignore E. Aside from A, E is the most important activity phase. Formative evaluation helps to tune the solution as you go.

So the ADDIE model isn’t broken. People just don’t use it the way it was intended. We are lazy, I suppose.

Back to the Profile:Patterns model. I’m sure that what I’m talking about isn’t new. But there are concepts that are not common, and there IS some uncommon pairing of elements.

Touched on profiles. I think of profiles as a combination of ‘natures’. The nature of the gap, the nature of the skill, the nature of the audience, the nature of the environment. Each of these natures is comprised of elements like Performance conditions, subject matter factors, practical application factors, etc… These should be identified in the analysis, but in concept the profile construction provides an avenue to challenge these in the context of their combination.

The attributes of the profile (I’ve been toying with some of the ways this could be represented) are defined using common language elements that ease the mapping to a pattern set. One example might be using a user attribute: Limited computer access and skills. A set of patterns may match up with this particular attribute. Enabling the decision maker / designer to filter suggested choices based on all of the profile attributes helps to narrow down not only what general design frameworks ‘might’ work, but also those that have a high probability of not working at all.

Patterns fall into two general categories, strategic and tactical. Models form strategic patterns while components form tactical patterns. For example, a model might be a general assembly model for representing a performance concept. A component would be a more specific concept model to address a more specific nature attribute (perhaps a skill of hand assessment element like assembling a weapon).

Just an idea that I think has some good application aligning the field. Dr. Ian Douglas and I proposed something similar a few years back. The response from the community in general was ‘we have best practices, we don’t need patterns’. This dismissed the entire idea of a pattern library and language. That we have problem solution pairing across the field, things we know work and things we know don’t work…

Where I really think profile:pattern would be powerful is for the emerging trend of ICDM (I Can Doit Myself).

At any rate, good stuff once again Clark.