Author: Yvette Lamidey
Published in: PAYadvice
Date: April 2006
Taxation: Electronic Delivery
The Way That I See It....
Employers are paying twice over for legislative changes. They have to bear the cost of implementation and then their software provider isn't always delivering the enhancements to the product that were expected because so much R&D is being sunk into meeting legislative changes.
Employers have perhaps had the raw end of the deal from software over the last few years in so much as all the changes that have been necessary for legislation have taken up so much development time and cost that it has been to the detriment of the enhancements of payroll functionality.
Software developers are often much maligned when they deliver software that has added unexpected features, bugs to you and I, although sometimes we are right to question the level of quality assurance that developers may or may not have undertaken before code has been released to the end user. But what we often don't take into account is the amount of changes that these developers have had to cope with and the conditions that they have had to work with, especially in the last 2 to 3 years.
Managing changing legislation across all government departments and ever moving technology is challenging in itself but when coupled with a what at times seems to be a lack of openness in and robustness of the test services and the delivery, completeness and timeliness of technical specifications these developers feel that at best they are working with one hand tied behind their backs and at worst with both hands ties behind their back in total darkness.
Government departments made a commitment many years ago that developers would have long lead times for changes in legislation and in the main this is the case and necessary work to get the changes into their various products and ties in with the release cycle for products. Unfortunately what isn't there is a test environment that is robust and mirrors exactly the live systems and often the test data itself is woefully lacking since there is insufficient data and nor does it cover every variation of circumstances that may occur in the data and so the testing undertaken is not as rigorous as it should be.
So what's the impact? Sometimes developers have no choice but to release software to their clients which isn't tested to the level that they would like and so employers may find that there are bugs in the software. Because the testing hasn't been as extensive as it should be it can mean that it takes time to establish whether the bugs are specific to the environment/operating system/data combination to that client or if it's a more general bug that all or most users would encounter. The former is a specific fix to that client the latter is a fix that has to be distributed to the whole client base. And for larger employers who test their software before going live this means additional costs to them to retest their system and then upload into live.
Every bug that is found in software is a cost to the client and the developer, we know that the nature of software is that it will never be 100% bug free 100% of the time but where these bugs arise because of the inadequacies of testing systems and technical data and specifications it is particularly galling as this is a cost that could have been avoided.
The solution - greater collaboration with developers when designing technical specifications and also in building test facilities. Making sure that test and live environments are absolutely exact clones; any difference between these environments will impact performance and jeopardise the delivery of correctly working software to employers. Completing the development of the functionality that supports/interfaces with the payroll software to the same early delivery schedule that developers have to adhere to. Test services have to be fully functional and up and running in October for any changes for the end of that tax year. If for any reason there is a delay in the delivery of the specifications and or the test and live services then this should be conveyed to developers openly. As soon as any issues are found these should be circulated to developers so that they don't waste time and energy looking for errors in their code when the cause lies elsewhere.
We recognise that this is something that might not sit well with government departments and potentially Ministers since it would highlight that there are problems with software developments where there is already a less than good track record but the benefits to developers and the ultimate savings to developers, employers and government departments and the goodwill that this will engender is not something that should be dismissed lightly and in time will result in much better working relationships for all concerned.
Yvette Lamidey
Yvette Lamidey is director of Paris and Parks Consulting
www.parisandparks.com