After some reflection, I realized that there are seven questions that need to be asked before you start on any project. While you may ask yourself a subset of these questions, it is critical to answer (or at least think) about all of them before writing a line of code.
Each of these questions has a direct impact on how the project can be engineered and what tools and techniques you use to engineer it.
1) “Problem?”
That is, the need are you trying to fill. Are you trying to save people a few minutes when typing of a document? Are you making a user interface easier to use? Are you providing control software for life support on Mars? Are you trying to give a bored person something to do for ten minutes?
Starting with a solution statement is almost always a recipe for disaster. Find out what the problem is that needs fixing first before committing to a solution. I have found that by asking what the problem is that actually needs solving, you can radically reduce the complexity of the answer.
2) “Target audience?”
Who are you trying to solve the problem for? Are you trying to solve the problem for your coworkers? For ten million people? For a surgeon in the middle of surgery?
Who your target audience is helps to determine how much polish you need to put on the product. A solution that is acceptable for your coworkers is going to require a lot less work than something to be used by a surgeon. (Unless, of course, you work in a hospital!)
3) “Time to market?”
Simply put, how long you have before the solution needs to be in place. Today? A week? Six months?
The solution to a problem that needs to be solved today is inherently more limited than one that can be solved by next week or next year. Sometimes a problem can’t be solved in its original form in the time frame required. In that case, you need to reduce the scope of the problem or increase the time frame.
4) “Headcount?”
The more people working on a problem, the larger the scope that you can handle. More people also means more communication, more up-front design, and more time needed to handle changes down the line.
5) “Budget?”
Budget can refer to both money as well as (existing) equipment and tools. If you have adequate equipment, you may not need a monetary budget over what is currently allocated. Sometimes, having a monetary budget means you can buy a solution off the shelf and reduce your overall time and effort to solve.
6) “Licensing?”
This means how are you going to sell — or not — the final solution. If you are solving a need for existing customers, is it part of a patch to the existing version or is it to be released in the next major version? Are you giving it away? Are you going to be using a pay-per-use model?
A solution for one licensing model may not work for another. It’s important to be clear up front what you’re going to do so that you don’t end up wasting everyone’s time.
7) “Return On Investment?”
This is perhaps the most open-ended of all of these questions. In a nutshell, how much value will this project give to you and your target audience — is it something that will save some infrequent annoyance, or is it something that will transform lives? The more impact it will have translates directly into how much more you can invest before hitting the break even point.