That’s a good point Debra about the IA’s special knowledge of users. We should be able to act as spokes-people, representing the interests of the user to the rest of the development team.

You wrote (edited for length): “A software company I once worked for employed many outstanding people…. Nevertheless, good IA was always crippled by non-technical, organizational factors: inadequate communications processes, inadequate specifications leading to frequent re-work, the wrong person doing the job and scope creep caused by revenue imperatives, etc. This business context, in which organizational factors contribute more to the success or failure of projects than technical factors, is far from unique.” This is an easily missed point. I once took a project management course where the instructor started the course by saying, basically, that software projects never fail for technical reasons. Even if the project fails because the development team couldn’t implement the code in a timely fashion, that’s not a technical failure, it’s a project management failure.

The only quibble I have with the article is about being a change agent with the customer, “…educating the end users and preparing the soil in which the new system will be planted.” I agree that this happens and I agree that it’s sometimes inevitable and I agree that when it’s inevitable that IA/UX needs to be deeply involved. But I think it’s worth emphasizing that producing a product that requires our customers to change is a Bad Thing, and whenever we hit that situation we should immediately step back and ask ourselves whether we can change course so WE change instead of the customers. So when we run into situations like this, “… we didn’t consider how the farmers would need to change their behavior to make effective use of the expertise that the software made available to them.” I think the appropriate response is to ask, “How can we minimize (or eliminate) the need for the farmers to change their behavior to take advantage of our product?” The more change we require from our end users, the less likely are our chances for success.

But again, I agree with you that this is sometimes inevitable and IAs/UXers need to consider that as part of our jobs.

Have you looked at SSM – Soft Systems Methodology? http://en.wikipedia.org/wiki/Soft_systems

A couple of quick notes on the second major idea, Systems Resist Change:

You say, “An organization is a complex system, and like all complex systems it seeks equilibrium.”

Systems often seek states other than equilibrium, something especially true of organizations in business environments, typically oriented toward growth of some kind, or efficiency. (Lately, the buzzword is innovation, but the pattern is that equilibrium is not their goal.)

Which leads to, “Organizational behavior tends towards a point where inputs, outputs, and internal processes are all stable.”

This sounds similar to the homeostatic view of organizational goals and behavior. It’s important to mention that many kinds of organizational goals work against homeostasis; think of the startup pursuing aggressive growth, innovation, acquisition, etc. Stability in this context is something to work against.

“Such systems react to change as a threat and act to restore equilibrium.”

As above, some organizations embrace changes in their states, or even actively seek changes: meaning change is not always a threat to these systems, and is often regarded as a benefit.

Basically, I’ve taken the long way around to say that context matters at the level of change management, which means that we should be aware of the organizational goals that drive our assumptions and approaches to change management in order to be savvy IAs.

I think your points about organizational resistance are spot-on. My particular take on this is that organizational culture drives most, if not all, organizational inertia.

I think I agree with the sentiment, but not the detail. It’s a great principle to make the computer model of a task match the existing users’ model as closely as possible. And asking ourselves whether we can do so is the right thing to do. The problem is that the answer is often “No”. There are (at least) two reasons why we can’t avoid the need for the customer changing their behaviour.

The first is perhaps pedantic, but the introduction of *any* new tool must change the way the task is achieved. Even a change to an existing tool means that people have to use the tool differently. So even a minor front-end IT change necessitates a change in user behaviour, even if its just clicking in one part of the screen rather than another. Even small changes in the tool mean that the user has to learn something new and leave some earlier behaviour behind.

The second reason is a practical one: the current state of technology often doesn’t allow it. Computers are in the early stage of their evolution and in many ways are very primitive. There are ways we’d like to implement applications that are not (yet) possible. Language parsing is an important example. We’d love to allow people to communicate in a way that is most natural to them — i.e. using their natural language. But we have to force other UI metpahors onto them and make them change the way they communicate because current technology cannot match their preferred behaviour.