Archive for December, 2012

Most human endeavor ultimately comes down to a process of repetition and continuous refinement, based on some kind of feedback and improvement mechanism.

In previous and arguably simpler times, people would have just called this ‘practice’.

“Practice makes perfect”, “when at first you don’t succeed try try again” etc. is what we are taught from school. And it’s a pretty good mantra for drawing, playing tennis, cooking, driving a car, building houses, Installing kitchens and so on. But I say “most” because it starts to go awry when we apply it to large scale engineering projects. And arguably it often (or even always) goes awry for large scale bespoke activities generally – regardless of what they are.

This is because once we get into bigger and more complex things, the notion of repetition, practice and continuous refinement cannot apply. We can’t repeat the exact same thing again to get better at it, and anyway the pace of change means that what we’ve done previously isn’t necessarily relevant today.

Not too long ago I overhead someone repeating a phrase I have heard countless times over the years: “An IT project should be like MOT’ing (servicing) a car”. Well, what I have just said explains why this isn’t and can’t be the case.

From this we arrive at the theory that maybe the traditional “project” approach doesn’t really work for technology. We need a new approach of some sort.

If we take The Mythical Man Month (first published 1975 and stimulus for much work since) as the first solid documentation that “projects” don’t really work for technology, then we have had nearly 40 years of arguing and philosophising about it. The basis of this is why IT and technology projects aren’t like servicing cars.  It really is time to move on.

If you take away the notion of repetition, practice and continuous refinement, then the only other major technique we have available to us is knowledge management and education. Anyone that knows me, has worked with me or has read this Blog, will know that my view is that this is the route to successful outcomes. Not trying to re-invent the traditional “project” over and over. Not applying more and more command and more and more control.

A project will be successful if you have a knowledgeable team. Simple as that.

This is what the ‘agile’ books call “a good team”. What the project concept can’t do is make the team “good” to begin with. Personally, I think agile is a better way of running a project, but agile can only work if the team have a high level of knowledge. If that is the case they will deliver anyway. The techniques we use to organise things – be it waterfall, agile or whatever else, can only optimise a situation that is broadly already working.

I have to say though, that I am continually frustrated that the notion of the Business Analyst as champion of knowledge management and education, isn’t something I generally see many BAs being interested in. I’m not sure why this is; Admittedly it involves thinking somewhat differently, and perhaps the issue is that we are dealing with collective activities somewhat outside the fray and taken for granted. It involves volunteering information and sharing. Looking beyond the self and helping ensure people are as knowledgeable and ‘up to speed’ as possible.  Because I’ve spend a fair chunk of my career surrounded by people who aren’t, and struggle as a result - through no fault of their own.  I dread to think how much wasted time and money that equates to.

So given the rewards that can flow from all this I find this bizarre and more than a little annoying, but with the dawn of a new year comes new possibilities. I hope.

Happy new year!

There are various reports in the press that HMV are having poor pre-Christmas sales, and this perhaps means that my prediction of them not being with us for much longer will come true.

I for one will feel sad about this: I’ve spent a fair chunk of my life in various branches of HMV and a good proportion of my CD and DVD collection is from there. I still think the shared experience of a physical shop is important. Their demise is therefore significant.

It is fashionable nowadays to not be emotional about such things. One must write it off as an agnostic “one of those things”; others lapse into phrases and clichés such as “flawed business models” as if they have any idea of what is really going on.

Bizarrely, I found myself saying all of this at a work event recently where I ended up sitting next to someone who turned to be a board member of my company. After all, what better way to break the ice than to talk about the future of digital media?

It is worth reminding ourselves that the drift away from CD – a key element of HMV’s woes – is in no way similar to what caused people to adopt it in the first place. People switched to CD originally from other formats (vinyl, cassette) because of ease of use. Not, as many ‘experts’ had predicted, because of durability and sound quality. In any event, claims of durability and sound quality turned to be highly contentious and still are.

By contrast, people switched away from CD – generally to MP3 – because they realised they could download them for free. Once word got round that this was possible, why buy a CD when you can get it for nothing from some eastern European web site? So the motivation for MP3 in no way mirrored a technical choice or decision making process in the way that the past – Vinyl versus CD, VHS versus DVD, Blu-Ray versus HD-DVD or even more dramatically, analogue versus digital, did.

Obviously not all MP3 downloads are illegal, but I would still say that for people to claim MP3 has revolutionised music is rather like saying shoplifting has revolutionised high street fashion retail, or train fare evasion has made the country more mobile. The genie is now well and truly out of the bottle. And not necessarily entirely for the good.

Quite where that leaves people trying to make it all pay, and more serious still, for those creators trying to do something new whilst paying the bills and putting food on the table?

I haven’t the faintest idea.

But we were out of time. And coffee.

I have always objected to this phrase as it is generally used in a rather disparaging and pompous way. The message tends to be “old crap from a bygone age that we have to reluctantly tolerate until such time as we can get rid of it”. Some people don’t seem to realise that “Legacy” simply means “successful live application”. Therefore it represents the technology that is running the business.

In my experience people are far too quick to jump to the conclusion that they are costly or difficult to maintain. This opinion is often formed on hearsay and lack of knowledge (and, more alarmingly, an unwillingness to acquire that knowledge or approach people that have it).  I have to add that even if a legacy application is “difficult and costly to maintain” the reasons for this need examination.  And it shouldn’t mean that the whole underlying basis for the application’s existence is flawed.  But that is another subject entirely…

In my view, projects don’t go wrong because of ‘requirements’. Requirements are merely a convenient hook on which to hang any issues encountered on the project – whatever they may be.

Projects go wrong because of a lack of understanding of how the requirements actually fit into the global game. This in turn is simply down to a lack of knowledge. There is no need to philosophise further. If you have pre-existing systems and infrastructure – as almost all projects nowadays will have – then this problem will increase dramatically if that pre-existing landscape isn’t understood. And frequently it isn’t.

I once attended a post implementation review for a project that had encountered overruns and a host of other issues. Much time was spent recounting tales of woe about the requirements. Yet it was pretty obvious to me that it wasn’t really the requirements at fault at all. The knowledge deficit (which was not the team’s fault, I would add) meant that any piece of work – big or small, simple or complex, would have caused them a problem. Even leaving requirements out of it entirely and having a bug to fix would have been a major challenge.  The only ‘safe’ way out would have been not doing anything at all.

By contrast, more recently I was involved in a complex set of changes to one of our key systems. The requirement from the business area was little more than ‘make it work’. Yet this was implemented relatively smoothly as it turned out, because – more by luck frankly – we had a knowledgeable team. We were able to shape what needed to be done based on our knowledge and come up with a set of actions that could be played back to the business for comment. In effect we were writing the requirements for them. They would then approve, reject or modify.

The whole situation could well have been very different and potentially disastrous with different people involved.

None of the above is actually to do with the ‘requirements’ per se in my view. Whilst some would argue that we should not even have gone ahead without something more substantial to start with, you also have to recognise that not everyone is good at articulating requirements. They are not always able to get their objective across, even if buried within it is the kernel of a good idea (which in my experience there generally is).  We in IT have to be alive to this. We should be prepared to put ourselves in the customers position and if necessary help create the requirements for them. The ‘alternative’ (if that’s what it is) is to do nothing and wait. This is futile and does untold damage to the reputation of our industry.  We should be in there proactively collaborating, assisting and doing whatever we can to move things forward swiftly. Not pushing people away and waiting.

Difficulty in creating requirements and expecting IT to help create them, doesn’t in any way mean the customer is disinterested or lacking in knowledge and commitment. In the example above they were anything but. They simply needed IT need to take a creative lead.  Once that had been established, they were more confident and more involved.

Neither does it mean there is some sinister rule violation taking place in IT or a flaw in our processes. I personally have no problem with IT getting involved like this and it is central to what IT should be doing in my opinion.  But it is possible only if you have a knowledgeable team.

How to get there is the big question. Sadly this is a much larger challenge than it perhaps should be.