IT departments, legacy systems, and limitations

A friend and ex-colleague of mine, Paul Swain, recently wrote a quick little post called “You’re pissing in my pond now“, which was around his thoughts on the matter of the IT departments and legacy systems that frequently hamper him during his work as Head of User Experience at The Unit in Brighton.

Paul and I have had many discussions over the years on this matter, and worked together on a particularly challenging project where the IT systems and teams were at the core of all decisions being made. His post prompted some thoughts of my own, so I thought that I’d add to his (already great) blog post with a reply.

Whilst it can be frustrating being blocked by IT departments or legacy systems (I’ve been there too; I’m a realist), I think that there are certain things that can be done on both sides to help smooth over some of the bumps. You’re always going to get flat out ‘no’s sadly, but it’s still worth trying a few key things right from the start.

As you may be able to work out, a lot of the below is what I do. This is all stuff that I feel strongly about, and is why I set out on this adventure to be a consultant. It really frustrates me when I hear of talented people being unable to deliver great work because legacy systems can’t support them, or IT teams won’t allow them, or simply because some basic tech planning wasn’t done up-front. I think we should all do a lot more to push for change, and to help clients understand if things could be done differently or better over the long-term. Too much of our focus is on scopes, deliveries and ticking requirements boxes, when really it should be on forming relationships, teaching, and helping solve problems.

Involve the IT team and technical consultant right from the start

Paul cites an example where he “recently had an important piece of jQuery functionality shot down because the current JavaScript library is outdated“. Introducing something ‘simple’ such as an upgrade to a JS library can often strike panic into teams where the knock-on impact is unknown – despite unit tests and modular development being prevalent within our industry, a lot of legacy code and teams don’t follow such principles, and simple suggestions can cause a flurry of chaos.

By getting a technical consultant involved early on, you can have someone assessing the systems, architecture, and overall ecosystem that exist around sites. They can flag up any potential issues, or identify areas for improvement. These could be things that are well out of scope from the original brief, but I’m a big believer that teams brought onto a project shouldn’t be so blinkered as to ignore or dismiss other areas without trying to ask the difficult questions. If suggestions are made early on, it may be possible to change areas that wouldn’t be possible later – for example adding some calls in to an API, upgrading libraries, or introducing other third party elements. In the above example, it could be an opportunity for the agency to actually work with the team, to establish the impact of updating the library, identify whether any affected areas could be improved at the same time, and whether practices such as unit testing could be taught and brought in. If you’re able to share your knowledge, understand problems, and work with the IT teams rather than just dictating terms, then projects are often a lot more successful.

The other benefit to involving IT teams early is to get their input into what they would like to happen. Very often it’s the case that internal IT teams are seen as being hostile to outsiders, however the reality can be that the same outsiders can help to facilitate changes that the IT guys haven’t been able to make happen. Say you’ve been pushing for a move to upgrade a major version of something, or to make your site responsive, or even to update that ancient jQuery, but your manager won’t facilitate it. If an outside consultant can come in and explain the benefits, sometimes this is all it needs to tip the balance of senior management approval. By listening to the IT teams and their frustrations, and building these into plans, it can really help the project later down the line.

Thankfully I don’t tend to experience this first-hand, but sometimes it can be the case that because an agency is a “design agency” or a “user experience agency”, they sometimes don’t see any kind of technical research or input as being relevant to them. It’s often up to the client to make things happen – the agency can make their suggestions, but if it fails due to the client’s internal team… well… that’s a shame. It shouldn’t be like that. We don’t want to be restricted by limitations and for technology to kill any potential greatness, but at the same time we need to be realistic. Our interface designs aren’t just superficial – they have a knock on effect to CMSs, or editorial teams, or whether we can get access to, or afford the data that we’ve scattered across our pages and components. We should make sure that our concepts will work across devices and platforms, and that performance won’t suffer. Our rationale should be based on sound technical principles as much as what the user sees and does.

Mixed teams and prototypes

Making sure that techies are involved in designs and proposed solutions is really, really important. I harp on about it all the time, but my favourite projects are those where I’m able to work alongside UXers and designers. This was something that Precedent do very well – during my time there last year I was able to work literally alongside a mixed team, and could get to grips with functionality whilst the UX and visuals were taking shape. Sketches would be produced which I would proceed to butcher by sticking post-it notes all over, referencing API calls and content management data structures. If we knew that an API couldn’t support something, then that was fed back to the client and designs could be updated accordingly. I checked that our geolocation concept would work by making a terrible looking prototype, which again got fed back into the overall solution. We made sure that the realities of the technical implementation, and the systems we were integrating with, were possible alongside coming up with our ideas.

The approach that I love best is when there is scope for a technical person to bring ideas to the table as well as testing out others’ ideas. I love hearing about a particular goal for a user, and to think “well what if we could supplement that with this information, or find some tech that might be able to enhance that“, and run away to see if there is an API available to support it, or something else we could leverage. For example, if the team are thinking about what users want from a holiday booking site, I might think about the related data that we could get. With historical data from weather APIs – why not allow sun-seeking users to search by entering the time of year they want, and to present to them the places that have typically been most rain-free over that period? By exploring technical capabilities and bringing little proof of concepts to the table, you can often help spark much bigger ideas.

Strong management

Paul also mentions the fact that having a digital advocate in a senior management team can really help when it comes to blockers, and getting decisions pushed through. From experience this can go two ways – with a lack of strong management it tends to come down to ‘us’ and ‘them’ again – either the internal team gets listened to because they’re part of the pack, or the outsiders get listened to because they’re being paid to advise. Either is dangerous and will likely lead to one side of the fence feeling resentment. Having a stakeholder who can act in a fair way when presented with decisions, and who can explore alternatives and impact of different options is absolutely key. Likewise, any agencies or consultants should be sure to present rational pros and cons of what they are trying to achieve in order to help them make that decision, and ensure that what they’re recommending is for strong client or user benefit – not for their own gains. Don’t push a CMS system because it’s “what you do”.

In our example above about advising on the impact of updating the version of jQuery, being able to spend additional time exploring issues that get uncovered is often something that clients are unwilling to do. Budgets are ring-fenced and cannot be extended. Time is critical. This thinking is however limited. When working on projects accept that unknowns will come up, things will go wrong, and directions will need to be changed. Having someone there to work out new solutions, and to advise on an ad-hoc basis will help no end. On the agency/consultant side, don’t be scared to state up front that you’d like a flexible budget for when things come up, and explain why. Helping the client to understand the journey ahead is as much a part of your responsibility as delivering the end-result.

Don’t play safe

“There are a million reasons why you shouldn’t do something and only ever one or two great reasons why you should”

Paul finishes on an excellent point, which is actually something that I try to live my life by. You can apply the above to all sorts – quitting a safe job to do something totally different that you love, choosing to give up the life/body/sleep/sanity you know and have a child, or to ditch your behemoth maze of legacy systems in order to create one that works for you.

As technologists we should be suggesting the crazy ideas as much as the safe ones. We often get so hung up on budgets, under-delivery and over-running timescales, and whilst these are incredibly important, if we only ever stick to this then amazing things won’t happen. Innovation is a term that gets thrown around a lot, but for it to truly occur there needs to be a hell of a lot of trust, a sprinkling of madness, and a willingness to explore and see what happens. If possible don’t just follow orders – try the renegade option and see what could come of it.

If you agree with any of the above (and I hope that you do) and would like to have a chat about working together, I will be available for new contracts from the end of March/April. I would love to help any new clients discuss potential web developments, or to work alongside agencies or individuals who want to ensure that technical thinking gets factored into projects from an early stage.

Header photo under Creative Commons by http://www.flickr.com/photos/newmundane/6379644393/