Alignment of goals, to create synergy going forward.
Like any good pragmatic IT guy, I have an aversion to buzzwords. One of the great ones (phrases) is “aligning IT goals with goals of the business”. I have just had an “aha” moment on this one though, and am now searching for a way to push “alignment of IT goals” without triggering off a buzzword bingo bonanza in our next discussion.
The goals of an IT department and in particular any software development effort are pretty much common across the board aren’t they? I’m yet to hear of a system that didn’t need to be robust, scalable, maintainable, secure etc. Maybe there are varying degrees for each aspect but pretty much, the goals of the development effort always boil down to this, as well as, naturally, meeting the needs of the user – adding value etc.
I am however an advocate of letting the business drive IT, and “aligning” the IT goals with the goals of the business. As mentioned, I’ll try not to use buzzwords though – so I call this, letting the guys tell us what they want – novel!
However, I would propose that alignment of goals has nothing to do with setting of goals – IT goals are pretty much always the same. The key to this is in understanding what the business goals are, then how and why these goals translate to the IT goals.
Every member of an IT team must understand what business, the business is in, and therefore why, security, robustness, scalability, maintainability etc are important goals for them, in order to deliver the required system to their users.
A little too abstract? Here’s an example. I am an IT manager for a finance company. Every system we build must be robust. No kidding! Every system we produce must be secure – there is a large (very large) emphasis on security in this industry – no kidding! As this company is growing, the systems must be scalable! Really, who ever heard of a company that doesn’t think they are growing! All our systems must be supremely maintainable and we must build very cohesive, re-usable software components because the users are prone to changing their minds – imagine that! So we end up with the same old objectives here don’t we – maintainability, usability, quality, scalability, blah blah blah. This all sounds just like when I built systems for home builders, and one for a chain of caravan parks and so on.
I spend a good deal of time with our users. I love to learn about their world. In doing so, and listening to them, I have gathered an appreciation for the issues they face every day. And guess what, there requirements do change very regularly. Business does move fast. It’s all true. In gathering that understanding, I actually, unwittingly aligned their goals to ours. I didn’t change our goals, I simply understand, in my current set of circumstances, why those same old usual suspects – the “ilities”, are very relevant in this situation. I have an inbuilt appreciation for why our systems need to have all these characteristics.
It wasn’t until I tried to explain to one of the developers the advantages we were getting by breaking up a new system we were beginning to build, into very small re-usable components, and in doing so creating a bit more work upfront, that this all dawned on me. I’ve worked in teams that haven’t pursued these goals with much vigor at all, and I’ve felt the pain of the result. At times a very different type of user base, always a very similar feeling of pain.
So I think one of the keys to effective software development efforts is not in setting the goals – they pretty much set themselves, it’s making sure each and every team member appreciates why these goals are important in the context of their business environment - to their users. What do you know? That would be aligning IT goals with the business. Viola!

Stone Soup and Boiled Frogs

If you've read the book "The Pragmatic Programmer" - a highly recommended read for developers and technical managers alike - although I think you'll get more out of this if you've experienced non-pragmatic projects first :-( - you'll no doubt remember the Stone Soup and the Boiled Frog "fables".
The are explained beautifully here so I won't bother to redo this. But suffice to say, do yourself three favours, check out the Stone Soup and Boiled Frogs story, grab a copy of the Pragmatic Programmer and then, try to apply the principles of Stone Soup and Boild Frogs at least once in the next 6 months.

I love it when the system works!

I am often spouting on about the virtues of documenting requirements and I am forever thrusting these documents under the noses of the would be users. Sometimes these users don't even want to read documents - they just want their system builts.

Needless to say, if they don't tell you what they want, how can you build it.

I had another very vindicating (in my mind at least) moment yesterday when a couple of users, read some user stories that described how I intended to implement some of the requests I'd received over the past weeks. We have an interesting setup where our customers, are using our systems to manager their customers. Some questions arose over how the user login facility was going to work, and who had the authority and responsibility for resetting user password. (This is a web based system with some sensative data so this was a real issue). The solution I had proposed was fine, but due to a misunderstanding of some of the finer points of the business model , wouldn't have worked effectively in the field. So after a quick read of this user story, a 5 - 10 minute discussion with our "head of risk" and another white board session with our lead developer, the problem is solved - before it even arose.

Given some very pressing deadlines for getting this live and some new customers of ours that will be using this system, I can't imagine what this simple process has just saved us.
Certainly plenty of costly rework once the flaw was discovered, maybe a lost customer, or maybe worse, maybe a security breach or threat which in our industry, would have caused immeasruable damage.

So, document requirements, no matter what. Push them in the face of your users (and other stakeholders for that matter) and make sure everyone is clear on how things are going.

Sometimes it can be tempting to think you've understood all the requirements, and to "disappear" for a while to build a system that in your mind everyone will love. You could then unveil it, to great fanfare, down the track and recieve all the kudos. Not so! At such a great unveiling, even the smallest misunderstanding will knock all the wind from your sails. Things will fall very flat. If it is kudos you are after, and in IT (and particularly consulting it perhaps shouldn't be anyway) you'll get more by consistently delivering results, with "no surprises".