A large, global organization was operating with a legacy resource management application that required significant enhancements. The application was originally intended to support the resource management operations of one resource pool. However, as other resource managers heard about the application, they rolled it out in their respective areas and after several years, over sixty resource pools were managed with the application.
The application was not designed to handle such large-scale usage and thus experienced performance issues and required significant support. Furthermore, the business needs had changed from the original design and users requested numerous functional enhancements. Given the high number of user demands and the ‘fire fighting’ nature of the environment, the team encountered major production issues, missed several release dates, and was beginning to lose credibility. As a result, there was a risk that the users would abandon the application and implement individual solutions. The team needed to quickly stabilize the situation and roll out new versions of the application to keep the users engaged.
The solution was to implement a system development lifecycle to introduce structure, define roles and responsibilities and ultimately improve the predictability of the releases. The key aspects of the program are described below.
Separate Support from Future Development
Upon reviewing the activities of the application team, it became apparent that a significant portion of time was spent on providing user support. All user requests were handled as high priorities and since the team attempted to respond to all support requests in one business day, every member of the team became involved. As a result, very little time was spent on developing the required enhancements.
To ensure progress on future development activities, each team member was designated a primary role of support or development. Additionally, the support requests were analyzed and resolutions to common requests were documented. The first level user support was then outsourced to a centralized function and a process was put in place to periodically review the second and third level support requests to document resolutions to increase the scope of first level user support.
Define & Communicate Objectives of Each Release
When users were interviewed to gain an understanding of their needs, a common theme emerged. They believed the team was reactive and they did not know what to expect from the application in the future. Thus, they were uneasy about whether or not the application would meet their future needs.
To gain the confidence of the user community, the team needed to achieve some quick wins and show continual progress from there. Outstanding enhancement requests and performance issues were reviewed and categorized into major functional areas. These were then grouped into five application releases with scheduled release dates approximately 2~3 months apart. The overall plan was then communicated to users, including the major objectives of each release. Although the user community was initially skeptical, once the first couple of release dates were successfully met, they became very supportive of the process.
Involve Members of Other Functions
The application team was responsible for all aspects, including requirements gathering, design, development, testing, training, user documentation and support. Although the organization had centralized functions for QA, e-Learning, and Help Desk Support, the team had not been able to leverage them due to the ever-changing and volatile nature of the application.
By defining and planning the releases as described above, it became possible to involve members so that they could perform their respective functions and thus reduce the workload of the application team. A system development lifecycle was documented and templates for the key deliverables were designed. As part of the system development lifecycle, checkpoints were defined that triggered communications with other areas as appropriate. For example, as requirements and designs were documented, the e-Learning group was notified so that they could prepare user documentation and training materials to coincide with the release date. A process was also put in place to request feedback from these centralized groups on the process and the deliverables. Their input was incorporated so that the methodology was continually improved.