Protect Your License - Selecting a System

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.