How can you make money developing IOS games? An informal survey conducted by one developer suggests 'be in the top 10%' 

Owen Goss, an independent video games developer based in Guelph Canada, surveyed 252 developers who created games for Apple's mobile operating system, to find out how much they earned. The survey took place online over seven days. It turned up some interesting results, one of which was that the Pareto principle seems to apply to IOS app revenues; a small number of developers earn a large part of the cash.

One of the great things about being an app developer for Apple's mobile operating system is that the App Store can be used to market your app for you. Millions of App Store users can see it. However, that is also part of the problem: there are many apps to choose from, and it is easy to get lost in the crowd.

On average, games developers make about $165,000 from a title, but here is where statistics can be misleading. That is the mean average. The median splits the developers in half. 50% of developers have made less than $3000 lifetime revenue from the App Store.

The revenue curve is exponential, because the few developers who are most successful make most of the money. Those in the 75th percentile have made roughly $30,000 lifetime revenue from the App Store. The bottom 25% of developers have made less than $200. Those lucky 4% of respondents who are most successful made over $1 million.

Getting into that successful 10% at the top of the pile isn't rocket science, but it isn't easy either. There are some pointers.

Polish your app

the best IOS apps look good. They are shiny, just like the phones they run on. Games are properly play tested, and gameplay is well thought out, so that there is a solid progression throughout the game.

Do your own marketing

Doing your own marketing is also important. Simply relying on being featured in the App Store isn't a realistic business model. Good marketing includes understanding social media and soliciting user feedback.

Don't race to the bottom

There are thousands of apps for the IOS platform, many of them doing almost exactly the same thing. Your app will succeed on its quality. Don't be tempted to rush it out. Concentrate instead on making it better than the others available.

Look for new opportunities

New social media networks and other developments such as Apple's iCloud promise to disrupt games development. These opportunities along with in-app purchases, can be used to maximise your revenue.

Be original

It's hard to find originality in the oversaturated app landscape, but not impossible. Spend more time in conceptualisation, and ensure that your idea stands out from the crowd.

With Apple's iPhone 5 rumoured to be launching next week, this will be a big quarter for games developers. Will you be ready to capitalise on the ongoing success of the platform?

Microsoft's BUILD conference last week was a fascinating event. Of course the headline news was about Windows 8, for which we got the full technical details, or at least most of them, for the first time. There is also a public preview, and I tried out Windows 8 on a high-end Samsung tablet loaned for a few days, then again on a VirtualBox virtual machine after my return to the UK.

Windows 8 will no doubt arrive in a year or so, and we can debate whether it will be a storming success, a dismal failure, or something in between. I think it makes a great tablet operating system, but purely considered as a tablet, it will not be easy for Microsoft to break into the market dominated by Apple's iPad and with Android mopping up most of what remains. The purpose of BUILD was to encourage developers to build apps for the new Metro-style user interface, and if Microsoft can build up a decent range of apps with which to populate its new store, the early Windows 8 tablets will have more chance of success.

It is tempting though to think that this is mainly aimed at consumers, and the fact that the sample Metro apps are mostly games or other trivialities reinforces that impression. Does that mean Windows 8 is insignificant for businesses, or for business software developers?

I do not think so. In fact, the more I reflect on BUILD the more it seems to me a pivotal event not just for Microsoft, but for the IT industry. Here is my reasoning.

First, at BUILD Microsoft made it clear that Windows now has two personalities, built on different programming models and in fact different APIs. The old Windows, now referred to as "desktop", trundles on as before. There are few changes from Windows 7 in the preview build, other than that the Start menu switches you to the new Metro-style user interface, a controversial decision that may become user-configurable in the final release. Yes, Explorer now has a ribbon, the file copy dialog is improved, and I am sure that there will be more small and cosmetic changes to desktop Windows before final release, but they will be minor.

It seems to me that Microsoft itself has now re-positioned desktop Windows as a kind of legacy environment, even though it is the one that most of us are likely to use most of the time. Irrespective of whether Metro-style Windows is a success, the implications of this are huge. After all, Windows still dominates business computing. Yes, Microsoft will still invest in desktop Windows; but the strategy is focused on Metro-style and it is plausible that Microsoft will never now make radical changes or advances on the desktop side.

Second, Metro-style Windows 8 is not just a touch-friendly user interface. It is designed as a client for cloud services. This is most obvious when you realise that Microsoft has not included data providers for local network database servers like SQL Server; you are meant to interact with data via web services. Metro-style apps are isolated from one another, and can only communicate with the file system, outside their own isolated storage, via specified, user-controlled mechanisms called Contracts. Windows 8 shows that Microsoft really is embracing cloud computing, and that may be more significant than the fact that it runs nicely on tablets.

Third, and related, is that Microsoft is locking down Windows, especially in the version for ARM which we did not hear much about at BUILD. If Microsoft gets it right, Windows on an ARM tablet will be equally as secure as an Apple iPad. It is hard to be definitive about this, because the role of desktop Windows in the ARM build has yet to be clarified, but from what I can tell Microsoft plans Windows 8 on ARM as essentially a Metro-style platform, with apps available only through the new Windows Store. If users can only install Metro apps, the entry points for malware are greatly reduced. I suspect that Microsoft also has its eye on Apple-like control and profits from being the only source for Windows 8 apps, with interesting implications for software freedom, at least in the consumer market.

If there is a moment in history when desktop computing became legacy, I suspect BUILD 2011 will be a good candidate.

Finally, note that Microsoft's new Windows Runtime, within its locked-down constraints, looks to me exceptionally well done. Microsoft has achieved security, performance, and support for multiple programming languages including .NET, JavaScript and C/C++. One of its best decisions was to make every API call that might take more then 50ms into an asychronous call, and then to modify the programming languages to make asynchronous programming easier than it has ever been before, via new statements including the "await" keyword in C#.

The Windows desktop will be around forever, and in fact the stability of the platform in terms of forward compatibility has if anything improved, now that we know major changes are unlikely at least until Windows 9 in say 2015, and probably never.

More significant though is that the cloud computing model now has the backing of all the major industry players, even the one with what looks like the most to lose.

CEO Steve Ballmer called Windows 8 Microsoft's "riskiest product bet" and I am inclined to agree.

Project Charters are a way to initiate projects. Sometimes charters are text documents. Sometimes charters are boxes or brochures that "sell" the product's benefits and features to others.

I like text documents as a first draft because they are easy, and are a fast way to bring a team together that has not worked together before. Once a team has worked together, try a box or a brochure. But if you're new, consider a text document.

Especially if you're new to project charters, take a minimalist approach. I like to think, "What's the minimum I can put into this project charter and still make it be enough for this project?" I offer a project charter from Manage It! Your Guide to Modern, Pragmatic Project Management. That charter has these parts:

1. Vision: Concise and compelling idea behind the project
2. Drivers, Constraints, and Floats: What's driving the project, what's constraining the project, and where you have freedom to organize the project as you need.
3. Goals: What you might want to accomplish with the project, but not required that you do so
4. Success Criteria: Capabilities your product will have at the end of the project
5. ROI Estimate: Potential return from your project (only if your organization requires it)

Write your vision with the project team. That way, you can make the project vision compelling to the entire team. If everyone starts yawning as they start writing, you know nothing about the vision is compelling! Ask them, "What do we have to do to make this vision compelling?" Maybe they need to start with objectives, not the vision. That's fine.

When you think about drivers, constraints, and floats, do not think of the iron triangle. There are more than three sides to the iron triangle. You need to consider the organizational constraints: cost, people and their capabilities, technical debt, and the environment of the project. And, you need to consider the specifics of this project: the desired release date, the desired feature set, and the desired defect levels. Only by balancing what's honestly driving the project, what's really constraining the project, and what's really in your degrees of freedom can you make decisions about the project. You might need a project driver matrix to make those decisions.

The team may want some goals for this project, that are separate from the organization's requirements. I often see this when teams want to start paying down some technical debt. "We want to automate 10% of our regression tests."

Success criteria are the capabilities the product will have once the system is done. Knowing what success looks like is a tricky definition. You'll probably use context free questions to define success.

ROI, return on investment is something few of us have to calculate, but if you do, the project charter is the place to put it. Of course, you'll be wrong, but that's ok. (You'll be wrong because it's a prediction based on what the project will cost and how many people will use your results. You cannot know the future! If you do, please go gamble in Vegas.)

The value of the charter is not so much in the text, but in the discussions to create it. Your discussions as a project manager with the team, the team's discussions among itself, the team's discussions with senior management, anyone's discussions about the project driver matrix. The discussions create an atmosphere of teamwork, and create the agreements so people can start.

You may decide that you need a cross between a project charter and a project plan. That's fine. Maybe all you need is a project vision and release criteria. For me, that's the absolute minimum that any project needs. You know where you are going and you know what done means.

The project charter gives you one small way to build a team. Try it.