The Information Architect as Change Agent

(First published on Boxes and Arrows on 9 October 2007)

Some years ago I designed an expert system to advise cotton farmers about the appropriate choice of pesticides. We spent a lot of effort dealing with some major technical challenges to turn research techniques into a commercial product. Unfortunately, we didn’t spend as much effort dealing with how it would be deployed to the real target audience: farm managers with little experience of computers. It’s not (just) that we didn’t think enough about the software’s user interface, but we didn’t consider how the farmers would need to change their behaviour to make effective use of the expertise that the software made available to them. As far as I can tell, this project became one of the 19% of IT projects that were never used.¹

Several past articles on Boxes and Arrows have mentioned the idea that an IA is often an agent of change. It’s worth reading those previous articles in full, but here’s a summary:

In Succeeding at IA in the enterprise, James Robertson writes that, ideally, information architects would be part of a team in which someone else is responsible for change management, but that in practice the IA often does not have the support of such a team and needs some proficiency in organisational change.
In Enterprise Information Architecture: A Semantic and Organizational Foundation, Tom Reamy accepts that IA’s are often agents of change, but points out that so are many other people, and that role ought not be seen as essential to the definition of IA.
In Change Architecture: Bringing IA to the Business Domain, Bob Goodman introduces the term “change architecture” and neatly summarises Kurt Lewin’s three-phase approach of Unfreeze, Transition, and Refreeze.

In this article I argue, with a bit of logic and a bit of experience, that IAs can do their jobs better if they understand organisational change management, even if they don’t need to be change management specialists. I’ll also suggest a variety of concepts and practices that can (hopefully) help IAs in their change agent role, and I promise to throw in something entertaining as well.

Speaking logically…

Premise: Information architects frequently introduce new technology into organisations.

Premise: Technological change inevitably causes behavioural change.

Premise: Organisations are systems that seek equilibrium and resist change.

Conclusion: A necessary condition for the successful implementation of new technology is the successful navigation of organisational change, and the information architect is often required to act as an agent of change within this context.

There’s Often No Choice

The kind of work IAs do leads to changes in the way people behave. We are in the business of providing tools and structures designed to allow people to do something in a different way (hopefully a better way!) than how they did it before. As Goodman wrote in the article cited above, “As IAs, we are not just architecting information; we are using information to architect change.”

Yet for all our concern about accessibility, usability and the user experience, we seem to think very little about the nature of change. How many projects have you worked on where the implementation team gave any consideration to the way people would be affected by the changes the new system would impose on them? If your experience is anything like mine, then the answer would be “bugger all”, to use a raw but expressive Australianism.

A software company I once worked for employed many outstanding people: a team of excellent programmers with a genius leader, hard-working and intelligent people in QA, dedicated and professional consultants, productive and dependable technical writers. Nevertheless, good IA was always crippled by non-technical, organisational factors: inadequate communications processes, inadequate specifications leading to frequent re-work, the wrong person doing the job (for instance at one point the Vice President of Marketing was personally doing the software’s graphic design) and scope creep caused by revenue imperatives, etc.

This business context, in which organisational factors contribute more to the success or failure of projects than technical factors, is far from unique. In such a context it is insufficient for the IA to contribute just their technical input to the system design: the effective IA must also play a role as an agent of change. Sometimes this role is within the product development team: educating and channelling the team to “take on board” good IA practices. At other times this role is oriented towards the customer: educating the end users and preparing the soil in which the new system will be planted.

Primer on Change Management

There is a large body of theory and expertise in change management and I don’t mean to suggest that IAs need to master that whole discipline. What’s important is to be sufficiently aware of the dynamics of change that you can work alongside other players to support organisational acceptance of new IT systems. On that basis, here’s a list of some core change management ideas as they relate to the role of an IA.

1. All change is stressful

Every change brings with it some balance of costs and benefits, but even when a change is entirely positive, at least two factors cause stress. Firstly, introducing a new IT system will require the users to learn something: perhaps a new user interface component, a new range of configuration options or a new workflow. It might mean a change in responsibilities that affects the way they relate to co-workers. Because of these effects, a software change often results in a short-term loss of productivity. Secondly, a transition to something new almost invariably necessitates that something is left behind. People undergoing change often experience a grief process, the extent of which depends on the size of the change, the length of time the person has been using the previous system, the level of personal comfort with the previous system, the individual’s social support network and probably a bunch of other psycho-social factors.

The stress of change is exacerbated when the change is involuntary. For most people, a change imposed by external forces is a source of disempowerment, reducing their feeling of control and increasing their stress.

2. Systems resist change

The stress of change is evident just as much in organisations as in individuals.² An organisation is a complex system, and like all complex systems it seeks equilibrium. Organisational behaviour tends towards a point where inputs, outputs, and internal processes are all stable. Such systems react to change as a threat and act to restore equilibrium.

In some cases change is resisted and sabotaged so that the organisation reverts to the known equilibrium of the past. In other cases, change is accepted and the organisation moves on to a new equilibrium. What guides an organisation towards the second scenario is effective change management. This is where Lewin’s “Unfreeze, Transition, and Refreeze” approach can provide a useful framework.

In Why resistance matters (available from “http://www.beyondresistance.com”), Rick Maurer notes that “Resistance is not the primary reason why changes fail. It is the reaction to resistance that creates the problems.” The professional IA will understand that resistance to change is inevitable and should use some of the techniques below to pre-empt and respond to that resistance.

3. Communicate

The people who will be affected by an IT change are unlikely to be impressed if the change is just sprung on them without warning. IAs can reduce resistance by ensuring that the nature of the technological change and expectations of behavioural change are communicated ahead of time. Concerns to be addressed include “Why do we need to change?”, “How will the future state differ from the current state?”, “When will the change occur?”, “Will it happen all at once, or gradually?”, “Will I receive the training that I need to make the changeover?” and “How will the change benefit me?” The last question is perhaps the most important, because people who can see the benefits of a change are far more likely to support that change.

Even if you believe the change will benefit the users, they may still have their own reasons for subverting the process. There’s a saying that goes “You can lead a horse to water, but you can’t make it drink”. I once heard a psychologist add to that saying: “But you can put salt in the oats!” He meant that you might be able to make the horse thirsty enough that it will welcome the water.

The next few points suggest ways to “salt the oats”.

4. Use participative design to foster “ownership”

There are many forms of communication and not all will avoid the resistance to change. If communication is one-way – from the people imposing change down to the users – resistance is virtually guaranteed. And it’s no good faking two-way communication with a couple of open question and answer sessions and a suggestion box. What you want is real involvement throughout the process by the people who will be affected by the change.

In a First Monday article, Marty and Twidale repeat a common claim that “the best way to evaluate an interface for usability is to test that interface with representative users”. I don’t disagree, but I believe that greatest benefit of user testing is not the feedback it provides about usability but the opportunity it provides to involve the users in the IA process. User testing is an important means by which the voice of the user can influence design decisions. The more participation there is by the user community, the more that community feels some control over the change.

This is a basic principle of participative design.³ When the people affected by a change feel ownership of the change because they were part of its design and development, they will more readily support the behavioural changes necessary to make the system a success.

Associated with this sense of ownership is the value of a shared vision. If the body of people who will be affected by a change understand the intended future state and are convinced of its benefits, then the energy and excitement within the group can drive the transition forward. This is even more so, of course, if the users created the vision in the first place.

5. Build relationships

The IA who is just a technical resource is far less valuable than one who can listen, build trust, and facilitate group interaction. The effective change agent is adept at forming relationships with business management, other technical contributors, and users. The IA is typically not the head of this team, but can be central to it, playing an empathetic and facilitative role as a conduit between the various stakeholders.

The IA can make a big difference to the outcome of a project by relating to users in a way that acknowledges the value of their contribution. That can be done by taking their opinions seriously (which is what user-centric design is all about), by personally thanking them, by giving public recognition of their ideas and by engendering a collaborative environment that encourages honesty.

6. Find a sponsor and a champion

In the team responsible for implementing a new system, two particular roles are worth special mention: the Sponsor and the Champion.

Some writers confuse or conflate these two roles. In Think like a consultant, for instance, George Olsen considers the need for an IA to be an agent of change and suggests the priority of enlisting the CEO as a champion but I think he means a sponsor. A Sponsor (or Patron) is a high-ranking person whose support for the project will guarantee that others will co-operate. The Sponsor just needs to “give the nod” occasionally to vest the IA with authority.

In most cases, however, the IA will not be senior enough to call the shots. Even with the Sponsor’s blessing, the IA will need the support of other significant change agents. In many cases, it is an effective partnership between the IA and the Champion that drives change. A Champion is the one who will push the project forward; ensure that the right people attend meetings, hire the necessary consultants, talk to everyone about how important the project is, inspire the team, push aside the barriers etc. Whereas the IA is often an outsider, the Champion is a respected and trusted leader within the organisation.

The Sponsor and Champion may not always be two separate people: they may be one or it may be that many such people are enlisted to help others to change.

7. The objective side of change management

Not all change management is as “soft” or subjective as the previous suggestions might imply. Insights from Enterprise Performance Management approaches, such as the Balanced Scorecard Methodology, can add elements of objectivity to change implementation.

Document a set of clear goals, for example, “Decrease data entry error rates”. If an IA project doesn’t have goals, how will anyone know whether it succeeded?
Define a set of measures that indicate the extent to which the goals are being met. In many cases, these need to be tracked over time or at least measured before and after the change. For example, “Number of times data validation errors are displayed” and “Percentage of transactions that are edited after initial submission”.
Identify project risks–that is, internal or external threats to the stated goals. Categorise the risks according to their estimated likelihood and potential impact and then plan how to either avoid them or mitigate their effects. For the IA, one significant risk will always be lack of user acceptance of the new system.
Reward behaviour that supports the goals. That’s pretty obvious really but often overlooked. What do data entry operators gain from making fewer errors?

To understand how these suggestions can be quantified and systematised there’s a good overview of the Balanced Scorecard Methodology on answers.com. While these techniques are totally ineffective without the inter-personal dimension, they can add depth to the IA’s toolkit and help to position IA within the larger domain of organisational strategy.

Conclusion: Encourage Authentic Participation

Through this article I’ve focused on that aspect of the IA’s role by which they contribute to change management. This may not be their primary role, nor even an essential role but being an effective agent of change can often mean the difference between a successful IA project and a failure. An agent of change needs to understand organisational dynamics and use their inter-personal skills to facilitate, motivate and empower behavioural change. I believe the most important principle in this process is to encourage the authentic participation of the people affected by a technological change in the design and implementation of that change.

Oh, and here’s the promised entertainment … Change is inevitable, except from vending machines.

Footnotes

1 See How to Spot a Failing Project by Rick Cook for a discussion of IT failure rates.

2 Some consultants, such as Sandy Fekete, push the analogy even further, evaluating “corporate personality” using psychological instruments like the Myers-Briggs Type Indicator.

3 The term “participative design” can be understood intuitively to mean “involving the users in the design process”, but I’m actually referring to the technical use of this term as it is employed by Enid Mumford and others who follow the socio-technical approach to systems design.