In April we moved on from the regulatory issues and
more toward the business issues associated with operating in a regulated
environment. We looked at establishing strategic direction and
identifying the choice of "vehicle" to move your profit margin from A to
B. Now let's look closer at that vehicle selection. What system will you
choose to operate?
Specification and Selection
Don't just buy an Internet gambling system and expect
all your troubles to be over.
- How will you achieve product
differentiation? After all, your competitors probably use the same
back-end system.
- Who is your target market? How will you
customize your chosen system's look and feel to appeal? How easy is it
to integrate third party games?
- What jurisdiction are you locating in? What are
the reporting requirements and customized regulatory reports?
- What about internal controls and operating
procedures and how compensating controls might make up for system
deficiencies or vice versa?
Your specifications are formed by what you require,
what your supplier offers, what the customer requires and what the
regulator requires (collectively, "the stakeholders"). It is certainly
true that there is a large overlap amongst the major stakeholder
requirements; however there will always be significant and subtle
differences.
To return to the vehicle analogy, have you ever
visited a vehicle yard to purchase a vehicle not knowing if you wanted
a van, truck, sedan or sports car? Had you at least decided if you
wanted two wheels or four? Perhaps a road bike?
Without defining your requirements first, how will
you be sure you've selected the system (the vehicle to take your profits
from A to B and beyond) that best meets your needs?
Your requirements are your selection
criteria. If you choose the system first, then decide your
requirements, you might be months, even years, away from getting it
right … if ever.
Can you imagining re-engineering a motorcycle into a
city bus? Why do it with your technology?
It sounds simple, but time and time again technology
operators (in all industries) have done just that.
When there are problems (and there always are), what
can the operator (client) or the developer (software supplier) fall back
on in the contract if the requirements (functionality, etc.) were never
defined up front? Consider including your project plan and your requirements in the
contract along with any suitable penalty clauses.
Think carefully about the implications of your supply
contracts. For example, if your supplier sells a system to your
competitor with a requirement for a percentage of profit and they sell a
system to you with no such agreement, what incentives have you
engineered into your contract to protect your position? That is, why
would the supplier not concentrate its efforts on getting your
competitor live first, while your delivery dates slip and slip? Where is
the incentive?
What if your supplier sells its software business to
your competitor?
Does your system supplier provide a "one-stop shop"
or do you need to negotiate the hardware, operating system, database
purchases, licenses or maintenance agreement? What ongoing support is
offered?
Does your system supplier integrate with third party
games to provide you several degrees of freedom in product
differentiation?
The Development Whirlpool
There is just one message: Don't get sucked in!
System developers/suppliers: Do not commit to supply
contracts unless you have agreed specifications and milestone dates.
Operators: Do not commit to a system without
obtaining sign-off on your specifications and milestone dates.
Why are specifications and milestone dates so
important?
Customers may change their requirements spontaneously
during system development with no appreciation of the implications on
development. Remember that Internet operators generally just want to
operate the system and not develop it. In parallel with development, the
customers will continue their market research and various other factors
will make them change their mind. Any variation to a specification may
result in a variation to milestone deliverable dates and cost. No
developer wants to be slapped with penalty clauses by having not defined
what it is they are developing.
Software development programmers do not necessarily
understand the customer's requirements upon a verbal request. Rather
than have the programmers document their understanding and have the
customer sign off, they are known to rush in, performing a good deal of
work, only to have the customer say, "But that isn't what I wanted." If
it is what the customer wanted and it is defined in writing, then any
change may result in a contract variation. However, if it is not what
the customer wanted, then the customer has a right of recourse.
In all cases of variation, development schedules blow
out and resources are stretched.
What invariably suffers is the system documentation
(not enough time, they say) and before too long there may be no current
description of the system and no current design documents, no record of
bugs or full system functionality. If staff leave, knowledge leaves
with them and there are no documents to refer to, so new engineers are
thrown in at the deep end and old engineers are diverted from
development because of the intensive "one-on-one" training
required...and...schedules slip further, so in order to try to catch-up,
engineers start by-passing development procedures and what was once a
controlled tip of software branches from the tip and
becomes in effect a different system for each customer.
A bug is found for one customer and rather than fix
the bug in one module on the tip, it must be located and fixed in all
branches for all customers. One fix is missed and there is a panic to
fix the bug, again resources are stretched and schedules delayed.
The number of bugs and patches increases and before
too much longer there is an uncontrolled, ill-defined, poorly understood
set of "spaghetti code" that is inherently unreliable, that is
statistically 100 times more expensive to maintain.
Because of the additional work required, time to
market becomes a big issue and so product is pushed out the door without
effective internal testing.
Customers sue operators, operators sue developers and
governments are embarrassed. Goodwill suffers, regulators lose
confidence and time to market increases as a consequence.
So, coming back to the question, "Is time to market or making an
informed and 'right' decision that equates to protection of brand name
and protection of license the important factor?"
When selecting a system auditor, is a retrospective
audit on a sample set of numbers sufficient? Or is a thorough
evaluation of systems, security and methods a better method of
establishing confidence and mitigating business risk?
Test Environment
Get one!
Never take software releases straight from your
supplier to your live system without undertaking a trial installation
first.
The test site should ideally mirror your operating
site, but of course a test site adds an additional cost, so the level of
risk one is willing to accept should determine the degree to which one
does establish a test site.
Regulatory Requirements or Guidelines
At this point I am once again compelled to mention
the regulators.
Any of you who have read a well-defined set of
regulatory requirements will note that the requirements seek to address
many of the risks mentioned above. A review of the system supplier's
development environment is a regulatory requirement. Proper build,
install and release procedures are equally requirements.
If one steps back and takes an objective look, it
becomes evident that a well-defined regulatory requirements framework is
in essence the basis for a requirements specification that, with some
edit, simply defines good business practices in any event. It is
something an operator or supplier could consider appending to a contract
as a specification document.
Regulatory requirements or guidelines, if structured
properly, can and will be an aid to business, not an encumbrance.
If an operator is considering a system that has been
approved against sound regulatory requirements, then one must consider
that the testing and regulatory approval of such a system provides a
high degree of confidence that the system mitigates most if not all of
the risks I outline above. Equally, I am sure there are good systems
operating in "gray" markets that meet the "good business" criteria,
however therein lies another mine-field: probity and impact on gambling
licenses.
Shades of Gray
A supplier who may be operating in a "gray"
jurisdiction may put at risk the license of an operator who is licensed
(terrestrial or Internet) in a jurisdiction that deems the suppliers
activity to be "gray."
Probity is a major consideration in selecting a
system supplier, depending on the business strategy of the operator.
Is the glass half empty or half full? Is it a circular
argument or a simply a sign that the local bar is stingy in pouring the
drinks? We know what we perceive and often perception is our reality.
Is the supplier a few shades darker than white, a few
shades lighter than black or gray?
We'll leave the probity issue for the lawyers and the
international regulatory community to resolve.