1. Technology Consulting | IT Strategy and Transformation
End-to-End Software Change
Management
Accenture Case Study
Evgeny Nedelko, February 2012

2. Original Problem Statement
• A big Russian bank needs to prioritise 12000 application change
requests received by IT Department annually, introducing clear
and simple criteria to reject 60% of requests, which don’t fit into
the budget.
• The existing prioritisation process is not transparent, rising
conflicts and substituting business needs with local politics.
• The resources of the System Analysis department are not enough
for the detailed analysis of each incoming request.

3. Detailed Analysis of the Process
There are more Subjective
12 000 Approval by a Development of than 9 000 requests Development,
Registration of prioritization 5000 of RFC
requests per Business system awaiting implemen- testing and
request tation and the to include in a per year
year owner requirements implementation
queue is growing SW release
Rejected 3 000
of requests per year
• Number of requested changes is much higher compared to the number of changes that go into
production (input12 000, implemented 5000). Some requests are rejected but not enough and
there is no formal rules causing a lot of complaints from users.
• Analysts and developers are overwhelmed processing requests that are not economically rational.
• The business users’ competition for IT resources causes frequent queue reshuffling resulting in
that some commenced developments never go into production.
• Business owners are overloaded by the flow of requests spending not enough attention on each
particular request, making impulsive, unjustified decisions.

4. Improved Change Management Process
Registration of Development of Definition of
12 000 Express Automatic
Queue no release scope. Development,
request and prioritization. functional 5000 of RFC
requests per evaluation of longer than Reject testing and
evaluation of Reject below requirements, outstanding per year
year costs threshold AA 2000 requests implementation
benefits refining estimates requests
Up to 5 000 requests Up to 2 000 requests
rejected per year rejected per year
• Analysts pulls most valuable requests to develop system requirements using the auto calculated
cost / benefits ratio.
• Requests are rejected on the first gate with a threshold leaving space to correct errors of
cost/benefits estimations.
• Analysts then refine both costs and benefits estimations while developing requirements.
• Developers pull the requests for a release in accordance with refined priority. Outstanding
requests are rejected.
• Business owners are permitted to change a priority of any request not yet included in a release,
when they can justify their decisions.

5. Improvement
The main idea of improvement is to move the Go/No Go decision
as early as possible in the process flow.
• Since the uncertainty at the beginning of the process is very
high, requests can be rejected at several steps of the process as
long as the confidence increases.

6. Focus cost reduction
• To reduce the actual cost of implementation, the existing best
practice in the bank was used: every big enough requirements
specification should include several implementation options.
• For example if somebody requests a internet shop, there could be
several option such as:
– a simple web page with a link to the pricelist.xls and contact email
– a ready to use PHP solution
– a full scale custom internet solution (such as Dell.com) integrated with the
corporate ERP

7. Calculator for Benefits Estimation
• To simplify the benefits estimation for users and to make the process repeatable,
a set of benefits categories was identified with respective formulas to calculate benefits.
• An open-source version of the benefits estimator is available online:
– http://benefits-estimator.googlecode.com/hg/benefits.html

8. Calculators excluded from open source version
– Impact on company’s reputation / customer behaviour
– Minimum capital requirements
– Railroad transportation
– Warehouse logistics
– Electric power consumption

9. Validation of benefits and costs
• To validate the costs standard project portfolio management
software is used capturing all timesheets and other associated
costs (hardware, licenses, etc).
• Validation of value is bit more tricky. There are two points of
validation introduced:
– As result of UAT, the users enter to the system the perceived extent to which
their goals where achieved.
– Also there are random audits performed by the controlling department 2-4
times a year, doing the evaluation of actual benefits achieved by the
improvement utilizing their financial tools and expertise. Variance between
actual achievements and estimates is used as equalizing coefficient for
estimates provided by users.
• After 2-3 years of implementation the methodology should be
updated since people will learn over time how to trick the system

10. Unresolved Issue
• While requests are raised by the business
users and analysed by the analysts
aligned to the business structure, Front-end Back-end Reporting
the software changes are implemented by system system system
developers aligned to the application
systems. Retail
request change change
• To support such matrix structure it would
be necessary to split many incoming SME
request
requests to several dev groups,
still calculating priority for original Corporate
business request summing up all cost request change change
estimates as a total cost. Public
• Even more complex case is when several request change
business requests are resolved by a single
…
system change.
• To implement such logic a reasonable
enhancement of the ticket management
system is required.

11. Benefits Estimation for the Improvement
Better selection of changes to be implemented along with reduction of
disturbance should raise the average benefits/cost ratio from 2:1 to 3:1
or more,
bringing the benefits equal or greater than the overall Bank’s budget
spent on application enhancements (about $30 mil. per year)