The ideas that Lars and yourself are talking about are things I’ve been attempting (often unsuccessfully and unskillfully:)) to articulate to every organization that I’ve been a part of.

There are a lot of reasons why I think that alternative delivery methods fail to live up to potential:

1. They are often thought of as isolated interventions. This makes me a sad panda and goes back to the ‘spray and pray’ solution mentality. This is a tough nut to crack with so many stakeholders and owners (each with an expectation of traditional packaging.)

2. We support the product assembly with an array of theories. The ‘pick what you want, flavor of the day’ theory support makes it pretty difficult for us to self diagnose what’s wrong with the typical package. Try to bring a pragmatic argument to the table and you are met with ‘but, so and so says’. I don’t care as much about what so and so says as I do about meeting the needs of my peeps. Truth is a solution is about more than what a slew of theories ‘can’ support. It’s about doing what you can when you can to deliver the right solution. Minimalist ideas fit the bill.

3. Our design folks often get hung up on what’s been done before. We are model driven and breaking out of a pattern of packaging is a really difficult task. Changing that expectation with exemplory cases and following that up with comparative studies is likely the only way we are going to win the expectations battle.

4. When something new comes along (rapid eLearning, for example) decision makers tend not to fully qualify it for what ‘part’ of the need it will meet and how it will meet that need. Ooh, a new paintbrush. Order a bunch of these and we’ll have everyone paint everything with this brush. It’s far too easy for folks with a limited imagination to evaluate a solution path for what it is instead of listening to bits of pundit around the table and concluding with narrow focus.

5. Our design folks are limited in their skillsets by many years of learning what we think they need to know to DO what they need to do. The traditional education focuses a tremendous amount of energy on theory and practice to support the theory. As a result, it’s a little unfair to expect most designers to be able to fill multitude of skill roles that it takes to make a successful product. Knowing how to write is a rare skill. Of those that know how to write, even fewer can write well for their audience. I’ve seen far too much of what I call androidgogy. Programmed instruction…

6. We bend to the will of the SME. We bend to the will of the designer. We bend to the will of the stakeholders. We bend to the will of the developer. So many wills. The SME wants to fill it with his passion. The designer wants to do everything they can to apply each theory appropriately (structuring the product by these rules). The stakeholders want their piece, often adjusting the design during development as they see what can be done or ask others what they think since ‘this stuff isn’t their business’. The developer wants to contribute, this often results in overcomplication of the solution. We need less forces of will. Particularly when we try to keep these forces equal.

So we have come to a point where we now expect that we can toss aside our developers and one-stop-shop a soup to nuts product with a small staff of designers. Unless we change what our folks know, we are destined to experience the same level of fail we have been for quite some time.