Another IT Failure?

A tiny example of a very poor (but typical) implementation

Involves HMRC - but could be anyone

Situation:

Recently, started new job (not at the beginning of month). I did not get paid first month. I received 6 week’s pay in second month. Later, received email from company payroll after about 8 weeks advising of a new improved tax code.

Note - HMRC receive full, accurate and immediate information from my employers about my employment, covering start dates, payment dates, remuneration etc. This has been the case, for a number of years now – its real time!

The Error:

HMRC had advised my new employer of a new tax code. This code increased the tax I would pay by about ￡1600 pa.

My online tax account showed that I had a new tax code. And, also showed the calculation. The calculation was incorrect, and the code calculated by the calculation was different to the code sent to my employers.

There was no need to alter my tax code – the sums performed by HMRC where incorrect according to their own data.

The Recovery:

Two lengthy phone calls 10 days apart covering the key aspects both times.

First call caused my online tax code to revert to the correct figure.

The second call caused confirmatory email communication to both myself and my employer.

The explanation:

In short, the very nice person (you have to feel for these guys) explained that it was auto generated from the information supplied (start date, payment etc) in order, to ensure I was paying the correct tax and minimise surprise bills at the end of the tax year.

The failure:

1)     Business needs and requirements capture - Get tax codes correct from the data we hold, cause less calls to our help centre, send consistent information to all parties obviously missing? What was the acceptance criteria?

2)     Algorithm implementation – given HMRC have the employment start date, annual salary, monthly payment information. It is difficult to understand how the algorithm could produce two distinct answers, both incorrect.

3)     Testing and verification – Massive failure in test analysis and execution. Clearly what does the system do if you don’t start a new job at the beginning of a pay period was not a test condition considered. As was making sure all algorithms produced the same outcome for the same input data. Or, in fact challenging why there was a need for multiple calculations?

Alternative view is that it was found and allowed to be released anyway.

Business Outcome:

·        More tax codes correct, more often – Cant see how this can possibly be true

·        Less calls to help line – there must be more calls unless people don’t notice

·        Increased revenue by reducing delay in collecting tax – maybe, but HMRC must also give it back when its wrong and this has a cost

·        Cost base will increase, because the solution will need to be re-implemented correctly at some point.

Another way?:

• Hire people who can and who care
• Capture the requirements – if this bit is wrong there is never a recovery. You are servants to luck and hope now.
• Have a quality approach and make it matter to everyone.
• Invest in testing tooling and trust your test outcomes
• Reflect on all failures and correct the people, the process and the tools. Defects are an excellent tool to drive productivity and improvement of outcome

A side note – Ruud Gullit (a very famous footballer) once wrote that football is an easy game, as long as the player with the ball stands still and everyone else moves.

Software production is also simple – as long as you follow your model with rigour and stop lying!