In the 20th century, it was said that, “Content is king.”  Consumers and marketing professionals alike have observed this after years and years of experience with traditional media outlets such as television and print.  Marketing professionals know their message will reach wider, larger audiences when bundled with content that is in high demand by a large and varied group of consumers such as an episode of ABC’s Lost or an issue of the New York Times.  Since there’s good marketing money to be made by producing content that reaches a wide audience, an impetus to increase the quality and value of content was placed on content producers.  The result is (arguably) better television programming, better magazines, and better news papers.  The consumer wins in this situation at the cost of seeing some marketing materials along the way.  Thankfully, humanity didn’t forget who the King was when the 21st century dawned on mankind and ushered with it the internet as a ubiquitous part of our lives!  Competition is so fierce for a consumer’s attention that quality content has become a baseline starting point, and not just something to separate the NBC’s from the CBS’s.  The internet can be like a full cable package:  5,000,000,000,000 channels and nothing’s on.  

The last month has been rife with both speculation and confirmation of the “side projects” the geeks at Google have been focusing on for the balance of 2007. Two big announcements involved new, open source platforms for web development in two of the hottest and fastest-growing arenas in interactive advertising: social media and mobile.

We’ve included a video with WSJ reporter Amol Sharma above. Sharma does a great job of presenting, in layman’s terms, the implications of Google’s newly-announced mobile platform, Android. Android is the real-world version of the heavily rumored “gPhone.” Rather than a hardware device, Google has announced an open-source (and presumably ad-supported) mobile application platform.

Mobile advertising has been a major buzz item in interactive advertising circles for most of 2007, however, it has also mostly failed to live up to the hype surrounding it. U.S. numbers for mobile web access continue to lag far behind Asia and Europe.

While the prospect of a near-universal, open source development platform means that interactive developers have a new foothold in getting their applications onto the mobile web, it doesn’t guarantee that there will be an audience to monetize once they arrive. It also seems unlikely that an influx of new “cool mobile apps” from independent publishers and developers will significantly increase the number of Americans accessing the web via their mobile devices.

However, as is often the case, the saving grace for mobile may be more traditional media channels, most notably the television, film and music industries. If the new Android platform lowers the cost and time-frame for mobile applications enough that these industries begin releasing more highly-sought mobile-only content (such as mobisodes for extremely popular shows Heroes and Lost).

Clients and developers alike are far too familiar with software delivery that works, is on time, and within budget but doesn’t actually solve the problem that the client was trying to solve (http://www.projectcartoon.com/cartoon/2). This situation typically arises from misunderstandings that occur early on in a project through no fault of any one person or any participating organization. These misunderstandings would have been easy to correct for had they been identified early. Project teams spend countless hours communicating with each other in an attempt to have as complete a picture of a project as possible. They begin software architecture and design work now heavy with all this great information, but despite their best intentions, the damage may already be done.

Rather than jumping into all the technical details and intricacies of the project first, planning and design should begin with some good old fashioned journalism. The answers to who, what, where, when, and why will ultimately provide the answer to how.

Who (will be using the software)?
What audience is your software for? Is the software for internal users on your intranet or will it be a customer facing? More often than not, an application for internal use or business partners will be larger to write than one for external users/customers.

What (should be built)?
This question is the one where the misunderstandings typically come from. A client may ask for a fully-integrated B2C communications portlet when what they really needed was a contact form. This question is still very important because the answer to this question was derived from the answer to “Why?” It helps both sides at least start off in the same ballpark as one another.

Where (will the application/web site/software be deployed)?
This is the question that establishes the deployment environment which will dictate how the problem is solved. Answering “where” will determine the following variables:

• Where will the application be hosted?
• What languages are supported?
• What development frameworks can be used?
• What operating system?
• What application server/servers, if any?
• What database server?
• What email server?
• What web server?

When (does it need to be done)?
This answer will determine if a realistic timeline can be established or whether scope must be cut to meet primary goals. What other constraints must be worked in/around/on/under?

Why (are we doing this)?
Finally, we have reached the “y” of the journalism questions world. Without a doubt, this is the most important question! This question transcends “what are we trying to build” because it forces us to identify (in no uncertain terms!) the problem that must be solved. This is absolutely the guiding principle that must be kept in mind by all participants at all times. If things are happening that don’t directly help solve the problem, their value to the project probably needs to be assessed. It was a problem that lead the client to seek help (”People can’t currently see account information when they log in” or “Our web site doesn’t have a pricing tool that would make us competitive”) and it should be the developers’ responsibility to solve that problem. If you can’t say “the problem is solved” at the end of the project, the team likely lost direction, possibly from the very start!

Projects that are completed under budget and early can be failures if they don’t emphatically answer, “YES!” to the “is the problem solved?” question.

How?

Fortunately, we’ve been good stewards of software journalism and have all of the information now to answer this question so that it accomplishes our primary goal of solving the client’s problem. All the answers to Who?, What?, Where?, When?, and Why? provide us with the information necessary to forge ahead towards the successful completion of the project (read: problem solved!)