Briefly describe how the need for this project arose and was recognized. This helps motivate the product, put it into the context of the overall business, and can help identify project stakeholders.
Use 2-4 sentences to describe the problem that your potential users are having right now. Focus on business problems, not technical problems. If you are trying to solve a technical problem, describe the business need that makes that technical problem important enough to solve. Do not say anything about your solution here.
List some of the alternatives that your potential customers have now. Listing these now will help set requirements for your product to be better than these alternatives, and it will help identify the expectations of potential customers that have already been using the alternatives.
Explain why a better product would matter to customers or project stakeholders. Your argument would ideally impact business metrics such as profit, costs, revenue, sales, time-to-market, brand value, size of customer base, or return on investment.
Describe how this product will actually be better than the current alternatives. This may be due to better functionality ("defining features" are covered below), or other aspects of the product that make it easier to buy, install, or use.
Link to more information on the problem that customers face. Is this problem growing? Is the problem big enough to create enough demand for the product? These documents should support the decision to authorize the project by explaining the need.
Write 2-4 sentences or bullets on your main goal for the project. Briefly, name your target audience and mention key benefits that your customers will gain by using your product.
Briefly list the most important features of the product. It is alright to reiterate features found in the alternative products, but focus on the unique features that will set this product apart.
If you have other documents that support this project proposal, link to them from here. These documents should support the decision to authorize the project by explaining the value of the proposed solution.
There are several useful formats for explaining the scope of a proposed project. A good scope description provides insight into the resources that may be needed for the project and helps you avoid feature creep later.
The simplest format is just a paragraph: give 2-4 sentences that summarize what you intend to do as part of this project. It is often a good idea to explicitly state some things that will not be done.
The third and best format is a table with columns that list things that are in scope and out of scope. Each row of the table defines a direction, the first column says how far you plan to go in that direction, and the second column names something that is too far in that direction.
Briefly list the deliverables in enough detail to support the decision to authorize the project. You can describe deliverables in more detail in the project plan.
Briefly list risks to the success of the project and the main rewards to the organization if the project succeeds. Include enough information to support the decision whether to authorize the project. Later, you can describe and track project risks in more detail in the risk management worksheet.
