And the award goes to .... The Hurt Locker

OK I know the Oscars are long finished but I just saw 'The Hurt Locker' at the weekend and I've wanted to tie it into a post for ages.

My two cents worth - I desperately wanted 'The Hurt Locker' to be a worthy winner of six oscars, especially as it won out over 'Avatar'. However, I was disappointed. Whilst it is a good film, it certainly isn't a great one. Best Film and Best Director - I don't think so. But this just reaffirms what I've always believed about luck and timing playing their part in awards ceremonies.

At my last ever Oracle Consulting conference I was led to believe by my Practice Manager that the project team I had lead was up for an Outstanding Performance Award. We had just finished a difficult 4 month project that was a great success. The client was happy and referenceable, the systems integrator couldn't praise us highly enough and was lining us up for more work. And we had achieved all of this with the minimum of fuss. OK, we'd worked a few weekends and late nights but nothing out of the ordinary.

So there I sat at the dinner at the final night of the conference fully expecting my team to be one of those to pick up an award. You guessed it though - we didn't even get a mention. I have to admit I was desperately pee'd off. The project that claimed the prize we'd been promised, by contrast, had been classic car crash IT. Badly managed, poor quality, late, over budget, all hands to the pumps, client threats, the whole lot. Some hours later my Practice Manager came skulking over with some lame explanation that the award was given as recognition for all the 'above and beyond' efforts put in by the other project team.

So my advice to you. If you want to win awards and get recognition go ahead and fcuk up your project and then flog your staff for 18 hours a day to correct your mistakes. Don't, whatever you do, just run a successful project without drama. I left Oracle a few months after that and the irony was that I got a posthumous award for another penultimate project I'd been on. Too little, too late.

Monkey See Monkey Do

I remember seeing a Rodney Dangerfield film in the 1990's which was pretty much forgettable except for one scene. The scene was set in a typical university ampitheatre with a lecturer and say 200 students. Over time as the weeks passed many of the students opted to skip the lectures but record them on a tape recorders, until finally even the lecturer himself failed to show and simply played an audio recording of the lecture to the non existant students.

So what's the connection with IT. I worked with some Oracle PreSales in the 1990's. They were always a pretty busy bunch responding to RFI/RFP's and doing demos. At the time Oracle has a graduate recruitment program and one of the grads I knew was on secondment to PreSales.

Chatting one day I asked what she was doing and she said that she was responding to an Oracle Financials RFP. I was impressed, actually more baffled, that given their lack of experience that they were entrusted with this work that would normally be entrusted to a senior Financials PreSales resource. Digging a bit deeper the answer became obvious. I found out that the grad was pretty much cutting and pasting answers from previous RFP responses into the new one.

How could they do this? Easily, really, becuase the RFP's at the time we being generated by grads sitting in the Big Six consultancies and contained a random subset of the stock RFP Financials questions they had.

The difference is that our grads were working for free (chasing new business). Somehow I don't think that the client would be paying the Big Six consultancy grad rates for their RFP work.

The Big Six

I have previously worked as a Consultant and in both cases they have been for software houses. I always felt that if you were going to pimp out yourself then you might aswell have the inside track and worked for the company that wrote the software. Despite the supposed prestige associated with them I was never ever tempted to work for any of the then so called 'Big Six' (now known as the Final Four) consulting firms as I don't believe that our personalities would have been compatable.

Why? If you had witnessed some of the things I've seen the Big Six get away with you'd understand. Some classics include:

- A 'Big Six' female PM lodging a sexual misconduct complaint against a male client PM who sought to challenge the success of a major project. I can't say whether the complaint had any grounds but it was clear that it would never have seen the light of day had the client PM kept his mouth shut.
- A Big Six firm getting a project I was working on shutdown because we were close to delivering more in 3 months than they had in two years and promising to finish out Project within a month. This one ended up in litigation I'm pleased to say.
- Rigging RFI scoring to pick the most expensive packages to implement rather than those that best fit the client requirements.
- Attending onsite training courses with the client staff and then advising the client on configuration against the advice of the consultant trainers.
- An Big Six 'oracle development practice' that was running around Sydney in the 90's developing applications. Only was that they'd never discovered what an Index was!
- Big Six consultants sitting onsite doing a online SQL training course whilst billing a grand a day.

I'm sure there are lot smore examples out there and I'm not saying that the consultancies I worked for were whiter than white but there's a long way between them and what I've seen of the Big Six.

Madness in the Method

In the UK there was a famous 80's TV commercial for British Telecom starring Maureen Lipman (http://centuryads.blogspot.com/2007/01/you-got-ology-1987-launch-of-bt-beattie.html). She plays a stereotypical Jewish grandmother who upon discovery that her gransdon has flunked all his exams except Pottery and Sociology replies "He gets an ology and he says he's failed... you get an ology you're a scientist." Maybe, just maybe, Andrew (the grandson) didn't become a scientist but got another ology ... a methodology instead.

This would tie in with how many methodologies are used (and abused?) in today's IT. From what I seen methodologies are used as a crutch by below standard IT consulting organisations/individuals to present a veneer of professional competency and mask the lack of any real ability.

Don't get me wrong, there's nothing inherently wrong with a good methodology as far as they go, but don't for one minute believe that an ology will somehow replace common sense, experience and good judgement.

Master Data Blues

Master Data Management is currently one of the hot topics doing the rounds of Enterprise IT. For those unaware of the concept MDM is basically the storing, either physically or virtually, of all corporate reference data in a single MDM repository. Consultancies love to sell MDM solutions for two reasons:

1) They are quite easy to justify
2) MDM technology, whilst expensive, is available

So in theory we should all be swimming in MDM's by now. I don't know about you but I'm not. In fact a friend of mine became the first and only person I know to land a successful MDM Project.

So if we agree that it's the correct thing to do, and that the technology is available then why don't we see MDM's all around.

Simple really - the business side of MDM is very, very hard so before you begin you'd best make sure that the business understand what they are biting off.

Of course, if we'd kept a tight rein on our corporate IT systems in the first place then we wouldn't need MDM would we!

The Price of Everything, The Value of Nothing

Back in the days when I wore a proferssional services hat the T&M (time and materials) contract was prevalent. T&M was good for a consultancy as it loaded most of the the risk on the client. I also think it did a good job of focussing the client minds as the last thing they wanted was expensive consultants sitting idle whilst they provaracated over making a decision.

Over time clients more often moved to a Fixed Price model for their consulting engagements which helped control their costs. It also shifted the risk to the consulting firm and for that I know that my consultancy would add a margin of 30% to offset that risk. What the clients failed to understand in the shift from T&M to Fixed Price was how that would change the mindset of the consultancies that they engaged.

Back in the T&M world we really focussed on doing things right. We knew we were expensive and we knew we had deadlinesto meet. I can honestly say that when I worked on site I believe I acted in the clients best interests. The problem with Fixed Price is that the consultancy focusses on doing as little as possible to cover its contractual obligations.

Hence the client may think they're getting a better deal by fixing the price - but you know what - I'm pretty sure they haven't figured out how to measure whether they're getting good value or not.

7x24

If you've been around in IT for a while you've probably come across the term 7x24 meaning 100% system uptime.

I was once employed in London by a Investment Bank as a DBA where we were developing a mission critical global options trading system. Luckily the data volumes were small, the servers and environments stable and I'd had plenty of time to work through a reliable hot standby failover solution with an excellent UNIX Sysadm. All was good in my world.

Then during the preparations for go-live the topic of Availability arose. The Project Manager threw into the mix that we had to guarantee 7x24 availability.

My response was that we could aim for 100% uptime excluding planned outages but that we couldn't guarantee it. This resulted in a bit of table-thumping, as was quite often in IT projects in an Investment Bank.

Suffice it to say that when I explained the costs and complexities involved in guaranteeing high that availability from a solutions side and the human side it the PM became a bit more reasonable, especially when I threw in the fact that neither Scott McNealy nor Larry Ellison could guarantee 100% uptime on the configuration of Solaris and Oracle that the solution was constructed.

So the lesson is that before you start discussing High Availability the metric that needs to be understood is the actual cost, either in dollars or reputation, to your business of the mission critical app being unavailable. Until you have that there's really no point in discussing the HA requirements of the system. The funny thing is that when I was consulting I designed lots of Technical Architectures and never once could I get that fact out of the client.

Six Sigma

A couple of years ago during an RFI an offshore software vendor presented indicated that their software labs were 'six sigma' certified. Essentially this was offered as a guarantee of quality. They won the business essentially becuase they were the incumbent and they were cheap. So I ask you - how can a six sigma company submit software that has allegedy been system tested that doesn't even compile. Funnily enough the vendor bid for some more business recently and dragged out the same six sigma powerpoint slide. Some companies have no shame.

The Enemy Within

I have in my time had the displeasure to work in a couple of companies who have outsourced parts of their IT organisation (whether it be support, development). Whatever the relative merits of outsourcing, IMO, outsouring brings very few real benefits in the medium to long term. Obviously there is a percieved short term value proposition which leads companies down the outsourcing path in the first place (i.e. by reducing headcount) otherwise companies wouldn't do it.

As a result many IT people fear outsourcing, especially when cheaper offshoring is mixed into the equation. I used to be in this camp and a few years ago I believed that the best personal survival strategy against this trend was to move up the IT ladder into the 'talking' and 'thinking' space and distance myself from the 'doing' bit. I now don't have these worries.

Why? Well I recently had the opportunity to look at a large company that had outsourced almost its entire IT operation 5 years ago. The only elements not outsourced were the IT executive ('the talkers') and an enterprise architecture function ('the thinkers').

Their problem was that they had stopped delivering anything meaningful to the business. Why? Well there are a number of reasons but the one I wanted to focus on here is my belief that the outsourcer ('the doers') had effectively morphed into a fifth column working inside the IT shop. The resisted change at every opportunity and driven by the nature of the SLA's in place had redefined their role 'keeping the lights on'.

So did the business take this lying down. Of course not. It simply can't afford to. What it does is it effectively insources IT, usually covertly. Five years down the line they had more IT architects employed directly by the business than were left in central IT.

The BodyShop suffle

Early in my career I remember my first ever experience in dealing with external IT consultant. My bosses boss paid a flat twelve hundred quid daily rate (a lot in 1992) for they guy to fly up to our office sit in meetings for 6 hours and provide some quidance to a specific performance issue that we were having with their software at a client site. The said consultant was experienced, eloquent, convincing and as it turned out dead wrong in his analysis and diagnosis of the problem. Of course our advice was ignored cos it didn't cost 1200 smackers.

So a number of years later when I joined a large professional services company I asked myself whether I thought I was good enough, would clients really pay exhorbitent rates for my advice and counsel. As it turns out the answer was yes and I had a good and successful stint. But at least I asked myself the question.

Over the last 10 years I've dealt with many consultants. I don't think many ask that question anymore.