Making IT Happen

This is a follow up to a recent entry about measuring IT value. As that entry said, most IT teams don't put much effort into measuring actual value, but that's not necessarily a bad thing as some of the attempts I have seen over the years are pretty bogus in any case. Your boss, and other people in the organisation, will always have their own instinctive valu-o-meter, and no post-implementation report is ever going to swing it much.

What IT teams are great at is predicting value, and getting other people to agree with these predictions. Of course we have a technical term for these predictions - business cases. Every year we pursuade our colleagues to sign off billions of pounds worth of cases - a great and unheralded strength of the IT profession.

I've read lot's of theory over the years. My experience is that, in practice, the cases that get approved tend to be one of the following types:

Well sponsored cases. Remember the mantra "it's not an IT project it's a business project." This is of course completely true, and getting an influential person elsewhere in the organisation to drive the case because they think they will benefit from it is a good approach. The problem with this approach is that it doesn't necessarily identify the best cases, just the most popular ones. There is a difference.

Cases that prey on fear. The value proposition is usually compliance based - i.e. approve this and you won't go to prison, get fined, ruin our reputation etc

Real value adding cases. The classic 'case' - based on real observable cash flows - spend this now, and increase that income / save that cost in the future. FD's are always very suspicious of these - they manipulate numbers for a living, and know all the tricks. Grind them down and they will eventually start to feel guilty about not signing them. Don't go too far or you will seem like a stalker.

Transformational cases. Best approach here is to hook into something your colleagues read about in the paper - Web 2.0 is a current favourite - and then subtly imply in the case that anyone who doesn't approve it is a progress halting luddite dragging the organisation backwards into the stone-age.

'Trust me' cases. I put one of these through every now and again. If you have an instinctive judgement that something is right, you shouldn't let the fact you can't articulate it put you off. Creativity and experimentation have a place.

One of the projects I'm planning to follow in the blog is our new website. There are a number of drivers for this project - the main ones are that our business is evolving, and that the current site is looking ever more 2004, and doesn't provide things that we need.

If you have any comments on the current site I'd be pleased to hear them - www.telereal.com . Many thanks.

Our new website project has thrown us into a fundamental question about Telereal - what do we actually do? A lot of people have been asked and a lot of answers received - but at the end of the day this has needed to be boiled down into some pithy text, which has caused a lot of debate. Much headscratching has revealed we are an investment and services company. Seems obvious looking back.

Our new website went live recently. It is very simple, and we're all very happy with it.

However, we almost ended up with a website that no-one really liked. Main lesson learned? Don't design by committee.

Design is one of those professional areas where it always strikes me that there are low barriers to entry - everyone has an opinion. People who wouldn't presume to tell a brain surgeon how to do her job will expound at length on their ideas on web design.

Hannah, our excellent web designer, was pulling her hair out with contradictory guidance from everyone involved. Hannah came up with an initial version of the website that responded to everyone's every design input, and it met every requirement. When I discussed it with Hannah I found it had a subtle flaw - she didn't like it.

An hour of scribbling later and we'd come up with a functional structure we liked, and a week later Hannah produced a prototype of the new site which everyone thought was a knockout. I then spent a day editing all the text into digestable chunks (someone had to do it) and you can see the results.

We're planning to roll out a new fleet of laptops and desktops for everyone in the company. One of the key decisions is whether we deploy Office 2003 or Office 2007. (In fact XP / Vista was also a key decision but we quickly decided to stay on XP.)

I canvassed a wide group of other CIO contacts about what they had done or were planning to do. Of 8 responses, 3 were 'already done it', 1 was 'soon', and 4 were 'not this year'.

For the 3 that had done, main lessons were:
1 - training is key - train at the point of deployment, set people's own PC's up before the trainer leaves
2 - wait 6-12 months - still too glitchy (!!!)
3 - use the quick access toolbar in preference to the ribbon.

For the 'soon', interesting feature of approach was the plan to just do Outlook 2007, and to stick on 2003 version of Word, Excel etc

Main factors for the 'not this year' group were:
1 - trialled Vista - slow
2 - no busines case, major benefits
3 - no glory in it for IT (which sounds cynical but I don't think it is - put another way, glory somes from happy consumers)
4 - licencing

Main reason we are looking at it is integration with Sharepoint (we are heavy users of Sharepoint 2007) and general XML integration capabilities. Finally, here's the official MS top 10 benefits of Word 2007 - a lot of which will apply to any of the family - http://office.microsoft.com/en-us/word/HA101650321033.aspx

Have you ever sat in one of those sales presentation which has gone so completely off the rails that you have to step in, stop the thing and put it back on the tracks? This happened last week when we had Microsoft in (at short notice) showing off PerformancePoint. We'd allocated 60 mins for product intro and demo so that we could spend 2 hours talking about what we wanted. Well the introductory presentation took 45 mins and we were almost another hour (and maybe 25%) into the demo when I pulled the plug.

After the meeting some of my colleagues were more or less ready to ditch the product there and then.

Fair play to Microsoft though, they took it on the chin, spent the rest of the week and the weekend working with one of their partners - IM Group - and came in on Monday with a presentation that was spot on. They had a fully configured prototype that answered many of our questions and demonstrated that they had listened and learned. They are now in with a good chance of getting the work. Provided the numbers are right, of course....

I have been reviewing two projects lately - one that is going well and one that is going badly, and I was reminded of my rule of 20's for successful 'IT' projects - a succesful project delivers 80% of the requirements, is no more than 20% late and no more than 20% over budget.

Of the various aphorisms I have wheeled out over the years at Executive Committee this is the only one that has been repeated back to me by other directors - and in a positive way. My conclusion - close isn't always good enough, but it is sometimes, and it's always better than a complete miss.