Your SlideShare is downloading. ×
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
End-to-end software change management (case study)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

End-to-end software change management (case study)

896

Published on

Published in: Business, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
896
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
52
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Technology Consulting | IT Strategy and TransformationEnd-to-End Software ChangeManagementAccenture Case StudyEvgeny 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. ImprovementThe main idea of improvement is to move the Go/No Go decisionas 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 ImprovementBetter selection of changes to be implemented along with reduction ofdisturbance should raise the average benefits/cost ratio from 2:1 to 3:1or more,bringing the benefits equal or greater than the overall Bank’s budgetspent on application enhancements (about $30 mil. per year)

×