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
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.
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.