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!)