The document discusses a case study on 'Credit Focus,' a web application designed to assist small businesses in managing credit control and debt recovery efficiently and affordably. It highlights the challenges small businesses face with late payments and the importance of selecting the right offshore development vendors to create user-friendly, scalable solutions. Key recommendations include thorough requirements understanding, maintaining formal communication channels, and ensuring strong management visibility throughout the development process.

1. Successful offshore product development
Credit Focus from Barclays – A case study
February 2009

2. Agenda
I. Introduction and business context
II. Choosing an application development vendor
I. Business drivers for going offshore
II. Vendor selection criteria
III. Lessons learnt by a first-time product development offshorer

3. Small businesses have a huge problem with late payment and
bad debt, but lack credible tools to deal with the issue
Late 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 tools
Sources: DTI, Allianz, R3, CMRC, Barclays surveys, Credit industry research; BACS; Bibby; Experian, Insolvencies Service

4. Business drivers meant that any solution had to be intuitive,
flexible and scaleable; it also had to be cost-effective
Selected 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. Credit Focus is a web application designed to think and act like a
professional credit control department, all for an affordable fee
Example 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. Agenda
I. Introduction and business context
II. Choosing an application development vendor
I. Business drivers for going offshore
II. Vendor selection criteria
III. Lessons learnt by a first-time product development offshorer

7. Credit Focus was considered an ideal project to evaluate
new 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. A key consideration during vendor selection was to find
a 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 clients
Long 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 vendor
Decision
• Level of senior management engagement
• Quality of key team members offered
• The right price
= Zensar Technologies

9. Agenda
I. Introduction and business context
II. Choosing an application development vendor
I. Business drivers for going offshore
II. Vendor selection criteria
III. Lessons learnt by a first-time product development offshorer

10. Trivial differences in the understanding of business
requirements are magnified by onshore/offshore distance
Recommendation Comments
Complete the requirements understanding If the requirements understanding phase slips, let the overall
phase properly, no matter what project slip: it will still save you time and money in the long run
Overspend on creating a highly Once development starts you won’t have much visibility on what the
detailed, functional prototype offshore team are doing; a decent prototype is the best insurance
Champion team members who Make it clear (in words and deeds) that there is no such thing as
challenge ambiguity in the requirements a stupid question during the requirements understanding phase
A lot of understanding is lost If at all possible, go to the offshore location during the
without face-to-face interaction requirements understanding phase to explain the business vision
Be realistic about what cannot Some things cannot be offshored (e.g. writing good in-product
be done offshore copy): leave time and budget to get them done onshore

11. Crack down on informal channels of onshore / offshore
communication (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. Even more than for onshore projects, success or failure
depends on the quality of a small number of key individuals
Project 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. To compensate for the lack of a physical presence, onshore
management must find ways to be visible to the wider team
Techniques 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 doesn't 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 offshore
behaviours 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 whole
team calls that all team members team has worked hard, but in particular he stands
can join (onshore and offshore) out for me.”
• “From what I've 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. Questions
?