Defending change

Resistance to change often comes from those most loyal to the organisation.

I worked in the IT department of a large end-user organisation for fifteen years. For much of the time my role involved advising my colleagues about the technologies and systems that we had, and on the approach to and impact of change.

As part of this role, I had to critique new technology, new packages, development projects and management initiatives, and consider if and how these would work alongside our existing IT. A large part of my role was to represent what we already had to those wanting to change it.

This was a valuable role, but in the end it was untenable. Although my job was to understand and advise on how best to change, inevitably my role became misinterpreted as resisting change. Eventually, I found myself on the wrong side of organisational politics and had to go.

Over the past few years I have been working more as a consultant. I help organisations collect the information they need to support change, and help organisations develop new ways of working. As I work with other organisations, I see mirrors of my old self cropping up time and time again.

Whatever change we are involved in, we always come across resistance from a minority of people. Although it is tempting to dismiss them as selfish "blockers" who are resistant to change, I find myself sympathetic to them.

Often the people resist because for years they have been guardians of value. If my experience is typical, they have had to defend the organisation from dozens of ill-conceived products, projects and management initiatives. However much I believe in the work I am doing, I respect that the people I contend with are doing so out of loyalty.

Is this conflict inevitable? Will the defenders of IT always be sacrificed on the altar of change?

Sadly, I think they will. Organisations encourage people to be loyal and committed, and though this works well for years, the individuals involved can never know when they should finally capitulate. But as someone who has spent time on both sides of the argument, I have some advice.

If you are proposing change, respect those who resist. They may have spent years defending against multiple ill-conceived initiatives. Engage with them honestly about objectives. People will often agree with the ends more than the means. And if they do not agree with the objectives, then you can tackle that directly rather than wasting time arguing about the details of the changes.

If you find yourself resisting change, remember that those pursuing the change are not out to get you, and would rather have you on their side. Work out what they really want. If you think your position is under threat, remember that being open to change is the most secure option.

And if you run an IT organisation, watch out for putting your people in an impossible situation. If people are too settled and committed to what they are doing, move them around before they can no longer accept change.

This won't get rid of the conflict. But it might make it a little more bearable for all involved.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Client or server?

Like many design questions, deciding whether to perform processing on the client or the server depends on who you talk to.

Many applications perform some processing on the client (or PC) and some on a server, and the designer needs to decide what processing runs on which.

The server is a more controlled environment, and is the right place to manage data and implement business rules. In a web-based application, the server sends the results of this to the client as a web page.

The browser on the client is responsible for interpreting the web page and interacting with the user. In some case, the web page is just displayed by the client. Many application provide additional user interaction, typically written in JavaScript.

The split of responsibilities between client and server is generally easy to understand. The boundary between client and server can be modified, for example carrying out more on the server if more control is required, or more on the client if more interaction is required. But wherever you draw the boundary, there can be situations where it is difficult to decide where to put the processing.

We hit this situation in our Metrici Advisor assessment tool. Assessment results are collected into result sets. This uses incremental recalculation and caching, which are best done in the well-controlled server environment. Showing the results, in tabular or graphical format, is best performed in the client browser.

Some processing falls in between these two, such as selecting which rows and columns of data to show, and preparing data for export, for example as CSV.

In cases like this the designer needs to weigh up the strength of requirements for server characteristics and client characteristics. In this case, processing on the server would allow views of the data to be pre-calculated, cached and combined, and reduces the amount of data transferred between server and client. Conversely, processing on the client would provide a more instantly interactive experience, and closer integration to other client features such as graphics. We need to weigh up the relative merits of each.

However, to be honest, it is hard to make a completely rational choice because the designer will generally be more comfortable with one environment than with the other. I am as guilty as anyone on this. I grew up using mainframes and dumb terminals, and err too much to server-based processing. So my applications are robust and well controlled, but a bit clunky. These days the opposite is probably more common, with developers with a good knowledge of web technologies putting too much in the browser, giving richly interactive applications which look good but are not so robust. Architectural decisions like the split of processing between client and server are more often dictated by the past and preferences of the designer than a rational analysis of requirements and capabilities.

In this case, working with a colleague who is more steeped in client-based processing, we have compromised on a single JavaScript component that can be used on the server or client, which I believe is a good solution. It is only by recognising our biases, and working with people with different viewpoints, that we can create the best designs.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Using technology to create structure

How can we use technology to support the evolution of structure?

Over the last couple of weeks I have been considering how, for all but the most routine work, it is wrong to impose too rigid a structure on the work before it starts, and that we need to accept that structure will evolve as the work proceeds.

There is a lot that technology can do to help. Computers are good at holding different deliverables, and make it easy for us to change and rearrange them to create the structures that we need. Although we take them for granted, office applications - such as word processors, spreadsheets, and project management software - are great tools for gradually building and refining our ideas. Collaboration tools, from simple file sharing and email to sophisticated platforms such as Microsoft Sharepoint, allow us to work together on shaping structure.

To explore this further, I thought I would go though some of the thoughts we have had on how to use Metrici Advisor to create structure. Although Advisor is ostensibly a tool for carrying out pre-defined assessments, most situations demand something more fluid. Often the idea of what we are assessing, the objectives, the materials, or the people involved, are not known before we start.

To help build structure, here are some of the things we have been doing to support our clients:

• Using Advisor as a secure file upload tool to share initial documents.


• Using Advisor as a hybrid database-survey engine, defining a database structure, and then creating surveys to populate and interlink the items within it.


• Using libraries of pre-defined assessment materials to create more tailored materials for specific client situations.


• Extending the analysis and reporting capabilities, to explore and visualise data, to build meaning and structure for the clients.

All of these help turn initial ideas into more formal structures. So far, however, this use of Advisor has been reactive, using the tool to overcome specific client problems. There is much more we could do proactively to support fluid and evolving fact-finding and analysis. For example:

• As well as capturing factual assessments, we should make it easy to capture and interlink other types of information, such as opinions, decisions, assumptions, judgements and conclusions.


• Advisor provides lots of structuring capabilities, such as creating links, classifications, calculations and rules, which we use for building solutions. We should make these more readily available as part of the end-user experience to build structure.


• We can provide better support for planning, process management and tracking progress, allowing Advisor to structure more of the entire process.


• We should strengthen the subscription mechanisms, to make it easier to incorporate pre-defined materials and patterns into an evolving structure.

These kinds of features help bring order and structure to the ill-defined and messy situations that exist in the real world, and this is a good direction of travel for any tool that supports fact-finding, consultancy and advisory activities. Of course, I do not know exactly what we need, but that, like everything else, will evolve as the work proceeds.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.