Page 10 - Helixion-swisscom-tapit-case-study
P. 10
Tapit: The Development
Whilst there are a number of areas to consider when
embarking on a development of this nature, some key
areas are highlighted below that anyone considering such
a development might wish to consider in more depth.
Project Methodology
The decision in this instance was to follow an Agile approach with two week sprints. There are
plenty of papers on the pros and cons of Agile development, but it is fair to say that with this
project, the sprint approach with its regular feedback points had its benefits in consolidating
the working partnerships. On the other hand, the danger of an Agile approach like this, is that
it can impose a significant project management overhead – especially when teams are remotely
situated. A balance has to be reached within any project between the need for face-to-face
meetings and the resource required to administer them and implement the outcomes.
SIMs and Personalisation
As anyone who has worked in the smartcard industry knows, one of the hardest items to get
right is the personalisation of the cards. If test SIMs personalised to match the deployment
profile are not available on time, development at best has to be rearranged and at worst
delayed. This problem is not unique to the Tapit project, but getting the SIM cards’
personalisation correct took many more iterations than initially envisaged.
As Helixion has strong expertise across the whole NFC payment ecosystem, it was able to
prepare its own test SIMs and create work arounds, thereby minimising potential delays.
Work-arounds are an example of where an experienced technology partner can add real value
to a project. In this instance, for example, Helixion provided a solution which averted delay to
the delivery of Swisscom’s Tapit.
Helixion’s advice to anyone undertaking a similar development, unless your technology
partner can provide a workable interim solution, is to allow far more time for this part of the
project than might logically seem required in the planning stages – at least doubling the
allocated (elapsed) time is not unreasonable. Utilising standard prepared personalisation
profiles when available, rather than taking on the risk of creating bespoke profiles, is an
alternative approach to consider.
Beta Trial
Good standard practice prior to any large scale commercial launches of new software is to
conduct a beta trial or soft-launch. It helps identify any last few issues that were not
encountered during the more controlled laboratory testing phase, thereby limiting the chance
of any embarrassing “hic-ups” when the general public starts to use the product.
In Swisscom’s case the beta phase will last approximately 4 months and involves trusted users
(mainly employees of Swisscom) who have been given a preview to use and more importantly
test the solution in a live environment.
10 A Helixion Case Study
Whilst there are a number of areas to consider when
embarking on a development of this nature, some key
areas are highlighted below that anyone considering such
a development might wish to consider in more depth.
Project Methodology
The decision in this instance was to follow an Agile approach with two week sprints. There are
plenty of papers on the pros and cons of Agile development, but it is fair to say that with this
project, the sprint approach with its regular feedback points had its benefits in consolidating
the working partnerships. On the other hand, the danger of an Agile approach like this, is that
it can impose a significant project management overhead – especially when teams are remotely
situated. A balance has to be reached within any project between the need for face-to-face
meetings and the resource required to administer them and implement the outcomes.
SIMs and Personalisation
As anyone who has worked in the smartcard industry knows, one of the hardest items to get
right is the personalisation of the cards. If test SIMs personalised to match the deployment
profile are not available on time, development at best has to be rearranged and at worst
delayed. This problem is not unique to the Tapit project, but getting the SIM cards’
personalisation correct took many more iterations than initially envisaged.
As Helixion has strong expertise across the whole NFC payment ecosystem, it was able to
prepare its own test SIMs and create work arounds, thereby minimising potential delays.
Work-arounds are an example of where an experienced technology partner can add real value
to a project. In this instance, for example, Helixion provided a solution which averted delay to
the delivery of Swisscom’s Tapit.
Helixion’s advice to anyone undertaking a similar development, unless your technology
partner can provide a workable interim solution, is to allow far more time for this part of the
project than might logically seem required in the planning stages – at least doubling the
allocated (elapsed) time is not unreasonable. Utilising standard prepared personalisation
profiles when available, rather than taking on the risk of creating bespoke profiles, is an
alternative approach to consider.
Beta Trial
Good standard practice prior to any large scale commercial launches of new software is to
conduct a beta trial or soft-launch. It helps identify any last few issues that were not
encountered during the more controlled laboratory testing phase, thereby limiting the chance
of any embarrassing “hic-ups” when the general public starts to use the product.
In Swisscom’s case the beta phase will last approximately 4 months and involves trusted users
(mainly employees of Swisscom) who have been given a preview to use and more importantly
test the solution in a live environment.
10 A Helixion Case Study
