All artists begin with preliminary sketches. You too need to begin with an outline plan. A good way to tackle this is to break the project down into four bite-size pieces.
1. The reason for being—Why the product should exist.
2. The business rationale—Who wants it? What do they want it to do? How many will buy it? How much will they pay? How long will the product last? What side benefits, in terms of deliverables and so on, are there?
3. The mechanics—The architecture and main components. How will they link? What snags are foreseen? How to stop and start the program.
4. The presentation—The way that screens will work. The face of the product. Its name, packaging, and support material.
You can then begin to flesh out your skeleton:
♦ The reason for being
• What the market is looking for and why
• What the product offers
• The product's development title
• Why there isn't any direct competition
♦ The business rationale
• The group(s) at whom the product is aimed
• What they are prepared to pay
• How it surpasses alternative products
• The ceiling of development costs
• How this breaks down into overheads, salaries, bought-ins, and third-party workers' time
• The price range allotted for these
• The number of units that have to be shipped (in the first six months or a year)
• How they will be distributed
• How they will be promoted
• Cost of production broken down by overheads, materials, labor, and so on
♦ The mechanics
• What the program does and how it does it
• The operating system(s) the program will work on
• Minimum hardware requirements
• Environmental constraints
♦ The presentation
• The product name, technical description, and logo
• Product attributes the program must have
• What the program has to be seen to do to deliver these attributes
• The User Interface, how it looks and how it responds
• Advanced Programming Interface (API), if appropriate
• The startup sequence
• How the screens will perform
• How the session will close
• The deliverables—the product labels, packaging, manuals, Help system, discs, downloads, and so on
It should come as no shock to you that most of these questions will have already been supplied by your initial market research. The main task of planning is to bring together everything that the team believes from experience needs to be done to create a sellable product. In the process of fleshing out your plan you will find yourself sorting out priorities and finding ways around pitfalls.
So that everyone on the team knows what they have to do, you should draft your plan in a development plan. A development plan is not the same thing as a list of software requirements. The spec is about what; the development plan begins to focus on the how.
With a coherent development plan everyone should begin to get an overall picture of the project in a single comprehensive document.
Note |f you need to exclude sensitive areas such as financial details from some copies of the development plan, just remove them.
Let's now take a closer look, from your customer's point of view.
Was this article helpful?