Tag Archives: Business Analysis

No kicking, no biting, no gouging

I had such fun yesterday.

I spent it on a training course which included elements of role-play. We were there to improve our facilitation skills and when I explained this to the one I explain these things to he said “oh, chairing meetings”. Mmmm. Not quite. Meetings are for sharing information among people who meet regularly. Workshops – in theory at least – produce “jointly-owned” “outputs” or “work-products”, the hole being greater than some of the parts an’ all that. Facilitation is more like being a referee – you aren’t part of the match but you make sure the match happens and that there is no kicking, no biting, no gouging. You also get to record the score. Not the best analogy I’ve ever written, but I like it for the suppressed violence it implies.

There were seven of us, and we took it in turns to facilitate various mini-workshops. One of my team-mates was there, and he was briefed to be incredibly talkative but know nothing at all. That was fun to facilitate. Of course it was fun. Yes.

Then I got to be the stroppy one, twice. First time round I had to make sure that my (rather irrelevant) point got made, talking over people if necessary. That was a very therapeutic experience. Second time round I didn’t care what happened so long as no-one gave me any more work to do. Being completely irresponsible and giving the nod to stuff that was clearly crap was pretty therapeutic as well.

I wish there were more days that I could go to work and be paid to behave really really badly.

I wish to speakā€¦

MTAS – The silent “SH” in Department of Health IT

Five out of eight reasons why IT projects fail come down to the the project team failing to understand how the system will be used or what it it should do – MTAS ran depressingly true to form.

I found an MTAS Milestones document on the web some time ago and didn’t know what to make of it. I still don’t. However, MTAS is now officially dead, so I’m going to critique it here before it disappears forever.

The document is a one-page timescale for the MTAS IT Project including the engagement of sub-contractors. There is much here that I am not qualified to comment on, but even so there are a few points that I find interesting.

One month (Oct 05) to scope and set up the project

Fairy nuff. There’s not enough information here to assess whether this is enough time or not.

One month (Nov 05) to initiate the project, set up project board and agree project brief

As above.

One month (Dec 05) to “agree requirements” and that month is December, so in effect you have only two weeks.

This is what has set my alarm bells ringing like klaxons. The Standish Group did a survey, admittedly in 1995, which discovered that five of the eight major reasons for IT project failure are requirements based. In other words if you don’t know what your users need, you won’t be able to build it. I could get rather tedious on this subject.

Let’s just say that I would allocate between 6 and 12 weeks for requirements gathering assuming that I had full access to representatives of those who might use the system. The first thing would be the conceptual stuff including the security of the system, (hah!), the amount and nature of the data, how would it be searched and sorted, how many users in total, how many users at once, and stuff like that. The next thing would be the step-by-step process, and the final stage would be a screen-by-screen storyboard.

You can see that this is not something that can be done in 2 weeks, and that you would need to speak to a very wide range of people including security specialists and sample end users, (sample Junior Doctors, sample Consultants, sample final year students).

This sounds to me like a system designed entirely in theory, with no reality checks or sanity checks from real people.

Four months (Jan-Apr 06) for the procurement cycle.

Four months to choose a supplier, and two weeks to say what they will be delivering? Yes, that is as insane as it sounds.

Five months to deliver (April-Sept 06).

This is the infamous “Miracle occurs here” step. There is nothing about taking the list of requirements and turning them into a design, nothing about building the system, nothing about testing it.

Good work, but I think we need a little more detail right here

The DoH has kept for itself the luxury of time – a whole third of the time available has been allocated to picking a supplier. The poor supplier has had nothing like that wriggle room: they have had to design, build and test the system in less than half of the total time available.

Now, picking the right supplier is crucial, no doubt about it. But no matter how beautifully built a car is, no matter how gleaming the paintwork, how smooth the leather, how fast it goes from 0-60, it’s no bloody use if what you want is a tractor.

As I said, I am hesitant to rip this document to shreds; I have no idea whether it is a final copy or a draft, I have no idea what other documents supported or contradicted it, I’m not even an IT Project Manager. But I am both competent and qualified to comment on the idea of allocating only two weeks for requirements gathering.

If the rest of the project was as mad as that is, then it is a wonder the bloody thing lasted as long as it did.