No Mobile for Multi-Player Poker

July 10th, 2010

Mobile games are the rage. In some jurisdictions, mobile gaming … real money wagering … is hot. Some companies are even working on poker for mobile devices. Not video poker against the house, but real money, multi-player poker. I think that’s nuts!

Let’s review. Real money poker is a time-based, sequential game. You act, and then I have to act. If I don’t act in time, the system acts for me … check or fold. That’s it. Buh-Bye Dan. All-in disconnect protection, where it is available, might help me once or twice if I lose my connection, but abuse of all-in protection has resulted in most sites limiting or not offering it.

Now, put me on a bus or a train. Even in countries with great cellular infrastructure, mobile means connections get weak or completely disrupted. Sure, I can be sitting in a station or at an airport, and a couple hours of poker, playing from my smart phone, might be a great way to spend two hours waiting for a departure. But do I really want to risk being in a big pot, with the nuts, while riding on a bus, train, or in a car? Not me!

I simply don’t see mobile technology as quite ready for a time sensitive, high stakes wagering game. Any gaming where a player has time constraints, and multi-player poker certainly fits that description, is not a good candidate for mobile devices at this stage of the technology.

Any gaming company that rolls out real money multi-player poker on mobile devices would be wise to cap the stakes and to avoid pot limit and no limit varieties. Yes, even multi-table tournaments, where the prize pool could be large, are unwise for mobile device access. Pity the customer service representative who has to deal with a player using a mobile device who got folded at a critical point because of a loss of signal. This could make dial up seem downright reliable in comparison under some conditions.

Setting aside tablet devices, most mobile devices have fairly small screens. Touch technology allows for easy to use user interfaces. But consider the perils of designing a poker table interface for a mobile device. Put the fold, check, and raise buttons too close to one another, and add in a few untimely bumps in the road, or poorly steered piece of luggage as the player acts, and the wrong action could be selected. Sure, the GUI designer could add an “are you sure” step for all critical decisions, but that would take away from the flow of the game, and slow the player’s response.

Call me conservative, but I just don’t see mobile and real money multi-player poker as a happy marriage.

And Now For Something Completely Different – www.GreenMonsterPromos.com

June 18th, 2010

I am pleased to announce the launch of an e-commerce site for customizable promotional products, www.GreenMonsterPromos.com, with which I am associated. Read the rest of this entry »

Zynga is Hedging its Bet on Facebook

May 9th, 2010

Recent reports are that the company that built its fortune putting games on the Facebook platform, Zynga, is moving to lay the groundwork to move away from its dependence on that platform.  Zynga is supposedly working to launch Zynga Live, a web-based platform that doesn’t require complete dependence on Facebook.

Word is that Facebook and Zynga are on the outs, as Facebook is trying to monetize its own platform.  As I wrote in a prior post, betting a business on the ability to access or leverage another company’s business carries risk.  Just how much risk is going to vary by the situation but the principals of any business that is dependent on another business must be cognizant of the risk factors, and should re-evaluate regularly.

If a company can execute crisply and take advantage of an opportunity built on another company’s platform, and is confident that the short term ROI is sufficient to go forward, then there is nothing wrong with building such a business.  The problem I see comes when the time frame for sufficient return on investment extends too far out into the future.  The longer a business is dependent on another’s, the higher the risk that a change in the relationship could bring the dependent business to an end before it gets the required return.

My take-away is that one must craft a solid plan that reflects an understanding of investment and expected returns, and that supports effective implementation.  Dithering will only decrease the likelihood of success.

Copyright 2010 Project Management Consulting

What Is Important When Outsourcing Offshore?

February 25th, 2010

Recently, I saw the question, “To what country would you recommend outsourcing an IT project?” When thinking about outsourcing offshore, that is the wrong question!

Regardless of the country, when you outsource at the project level, you must remain engaged with the project and the implementation team. I  recommend some form of Agile approach in that you should require numerous short term deliverables  demonstrating the team is moving the project in the direction you intended. Set up regular conference calls so you can ask questions and the team can ask you questions. Approach it like a virtual scrum. Read the rest of this entry »

Betting Your Business on the Back of Another Company

February 21st, 2010

The world is full of very successful businesses that have been built by tapping into a market created by a different business. What are the risks of building a business on the back of another company’s success?

Stepping outside technology for just a moment, consider that many baseball stadiums of lore were in urban neighborhoods. And many still are. Around those stadiums are bars, restaurants, parking lots, and other businesses that thrive largely because of the crowds (okay, some teams are too pathetic to draw large crowds but this is just an example) that attend 81 regular season home games. Now consider what happens when the team is moved to another city, or builds a new ballpark in another location. Ouch, there goes a micro-economy.

Now back to the tech sector. How many apps are being built to run on the iPhone? How many businesses are thriving because of Facebook? It seems to me there are few, if any, risk mitigation strategies open to companies totally reliant on either or both Facebook and the iPhone app store. Read the rest of this entry »

Should Project Managers Step into the Code?

February 16th, 2010

I recently heard a conversation around the question, should project managers step in and help code? My answer is, in most cases, “NO!” Read the rest of this entry »

Multiplayer Game Models

November 8th, 2009

The term, multiplayer games, includes a range of back-end game server (defined below) complexities.  This post outlines the different types of multiplayer game models.

For purposes of this document:

  • Multiplayer game means any game where more than one player is involved in some form of competitive play, or non-competitive, interactive play (such as in Second Life). Read the rest of this entry »

Dan on Gaming and Games on the Internet

November 8th, 2009

With eight (8) years now in the Internet games and gaming space, I am expanding my blogging to include periodic discussions on topics related to Internet based games and gaming. Potential topics include games themselves, game and gaming models (including real money, social, casual, skill, etc.), software development for games, finding game development vendors, licensing models, and probably any number of other topics.

I’m Still Blogging

October 30th, 2009

I am still blogging but these days, you are more likely to see my posts appear at:
www.D2MConsulting.com
where I am a partner. I encourage you to visit that site.

D2M Consulting, LLC is a company I formed with two partners, Dave Arfine and Matt Harriton.  We provide start-up and small companies with a range of supporting consulting services including strategic financial planning, direct marketing, Internet marketing, e-commerce, business process improvements, software related advice, and project management.  You can see our full range of capabilities on the D2M web site capabilities page.

Thanks!

The Only Constant is Change

May 26th, 2009

The project manager’s job is to buffer the project team from the vagaries of change, but that said, it is essential to recognize that change is constant. It is the rare project that runs from start to completion without change. Thus, the successful project will be executed by a team, and led by a project manager capable of adapting to change.

Change can come from any quarter. Most frequently project changes stem from new or modified requirements. With some process appropriate to the size of the project and the culture of the shop, requirements changes can be managed. But change is sneaky. It may well come from an unanticipated direction. A very limited list of possible sources of change includes: staffing change (resignation, promotion, reassignment, illness, etc.), budget change (sadly, usually downwards), corporate reorganization (mergers and acquisitions included here), competitive situations, sales (see the blog entry on chasing the next sale), loss of the key customer for this project, partner relationship changes, vendor changes, changing deadlines, and pure corporate politics.

How does a project manager deal with change? When does the project manager inform the team and when should such information be withheld? When does the project manager inform upper management of project changes as opposed to managing against them? There is no definitive answer to these questions. On highly complex projects with rigorous, published tracking metrics, change often needs to be addressed head on and openly, early. On smaller, more contained projects it may make sense to buffer a manageable change. Corporate culture and management style also play a pivotal role in how change should be handled, as do the extent and immediacy of impact of the change.

Project managers who work for me get significant latitude. My management style gives the project manager a clear objective, an understanding of the strategy the project fits within, and the charter to manage to success as she or he sees fit. I expect to be informed of problems that cannot be solved within the project and that require my support. I expect to learn about significant changes of schedule. I encourage project managers to work through problems that are addressable and to seek support where they are not. I tell both project managers and development teams who work for me that, above all, I don’t like surprises that come up too late to be addressed. Experience as a project manager, and the experience the project manager has with the current team play a large role in when a project manager needs to raise a flag.

From the other direction, I may learn of a change of priorities that impacts one or more project teams. My job, managing a team of project managers, is to ensure timely communications where appropriate. For example, a major new customer has signed an agreement. The schedule to bring that customer online requires resources currently committed to other projects. Working with other senior managers, priorities and schedules must be evaluated in order to free the appropriate resources. In some cases, resources may be needed from multiple teams … it’s rare that one lower priority project is staffed by a team appropriate to the new customer project. Senior management’s role is to support the decision process for adjusting priorities and schedules. The project / program management team must implement the changes dictated by reallocating resources, adjusting schedules, and ensuring that work in progress that is to be deferred gets properly parked. For example, code is documented and saved to a recoverable configuration, development and test systems are properly backed up before being reallocated, design and code artifacts are saved with sufficient documentation detail to recover when the project is resumed, and test plans are similarly preserved.

Of course, this kind of change leads to the inefficiencies of context switching (see the note, “Flail Leads to Fail”) and can be dispiriting for the team members affected. It is in such situations that the project / program manager must ensure the affected team(s) have sufficient information regarding the reasons for the change to understand. At such times, I remind team members of my mantra: the only constant is change.