Change Steps
It's not the journey, it's the destination, stupid
By Julian Browne on May 16, 2008. Filed Under business, delivery
There are many things to love the Discovery Channel for: a sense of having expanded your knowledge with a broad but shallow series of details about Sharks, Egyptian Mummies, the Nazis and the bewildering array of household items you can make with injection moulded plastic for one. But I think most of all I love those shows where some would-be professor type, who more often than not is bearded and English, goes in search of one of the great quested-for items of deepest history - the Ark of the Covenant, the Holy Grail, Atlantis, or the resting place of Noah's Ark.
We travel to various distant lands, each linked by some clumsy and illogical segue, until we find ourselves back where we started with Mr Beardy looking wistfully into middle distance as the narrator says "Perhaps [insert quested for object here] just isn't meant to be found. Perhaps [object] is really just a metaphor for life's quest for meaning. Perhaps it's not the destination that's important, but the journey itself."
What a crock. If I went looking for the Holy Grail and didn't find it then I would consider my project a failure. At the very least I could have spent my time doing something more productive. If I want to go on a journey I would remove all ambiguity and call my project 'Going on a Journey'. Nothing wrong with going on a journey. Journeys are great. What isn't great is setting an objective to do something, failing, and then pretending that what you did anyway was in fact the objective all along.
That's called a big. fat. lie.
Whilst failing is clearly a state of affairs to be avoided if you I can, I do think that if you find yourself in that uncomfortable position it is always better to admit it, fix it, and move on than it is to lie about it. Lying just means it will happen again.
Sometime ago I wrote a piece about change programs. It was mostly making the case for not having one in the first place because, in my humblest of views, if you want to change you should just change, not bulk up your actions into the form of a programme. I followed that article up later with a satirical look at why consultants make change programs fail and promised to come back with a final piece (because frankly I am fed up with talking about them, so you must be fed up with reading about them too) on what you could do if you absolutely insist on having a fiesta of change.
Because of the nature of change, I can't say what you in particular should change, but that's fine because you probably already know what stops you working to your maximum potential. Consultants will happily tell you what to change, but only because they stole the list from the last place they messed up or if it's something you can't measure later.
What follows then is a general array of suggestions based on the sorts of things that everyone could do better.
Think Agile
Change programs are best when they do just that - make change. Not talk about change, or draw pictures of what the benefits of change are. If you are in a change program then someone somewhere thought change was a good idea so there's no need to waste a single minute on saying why change is needed or why change is good. Just make change.
A good way to make change effective is to adopt a classic agile approach to it and by that I mean draw up a scrum-like product backlog containing all the things that need changing (we'll talk more about these next), then set yourself a short period (a sprint) to make some change and assign to it the highest priority changes you can make in that period. Then make those changes and stop.
Wait a short while to see how those changes are working and add the ones that don't work back into the master pile (naturally you are aiming for changes to work so in no way should changes be rushed: plenty of time to think through the change, communicate it and bed it in is a must).
Then repeat the cycle. Scrum sprints are usually four weeks and fixed in duration. This is good for generating momentum in software development but probably a bit rigid for a change program. I think there is a case to make the sprints longer and of differing durations depending on what is being done. Some change may necessarily be organisational and it would be a pretty heartless organisation that attempted a large structural change without giving time for people to understand and think about their options. But sprints should not be any longer than they absolutely need to be. The name of the game is only to make the changes - in true agile fashion all that talking and designing and work-shopping is for you to deliver, not what the customer values.
Forget Architecture
If you can possibly avoid it, do not try and create your strategic architecture on the back of a change program. As I have said before architecture isn't very real - it's an ideal to measure your tactical operations against. That's not to diminish its importance in any way, it's a critical feature of making IT effective, but at the end of the day it's not change. A better form of 'Architecture Change' would be giving teeth to the governance process, adding resources to the team, or starting a technology library. It should not be what would otherwise be business-as-usual. As Scott Ambler said in Agile Architecture - Strategies for Scaling Agile Development
Agile architects have the courage to focus on solving today's problem today and trusting that they can solve tomorrow's problem tomorrow (Beck, 2000), and the humility to recognize that they cannot accurately predict the future and therefore choose not to overbuild their architectures.
The issue with doing 'architecture' in a change program is that you are not reacting to business projects and have all the free time you need to overbuild your architecture to the point where everybody will ignore it.
Hardware
It always takes longer to procure hardware than you'd like. So here's a change - set someone the task of buying hardware in advance and storing it. Not lots of hardware, and certainly nothing exotic, but maintaining a store of a few servers won't cost much, and the time it will save projects will more than pay you back.
Environments
Developing, or worse, testing, against environments that don't look like production? Releasing code that comprises 'some executables and a need to speak to Dave who wrote it' which means your ops guys can't easily configure it properly? That smells like risk, far too much time to deploy to live, and no way to easily recreate for testing later.
Buy a tool to manage software configurations and start using it. Add a Package Test Gate to the operational acceptance process so that only software that is re-installable can go into live.
Change Control
I am still shocked at the number of organisations that think a file system is also a good code repository, or that knowing what is checked out means asking Dave who's got what today. Buy a code management tool and force all teams to use it. Make it a part of project compliance for basic things like release notes, readmes, installation docs, etc to be present in the repository.
Continuous Integration
And as you check stuff in it should be tested automatically against the build, not at some later point when many things have changed and you don't know where you are. I have heard well-made arguments that it can be a bit of a hassle to set CI up, and I heartily agree that it can be painful the first time. But it's always worth it on anything but the most trivial developments.
Operational Blitz
Get a list of what systems go wrong, how they go wrong and the business impact they have (if you don't have that list make change number 1 creating a weekly list and emailing it around, then come back to this change later). Then create a mini project to make direct changes on a week by week basis - add hardware, add load balancing, upgrade memory, add disk, apply patches, etc and keep going until the top issues are gone. Not only is this proper change (however tactical it will feel) it will give the operational staff time to contribute their ideas to the other changes required.
Process
It's tempting and rather seductive to spend hours waxing lyrical about the process that could be in an organisation. It's also worth remembering that whatever you think the process is, it's probably slightly different, and even the people who do it may have contradictory views.
In the days before IT if you wanted to change a process you just told Dave to operate in a different way. Nowadays a software project stands between you and making that change. Make the software project quicker and the change will follow, you don't really need to spend hours on designing process. No process stands still for long anyway, so rather than design process, make it easy to change little bits of it.
That way you can react when you need and change as you go.
Documentation
Now here's a radical idea. Most change programs end up defining a whole suite of new documentation: new categories of document, new standards, new fonts, layouts, sections and subsections, owners, sign-offs, the list is endless. But what about removing and reducing existing documents? What about a short exercise in seeing who reads what and chopping out anything that isn't strictly necessary?
Anything that's written once and never updated (quite a few aspects of project definition for example) should be online, not copy/pasted into five more documents to make them feel more serious.
And.. this is a pet peeve of mine.. architecture documents should contain only architecture and nothing else - not the business case, the story of how the company started, just the designs and their relevant justifications in the form of a traceable cross-reference to the requirements they are meeting.
People
You've probably heard of the mantra "people, process and technology". It's used as a kind of mnemonic to cover all the aspects to be considered when making a change. Well the ordering of those words is important.
To make change that will last longer than it takes for you to fetch another coffee you have to start with the people (listen to the problems, tell them what they need to do, train them, etc) then the process (which they will generally sort out for themselves if you've done the first bit right) and only at the end do you add the technology.
Because if people know what to do and they have a process for doing it, the technology acts as an optimiser and not as the be all and end all. I think I've seen more changes fail because these have been addressed in the wrong order than anything else.
Training
This is related to the people aspect above, but not quite so tactical. If you want to change, it means you want to work in a different way. To be different you'll almost certainly have to learn something and to avoid having another change program next year (remember there are only two kinds of people in the world: those who have never been on a change program and those who never want to be on one again..) you'll need to keep learning.
So make a Training Plan. Plot out how you will spend all the budget you can muster on training. Publicise it. Training is good because, even if you don't actually use the knowledge immediately, it makes people think about something other than fighting today's fire and cannot be discounted as a kind of reward in itself (something I profess never to have understood, I hate training courses, but there you go..).
So, to summarise this topic, before I move on to something more interesting, what I am really saying is that all organisations think they are worse at IT than others. In reality it's a bit rubbish everywhere, with just different types of awful to contend with.
The good news is that all of it is fixable, but fixing it should just be part of doing it, not separated into a form where you absolve the doers from the responsibility of owning the problem - more often than not all the doers want is some support from management to make the fixes.
There's no reason to think a consultant who doesn't know you can help you out (if they believe they know the answers then ask them to describe the last time they delivered software in an end-user organisation like yours and actually solved your issues).
Sometimes though you have to be seen to be making change in a very public way. If that's your situation then just take the list-and-fix approach: list what causes you pain, fix some things and make another list, repeat until you run out of money or time.
That's it. It's not rocket science