Tag Archives: Project Management

Knee deep in chicken-shit

Mr RedHere’s one I didn’t publish at the time for fairly obvious reasons.  I’ve no recollection now, five years later, whether whatever it was did pan out as I predicted, partly because my memories of 2008 mainly comprise the banking crisis.  I am making this post public in 2013, but backdating it to its original date in March 2008.

Schadenfreude, or taking pleasure in others’ pain, isn’t pretty, but by god it can feel good.

It was inappropriate of me to snigger at the end of last week when the system that went live last month fell over. It was wrong of me to be amused that the patronising assurances we’d been fed for months that it could never happen here were embarrassingly and publicly falsified. It was nasty of me to find it funny when the centrifugal force of the spin doctoring failed to deliver on the promises that any problems would be treated as a Type 1 incident.

Oh dearie me, dearie me, dearie me. It was wrongest of all for me not to give a flying f*** if the system as a whole ends up pulled as a result of going belly up last week.

You see, I can be a judgemental and vindictive cow, and I find professional sloppiness unnecessary and disgusting. I have spent months feeling uncomfortable, watching corners being cut, political games being played, a lack of progress being spun into news of progress and a sense of “them” and “us” being created.  I also have a strong sense of cause and effect. I believe in consequences. So it was grimly satisfying to know that the clucking and squawking last week was the sound of a whole flock of headless chickens coming home to roost.

We’ll be knee deep in chicken-shit next week, but by god it’s going to be worth it.

Mr Red and Mr Blue and the Other Boot

Mr RedI’ve already blogged about the fact that I feel distinctly uneasy working without a Plan B.

Management texts define a Project as a complex one-off activity and a Process as a repeatable one. I have put it to Mr Red, who’s my boss, that no-one chez nous has previously done the work we’re are doing, that there are lots of places where it can go wrong and that therefore it qualifies as a Project. I won’t bore you with the scope of the thing, but I do tend to win “my roll-out is bigger than your roll-out” discussions with former colleagues at the Geek Reunion Ball.

Mr BlueAnyway, it isn’t being managed as a Project and we don’t have any contingency plans if things go wrong except “work out what to do at the time”. We are a bloody minded bunch so it’s an approach that will work, but it takes so much effort to make it up as I go along. I’d much rather implement a plan I made earlier. Maybe I just watched too much Blue Peter as a child.

I have been predicting doom and gloom like the dour Scottish one from Dad’s Army, and reminding my team that people always over-promise and under-deliver, and being told on a daily basis “Aphra, you are so cynical”. Well, cynical or not, I’m also right. Ner.

We are in fact only one week behind where I expected to be, which is a month behind where the rest of the team expected to be, all because other people over-promised and under-delivered and we believed them instead of tracking their status on a daily basis. I may be cynical, but Mr Red told me not to be anal, and now look at us.

All of that as it may be, I have spent the last 8 weeks waiting for Something to Go Wrong. Now that it has, I feel an enormous sense of relief. We have no choice now but to deal with reality. No more floating around in pretty-fluffy-cuckoo-land where people do what they say they do without being checked up on and software tests perfect the first time through.

I am thinking of having a motivational poster printed up saying:

People lie.


Software fails.


Deal with it.

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.