Project docs
This document will attempt to define the bare minimum documentation required management of the POC, Dev and Production processes
Contents
POC stage (Proof of concept)
Feasibility Report
- Major task requirements
- Is the POC feasible?
- Technology
- Economic
- Legal
- Operational
- Schedule
- Market
- Resource
- Culture
- Financial
Project Charter
- Stakeholders: (These can be minimized.)
- Purpose statement
- Bailout plan
- Pass/Fail criteria
- Resources
Process docs
- Collect docs and web sites used as technical authorities
- Document deviations from authoritative sources
- Document observations:
- Diffs from specs
- Faults in functionality
- Lessons learned
- Installation notes
Final report
- Pass/Fail
Handoff to dev/ Dev kickoff
Stakeholder handoff - Dev engineers know who has been involved, who needs to be involved. Devs examine POC docs for completeness and understanding. POC engineers are available for questioning concerning scope of POC so a gap analysis may be done. Requirement Specification
A requirement specification document is a complete description of the system to be developed. It contains all interactions the users will have with the system along with the non-functional requirements.
Design Document
The design document showcases the high or low-level design components of the system. The design document used for high-level design gradually evolves to include low-level design details. This document describes the architectural strategies of the system.
Work Plan/Estimate
A work plan sets out the phases, activities and tasks needed to deliver a project. The timeframes required to deliver a project, along with the resources and milestones are also shown in a work plan. The work plan is referred to constantly throughout the project. Actual progress is reviewed on a daily basis against the stated plan. It is therefore the most critical document to deliver projects successfully.
Traceability Matrix
A traceability matrix is a table that traces a requirement to the tests that are needed to verify that the requirement is fulfilled. A good traceability matrix will provide backward and forward traceability: a requirement can be traced to a test and a test to a requirement.
Issue Tracker
An issue tracker manages and maintains list of issues. It helps add issues, assign them to people, and track the status as well as current responsibilities. It also helps develop a knowledge base to contain information on resolutions to common problems.
Change Management Document
A change management document is used to capture progress and to record all changes made to a system. This helps in linking unanticipated adverse effects of a change.
Test Document
A test document includes test plan and test cases. A test case is a detailed procedure that fully tests a feature or an aspect of a feature. While a test plan describes what to test, a test case describes how to perform a particular test.
Technical Document
Technical document includes product definition and specification, design, manufacturing/development, quality assurance, product/system liability, product presentation, description of features, functions and interfaces, safe and correct use, service and repair of a technical product as well as its safe disposal.
Functional Document
Functional specifications define the inner workings of the proposed system. It does not include the specification how the system function will be implemented. Instead, it focuses on what various other agents (people/computer) might observe when interacting with the system.
User Manual
User Manual is the standard operating procedure for the system.
Transition/Rollout Plan
The rollout plan includes detailed instructions on how to implement the system in an organization. It includes the schematic planning of the rollout steps and phases. It also describes the training plan for the system.
Handover Document
Handover document is a synopsis of the system with a listing of all the deliverables of the system.
Contract Closure
Contract closure refers to the process of completing all tasks and terms that are mentioned as deliverable and outstanding on the initial drafting of the contract. This is only applicable in case of outsourced projects.
Lessons Learned
Lessons learned are used at midpoints of the project and at project completion to catalog significant new understandings that have evolved as a result of the project. They are used to build the knowledge base of the organization and to establish a history of best and worse practices in project implementation and customer relation.
Project Charter
Project Charter is sometimes also known as the Project Overview Statement. A project charter includes high-level planning components of a project. This lays the foundation of the project. It acts as an anchor, holding you to the project's objectives and guides you as a navigator, through the milestones. It is a formal approval of the project.
Requirement Specification
A requirement specification document is a complete description of the system to be developed. It contains all interactions the users will have with the system along with the non-functional requirements.
Design Document
The design document showcases the high or low-level design components of the system. The design document used for high-level design gradually evolves to include low-level design details. This document describes the architectural strategies of the system.
Work Plan/Estimate
A work plan sets out the phases, activities and tasks needed to deliver a project. The timeframes required to deliver a project, along with the resources and milestones are also shown in a work plan. The work plan is referred to constantly throughout the project. Actual progress is reviewed on a daily basis against the stated plan. It is therefore the most critical document to deliver projects successfully.
Traceability Matrix
A traceability matrix is a table that traces a requirement to the tests that are needed to verify that the requirement is fulfilled. A good traceability matrix will provide backward and forward traceability: a requirement can be traced to a test and a test to a requirement.
Issue Tracker
An issue tracker manages and maintains list of issues. It helps add issues, assign them to people, and track the status as well as current responsibilities. It also helps develop a knowledge base to contain information on resolutions to common problems.
Change Management Document
A change management document is used to capture progress and to record all changes made to a system. This helps in linking unanticipated adverse effects of a change.
Test Document
A test document includes test plan and test cases. A test case is a detailed procedure that fully tests a feature or an aspect of a feature. While a test plan describes what to test, a test case describes how to perform a particular test.
Technical Document
Technical document includes product definition and specification, design, manufacturing/development, quality assurance, product/system liability, product presentation, description of features, functions and interfaces, safe and correct use, service and repair of a technical product as well as its safe disposal.
Functional Document
Functional specifications define the inner workings of the proposed system. It does not include the specification how the system function will be implemented. Instead, it focuses on what various other agents (people/computer) might observe when interacting with the system.
User Manual
User Manual is the standard operating procedure for the system.
Transition/Rollout Plan
The rollout plan includes detailed instructions on how to implement the system in an organization. It includes the schematic planning of the rollout steps and phases. It also describes the training plan for the system.
Handover Document
Handover document is a synopsis of the system with a listing of all the deliverables of the system.
Contract Closure
Contract closure refers to the process of completing all tasks and terms that are mentioned as deliverable and outstanding on the initial drafting of the contract. This is only applicable in case of outsourced projects.
Lessons Learned
Lessons learned are used at midpoints of the project and at project completion to catalog significant new understandings that have evolved as a result of the project. They are used to build the knowledge base of the organization and to establish a history of best and worse practices in project implementation and customer relation.
