Another Project Failed?
We often read about failed projects but what does failure really mean? I was reading today about the HMRC IT projects which were supposed to help detect and recover unpaid tax to potentially save £4.5B over 5 years. Needless to say, the National Audit Office branded it poorly performing, "The NAO attributes the delays to a series of factors, including late approval of project design or specification changes, projects being phases in over successive financial years to keep within funding limits, including adjusting the scope of work to fit within those limits, and greater complexity in the delivering the projects than was first envisaged." So basically, nothing new there. It still amazes me that despite the fact that these are well known risks to a project, they are still not managed, seemingly at all. We have all these wonderful Project Management courses and MBA degrees and all these people who are paid vast sums to manage these projects and yet this happens.
These are not hard to plan for in advance. If you know that yearly budgets are relevant to project payments, which they would be for any serious sized project, then you have to factor that in. This means it takes longer to finish perhaps but it should not cost any more within reason. Specification changes is another monster and, again, happens on virtually every project, the number of changes being exponentially proportional to the size of the project. If these changes are unacceptable then the specs need to be nailed down in advance so the developers and testers can crack on and get it finished quickly. If they take too long, they will deploy a project that is already out of date (like electronic MOTs). If changes are acceptable and realistically, they should be, then there should be a way to cost these into the project that increases over time. If your customers sudden requirement to change the main system 2 weeks before delivery relates to a cost and time extension of £50M and 2 years then that cost is made clear to the stakeholders who have the decision about whether to pursue it or not. We should probably accept that sometimes things will get canned.
On the other hand, we often do no root-cause analysis on why these projects fail and the main reason? Usually too much complexity which leads to many unknowns or disagreements in functionality and inevitably massive time and cost hikes. For instance, when looking at electronic patient records, another system that seemed doomed to failure, even if we just created a basic system that recorded, say, appointments, treatment, allergies and drugs for each patient at a very basic level, that would already be miles better than what exists currently and would allow an IT infrastructure to be rolled out and used (which would be much easier to upgrade later if required) and would cover, perhaps 80% of useful functionality. You could then design the system to have pluggable modules so at a later date, you might be able to make electronic X-Rays available in the same system as time and money permits. This allows people to use the system, iron out basic issues and see what they really miss and therefore what should be highest priority for the next development. It also allows an open API to be created and multiple companies to develop multiple components that all just plug in.
I will say it again, simple is good!
These are not hard to plan for in advance. If you know that yearly budgets are relevant to project payments, which they would be for any serious sized project, then you have to factor that in. This means it takes longer to finish perhaps but it should not cost any more within reason. Specification changes is another monster and, again, happens on virtually every project, the number of changes being exponentially proportional to the size of the project. If these changes are unacceptable then the specs need to be nailed down in advance so the developers and testers can crack on and get it finished quickly. If they take too long, they will deploy a project that is already out of date (like electronic MOTs). If changes are acceptable and realistically, they should be, then there should be a way to cost these into the project that increases over time. If your customers sudden requirement to change the main system 2 weeks before delivery relates to a cost and time extension of £50M and 2 years then that cost is made clear to the stakeholders who have the decision about whether to pursue it or not. We should probably accept that sometimes things will get canned.
On the other hand, we often do no root-cause analysis on why these projects fail and the main reason? Usually too much complexity which leads to many unknowns or disagreements in functionality and inevitably massive time and cost hikes. For instance, when looking at electronic patient records, another system that seemed doomed to failure, even if we just created a basic system that recorded, say, appointments, treatment, allergies and drugs for each patient at a very basic level, that would already be miles better than what exists currently and would allow an IT infrastructure to be rolled out and used (which would be much easier to upgrade later if required) and would cover, perhaps 80% of useful functionality. You could then design the system to have pluggable modules so at a later date, you might be able to make electronic X-Rays available in the same system as time and money permits. This allows people to use the system, iron out basic issues and see what they really miss and therefore what should be highest priority for the next development. It also allows an open API to be created and multiple companies to develop multiple components that all just plug in.
I will say it again, simple is good!