Whether you are working in a Waterfall environment, an Agile environment or something in between, the application change process always starts with a business requirement. Someone discovers a bug in the existing application or r equests an enhancement or needs an entirely new system. At that point, they need to communicate their need to application development in order to pursue a solution. Many of the problems in managing application change begin with faulty processes for gathering and prioritizing change requests.
Change Requests must be captured at the source — directly from the user(s) who require the change. Business analysts and developers will need to take that information and work with the end user to define exactly what the system must do to fulfill the need, but it is important never to lose sight of what the user said that they want. As the change process progresses, there will undoubtedly be new requirements that are discovered and modifications to the original request. The ALM System makes these easy to track. This continually up-to-date information should drive the design of the solution and the creation of the tests that will be used to determine when a change is ‘done’ — i.e. whether it meets the need the user described in an appropriate way.
It is incumbent on the users to ensure that they identify the business value of the requests they submit in order to drive the prioritization process. The ALM system can automatically route the change request to the appropriate end user team members for review and value assignment, gather the signoffs, record the responses and then, if approved, forward the request to application development.
The ALM system:
- Provides a simple method for entering requests
- Ensures they contain the necessary detail
- Notifies people who must be involved in the review
- Gathers and records approvals
- Routes the r equest through the appropriate workflow
- Records all communication regarding the request to ensure nothing is lost
- Provides a method to generate reports regarding activity
- Keeps the request accessible to all authorized stakeholders
These are all necessary steps in most compliance and best practice standards for ensuring that the appropriate information is tracked and that nothing is ‘lost’.
Once a Change Request has entered the system, it must be prioritized so the application development staff knows which things to do first. Inadequate prioritization is a major contributor to misalignment between application development deliveries and business needs. It is the responsibility of the business users to adequately communicate those priorities to application development. The ALM System can record business value information and priorities and make them visible to all the appropriate team members and stakeholders. High performance application development organizations use the ALM system as a tool to constantly review their change backlog to ensure they are working on the changes that provide the greatest business value.
The ALM System can be a useful tool in creating prioritized lists of changes based on business value. It can provide users with the capability to display a filtered list of backlog items based on whatever criteria the user finds helpful. Users can then move items around in an ordered list until they are in descending order by value with the most valuable changes on top. The ALM System provides visibility to the prioritized list for all authorized, interested stakeholders.
More sophisticated methods of prioritization involve assigning specific economic values to change requests. The most common method is to assign an ROI value to the project. However, the problem with ROI is it does not consider the value of timing. There may be a project in the backlog with a very high ROI relative to other projects, but that ROI is
A two-month delay will only cost us a fraction of the high ROI project value, while we will lose all of the value of the Limited Window project.
available whenever the project is delivered. Conversely, there may be a project with a lower overall ROI, but the value it provides might be highly dependent on when it is delivered. In that case, the second project has a higher Cost of Delay. In that case, application development might want to deliver the project with the higher Cost of Delay first (see chart on page 2). Whichever method you choose, the prioritization justification should be visible in the ALM System so that everyone is aware of how decisions are being made. Once the change has been delivered, actual values can be recorded so that the decision making process can be validated.
If a choice must be made between two projects, one with a very high ROI and the other with a smaller ROI but with a higher Cost of Delay, the choice should be the project with the higher Cost of Delay. In the example above, ther e are two projects. Each will take two months to implement. However if the March delivery date is missed, the entire value ($100,000) of the Limited Window Project will be lost while only two months of return ($40,000) of the High ROI Pr oject will be lost. In scheduling and managing development, it is critical to understand and record the Cost of Delay. (See Donald Reinertsen’s book “The Principles of Product Development Flow” for an excellent discussion of the importance of tracking Cost of Delay.)
At Aldon we ran into this situation and our ALM system made it immediately visible. We were implementing a restructuring of our database that would provide a platform for a variety of new enhancements to the product. Once those enhancements were delivered, we anticipated a large ROI for the project. At the same time, our salespeople were telling us that we could win a greater percentage of our current opportunities if we would make some changes to our user interface. The ROI for those changes was smaller overall than the architectural change, but the window of opportunity for winning the current deals was relatively short. We decided that the cost of delaying the big project by a few months was relatively minor while the cost of delaying the changes required by our prospects was much higher. We chose to deliver the interface changes first and delay the restructuring. By recording the relative value information in the ALM system, everyone understood the justification for our decision.
The ALM system allows request tracking to occur automatically as a by-product of working together on a Change Request, so developers need not be burdened with time-consuming activity documentation requirements.
Once a Change Request has been prioritized and approved for work, the ALM System routes the change through its appropriate workflow and notifies users when they have a task to perform. It records signoffs and state changes so that important metrics like cycle time, velocity and wait-times (bottlenecks) can be recorded and managed. Developer activity is automatically logged as they perform operations
like check-in, build and unit test. By automatically gathering this information as part of normal day-to-day activities, the ALM System can significantly reduce the administrative documentation burden placed on developers by audit and regulatory compliance requirements.
Integration with the developer’s preferred IDE allows them to keep the ALM system up-to-date without being saddled with a lot of additional administrative work. In the example above, a developer associates the changes they are making to an ALM task directly through Visual Studio.
Developers can associate their changes with a Change Request directly through their IDE or version control system at the time they Commit, Check-out or Synchronize. Development change activity can then be tracked and reported upon with very little administrative impact on developers.
By tracking the Change Request from initiation to completion, the ALM System will be able to identify for the development team and other stakeholders how long it takes changes of different sizes to make it through the system. These ‘cycle times’ can then be used to make deliveries more predictable.
Later, the activity logs can be used for compliance reporting. Auditors will be able to use the ALM system to view exactly what happened from the time the request arose until the solution was delivered into production. They will be able to easily verify that the change process met the audit requirements.