Project Management - the trinity extended

Project management fundamentals teach us that that project management was a trade-off between the trinity of:

• Schedule
• Scope (requirements)
• Resource (people, competency of people, and money)

The three dimensions are in equilibrium and each dimension is proportional (inversely or directly) to the other two.

Formulas like the Ideal Gas Law (PV=nRT) work well to simply communicate the basic relationship between pressure (P), volume (V), and temperature (T).  Very abstractly, project management fundamental values might look like the mathematical formula:

Schedule * Resource = Scope

For example, if Schedule is decreased, then Resource must increase (inversely proportional) and/or Scope must decrease (directly proportional).

Each of three values are only so elastic. To be a practical formula, none of the values can be extremely low (0) or infinite.

Customers/stakeholders may only control one or two of the above three. Not all three. If stakeholders try to control all three and the estimates for all three are reasonably correct, the project will fail.

For example, "scope creep" results when the scope is increased by stakeholders that don't want schedule or resources to increase from your original estimates. The formula indicates that this simply isn't possible and scope creep alone (without compensating by increasing Resource and/or Schedule) will cause project failure.  Note that increasing Resource can also be delivered as improved Resources (e.g., same headcount, higher quality but more expensive staff).

There are three other important dimensions. They are derivative from the above three, but important enough to warrant their own explicit treatment. They are:

• Quality
• Risk
• Technical "Balance"

Expanding the formula, it now looks like this:

Schedule * Resource * Risk * Technical Balance = Scope * Quality

(Note: I use "Technical Balance" rather than "Technical Debt" as I believe in at least some areas you can "future proof" or "over architect" to create a positive/credit balance that may or may not create yield at a later time.  This is akin to the agile tenant of "only build what is required" versus "I *know* we're going to need this in a year, and it's a lot more efficient/cheaper to build it now."  It is also similar to cash sitting in a bank account that you're not investing in a way to maximize yield.  Regardless, a tip-of-the-hat to Ward Cunningham and others on the concept of technical debt, it's brilliant.)

Examples of putting these derivative values into play:

• Decrease quality to reduce schedule (e.g., launch sooner and let the customer test for us; we only fix what the customers complain about)
• Create technical debt to reduce resources (e.g., don't bother with code/build tools, don't bother with reducing code duplication or code quality refactorings)
• Reducing the scope allows us to reduce the risk (e.g., of delivery) - the less to deliver, the lower the risk

The above 6 project management dimensions are about managing participant and customer expectations - making sure the trade-offs you are making in the project are transparent to the customer/stakeholder so they can make better decisions to guide the project.

You could use these 6 items in project status reports or at least during major review points with customers.

Update May 2010

There are emerging approaches in software development coming from the manufacturing world (Toyota) which claim to be tearing down the "time, quality, money - pick two" formula and re-writing the laws of engineering and hence software development.  These practices have been adopted into so-called "lean" practices.

Observations:

• The old schedule-scope-resource formula holds, but only if you don't include a time dimension.  Schedule-scope-resource continues to apply in a short period of time, but not in a long period (e.g., due to trading out scope/quality for few resources and tight schedule).  If you are delivering a single shot software, the formula works.  If you are going to live with that software for a long time, evolving and extending it, then you have to include.... time... in the formula.  The time horizon is a business decision.  You educate your business counterparts on technical debt levels, and let them decide.  
• Good non-tech business leaders responsible for a business that uses tech to power the business must develop an understanding of how to make these tradeoffs, no different than being able to assess balance and P&L sheets.  If they can't do this, they won't be effective leaders of a tech heavy business.  I have yet to work with a business leader that has a time horizon greater than a year, and it's probably closer to a quarter (especially with publicly traded companies: shareholder horizon = board horizon = CEO horizon, and so on).  At least in Internet Gambling, the business doesn't seem to prioritize "built to last" over "get me X right now!!".
• By including "technical balance" in the above formula, which captures changing technical debt due to scope/quality versus resource and schedule, there is an implicit temporal aspect to the formula.
• Some technologists prefer to root cause all defects, maximize learning as the business progresses, and keep a very firm, low-debt foundation under them.  However, the reality is that many early stage businesses have to make trade-offs every day between enabling future scalability versus doing whatever it takes that week to get a sale made or acquire a few more customers.  The alternative is the business runs out of money and its game over for everyone.
• Unless business/board leaders are extremely confident of the business proposition, they are not going to invest heavily in future-proofing the business.  This comes down to the business leaders making the right guesses and being in the right place at the right time (note here the debate between user centered design versus good/lucky business leadership - either is valid in the right circumstances, but bring both together and wow).  Great business leaders being in the right place at the right time is a fairly unique combination.

The formula could have a stronger time basis added to it.  You can't (e.g.) inject money into the formula and instantly increase quality and scope.  It generally takes time for a change in one variable to ripple out to adjusting the other variables.  The same applies by gradually downsizing the team - things don't necessarily start failing immediately.  This is an inertia, latency, or lead time effect.  However, you can minimize the time required to (e.g.) inject new talent onto a team by prioritizing as a requirement the ongoing creation and maintenance of tools, processes and techniques that facilitate insertion/deletion of talent onto a team.

The time basis could also be included from the perspective of the time-value of the scope being delivered.  From a competitive viewpoint, it's likely that having the output right now is of highest value, with scope value decreasing as schedule increases.  This is no different than building a new building - once the decision to build is made, every day the building isn't earning money is lost revenue.  The faster you try to build it, the higher the costs - there is a cost/revenue sweet spot here, but difficult to identify in advance.

Another huge variation is that not all resources are created equal.  Some resources can even create a net productivity loss.  Similarly, as resources mature in a team and learn the codebase/technologies, their efficiency increases.  Therefore resource effectiveness becomes it's own formula that replaces the simpler "resources" in the above main formula.

The formula also doesn't fully capture project "success".  Success comes from successful project execution (formula captures this well enough), but not whether the resultant delivery is successful (e.g, with a customer, in a market, creating positive revenue).  A successful delivery is half or less of the battle.  Creating a product valued by customers resulting in healthy and sustainable net profits is really the battle to be won.

Portal/CMS selection, some alternative criteria

When selecting a portal/CMS, there are business standard ways to select one:

• Formal RFI, RFP processes
• Formal reports from the likes of Butler and Garter
• Mesh requirements to features
• Cost
• Installation consultancy, on-going support provisions
• Top level Company/IT strategy considerations:
• In-house versus outsource
• Open-source vs commercial vs hybrid
• Technology stack (production support) and language (development)

What is one key flaw with the above list?

You don't actually know if the solution will *work for you*.

The above approach is primarily business oriented and only superficially technology oriented. It is sales and marketing information used by non-technical decision makers. It is information contrived to make a sale. I really believe this is one key reason why so many IT projects fail. Products such as CMS software is selected with only light technology considerations.

And when I write "work", it's more than just the pure technology itself. It's also about integration into your existing environment, IT team adoption, bugs specific to your use of the product, and fit for purpose with respect to your requirements. It's about de-risking the technical side in parallel with the business side.

Don't get me wrong. The above list is important. It primarily provides information to help you sell the proposal with non-technical bosses, stakeholders, and downstream customers. It helps you learn about the partner and your requirements. But if you want to enable a successful project, you should be de-risking deeper technical aspects as well.

It's also important to maintain a commercial view, for example:

• TTM (Time To Market) requirements
• Off-paper requirements (e.g., common shareholders between your and the other business; individual relationships)
• Forecasted revenue benefit to project (i.e., how much can you afford to vet)

Given all this, there is a lighter (higher risk, less work) and heavier (lower risk, more work) investment approaches to software selection.

Light weight investments that can be done relatively quickly (in a week or so) and at lower cost:

• Check in with colleagues that have been involved with portal/CMS creation, selection, and deployment. Similarly, if you can, determine what your competition is using.
• Research forums. This is particularly useful for open source or mixed open/commercial source solutions. Look for use of the product that mirrors your intended use - what issues are people reporting? How do the issues change over time?
• If available, review product case studies. Do the case studies reflect your intended use of the application? For example with portal/CMS, are you trying to build a b2c customer facing website and the case studies are all about ECMs (Enterprise (Intranet) Content Management)?
• Where is the company based? What is their primary language and how does that compare to the project's primary language? Cross-cultural issues to consider?
• Use google to look for your proposed CMS - how many pages come up?
• Go to a recruitment/jobs site like jobserve - can you hire developers and systems administrators that have experience with the CMS?
• Use google to look for consultancies - on-shore, offshore, outsource - that specialize in the software you're considering
• Similarly, talk to recruitment agency contacts and ask them what CMS experience they have on CVs and job placements they're working on
• Perform a more detailed analysis of the system architecture and compare to your own competencies

Let's consider a practical example of the lightweight approach. We are considering two possible portal/CMS/website technologies, Day Communique CQ5 and Alfresco. From a non-technical perspective, we're favoring CQ5.

Checking in with colleagues and in the industry:

• Most sites have a hand made portal and CMS for their core customer system. This isn't surprising for igaming as most sites are transactional/functional (not content) oriented.
• Some PHP portal/CMSs are in use. Again, not surprising as PHP was and continues to be the techies choice of underpinning CMS language.

Forums: TBD

Case Studies:

• Communique/CQ5 had eleven case studies, one of which looked like what we need to do
• Alfresco had 24 case studies, not yet reviewed.

(Aside: note how Alfresco uses "case studies" in the URL and Day does not. I'm might think that Alfresco has people involved that understand SEO and Day does not. Or it could be a language thing.)

Location and Language:

• Alfresco is UK/English
• Day is Swiss/German

Google basic search results:

• "CMS Communique" yields 323,000
• "CMS CQ5" yields 11,800
• "CMS Alfresco" yields 961,000

(Aside: Day has made search/SEO particularly hard on themselves as they appear to be moving from "Communique" to just "CQ5" and also sometimes including the "Day" company name prefix rather than just a name. Compare that to Alfresco which goes by... Alfresco.)

Jobserve results:

• Communique or CQ5 yields 2 job postings
• Alfresco yields 10 job postings

Google results for consultancy: TBD

Google results looking for outsourcing and offshoring:

• "CMS alfresco outsource" yields 17,600
• "CMS alfresco offshore" yields 5,130
• "CMS communique outsource" yields 6,470 (CQ5 is 384)
• "CMS communique offshore" yields 12,900 (CQ5 is 2,040)

I also had one colleague report pain dealing with Alfresco consultancy and support.

System architecture review: TBD

(NB: the TBDs here are due to a time limited review and some prior knowledge of both systems.)

I'll let you draw your own conclusion for the lightweight approach.

Heavier cost and lower risk approach is to do two or more Proof of Concepts (POCs). Create an end to end working system that demonstrates some difficult (high risk) functionality. Determine if the system actually works to the hardest bits of your unique requirements. This can be done independently (cheaper, higher risk) or in collaboration with a vendor or consultancy (more expensive, lower risk).

A practical example of the heavier approach? As you might guess, it's TBD!

In conclusion, you'll have some variable amount of time to evaluate portal/CMS choices. Be very wary of a selection driven only by business and not technical reasons. While it might be a commercial reality that you're forced to not technically qualify a choice, you can now at least quantify what should be done and some consequences if you don't do it.

Software Escrow Services

Had quite a discussion with NCC the other day about software escrows. The net result was that software escrows might as well be a dinosaur with respect to Internet gaming.

Often in a contract you might require a vendor to escrow their software in case the vendor suddenly disappears. On the surface this seems sensible, but lets take a closer look.

Reasons to not use an escrow service:

• How does the customer verify that the auditing firm has the correct version of software?
• How frequently does the vendor update the auditor with new software? As frequently as the software is updated in the production environment?
• A lot of software for web based systems is interpretive (ASP, Java, PHP). You have working source code on your production systems already.
• Also the working environment you have... works. You have no guarantee that whatever is with the escrow service actually works.
• Say the escrow service takes in regular snapshots of the vendors source base. What about all the build, configuration, and deployment tools required to create a working production system? What about related documentation?
• How many vendors have you worked with in your career that have suddenly disappeared? Even if they did, likely someone will still be around to make a few quid and offer you the source.
• Escrows are sold via sales FUD, which should generally indicate you don't need them.
• They cost money that could be better spent on pizza (A LOT of pizza) for the IT team

One possible reason might be that you are dealing with a two-guys-and-a-dog software company and they really could disappear tomorrow. Will a company like that really have the time to play nice with a big-boys escrow service? Unlikely. If the software their supplying isn't interpretive code (e.g., big C++ poker server application) then you ought to think about buying the source and having the vendor build the image on your systems. Or only buy software with interpreted code (Java, PHP). There should be a practical/commercial approach that is much more suitable that an escrow service in this case.

Regardless, if you have an operating system in production, the source likely isn't immediately needed.

And if there was a loss of vendor, followed quickly by a catastrophic systems failure, what good is the source going to do you? It's likely you need the expertise behind the source.

I came up with three reasons why we might work with a company like NCC:

1. A customer of ours insists the third party elements of our software stack have the source code held by an escrow company
2. Our statutory auditor advises our board that an escrow service is a really good idea (NB: look for new statutory IT auditor).
3. A cheap way to acquire source if you thought the vendor was likely to fail (although this sounds more like a Sith mind trick!).

Conclusion: Don't bother with software escrow services.

Web server stats - OS and Browser Usage

Just a few real life stats from a number of UK and EU targeted sites from the month of June, 2009:

• Windows (XP+Vista) makes up 96% of users
• IE 6, 7, 8 make up 87% of users (14%, 55%, 18% respectively)
• Firefox is 11%, Safari at 1.6%

(Stats approximate - usual web log analysis constraints)

Game client-server coms - choice of IP port and data encapsulation

It's always fun to get down to the network protocol and packet level. One of the things I find frequently misunderstood is how IP port addressing works with respect to outbound firewalling. This comes up when considering how a gaming application can work within a corporate firewall that is blocking most outbound ports.

First, the basics:

• IP is the network protocol. Basically, it deals with hooking up a client and server to talk to each other by using a source and destination IP address and ports.
• http is a data format protocol. It is a description of how data will be sent between client and server, and specifies some "meta" data. Think of "meta" data as the address on the outside of an envelope you put in the mail and the letter in the envelope is the data itself.
• SSL and TLS are two security protocols. They describe how a client and server can communicate with each other securely.
• https is the combination of http, SSL/TLS
  

A high numbered port ("source port", "ephemeral port") is assigned by the IP stack on the client automatically when the connection request is sent by client to server. Intermediate networking components such as a firewall may select a different port (known as PAT or Port Address Translation) but regardless will allow inbound (back to client) traffic on the source port until the connection is closed or times out.

To avoid corporate firewalling blocks, a client gaming app should encapsulate data in https and use port 443 ("destination port") to communicate to the server.

Any service on the server can listen on port 443 or any available port for that matter. In the case of a game server, the application can listen for game client requests on port 443.

Using 443 also has the benefit of disabling most (but not all) stateful protocol inspection by a firewall. To be 100% confident of corporate firewall bypassing, the client-server protocol could be encapsulated in https so that the https (SSL/TLS) setup packet inspects as https. While http (https) is expensive in terms of bloat/performance to send small bits of information back and forth between client and server, it has the advantage of effectively tunneling through proxy and firewall security blocks. By implication, don't bother with port 80.

Note that using port 443 should play nicely with corporate proxy servers as well although you would need to explicitly set this up in the client unless you can find a way to inherit proxy settings automatically from the OS or browser.

Also note that while this approach is straight-forward for a downloadable rich game client, it can be harder in Flash game client.

A few documents you might find useful:

• Firewall FAQ
• Adobe Flash practicalities
  

Portal Versus Content Management Systems (CMS) Versus Web Pages

Introduction

There is a lot of difference of opinion on what a portal is.  This is down to several common, conflicting definitions of portals, thinking that portals and CMSs are the same thing, and many different ways to actually build a web page.

Closely related technology and terms will also be covered, along with some practical best practice recommendations.

History

In the mid to late 90s, the first phase of web applications were the same as websites.    Portal and CMS concerns blended together.  Website developers recognized the need for a control panel to control the customer facing part of their site, to which they added some content controls.  They controlled the whole delivery stack.

By the late 90s to maybe 2004, a number of CMSs became available.  This was the second phase of website construction.  You “had to have” a CMS.  These CMSs blended together portal and CMS concerns.  The CMS was the website – pages, content on pages, how pages linked together.  Great for content sites, but building a transactional, functionality oriented site was painful and expensive as the CMS had to be extended.

Also during this time some very clever people working on Java standards recognized the difference between portal, portlet, and content services and wrote JSR-168 (later 286) and 170.  They got it, but practice was well behind theory.

Starting as early as 2001, but really more by 2005, AJAX and web services were catching hold.  The idea that you didn’t need to control the whole delivery stack became clearer.  The first mash-ups started to appear – pulling in services from one website (service) into another.

Also at the same time, an older concept finally caught, which was the separation of content and business logic.  This was the old MVC (Model-View-Controller) approach, but people finally rallied around it.

This leads to the third phase, which we’ve been in for maybe 3-4 years now.  People began to realize that a website is really a container that can draw services from anywhere.  They also refined the MVC approach to separate content-with-format into content and presentation of that content.  They also took a more granular view of web page construction, effectively creating an MVC for each component on a page rather than treating whole pages at a time.

As a result, a portal became a "container of containers" that pulls in and visually organizes content and functionality from wherever it can, but isn’t otherwise primarily concerned with content itself.

Today (mid 2009)

Which takes us to today.  In a nutshell, if a site is very content oriented (not function/transaction oriented) and the content is self-contained, one of those big CMSs may still be appropriate. 

If a site is quite mixed (content, functionality) and has small volumes, little revenue, you still just hack everything together like you would in the 90s.  Same for those that haven’t made the jump in understanding the differences of concern between portal and CMS, don’t require multi-service integration, or “control everything”. 

For everyone else, content and portal are being treated as separate areas of concern.

Making things more complex is that all the terminology and definitions are evolving, quite variable and/or misunderstood.

Portal

A portal is not a CMS!

A portal unifies together one or more service providers into a unified user interface for an information and service consumer.

Examples of service providers and services used by a portal:

• Customer handling system – create and manage customers
• Payment system – debit and credit a customer’s credit card
• Mash-up classics: flickr photos, google maps and news, youtube video
• Content Management System (CMS) – manage content

The service providers may be based on different technology stacks.  In some fashion (there are various) they need to export (make visible) the services they offer.

A service provider, particularly a legacy system or one that is difficult to change, may not use web services or may not be able to easily change the web services it has.  In this case it is common to create some middleware to form a bridge between the legacy system and portal.  The middleware speaks “legacy interface” on one side, and provides a set of modern web services on the other.

The service providers do not need to know about or interact with each other to provide their services (not coupled).  The connection between the portal and the service providers is flexible (loosely coupled).

Assuming the service provider interface remains the same or is backwards compatible, it may evolve independently of the portal consuming that service and other service providers in use by the portal.

Web based solutions are typically a website as displayed in a browser or a rich Internet client (e.g., an MMRPG client).  A rich client stands alone, a website requires a browser.

Choice of portal means choice of technology.  The most common models are the "P" family (PHP, Perl, Python that sit on the front of a LAMP stack), ASP/.Net, and Java.  There are others growing in popularity like Ruby.  Choice of technology will drive the portlet approach which is covered next.

Portlets

Portlets are also called fragments, widgets, blocks, or CMSlets.

A portlet is used to encapsulate a service provider’s service or combination of provider services.

A portlet provides a uniform interface used by web page authors to construct web pages.

It is possible that a service provider might provide a portlet directly rather than a service that the portal encapsulates as a portlet.  This is dangerous because it creates a greater degree of coupling between website construction and an underlying service.  Conversely, it might be faster as web service and portlet are collapsed into one (less code, simpler, less fragile).  Note that this is only possible if the service provider uses roughly the same technology as the portal.

Aside: A rich client may have an equivalent to a portlet, a way to encapsulate a service or combined set of services in a uniform way for the client.

Content Management System (CMS)

Sometimes a CMS is a portal!  But it shouldn’t be.

A CMS is an optional services that a portal can draw on to manage content.

A portal encapsulates CMS services into portlets so a website author can dynamically mange website content.

A CMS should contain all site content – both text and images.

A CMS supports localization of its content.

A CMS will have a backoffice interface to manage the content.  A content administrator can preview content updates in a pre-production (staging) environment prior to live publication.  Content is under version control - who/when is recorded when content is created and changed.  Other typical backoffice functions are present: workflow, audit trail, role based access controls, reports.

A portal may pull text from the CMS and mix it with transactional functionality from a service to create a customer solution.  For example a portal might have a portlet for a registration page that pulls all the field prompts from the CMS but creates the customer in the customer management system.

Historically CMSs owned both blocks of content on a webpage and the webpage itself.  They mixed together portal and CMS concerns.  This is bad for transactional sites as it makes it more expensive to evolve website functionality.

CMSs have many other feature considerations, this is only a high level view of them when positioned in the delivery stack as a service and relevant to portal integration.

A few best practices when working with CMSs:

• Content seen by a customer is never written into a web page.  The web page author requests content from the CMS.  The author knows the context on the webpage and brings in content appropriate for that context.
• A CMS should never be able to publish Javascript.  Javascript should be considered as application code and flow through a control/QA process before live site publication.  Javascript should be encapsulated in tags, not be present in the web page itself.
• A CMS should only publish content with a limited and well-defined set of safe HTML tags around the content.
• Sometimes content and functionality is interdependent.  For example, a new promotions page with some user interaction (e.g., enter a mobile # to access a promotion) needs to go live at the same time as updated (e.g., T&Cs and various links to the new promo page).  To support this, a number of related content changes can be grouped as a change set, and only published all at once when the new functionality is deployed to the production environment.
• In a shared services environment (one infrastructure and software stack running many different websites), the CMS will require strong RBACs to prevent partners seeing or accessing each other’s content.
• Only bring in the CMS you need.  When you only need content control over a few areas, its a viable option to leverage simple tools or just roll your own CMS.  This is where many companies make the mistake of bringing in an expensive CMS package and customize it versus just having a couple of web page authors making updates and handing the business a simple backoffice interface to update a few portlet's content.
• Ideally a CMS contains all service messaging, including error messages.  A service passes along a code for what information to display, the portlet looks up the information in the CMS using the code as a lookup key.

Web Pages

One thing that might feel uncomfortable with the above CMS definition is that the CMS only controls content as displayed in portlets rather than whole web pages.  It's ok, this should feel uncomfortable to some of you.  If you must enable end users to quickly and non-technically create and deploy new web pages to your site, your only choice is to look at a more traditional big boys CMS and hand your soul (and wallet) to the consultants to tailor the CMS to your business.  It means you're going to have to write a set of customized plug-ins for the CMS in the CMS's terms, usually something proprietary.  You may be able to hybridize your approach as well, and I'll cover that below.

However, if the view of CMS as a supplier of CMS oriented components/portlets and not necessarily whole pages is making sense to you so far, let's move into what that means for constructing web pages.

Web pages are requested by a browser.  The browser may pass in a number of parameters when requesting a web page to achieve an affect such as moving through a workflow.  Web page requests are received by the server.  The server identifies the correct page and processes it.  The pages are then handed to a customer’s browser, and processed further by the browser.

The server processes the web page by substituting custom tags with HTML and Javascript.  The custom tag methodology is provided by a custom tag framework as specified by the portal technology choices.

Web pages executing within a client contain a well defined and consistent interface to access dynamic functionality on the server.

Web pages are written by web page authors (aka designers) who specialize in HTML and CSS.  Custom tags aren't a big stretch for them but complex Javascript might be (they typically aren't programmers).  The closer these tags look to conventional HTML, the more effective the HTML/CSS web page authors are when using them.

A few best practices when considering web pages:

• Web pages typically contain Javascript.  A lot of Javascript in more advanced, interactive, dynamic web pages.  The Javascript should be encapsulated in custom tags or portlet and server side substituted into the web page definition using a custom tag interface.  Javascript should not be added to pages directly.
• Web page authors are most comfortable working with a whole web page inside an HTML editor as stored on a filesystem.  Submitting web pages into a database (that is, web pages pulled from DB, not served from filesystem) is painful.  Reformatting XML data extracts via XSLT is painful.  This is why web pages best live at the filesystem level and not inside of a CMS.
• Web pages are under version control and must be checked in and out.  
• New and updated web pages must be tested on a pre-production (test) environment prior to being placed in a production environment.  
• Web pages should be published to production in a controlled and audited way.  There should be a toolset that supports this activity to make a web page author’s life easier.  You might almost consider this a webpage level CMS, but with a different users and tighter production release style controls.
• The CSS is a web page concern.  Designers own the specification of what the CSS markup should do.  Portlet and custom tag developers own insertion of the CSS markup itself.  Developers and designers must work together via a "CSS Contract".
• The portal must force subordinate services to use a well-defined namespace for CSS use.

A Hybrid view of CMS and Web pages

If for whatever reason an expensive enterprise grade CMS with a recognizable brand is a hard requirement for your website, you have two choices:

• Write custom CMS plug-ins to integrate all the server side functionality you require to build the solution.  Be aware:
• What you build will most likely be non-portable to other CMSs in the future
• You've achieved vendor lock-in.  Vendors like this - you may not in the future.
• You're likely going to have to (re)train a group of developers to write the plug-ins for the CMS.  The big boys CMSs are big and complex and you're going to have to develop a lot of vertical knowledge to make them successful.
• Be prepared to bring in consultants specializing in the CMS to help your delivery team and operational support team.  Vendors also like this - your CFO won't.
• Be prepared to closely risk manage the new CMS technology risks (like any new, big, complex technology introduction) across your IT team and into the business
• The CMS controls the whole website page.  Designers must work with the CMS to create and update whole page designs using a proprietary approach.  Designers will be creating page "templates" which are then throw into a stable of templates that non-technical users access to create new pages on the site.
• Look at a hybrid view

What is the hybrid view?  Assuming you have the staff and dosh to make this happen, create two parallel delivery tracks.

Track 1 is about delivering a site using the way I've described above, with strong separation of concerns between services and portal, treating the CMS as a service.  The portal owns the web pages, specifies the technologies to be used to construct pages and support client/browser and server interaction.  Assuming you have a team of people that have done this before, risks are low, productivity is good, and the website comes into being rapidly.  Keep Track 1 focused on the core user journeys web pages and lightly stub all other pages.

Track 2 is about deploying the CMS, building up an understanding of it, and seeing what you can do with it while Track 1 is building the website.  To start with, Track 2 should focus on delivering content heavy and frequent content changes pages into the solution.  Track 2 pages should be covering off all those lightly stubbed pages you're creating in Track 1.

You then bring these two tracks together.  Ideally you can get to the point where the Track 2 CMS controls the content heavy, functionality light sections of your website, while the Track 1 website focuses on functionality heavy portions of the site.

To accomplish this, you'll at least have to write CMS plug-ins to functionally provide login, session, logged-in status, and one or more navigation blocks.  This will allow you to maintain the customer's login state as they move between Track 1 and Track 2 pages.

What are the benefits of the hybrid approach?

• Primarily, it's risk management.  The approach de-risks the use of a new, big, complex technology.
• Can get a basic up and running quickly, assuming you are building websites in a standardized way, using the separation of concerns as outlined in this blog.
• You can incrementally shift functionality from Track 1 to Track 2 based on growing depth of knowledge of both approaches.
• But you don't have to shift everything from Track 1 to Track 2 - you can take a balanced priorities, efficiency, cost view of how to evolve the two tracks.

Conclusion

Portal, CMS, and web pages are not the same thing.  Each has its own concerns.

Portals mix together various types of functionality to enable an end-user facing solution.

CMSs manage content and provide services to the portal to access content.

Web pages are the practical implementation of portal provided functionality.

If you architecturally mix the three together, perhaps to save initial coding time, you are creating extensibility and team scaling limitations for yourself later.  There is potentially nothing wrong with that - just go into it with your eyes open.

Product versus Operational Management

At least in the world of Internet Gambling, product management tends to have two parts to it: an operational side and a futures side.  I'll call these two roles "Product Manager" and "Product Operator".  As an organization grows these roles will tend to separate as each requires quite a different, and potentially conflicting, mindset.

Product Manager

- Product managers are responsible for the long term aspects of the product. They are more strategic and project oriented than on-going operationally oriented.

• Understand how investment in product correlates to revenue.
• May own product (line) P&L, but this really depends on the organizational structure and size of the company and the role of the CEO (who ultimately owns the overall P&L).  If a Product Manager owns the P&L, they're really more a business unit (subordinate CEO) manager.
• Focused on product futures
• Domain and product expert, including market and competition.  
• This typically requires research and analysis, and producing briefs and presentations to keep the rest of the business in alignment with product and market vision.
• This may include evolving government, regulatory, and licensing structure
• Support sales and bizdev opportunities to a certain level of product depth, and certainly in the context of a competitive selection (a Product Operations Manager will typically know the current product in a greater depth than the Product Manager)
• Documents roadmap including setting feature/backlog priorities and asserting timing aspirations.  
• Requests, aspirations, and priorities should be gathered across the business and customer base.  These are synthesized, traded-off and put together with product strategy and technology requirements.
• Maintain an evolving roadmap to be constantly prepared to communicate vision, strategy and plans.
• The roadmap isn't just features over a time period, it's also the key drivers and ideas behind feature priorities and timings.
• Lots of communications - with bizdev/sales about what's coming up, with marketing on new and updated features
• Drive consistent use of businesses cases and related process expectations.
• Create new and improved product business cases
• Educate product stakeholders what is required to get a new feature, product, or bug fix into the product backlog
• Must know when to break/bypass the process when a unique and compelling opportunity is presented.
• Identify how to identify and monitor business case assertions (KPIs)
• Document requirements and non-technical business logic
• Set expectations into the business about what is required by a delivery team or supplier for that team to effectively deliver new and improved products
• Create visual mock-ups and prototypes to help communicate requirements.
• Champion the user and commercially-sufficient-quality user experience
• Works with a project, solutions delivery and/or software development manager to deliver new features and functions.  The Product Manager is the domain expert that the technologists consult for feature/function decisions.
• Customer of delivered product from in-house development or suppliers
• Guides schedule-scope-resource-quality tradeoffs
• Understands and monitors technical debt level and makes short/long term technical investment decisions and priorities
• Verifies results against requirements (directly or using a QA team by proxy)
• Post delivery, measure business cases against reality. Create enterprise knowledge around what deliveries create revenue and who is driving them.
• Supplier selection, negotiation, and management, particularly the commercial/legal aspects.
  

Should product managers have staff or be like programme managers that tend to rely on other's staff and influence to get things done?  My view is that as organization and product complexity/diversity grows, product managers must build out a team support all of the above responsibilities.  Using influence to contend for (often precious) resources increases time-wasting political challenges.  In particular, appropriate staff are:

• Business analysis.  People that can develop deep domain knowledge, produce market/product competitive analysis, and create specifications.
• Visual requirements author.  Depending on the capability of your BAs, they may need a semi-technical person to work within Powerpoint, Photoshop, HTML/CSS, Javascript to put together wireframes and non-functional prototypes to communicate requirements.
• Project/Programme managers.  For larger projects, you need staff to glue together all the moving parts and manage aggregate progress and risks.

Note that Product Management can really overlap with IT, in particular with PMO and QA teams.  It doesn't really matter where the Product Management functions sits, although in an emergent and high growth  area it's probably worthwhile to keep it separated from technology to facilitate overall scaling of the business.  As the competitive advantage of product differentiation that comes through excellent product management decreases, it may make sense to merge it into Marketing or IT as a potential cost savings.

Product Operator

- Product operators are focused on extracting maximum value and efficiency out of the platform as it exists today. They understand the current product better than anyone else -  they're using it every day.  They feed operational inefficiency issues and new feature requests into the product manager.

• Focused on day-to-day operations of a product
• Current product experts - they know how the product works, all its quirks and foibles
• Uses backoffice systems to:
• Manage live product configuration
• Produce reports, analyze live data and product performance
• Solve customer problems
• Maximizes product revenue within the constraints of an existing product
• Own a tactical backlog of improvements and fixes that would improve product operational efficiency

Potential Conflict

As organization and product complexity and diversity increases, it's important to separate out operational, execution, and tactical excellence from futures and strategic excellence.  I find time and again these two ways of thinking pop up in all areas during business growth and need to be separated to work well together.

Internet Gambling Taxonomy - 2009 Update

Introduction

A taxonomy provides a way to organize a number of items into groups to make them easier to talk about and compare. A taxonomy is driven by efficiency, item affinities, and logical cohesion.

A UI/IA navigational structure is a taxonomy, but focused more on customer ease-of-use. They typically make simplifications and tailor an abstract taxonomy to specific user segments.

This post is an update to the taxonomy I created a few years ago.

PvH: Player versus House betting

- Fixed odds betting
- House sets/takes risk

Purely mathematical

- with a normal distribution, sufficient volume, house actually takes no risk, no player skill required

• Table games
• Examples: Roulette,Craps
• Absolutely no player skill involved, completely deterministic (unlike e.g., Blackjack)
  
• Slots (pooled aspects with progressives, mentioned below)
• Number of reels
• Number of lines
• Bonus rounds
• Fixed odds lottery and other numbers games (keno)
• Scratch cards
  

Skill based - mathematical

- players who understand the underlying game design and mathematics/odds can maximize their chance to win and drive down the house edge - players may quickly converge on optimal play if these factors are simple and well-known

• Table games
• Backjack
• Baccarat
• Virtual sports (e.g., some implementations of Virtual racing)
• "Skill" games (simple games of chance with variable payout based on skill demonstrated in game)
• Hi-lo games
• Video poker
  

Skill based – environmental and variable information affect outcome; event based

• Traditional (sports) betting
• Format (fixed odds, american handicap, asian handicap; multi-bets, accumulator, exotic)
• Racing vs. all other sports (racing, due to betting complexity, often treated separately)
• In-play or before event start
• Spread betting
  

PvP: Player versus Player betting

- house takes a percentage of play (a "rake")
- house takes no risk

• Poker
• Betting exchange
• Spread betting exchange
• Backgammon
• Mahjong
• Tournament blackjack (p2p variation)
• Aspects of “Be the dealer” (but more like an affiliate scheme the way it was done)
  
• First person shooters inside a tournament/p2p engine
  

PvH: Aggregate Player versus House Betting

- aka Parimutual; house takes a percentage of collective play with no risk

• Pools betting
• Lottery
• Bingo
• Progressives (typically slots, but could be applied to other types of games)
  

Miscellaneous

The above games can be distributed various ways. For example, Blackjack appears in:

• Download rich client
• Web/Flash based ("Instant" games)
• Live casino (rich client or flash based video stream)
• Mobile (typically a downloadable rich client)
  

Pending categorization

• Deal or No Deal
• Top trumps
• Slot tournaments, multi-player casino tournaments
• Who wants to be a millionaire
• Ladbrokes' Balls
  

Validation / Examples

- Other organizational views as taken from well-known on-line betting sites website navigation structure

Example #1

• Sports
• In-play
• Casino
• Card games
• Table games
• Slot games
• Video poker
• Progressives
• Games and Kino
• Live Dealer
• Poker
• Games
• Hi-lo
• Table
• Slots
• Numbers and keno
• Fixed odds
• Deal or No Deal
• Scratch cards
• Top trumps
• Sports & skill
• Bingo
  

Example #2

• Sports betting
• Poker
• Casino
• Blackjack
• Roulette
• Table Games
• 3 reel online slots
• 5 reel online slots
• Progressive jackpots
• Video poker
• Scratchcards
• UK Pub slots
• Other
• Games
• Multi-player
• Numbers and keno
• Table games
• Virtual sports
• Slots
• Hi-lo and scratchcards
• Jackpots and Quiz
• Bingo
• Financial bets
• Lottos
• Backgammon
  

Example #3

• Sports
• Games
• Dice and numbers
• Slot Machines
• Table games
• Card games (mis-labeled as "Slot Machines")
• Virtual Sports
• Dice Arena
• Casino
• Blackjack
• Euro Roulette
• Card games
• Table games
• Video poker
• 3 reel slots
• 5 reel slots
• Hilo + Instant
• Virtual Sports
• Poker
• Lotto
• Live Casino
• Bingo
• Dice Arena
  

Responsibilities of a CTO, CIO and other Technology Leaders

What does the CTO, CIO, IT Director, or VP of Technology do? There are many names, but what we're talking about is the person who owns all of technology for a business or an at least somewhat self-contained unit within a business. Of course this will vary a lot based on the size of the company and the company's raison d'être.

Context #1. I work for an Internet services oriented business. Its a medium sized business owned by a bigger business. I went back through a few months of my memories, emails and notes, here is what I was up to at one point or another.

Context #2. I have a strong belief that you should be clear on what you own versus what you do. I'm probably 50/50 between my own individual contributor work and IT management. So while I own and am responsible for all of technology for the business, most of the work is done by my team, while I do just a tiny little slice of of it. And to be fair, sometimes when I'm doing, I'm thinking about how to create leverage so I can shift what I'm doing to someone else and step back to just owning.

Context #3. IT output should always have a customer. I sometimes get tempted to pull in a product management capability into IT. This is typically due to lack of business engagement or my desire to offer a complete solution, particularly having team skills that enable us to think through complex requirements for our customers. We do this sometimes, with bitter-sweet results. The business has even less skin in the IT game and they become even more disinterested in the product and are reluctant to receive something they didn't help create (even though they didn't want to).

A similar pattern happens with backoffice systems. Right after something new goes live its possible that the project team knows the product better than the customer, especially if the customer has shied away from the hard business/domain logic thinking required to deliver a real product. The shorter the IT weening period the better.  From a cost and efficiency perspective, IT should get back to their main job of IT and the business must come to terms with their level of (sometimes lack of!) engagement during the project.

So in my world, Context #3 means IT doesn't own product management or non-technical product operations, or at least tries to hand it over as fast as possible.

With these contexts in mind, I've roughly divided my responsibilities into two sets: meta concerns and actual responsibilities.

The first are "meta" concerns - useful skills and traits which when bundled together help define leadership.

Meta Concerns (Leadership!)

• Communication
• Out - to customers
• Up - to the CEO, board, shareholders (KPIs and dashboard views)
  
• Across - to my peers - finance, operations, marketing, sales and accounts, product
• Lots of wiki, lots of slides
• Transparency encourages trust
• Out in the open about failures - who messed up what and when; what you're going to change (and not change)
• Drive and re-enforce important cultural attributes
• Transparency
• Over-communication
• Wallow in failures - learn and improve
• Incremental delivery
• Make sure you know and understand what you own; don't treat everything as a black box; pick a few things and understand them in depth
• Ownership
• Learning - sharing information, retrospectives; curiosity
• Sense of urgency
• Change management
• Organizationally
• Major platform/product changes
• Creating leverage
• Both for myself and helping my team to do as well
• Balancing supplier/external, outsourcing, contracting versus hiring leverage creation
• When can the business afford to create leverage versus having to make do with what is already present (budget vs leverage)
• Debunking leverage when it doesn't really exist but is represented to (internally, suppliers, in related businesses, as offered by others)
• As can be funded by the business - I keep spinning out aspects of my job to those that make a full time job of it. Each should be better and more qualified at that job than me and I expect to be able to learn from them
• Managing the politics

Areas of Responsibility

The following is a more practical view of what I own or do, all of which is supported by the meta level skills and traits above.

• People
• Organizational structure
• Recruitment policies, methods, process
• Recruitment plans, including consensus building, approval, sign-off, execution
• Closing on preferred agencies if used for recruitment
• Succession planning, risk management
• Coaching and mentoring
• Conflict resolution
• In-house, outsource; contractor, consulting firm; build competency or not
• Budget
• Yearly overall definition
• Expenses (human; everything else)
• Capex
• As driven by business strategy, key projects
• Monthly to quarterly evaluation of actuals to targets; adjust and warn/alter where needed
• Review and sign-off on invoices and expenses over a certain level
• Re-negotiate changes
• Technical strategy
• Supports business strategy (and helps define it, take it to the next level of details and tradeoffs)
  
• Communicated up/down/across/out in various ways
• Evangelize the strategy overall, but typically aspects of it
• Efficiency versus innovation balance
• Enterprise/Systems/Software Architecture
• Top level architecture (edge of systems, key subsystems, main software components)
• When high spends are involved
• When there are significant proposed changes in business strategy/direction
• Particularly at the edges between teams and major components (e.g., QA to Release; supplier to internal integration)
• Provide various views/summaries of the systems/software/components up/down/across
• Evangelize and push priorities of "wiring and plumbing", "quality of life", and "-ilities" changes (e.g., stability, scalability; as often internally technically originated as driven by vague business requirements)
• Emergent technology trends, what and how to take advantage of them
• High level, first pass, "does this make sense", "can we do this" business development support
• Work and delivery priorities
• As meshed with business priorities
• Project/portfolio planning - cross-portfolio coordination
• Communicate and summarize out/up/down/across
• Maintain close knowledge of where the business is, what people are thinking - I should be 90% right when I prioritize projects and allocate resource and the business will only fine tune around the edges if I'm close to to pulse of what is going on
• Conversely, need to create consensus and buy-in on tech priorities to make sure business is in support
• Outsourcing
• Processes
• Operational, delivery
• Pioneer some processes, collaboratively build others
• Drive incremental improvement
• Internal and customer/partner facing
• Initiatives
• Directly own several themed high level initiatives to address systemic or complex issues that the business and IT team is otherwise struggling to address
• The initiatives end up being composed of a number of projects. I do the work for the initiative itself but then own the related projects.
  
• Mergers and acquisitions support
• Be a catalyst to find break-through solutions when the business or team are stuck
• Initial solution creation
• Regular development
• Hotsite issues
• Come up with new options
• Encourage incremental solutions
• Be a catalyst in finding smaller increments to be delivered
• Help business (non-tech) to take an incremental view
• Help convert features/complexity into a managed risk
• Provide brainstorming/input on how technology can be used to solve business problems
• Have at least a basic understanding of all functional areas of the business
• Communicate and collaborate in their language
• Key supplier management
• Networking in the community
• Domain/sector specific
• Relevant technology areas
• Hotsites
• Making sure that hotsites receive top priority and that everyone who needs to is paying attention and involved
• Not just in tech, but also in non-tech cross-functionally where needed
• Creative engagement of resources not normally available
• Partner and customer interaction
• Learning what they really want
• Help craft solutions
• Gain needs sensitivity to better create and prioritize solutions
• Business domain knowledge, awareness of competition
• Corporate IT interface point (if business is owned by a bigger business)
• Corporate governance
• Audits (statutory IT audit)
• Board reports
• Corporate, secretarial, treasury management of IT business units (e.g., outsource/offshore IT unit)
• Government, regulatory compliance
• Support development of business strategy
• Contribute to product roadmaps, particularly very technical aspects
• Quality assurance
• Office/desktop IT/support
• Policies
• Security
  

Of course everyone is better or worse at these things - no-one can be excellent at all of them, especially on any given day.

How to keep IT aligned with the business

1. Stay in close mental alignment with your CEO and other key strategy and opinion leaders in the business (they are "the business"!). Written strategies and project plans are too cumbersome at this level (they are useful for some across and most down management into the organization). Talk frequently with them - where is their head at today and is IT supporting them as best as possible at that moment?

2. Keep those same opinion leaders engaged in IT priorities and deliverables. The IT leader should be able to prioritize with 95+% accuracy because of (1), but you still need their help and support. Keep discussions in their terms, not technical ones. Talk primarily about costs, benefits, and really material risks. For bigger projects, keep reminding them of commitments made between IT and the business in terms of upcoming benefits.

3. Strike a balance of short and long term investment with your opinion leaders. Some IT work only indirectly support the business over the longer term (typically "wiring and plumbing" infrastructure type projects). Visibly balance these with projects that help you "make the sale" or get short term revenue in the door.

4. Align speed of IT delivery with speed of the rest of your business and the market you play in. Speed costs - align views of time-to-market with budget, quality, risks, and aspirations. Kill projects that have missed the market - don't fiddle while Rome burns. If you can't deliver to market requirements or beat the competition, you and your business are in trouble.

Betfair into the USA and betting exchange economics

Betfair’s Christian Hellmers sparked up the Betfair Plans Rumor Mill by mentioning how betfair could provide USD 50m in revenues for racetracks and horsemen (oh, and betfair as well!) by 2008 if it is allowed to operate in the USA. Let’s think about the statement a bit.

There is no doubt that betting exchanges tend to re-vitalize what might otherwise be a flagging market. But where does that re-vitalization come from? Here is some background on the economics of exchanges in more mature markets (i.e., UK) to understand what is happening.

Betting exchanges allow savvy punters to take advantage of “free market” or “perfect market” pricing. The operator’s “excessive” margin is torn out. What does this mean for operators (or operators that trade on the exchange)? It means that operator over-rounds (profit margin) is eroded to almost zero (zero margin = perfect margin folks). If you’re betfair, this is great – you collect 2-5% commissions. If you’re the operator, you’ve been put on an extremely leveled playing field that only allows you to differentiate on price (approaching zero margin!).

But is a betting exchange really creating a “perfect” market for their punters? No, not really. Once you factor in the 2-5% commission for betfair, PLUS the eroded but present margin present in the exchange’s prices, the punter is in a similar position to where they were before. The punter pays a premium to betfair to wring out every drop of margin from the betfair layers.

So what has really happened here?

Betfair has been one of three market forces driving down bookie prices. The second force is the bookies themselves competing against each other. The third force is internet tools that allow the comparison of odds between multiple operators (e.g., Betbrain, OddsChecker). One might argue that the second and third forces would force down prices to the bone as well, albeit a bone that was defined by traditional gambling operator's cost model. Of course, betfair could drive out the additional bookie cost of odds compilation and trading, meaning that they could compete from a little better cost position then the bookies.

The US market, even more so than the UK market of 5 years ago when betting exchanges first appeared, is populated by fragmented monopoly operators. There is plenty of margin to be “removed” (that is, in part transferred to betfair) up by the betting exchanges. Given that this is the case, then it becomes a win-win for betfair and US punters (and a BIG LOSE for existing legal gambling operators in the US).

You’ll notice that Christian’s list of beneficiaries didn’t include existing US racing operators. In fact, by excluding other operators as beneficiaries, he is essentially suggesting that betfair be the (new) monopoly operator in the US market. Of course, the lead betting exchange, by virtue of the value of liquidity and p2p network effects, would naturally evolve to a monopoly position anyway.

It would be a huge coup for betfair to be able to legally (as might be made legal by US government law in the future) offering US horse racing to US citizens. The US focused, so-called “peer to peer” betting exchange betbug claims they can operate legally already in the US so there is some, albeit trivial, precedence.

Betfair, at least in times past, has offered US horse racing. Is there much interest in US racing outside the US? Not much. Who is participating in those market? I wonder. Its not that US-based punters aren’t familiar with offshore accounts to transfer funds to and from, a common practice encouraged by the early, wild, and wooly days of US offshore betting down in the Caribbean.

It’s too bad that betfair is bound (no doubt by its US venture capital investors) to play nice in the US market. Just imagine what they could do if they took the sportingbet or betonsports positions of gladly accepting US customers.

So where does that leave betfair? It is well understood from betfair that a majority of their exchange business is on racing. They’ve pushed into the Australian racing market, and signs suggest (see previous posts) that Japan is next via the Softbank deal. I would guess that betfair will continue to push on the US, quietly growing their US horse racing business by taking bets from US punter’s offshore accounts, and wait for a chance to move into the market in a bigger way.

Macau residency for expats

This post is about how Macau expats acquire temporary residency in Macau. It's a little out of left field compared to the usual tech and gambling posts. As igaming (ok, Internet Gambling) really picks up in Macau, hopefully some of you will find it useful.

There are two common ways to live and work in Macau. The first way is to acquire a work permit (aka, "blue card"). This process takes 3-6 months from the time you first file your work permit paperwork. You lose the right to live and work in Macau if you cease working for the employer that sponsored you. Less pleasant employers prefer this route because it gives them leverage over you. Others might just be ignorant of the temporary residency process.

Nice and well-informed employers suggest that while they start the blue card process for you, you should also go out and start your "temporary residency" process. Temporary residency is like a superset of the blue card, and allows you to continue to live and work in Macau, even if you change jobs.

Unless you're Macanese, you're not legally entitled to work in Macau unless you have one of these two permits.
The temporary residency process is managed by the "IPIM" (Macau Trade and Invesetment Promotion Institute) Office. They are located in the red and silver World Trade Center building on Avendia da Amizade. While there are 4 reasons you can request temporary residency, the one I'm going to write about is "Management staff and professional technicians" (if you're wealthy enough to do the other 3, you wouldn't be the type reading this blog!).

The first step is to go to the office and declare your intent to seek temporary residency. When you do that you receive an appointment card for an appointment at least 6 weeks after you get the card. Having the card is good. It is a stay of execution down at immigration - they will extend your entry visa to at least a week or two after your appointment. You will also receive the paperwork you need to fill out and some guidence notes. The notes are ALMOST complete (see below for my checklist). Even better, they are all in English, and chances are the staff you met and will meet through this process speak pretty good English.

Next is your appointment where you present all the paperwork you had to gather. The important thing here is that you most likely WILL NOT have gathered everything you need, and that's ok. So long as you have most of it, you'll pass the meeting. The people that I've dealt with at the IPIM have been VERY nice, amazingly nice compared to most government officials I've dealt with (immigration official, Heathrow airport, need I say more).

Providing your appointment is successful, you receive the all important "beige paper" titled "Gabinete Juridico e de Fixacao de Residencia". This is the magic! Take this paper down to the immigration office, and you should be able to get a 4-6 month extension on your entry visa. Plenty of time to sort out whatever you need to sort out.
Now, on to the list. I originally made up the list as a summary of the paperwork they give you at the start, and I've added a few gotchas to it as well.
AgentOfKaos' Macau Temporary Residency Checklist

1. Passport - two copies of complete passport, all pages of passport
2. Proof of residency granted by another country (e.g., passport; yes, redundant with number 1) – two copies
3. Departure card – one copy
4. Non-resident worker card – one copy (original taken back by government) – only if you have a current and active card; previous ones don’t matter
5. Birth certificate – one copy
6. Police criminal declaration
1. From country of origin (original)
2. If you have had a work permit or a temporary residency permit in Macau previously, then also one from Macau
7. One set of original fingerprints (like the ones you used to get your criminal declaration)
8. Photos – 5 black and white or colour photos; print your name on the back of 4 of the photos
9. Proof of marriage – one copy
10. Employment contract – one copy; should include all of the following:
1. employment period, remuneration, name of post
2. “the contract will take effect from the date the temporary residency is granted to the applicant” (this is important, the employment contract must make this reference and reference to the work permit law isn’t acceptable)
3. Main description of job and duties
4. Proof of education certificates
5. CV
6. Proof of professional qualifications
7. Certificate of commercial registration of organization employing or offering employment to the applicant
8. If applicant currently working in said position, Individual Professional Tax receipt should be submitted
11. Job description (must be separate from employment contract)

If your spouse is going through the process, she also has to submit 1-9 above.
A few other things to keep in mind:

• This isn't Hawaii or Sweden - verbally expressed undying love and domestic partnerships don't fly here - you need to be married or your partner can't participate in this process
• For everything above that says "copy", be sure to bring the original as well - the clerk will verify each copy against the original
• Everything can be submitted in English
• When I applied I was told it would take... 9 months... to process (in other words, get the blue card to gain the right to work in Macau, don't wait for your temporary residency!)
• If you get your blue card, when you receive your temporary residency you will need to forfeit your blue card in exchange for the temporary residency
• If you do happen to be working in Macau, without a blue card or temporary residency, DON'T MENTION IT! IT'S ILLEGAL! YOU WILL BE IN DEEP DOO DOO! (In all seriousness, they are plenty of examples of illegal workers being arrested at labor raids at offices and construction sites big and small. Don't mess with it. Fines. Jail. Bad. Your employer may be able to arrange a 45 day consultancy agreement with you to alleviate this. Make sure your employer is paying consultant level taxes to the Macau government if you do arrange this. This is safe and legal.)
  
• Conversely, it does seem to be ok to mention that you are currently living in Macau
  

Ok, I hope that helps some expat out there, in whatever industry they're in, to make their Macau experience just a little better.

About the author

It's probably worthwhile briefly mentioning my background so the readers of this blog might develop some belief that there is some credibility to what they're reading.
I've been involved in online gambling for over five years, touching all types of products and functional areas in several igaming businesses. I've worked with casinos, bingo, poker, betting exchanges, and soft games. I've had responsibility for all functional areas within a business, including P&L responsibility for several product areas. I've been involved in the US, UK, European and Asian markets.

Although familiar with all of these areas, my passion is particularly at the intersection of gambling, technology, and the Internet.
I am currently based in Asia, splitting my time between igaming consulting and new business development. If you're interested in getting involved in igaming in Asia as either an operator or investor, please don't hestitate to contact me.
-- AoK (agentofkaos AT gmail DOT com)

More on Scalability - At the Application Level

A few weeks ago I posted on scalability, in particular high level systems and software scalability (please refer to this previous post if you don't understand some of the terms in this post). I want now to briefly touch on a business's ability to scale geographically and how this applies to software applications. This post therefore contains a few more areas to use as part of evaluating potential software vendors. Also, as before it is generally about internet gambling products.

One way a business can scale up is to take its products and services from one market and sell them in a different market. It is important that if this type of activity is part of the business strategy, the business's applications that make up its products and services will faciliate this expansion.
When Internet games/gambling businesses expand in this way, they tend to get caught out in three primary areas:

• Language translation
  
• Localization and usability
• Currency

1. Language translation

For web pages and from a customer facing perspective, language should be a simple matter to change. This process is often called localization, although it should be called translation. Providing there is good separation between presentation and logic, it's typically easy to break down all the text into chunks, translate each chunk, then re-forumulate the pages.

Some languages present unique challenges such as right to left and top to bottom reading - that will be covered under Localization and usability.

This is typically more difficult for a heavy client as the text is sometimes more difficult to get at and change, and there is a heavier process for testing and distributing the resultant new heavy client. Again, providing a solid process was used to maintain text catalogs in the client, this should be fairly straightforward.
This is somewhat obvious, but on both the customer facing side AND the back office side, you should be able to effortlessly switch languages. While this isn't so important for customers, it is invaluable from a backoffice and testing side.

There are several gotchas I've encountered when discussing localization with a vendor. First, they may claim to have "localized", but all they've really done is translate the customer-visible test. Second, error messages, often generate at the applications layer, are missed by the translation effort. Third, translations haven't been done end-to-end such that the backoffice has had all text fully translated as well. All of three of these areas are required for a product to even start to be considered "localized".
Therefore, another way to measure product scalability is how quickly the product can be translated, end-to-end (customer facing to back office).
A subtlty in this area is not just what customers and employees see, but also how they enter data. For example, when a customer enters their stake for a football bet, are you ready to accept numbers both in Western Arabic form (1, 2, 3, ...) and Chinese form ( 一, 二, 三)?
Lastly, in the area translation, you may want to be able to set, easily change, and translate to/from your primary back office language. For example, to save money you may decide your Thai customer support team doesn't need to be bi-lingual. This means that all your customer facing and backoffice system must be in Thai. However, the common corporate language may be English, and all the customer service KPI results must be viewable in English and Thai.

2. Localization and usability
Localization is really much more than just translating text. It is about refactoring your product or service so that it is usable by your target market.
As a first pass on the road to localization, a business will often translate and offer one or more new languages.
The next step is to conduct usability studies to verify that your translations make contextual sense. This will often result in substantially different application UI ("User Interface", e.g., web page) layout changes, different types of help offerings, brand/color changes, and changed emphasize of product features.
Scalability in this area primarily means that the products UI allows for quick and simple changes to how information is presented to your customers and staff. Are the web pages made up of components that can be shuffled about easily? Do the web pages allow for global style changes to be made?
3. Currency
There are many aspects of handling financial accounts in gambling systems. Limiting this post to scalability, a financial system is scalable if it provides the following major features:

• Does the system support any number of different currencies?
• Can a customer select their working currency of choice, that is, the currency used to display all monetary figures to that customer?
  
• Can each discrete customer have multiple financial accounts (e.g., a credit card in USD, a bank account in GBP, and a Neteller account in EUR) each in multiple different currencies?
• Can the system accept and calculate against any number of currency conversion values on a frequent (at least daily) basis?
• Can the system have any number of financial accounts to represent internal operations
• Can the system easily switch between any number of currencies for back office reporting?
  

On the last point, a business will typically select its internal operating currency on a corporate level and work to it. However, for ad-hoc reporting, it is quite convenient to be able to easily switch between currencies for reporting.
---
The above areas are three more points you can use when evaluating gambling platform software vendors, at least if you're interested in adding a second language or currency.

World Poker/Betting Exchange (WSEX) Poker offers 100% rake refund

Sometimes you come across something that is so blatantly silly, you just have to highlight it.

WSEX (World Sports Exchange) has announced that their internet poker room has gone rake free.
Now as far as I know, most businesses and especially most gambling businesses are not generally run as non-profits. In fact, not charging customers a rake for a poker room means that a significant loss will be incurred by the business for poker room operating expenses. Whenever a business (especially a gambling business) makes such an altruistic statement, you can pretty much assume you're being mislead.

There are maybe five possibilities here:

• They really are a lovable bunch of guys running a business they love for a bunch of customers they love, or
• WSEX's sports betting overrounds are so big that they have (their customer's) money to throw at a zero rake model in "we do it because we love our customers" activities, or
• Although WorldPx appears to use proprietary software, perhaps they have found a loophole in their poker software supplier's contract that means if they don't earn any poker revenue, no revenue share goes to the supplier, and they're using zero revenue to pressurize a better deal from the software supplier, or
  
• WSEX poker room is doing poorly and they plan to use zero rake as an marketing loss lead to attract customers to save face, OR
  
• WSEX poker room is doing poorly and they are using a zero rake model long enough to get to a critical mass customer base and will then re-activate commission

If WSEX was serious about a forever zero rake for their loyal customers, they would:

• They would only offer zero rake to their long time loyal customers
• Not heavily advertise the fact they offer zero rake in order to attract new customers
• They would put a "you get zero rake forever" clause in the T&Cs of the game
  
• Not collect the rake in the first place and then redistribute it back to their customers on a weekly basis

Promotional activities are an important part of business. Is this promotion just another thinly veiled and misleading attempt to gain customers? Is it an ego play to address a failing product in any way possible? Or perhaps its a clever publicity play a la Golden Palace. One option I'd guess its not is truth in advertising.