A large UK Government Department is embarking on a programme to accelerate their delivery of new IT solutions utilising agile software engineering methods. During this time iCore were asked to look at some of their existing application support teams and see how we could help them to be more agile. These application support teams managed enhancements to existing corporate systems and users were becoming increasingly frustrated in the length of time changes took to get implemented.
This case study has been produced by Steve Ingall, Head of Business Services at iCore to demonstrate how iCore was able to able to help the application support teams move from twice a year enhancements to once a month.
Requirement
iCore were engaged by a large UK Government Department to support numerous Service Improvement initiatives aimed at improving the support and delivery of IT solutions. One of the initiatives was to look at how enhancements to the corporate Service Management toolset could be accelerated. The Service Management tool had been in place for over 6 years and it was now supported by a third party supplier as a managed service. The managed service covered the provision of full-time BAU Support team and 120 days per annum for enhancements to the system to be delivered by a part-time Development team.
Users and Senior Management were frustrated that whilst the process for reviewing and prioritising enhancement requests seemed satisfactory the actual implementation of the enhancements was taking over 6 months, even for a simple change. There were believed to be approximately 8-10 enhancement requests each month. iCore were tasked with improving this and if possible reducing the cost associated with each release.
Approach and Deliverables
Initial Assessment
Once the iCore consultant started talking to those involved in the existing process it was clear that the Service Owner and the Development team had become ‘comfortable’ with the way they approached the delivery of enhancements, and when challenged to identify ways that the delivery could be accelerated there was few suggestions.
The current process was quickly documented and iCore identified areas were the process could be improved. This involved making a few changes to the review and approval process and then in the flow of enhancements once they had been approved.
Review and Approval
Users would raise enhancement requests through the Request Management system and these were assessed by the support team to identify an approach and the effort required to develop the change. The Development team maintained a separate spreadsheet with all the details of the requests and their assessment which was discussed at a Service Board every week by the service owner and key stakeholders.
iCore advised that, as only the requests that were deemed high priority would go forward for implementation, it made more sense for the requests to be assessed after they had been prioritised, not before as was the current approach. This change meant that time was not wasted assessing requests that would either be declined or get a low priority. This revised approach meant that more of the 120 days would be used in developing the enhancements and not administering the process. In addition, iCore recommended that a more stringent approach was taking during the review to actually decline enhancements that would get such a low priority that they would never make it into a release, saving even more time.
Development and Release
Once requests had been approved they were added to the development backlog and the highest priority identified for the next release. Each release would include between 5-8 enhancements and the release would be scheduled to go into development, testing and then into media management for deployment. Typically every release would be at least 6 months in duration.
When breaking this timeline down iCore identified that for each release the development of the changes would take less than 10% of the duration with testing and deployment taking the rest of the time. The time in testing was caused by the fact that the Service Management system was not categorised as mission critical and so often fell down the testing schedule if something more important came in for testing. The Development team would be responsible for setting up the test environment to be used and for building the package to be deployed, but this was included in the development time. As an example the current release (which needed only 8 days to develop) had completed development in December but in May it was still awaiting testing.
iCore broke the timeline down and approach each team to see if the approach could be made simpler and faster. In the discussions with the Testing team we asked them how they decided the amount of time and effort they would put into testing a release of this system and, apart from the category of the system, it became clear that it was simply access to resource to produce the test plan and perform the testing.
The deployment needed to be scheduled via the Change Management team and each release was classed as a Major Change due to the fact that the release required a system restart, typically taking 1 hour. We discussed with the Change Management team why this was classed as a Major Change given this is a change that has been done many times and is a tried and tested procedure. It was simply the fact that the change needed an outage.
Even in development when we asked why they bundled 8-10 enhancements into a release knowing it would take 6 months to get deployed they could only say that it was what they always did.
Recommendations
Taking all this information into considerations we made the following recommendations:
- Only assess the requests once they have been prioritised to proceed
- Target doing a release every month and to enable this to be more easily scheduled with the operations teams and the users, this should be on the first Thursday of every month
- Only include 1-2 enhancements in a release which would enable the highest priority enhancements to be deployed faster
- The Service Owner should identify the highest priority enhancement they need the Development team to work on for the forthcoming release and the backlog should be reviewed to see if any of the requests could be implemented by the BAU Support team as ‘fix on fail’ where the change did not need a system restart
- Given this is a tried and tested procedure the change should be considered a Standard Change rather than a Major Change, which in turn would mean that the Development team did not need to complete a full release note
- With the release only containing a single enhancement then the Testing team did not need to perform a full integration test and they should be able to pass the release by observing the Development team performing their testing
Outcome
All recommendations were accepted and the Development team commenced a smaller, more frequent release strategy, which meant the user satisfaction increased and the releases became an accepted norm.
The simplified ways of working meant that more of the 120 developer days were used on development and not administration.
As a by-product of this work iCore also helped the Change Management team to redefine the criteria used to categorise changes, looking more effectively at the impact and risk of the change rather than applying simple tick-lists.
If you found this useful and would like to discuss how iCore can help you drive your IT Service Delivery then contact us on +44 (0)203 821 1252 or email info@icore-ltd.com
