Offshore product development - a case study

1,037 views

Published on

2009 presentation for Intellect, the trade association for the UK technology industry (http://bit.ly/lcSTel)

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

  • Be the first to like this

No Downloads
Views
Total views
1,037
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Offshore product development - a case study

  1. 1. Successful offshore product developmentCredit Focus from Barclays – A case studyFebruary 2009
  2. 2. AgendaI. Introduction and business contextII. Choosing an application development vendor I. Business drivers for going offshore II. Vendor selection criteriaIII. Lessons learnt by a first-time product development offshorer
  3. 3. Small businesses have a huge problem with late payment and bad debt, but lack credible tools to deal with the issueLate payment a huge problem Existing tools not credible solutions• 40% of small businesses have late payment • Cost – Existing best practice tools can easily take up 5% problems; for 10% their top problem of a small business cost base• Typically small businesses paid ~25 days • Complexity – High expertise required for existing tools late, losing them tens of millions in interest (small business owners generalists, not credit controllers)• Small businesses spend two working weeks • Information – Prohibitive costs of acquisition in the small a year chasing payments business segment means that there is low awareness• Bad debt costs the average small business • Fear – Poor knowledge means small businesses £1,000 each year overestimate the downsides of many existing toolsSources: DTI, Allianz, R3, CMRC, Barclays surveys, Credit industry research; BACS; Bibby; Experian, Insolvencies Service
  4. 4. Business drivers meant that any solution had to be intuitive,flexible and scaleable; it also had to be cost-effectiveSelected business drivers Design consideration Delivery• Small business owners are • Build a highly intuitive user interface, • Negligible customer generalists, not credit control with clear exception-handling and support queries in relation specialists heavy use of context-sensitive help to features and navigation• This is an entirely new concept, so • Support web-analytics to understand • Four releases in first year; the application must learn from its how users interact; production support customer support calls down user base team able to build new releases and satisfaction up• A business prize exists in creating a • Build an application that is • MySQL/J2EE solution tested new mass market for credit designed to be highly scaleable at a concurrency of 50 users management services from day one instantaneously• Simple, ground-breaking pricing • Avoid the cost and complexity of • Purely web-based; browser model required to open up this new client software installation compatibility covering market, so cost-per-user must be low >95% of internet traffic
  5. 5. Credit Focus is a web application designed to think and act like aprofessional credit control department, all for an affordable feeExample screen – customer homepage Key customer benefits I. Check - Know how risky your customers are before you extend credit to them II. Monitor - Be warned about changes in the risk profile of your customers III. Chase - Chase your debtors using a leading firm of debt recovery solicitors
  6. 6. AgendaI. Introduction and business contextII. Choosing an application development vendor I. Business drivers for going offshore II. Vendor selection criteriaIII. Lessons learnt by a first-time product development offshorer
  7. 7. Credit Focus was considered an ideal project to evaluatenew development models and vendors (offshore & onshore)Internal criteria for the right project Reason for criteria• Choose a ‘greenfield’ project with clear requirements, • Vendors will be willing to submit competitive fixed and no legacy systems to accommodate price bids • No excuses: if project fails then accountability is unambiguous• Choose a project able to be delivered in smaller, • Failure would be clear early on, allowing the plug to discrete phases be pulled • Leaves internal capacity to scale up management attention if required• Choose a ‘ring-fenced’ project with zero • Failure or delay will not impact established business dependencies for other business lines lines • Allows test and learn without ‘betting the company’ 7
  8. 8. A key consideration during vendor selection was to finda provider that had a lot to gain from winning the work Offshore vendors Onshore vendors • Big and robust... • Recognised sector leader (e.g. • Recognised industry leader (e.g. NMA top 10 technical agency) NASSCOM Top-30) • ‘Blue chip’ financial services clientsLong List • ‘Blue chip’ financial services clients • CMM-Level 5 or equivalent • ..but not too big • Want senior management attention • Don’t want to be allocated the ‘B-team’Short List • Quality of RFP responses (depth, advice, relevance) • Credible, relevant case studies in web applications • Clear why the bid makes sense for vendorDecision • Level of senior management engagement • Quality of key team members offered • The right price = Zensar Technologies
  9. 9. AgendaI. Introduction and business contextII. Choosing an application development vendor I. Business drivers for going offshore II. Vendor selection criteriaIII. Lessons learnt by a first-time product development offshorer
  10. 10. Trivial differences in the understanding of businessrequirements are magnified by onshore/offshore distance Recommendation CommentsComplete the requirements understanding If the requirements understanding phase slips, let the overallphase properly, no matter what project slip: it will still save you time and money in the long runOverspend on creating a highly Once development starts you won’t have much visibility on what thedetailed, functional prototype offshore team are doing; a decent prototype is the best insuranceChampion team members who Make it clear (in words and deeds) that there is no such thing aschallenge ambiguity in the requirements a stupid question during the requirements understanding phaseA lot of understanding is lost If at all possible, go to the offshore location during thewithout face-to-face interaction requirements understanding phase to explain the business visionBe realistic about what cannot Some things cannot be offshored (e.g. writing good in-productbe done offshore copy): leave time and budget to get them done onshore
  11. 11. Crack down on informal channels of onshore / offshorecommunication (senior managers are the worst offenders)Onshore / offshore channel Valid contents Rules • Defects • Each bug must be a fully transparent • Features audit trail of the entire ‘bug’ life-cycle Bug-tracking • Live Support • Only client can prioritise and close ‘bug’ system Formal channels • Requirements • Each version of a project artefact to • Plans be uploaded to the project wiki Project wiki • Prototypes • All versions must be clearly version- • Releases controlled • Any e-mail should carry the relevant bug-tracking system / project wiki E-mails N/A reference no. (which must then be correspondingly updated)Informal channels • All decisions arising in phone conversation to be followed through in the bug-tracking system / project wiki Phone calls N/A 11
  12. 12. Even more than for onshore projects, success or failuredepends on the quality of a small number of key individualsProject structure Comments l ed al ss to n s cu il ity isio fo ct ib c % je is d e V y 00 pro 1 n ke o ONSHORE OFFSHORE Client Client Account Programme Product Technology Manager Manager Head Head CRUCIAL Project PROJECT Onsite Lead Manager LAYER Develop- Analysis Design Testing ment
  13. 13. To compensate for the lack of a physical presence, onshoremanagement must find ways to be visible to the wider teamTechniques to generate management visibility Example: real management comments from the project bug-tracking application‘Walk the walk’ There is no point demanding • “Good spot guys” compliance to certain tools and processes without being willing to • “Failure to replicate doesnt prove lack of a problem” yourself use them • “Excellent bug report”Create consequences Select a few random examples of • “On what basis was this closed?”for bad behaviours bad practices (e.g. poor estimations or badly documented • “Thanks for the pragmatic response” work) and comment • “More narration is required in this bug”Reward good Ensure that exemplars of best Example: management feedback on offshorebehaviours practice are publicly team members acknowledged (particularly more junior team members) • “From the moment I became engaged with the Project team it was clear to me that [team member]Talk to the whole Arrange regular update / Q&A was a safe pair of hands... I know that the wholeteam calls that all team members team has worked hard, but in particular he stands can join (onshore and offshore) out for me.” • “From what Ive seen so far, [team member’s]Get on a plane There is no substitute for ‘face- contribution has been extremely strong. She has to-face’ to really communicate brought the a renewed sense of rigour and visibility business requirements to proceedings”
  14. 14. Questions ?

×