Merge branch 'master' of github.com:bike-bill/readyset-gfm.wiki
This commit is contained in:
commit
b478879c2f
57
Words-of-Wisdom-Proposal.md
Normal file
57
Words-of-Wisdom-Proposal.md
Normal file
@ -0,0 +1,57 @@
|
|||||||
|
# Proposal
|
||||||
|
|
||||||
|
## Line-by-line Instructions
|
||||||
|
|
||||||
|
### Project
|
||||||
|
Write the name of the proposed project.
|
||||||
|
|
||||||
|
### Project Time-frame
|
||||||
|
Write the proposed project start and end dates. This information will usually be appoximate.
|
||||||
|
|
||||||
|
### Summary
|
||||||
|
Write an executive summary of the proposed project. It is usually best to write the proposal first and then write the highlights here.
|
||||||
|
|
||||||
|
### What is the setting and history behind this project?
|
||||||
|
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.
|
||||||
|
|
||||||
|
### What business problem does this project address?
|
||||||
|
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.
|
||||||
|
|
||||||
|
### What are some current approaches to this problem?
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Why is this problem worth solving or worth solving better?
|
||||||
|
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.
|
||||||
|
|
||||||
|
### How will this product be better than previous approaches?
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Where is there more information on this problem?
|
||||||
|
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.
|
||||||
|
|
||||||
|
### What is the goal of this project?
|
||||||
|
Write 2-4 sentences or bullets on your main goal for the project. Briefly, name your target audiance and mention key benefits that your customers will gain by using your product.
|
||||||
|
|
||||||
|
### What are the defining features and benefits of this 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.
|
||||||
|
|
||||||
|
### Where are other documents that further explain the goal of this project?
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Scope
|
||||||
|
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.
|
||||||
|
|
||||||
|
Another way to document the scope of a project is to use two bullet lists: one for things that are in scope, and one for things that are out of scope.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Deliverables
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Risks and Rewards
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Project Plan
|
||||||
|
Link to a draft of the project plan.
|
71
Words-of-Wisdom.md
Normal file
71
Words-of-Wisdom.md
Normal file
@ -0,0 +1,71 @@
|
|||||||
|
The original [ReadySET Pro](http://readysetpro.com) words of wisdom are [here](http://www.readysetpro.com/words-of-wisdom).
|
||||||
|
|
||||||
|
# Template List
|
||||||
|
|
||||||
|
***
|
||||||
|
|
||||||
|
The following pages contain specific tips and advice on each template.
|
||||||
|
|
||||||
|
## Project kick-off
|
||||||
|
|
||||||
|
* [Project proposal](Words-of-Wisdom-Proposal)
|
||||||
|
* Target audience & benefits
|
||||||
|
* User needs & stories
|
||||||
|
* Interview notes
|
||||||
|
* All-in-one project summary
|
||||||
|
|
||||||
|
## Project Reference Information
|
||||||
|
|
||||||
|
* Project overview
|
||||||
|
* Glossary / Data dictionary
|
||||||
|
* Software development method
|
||||||
|
|
||||||
|
## System requirements
|
||||||
|
|
||||||
|
* SRS
|
||||||
|
* Use case suite
|
||||||
|
* Feature set
|
||||||
|
|
||||||
|
## Planning
|
||||||
|
|
||||||
|
* Project plan
|
||||||
|
* Resource needs
|
||||||
|
* Risk management
|
||||||
|
* Legal issues
|
||||||
|
|
||||||
|
## Design
|
||||||
|
|
||||||
|
* Design overview
|
||||||
|
* Architecture
|
||||||
|
* Persistence
|
||||||
|
* User interface
|
||||||
|
* Security
|
||||||
|
* Source organization
|
||||||
|
|
||||||
|
## Project tracking
|
||||||
|
|
||||||
|
* Status report
|
||||||
|
* Review meeting
|
||||||
|
|
||||||
|
## Quality management
|
||||||
|
|
||||||
|
* QA plan
|
||||||
|
* Test suite
|
||||||
|
* Test run log
|
||||||
|
|
||||||
|
## Product content
|
||||||
|
|
||||||
|
* Release notes
|
||||||
|
* Installation / Quick-start
|
||||||
|
* User Guide
|
||||||
|
* FAQ / Troubleshooting
|
||||||
|
|
||||||
|
## Product support information
|
||||||
|
|
||||||
|
* Implementation notes
|
||||||
|
* Demo script
|
||||||
|
|
||||||
|
## Release end-game
|
||||||
|
|
||||||
|
* Release checklist
|
||||||
|
* Postmortem report
|
@ -1,3 +1,5 @@
|
|||||||
|
**TODO:** Check for [words of wisdom](Words-of-Wisdom) for additional advice on this template.
|
||||||
|
|
||||||
::**Your-Organization Proprietary**
|
::**Your-Organization Proprietary**
|
||||||
|
|
||||||
Copyright 2003-2004 Jason Robbins. All rights reserved. [License terms](LICENSE). Retain this copyright statement whenever this file is used as a template.
|
Copyright 2003-2004 Jason Robbins. All rights reserved. [License terms](LICENSE). Retain this copyright statement whenever this file is used as a template.
|
||||||
|
@ -1,4 +1,5 @@
|
|||||||
* [Home](Home)
|
* [Home](Home)
|
||||||
* [Summary](Summary)
|
* [Summary](Summary)
|
||||||
* [Project Plan](Project-Plan)
|
* [Project Plan](Project-Plan)
|
||||||
* [Workflows](Workflows)
|
* [Workflows](Workflows)
|
||||||
|
* [Words of Wisdom](Words-of-Wisdom)
|
Loading…
Reference in New Issue
Block a user