├── LICENSE ├── README.md ├── general-business ├── README.md ├── basic-nda.docx ├── basic-nda.md ├── request-for-information.docx ├── request-for-information.md ├── statement-of-work.docx └── statement-of-work.md └── project-management ├── README.md ├── project-charter.docx ├── project-charter.md ├── project-post-mortem-meeting-guidelines.docx ├── project-post-mortem-meeting-guidelines.md ├── project-post-mortem.docx ├── project-post-mortem.md ├── requirements-capture.docx ├── requirements-capture.md ├── risk-register.docx ├── risk-register.md └── risk-register.xlsx /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2015 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Open Sourced Document Templates 2 | 3 | Free, best practice document templates as used in Documize. 4 | 5 | ##General Business 6 | 7 | [Statement of Work](general-business/statement-of-work.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/general-business/statement-of-work.docx) 8 | 9 | [Non Disclosure Agreement](general-business/basic-nda.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/general-business/basic-nda.docx) 10 | 11 | [Request For Information](general-business/request-for-information.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/general-business/request-for-information.docx) 12 | 13 | ## Project Management 14 | 15 | Capture business requirements for a sizeable project where you need to involve multiple stakeholders. 16 | 17 | [Project Charter](project-management/project-charter.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/project-charter.docx) 18 | 19 | [Project Post Mortem](project-management/project-post-mortem.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/project-post-mortem.docx) 20 | 21 | [Project Post Mortem Meeting Guidelines](project-management/project-post-mortem-meeting-guidelines.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/project-post-mortem-meeting-guidelines.docx) 22 | 23 | [Requirements Capture](project-management/requirements-capture.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/requirements-capture.docx) 24 | 25 | [Risk Register document](project-management/risk-register.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/risk-register.docx) [(XLSX)](https://github.com/Documize/document-templates/blob/master/project-management/risk-register.xlsx?raw=true) 26 | 27 | 28 | -------------------------------------------------------------------------------- /general-business/README.md: -------------------------------------------------------------------------------- 1 | # General Business Templates 2 | 3 | Free, best practice document templates as used in [Documize](https://documize.com). 4 | 5 | Just download the .DOCX file or click on the .MD file for a preview. 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /general-business/basic-nda.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/general-business/basic-nda.docx -------------------------------------------------------------------------------- /general-business/basic-nda.md: -------------------------------------------------------------------------------- 1 | #Non-Disclosure Agreement IN CONSIDERATION of [Entity Name] providing to the Recipient, Proprietary Information relating to its business, including information of a confidential nature, the Recipient undertakes to [EntityName] in the following terms: ##1. DEFINITIONS For the purposes of this Agreement the following words shall, save as otherwise expressly provided, have the following meanings: 2 | i) [Entity Name] means Proprietary Information belonging to [Entity/Entity Name] whose registered office or usual place of business is at [Entity Address]. 3 | ii) 'the Recipient' (also ‘The Recipient’) means [Recipient Name] whose registered office or usual place of business is at [Recipient Address]. 4 | 5 | iii) 'Proprietary Information' means information relating to products and technology contained in but not limited to documents, drawings, models, photographs and sketches. ##2. CONFIDENTIALITY **A.** The Recipient undertakes *i)* to maintain in strict confidence and secrecy and with the same degree of care that the Recipient uses to maintain its own proprietary Information all Proprietary Information of [Entity Name] that it receives. *ii)* not to disclose or publish such Proprietary Information directly or indirectly to any other person firm or corporation and the Recipient further agrees to disclose the Proprietary Information only to those of their employees to whom it is essential to disclose the same (and to require all such employees to sign undertakings in [Entity Name’s] favour to observe these terms). 6 | **B.** The Recipient will procure that any of their subsidiary or associated companies to whom any of the Proprietary Information is disclosed shall be subject to the same duty of care in respect of such Proprietary Information. **C.** The Recipient will take all reasonable steps to ensure that all employees to whom it discloses information under sub-clause A hereof keep the knowledge imparted to them secret and confidential and in the event of any failure on the part of any employee so to do shall take all reasonable steps or such action as [Entity Name] may reasonably require to rectify or to ensure the rectification of such failure so far as such failure is capable of rectification. **D.** Nothing contained herein shall be construed to impose a confidentiality obligation in respect of: *i)* any matter appearing in public literature or otherwise within the public domain unless the entry of information in the public domain is as a result of a breach of any of the conditions contained herein or in any other agreement made between the Recipient and [Entity Name] by one of the parties hereto; or *ii)* any information or knowledge possessed by the party prior to disclosure to it by the other or rightfully acquired from sources other than the other party; or *iii)* any information or knowledge acquired in a bona fide arm's length transaction by the party making the disclosure. ##3. COPYRIGHT **A.** The Recipient acknowledges that it owns no copyright or other intellectual property whatsoever in any of the Proprietary Information. **B.** The Recipient will not delete Proprietary Information copyright or trade mark notices (if any) appearing on any document relating to the Proprietary Information supplied to it by [Entity Name] at any time. 7 | **C.** The Recipient will not and will use its best endeavours to ensure that its employees will not make copies in whole or in part of any Proprietary Information or any other material provided or in any way obtainable in eye-readable or machine-readable form without the prior written authority of [Entity Name] and then only for the Recipients own use and ownership of such copies shall vest in [Entity Name]. ##4. ORAL COMMUNICATIONS **A.** Oral communications identified at the time of disclosure as Proprietary Information shall be protected according to the terms hereof provided that the disclosing party confirms in writing to the receiving party the Proprietary nature of the said communication within [Agreed period e.g. 7 calendar days]. 8 | **B.** All Proprietary Information delivered by one party to the other pursuant to the agreement shall be and remain the property of [Entity Name] and all written data and any copies thereof shall be promptly returned upon written request, or destroyed at [Entity Name’s] option at any time before or after the termination of this Undertaking for any reason. ##5. INDEMNITY The Recipient shall indemnify and keep [Entity Name] harmless in respect of any losses costs claims demands and expenses of whatever nature arising as a result of a breach by the Recipient or its employees or a subsidiary or associated company of any of the provisions of this Agreement including without prejudice to the generality of the forgoing legal and other fees incurred by [Entity Name] in enforcing such obligations ##6. LIABILITY **A.** It is understood by the Recipient that the proprietary Information may relate to products or services that are under development or planned for development. [Entity Name] makes no warranties regarding the accuracy of this information. [Entity Name] accepts no responsibility for any expenses, losses or action incurred or undertaken by the Recipient as a result of the receipt of this information. It is further understood by the Recipient that [Entity Name] does not warrant or represent that it will introduce any product or service to which the Proprietary Information disclosed herein is related. 9 | **B.** Subject to the provisions of Sub-clause C of this Clause the liability of [Entity Name] under this Agreement for loss or damage including consequential or indirect loss or damage to the Recipient shall in no circumstances whatsoever exceed the total of any payments made by the Recipient hereunder or under the relevant Specific Agreement during the three years immediately prior to notification of any claim whether such liability arises *i)* in contract or *ii)* in tort or *iii)* for negligence or *iv)* for misrepresentation or *v)* for term of this Agreement or the relevant Specific Agreement 10 | **C.** The limitation of liability referred to in Sub-clause B of this clause shall not apply so as to restrict [Entity Name’s] liability for death or personal injury resulting from [Entity Name’s] negligence ##7. DURATION This Agreement shall take effect as from [Start date in dd-mon-yyyy format] and shall continue for a period of [duration of agreement] unless terminated earlier by [Entity Name] giving the Recipient not less than [Notice Period for termination]. ##8. CONTINUING OBLIGATIONS Termination of this Agreement shall not relieve the Recipient from its continuing obligations under this Agreement to protect, safeguard and preserve Proprietary Information disclosed hereunder, which shall survive and continue in full force and effect ##9. ENTIRE UNDERSTANDING This Agreement contains the entire understanding relative to the protection of [Entity Name’s] Proprietary Information and supersedes all prior undertakings whether written or verbal between [Entity Name] and the Recipient and/or a subsidiary or associated company of the Recipient ##10. UNENFORCABILITY Should any provision of this Agreement be determined to be unenforceable or prohibited by any applicable law or treaty, this Agreement shall be considered severable as to such provision, which shall then be inoperative, but the remaining provisions shall be valid and binding ##11. NOTICE Any notice to be given hereunder shall be in writing and shall be delivered or sent by post to the relevant party at its registered or principal office or usual place of business and shall be deemed to have been given in the case of a notice which is delivered by hand when it is deposited at the appropriate address in the case of a notice sent by post forty-eight hours after the date on which a first class registered letter including such notice is posted ##12. JURISDICTION This Agreement shall be governed and construed and interpreted according to the [geographical jurisdiction under which this applies] and both [Entity Name] and the Recipient submit to the jurisdiction of the [legal body and/or arbitration body for the named jurisdiction] ###Signed for and on behalf of 11 | For [Entity Name] 12 | 13 | **Full Name** ............................................................................... **Title**.......................................................................................... 14 | 15 | **Signature**................................................................................. 16 | 17 | **Date**.......................................................................................... For [Recipient] 18 | 19 | **Full Name** ............................................................................... **Title**.......................................................................................... 20 | 21 | **Signature**................................................................................. 22 | 23 | **Date**.......................................................................................... *[it is advisable to specify dates in dd-mon-yyyy format, which is the international standard]* -------------------------------------------------------------------------------- /general-business/request-for-information.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/general-business/request-for-information.docx -------------------------------------------------------------------------------- /general-business/request-for-information.md: -------------------------------------------------------------------------------- 1 | #Request for Information (RFI) ###[YOUR COMPANY NAME] For the Provision of ###[Product/Service Description] From ###[RECIPIENT COMPANY NAME] Document Issued: *Note:* *Responses to this Request for Information (RFI) should be sent by email to [your email address] and received no later than [final submission date]* **recommend you use the international dd-mon-yyyy format for all dates** ##Confidentiality The information in this RFI is issued in strict confidence and you may not disclose or publish the information in this RFI to any other person firm or corporation. You should also disclose the Information in this RFI only to those of your employees and/or agents and/or affiliated companies to whom it is essential to disclose the same for the purpose of responding to this RFI (and to require all such persons to sign to observe the confidentiality of this document). 2 | ##Introduction State the purpose of the RFI. For example: *“[YOUR COMPANY NAME] requests information regarding your company and your products/services. Identical information will be gathered from different companies and will be used to evaluate the potential suppliers with whom we intend to subsequently transact. We will follow up the RFI process with a Request for Pricing within [TIME PERIOD] days of the final date by which all responses must be received. If you have not heard from us within 7 days from that date you may assume that your company has not been selected to proceed further in the process. We thank you for your time and diligence in responding to this RFI.”* 3 | ##Scope of the request [Give a generic description of why you are issuing this RFI but call out any must haves. For example: *“[YOUR COMPANY NAME] is seeking to implement a Warehouse Management System with full support for [RFID/Whatever you have to have…”]* 4 | ##How to respond Send the attached Excel spreadsheet/Questionnaire (in the format supplied) by email to [your email address]. Specify what questions responders can ask and how they should raise them. For example: *“Queries must relate only to responses on the RFI form and should be directed to [your email address]. You may expect a reply within one working day. Please note that responses to queries may be circulated to all other recipients of this RFI.”* 5 | ##Timeframe [Date] RFI Issued to all prospective suppliers. [Date] Responses received. After this date no questions will be answered. [Date] RFP issued to selected suppliers based on RFI submissions. [Date] Presentations by shortlisted suppliers. [Date] Successful supplier notified. ##Company Background Give details of your company. The type of information usually provided is: 6 | 7 | - Date of incorporation - Number of staff - Geographical spread - Location of HQ - Location where the project will take place - Core product(s) - Annual turnover - Link to your website 8 | ##Supplier Pre-requisites List the pre-requisites of a supplier to your business. These are typically corporate governance criteria such as: *“supplier must operate an equal opportunities programme, or supplier must have $n million of Professional Indemnity Insurance etc.”* You may also require suppliers to comply with specific standards e.g. ISO standards or to use specific methodologies in the area of Quality or Risk Management. Solution Pre-requisites List any pre-requisites of the solution or service you require. For example: *“solution must support internationalization and non-western character sets as it will be rolled out to multiple countries in local language/ supplier must provide French and Spanish speakers for the rollout in Europe as these are the languages of our businesses in those countries.”* ###Form to fill in as answer to the RFI |Question |Answer | 9 | |:------------------------|:-----------------| 10 | |Company name | 11 | |Company address (HQ) | |Website URL |Date of incorporation |List of products and services |In which markets do you operate? |Number of employees (worldwide) |Turnover (prior year) |Stock Market EPIC 12 | | |Contact Name and Title |Contact Email |Contact Telephone |Contact Address (if different from Company HQ) |Name and description of any products or services you provide that you feel fulfill the requirements as currently stated 13 | |Number of customers using any product(s) and services that match the RFI requirements *(Please provide a breakdown by country)* |Location of any support centre(s) you operate. Specify (by location) if this is 24 x 7. |What is your standard SLA response time to incidents?| 14 | |Please specify any standard project methodology you would utilize in an implementation for us. |What roles would be dedicated on the project, for example a dedicate PM/Scrum Master, Account Manager etc? 15 | |What directly relevant services do you provide e.g. training? *[Extend/amend the list above as your needs dictate]* -------------------------------------------------------------------------------- /general-business/statement-of-work.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/general-business/statement-of-work.docx -------------------------------------------------------------------------------- /general-business/statement-of-work.md: -------------------------------------------------------------------------------- 1 | #Statement of Work **Statement of Work For:** \ **Document Created:** \ **Author:** \ **Distribution:** \ **Document Revision History** | Revised By | Date | Comment | 2 | | -----------------|:--------------:|:---------------------:| 3 | | Initials or name | Date modified | Reason for revision | 4 | | Initials or name | Date modified | Reason for revision | 5 | 6 | | Start Date | End Date | Project Manager | 7 | | :---------:|:-----------:| :--------------:| 8 | |dd-mon-yyyy |dd-mon-yyyy | Initials | 9 | ##Background *[Optional section]* 10 | If there is a background to this SOW that is relevant, possibly because it will be distributed to multiple stakeholders that are not aware of the work background then describe it here. For example: *“[client] has been experiencing difficulty identifying sources coming to their website, which makes it difficult to track marketing spend…”* This type of background is often a justification for rapid sign-off of the SOW as it highlights the commercial imperative of the recipient of the work. 11 | ##Objectives State the high-level business objectives and proposed solution so that the two marry up, with the solution an explanation of how the objectives will be met. For example: *“to implement [solution] by [development steps] so that [objectives] can be met in a timely and efficient fashion.* ##Project Scope 12 | ###High-Level Requirements List the requirements that must be satisfied in order for the project’s goals to be realised. | Requirement | Comment | 13 | | ------------- |---------------------------------| 14 | |Requirement A |Delivery of A enables B to happen| 15 | |Etc. |Etc. | ###Milestones and Deliverables *List the major project milestones and the deliverables from them* | Milestone | Deliverable | 16 | | ------------- |---------------------------------| 17 | |Milestone A |Deliverable 1 | 18 | |Milestone B |Deliverable 2 | 19 | |Milestone C |Deliverable 3 | 20 | |Etc. |Etc. | ###Project Plan ####Timeline Lay out the timeline for delivery at a high level. It is generally wise not to commit to dates, only to durations in a SOW, as delays in approval often occur with the deadline not shifting accordingly. 1. Wk 1 - a. Kick off session - b. GAP Analysis 2. Wk 2 - a. Deliver detailed technical spec for sign off - b. Deliver database schema 3. Etc. ##Risks and Assumptions ###Risk Analysis If you are creating a sophisticated SOW you may have a separate Risk Register. Do not link to it, instead call out the risks in a table with the column headings below: **Risk Id** – A unique identification number [can be used to identify and track the risk in the risk register if one is in use]. **Category** –Is the risk financial (cost and/or revenue), regulatory or compliance, timeline, resource, environment, or some other key category? Categorising risks groups them and aligns them with stakeholders who are best placed to assess/mitigate and stakeholders for whom the risk is greatest. **Description** – Describe the potential risk. For instance: Item A cannot be completed until Item B has been purchased but approval is not yet forthcoming and there is a delivery lead time, or Item A requires resources that have not been identified and the project is currently resource constrained. **Potential Impact** – A quantitative rating of the potential impact on the project if the risk should materialize. Impact in a Risk Register should be scored on a scale of 1 – 10 with 10 being the highest impact. ###Assumptions List all of the assumptions that are being made. For example: *“to successfully meet its goals in a timely manner with benefits reflected in the current financial year, all parties have signed-off the budget and the project will begin on the scheduled start date.”*   ##Pricing List the price, stating clearly: 1. Currency (don’t get paid in Canadian dollars when you meant US dollars!) 2. Amount 3. Payment Terms (including any staged/milestone payments) 4. If price is Fixed or Time and Materials. If the latter, then specify that there is a Rate Card in the Appendix and put it there. ##Approval *This Statement of Work has been reviewed and accepted by the following people, as indicated by signature below:* [List all individuals whose signature is required, along with their titles and/or roles on the project. As a general rule, try not to put all the text of an Approval section on a page by itself and always place it immediately beneath the pricing information.] **Full Name** ............................................................................... **Title**.......................................................................................... 21 | 22 | **Signature**................................................................................. 23 | 24 | **Date**.......................................................................................... -- 25 | 26 | **Full Name** ............................................................................... **Title**.......................................................................................... 27 | 28 | **Signature**................................................................................. 29 | 30 | **Date**.......................................................................................... *[it is advisable to specify dates in dd-mon-yyyy format, which is the international standard]*  ##APPENDIX A - REFERENCES Include the relevant text of any documents referenced in this SOW (for example a Rate Card if T&M). Do not link to documents outside of the physical SOW as this document forms the basis for a contractual agreement and should therefore be complete in itself. ##APPENDIX B - GLOSSARY | Term | Definition | 31 | | ------------------------|----------------------------------| 32 | |Term used in the document|Its definition in lay terms | 33 | |Etc. |Etc. | -------------------------------------------------------------------------------- /project-management/README.md: -------------------------------------------------------------------------------- 1 | # Free Project Management Templates 2 | 3 | Free, best practice document templates as used in [Documize](https://documize.com). 4 | 5 | Capture business requirements for a sizeable project where you need to involve multiple stakeholders. 6 | 7 | [Project Charter](project-charter.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/project-charter.docx) 8 | 9 | [Project Post Mortem](project-post-mortem.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/project-post-mortem.docx) 10 | 11 | [Project Post Mortem Meeting Guidelines](project-post-mortem-meeting-guidelines.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/project-post-mortem-meeting-guidelines.docx) 12 | 13 | [Requirements Capture](requirements-capture.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/requirements-capture.docx) 14 | 15 | [Risk Register document](risk-register.md) [(DOCX)](https://github.com/documize/document-templates/raw/master/project-management/risk-register.docx) [(XLSX)](https://github.com/Documize/document-templates/blob/master/project-management/risk-register.xlsx?raw=true) 16 | 17 | 18 | 19 | 20 | -------------------------------------------------------------------------------- /project-management/project-charter.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/project-management/project-charter.docx -------------------------------------------------------------------------------- /project-management/project-charter.md: -------------------------------------------------------------------------------- 1 | #Project Charter Template **Project Charter For:** \ **Document Created:** \ **Author:** \ **Distribution:** \ **Document Revision History** | Revised By | Date | Comment | 2 | | -----------------|:--------------:|:---------------------:| 3 | | Initials or name | Date modified | Reason for revision | 4 | | Initials or name | Date modified | Reason for revision | 5 | | Start Date | End Date | Project Manager | Client | 6 | | :---------:|:-----------:| :--------------:| ------------| 7 | |dd-mon-yyyy |dd-mon-yyyy | Initials| Client/Stakeholders | 8 | #Introduction ##Purpose of the document *[You can use the boilerplate text below or replace with your own wording]* This document provides the information necessary to frame the project in the context of its scope, purpose, funding, resource requirements and approval. This document target audience is the major departmental stakeholders and decision makers in the leadership team. ##Project Overview State the purpose followed by the where, when and how of the project together with the estimated budget and affected/participating stakeholder groups. ##Business Case State the business case here. If you are creating a document as sophisticated as a Project Charter it is likely that there is a separate Business Case document (and possibly presentation slides and spreadsheets). You should reference any relevant business case documentation here for the audience. The business case should state the problem or opportunity that the business is addressing, the likely benefit, the cost associated with achieving the goal(s) and set out the ROI in clear terms. If the project is only a small part of the business case then it should be made clear in the Project Charter that the project is part of a larger strategic initiative, which might be described depending on sensitivity. ##Project Scope ###Objectives State the objectives in a succinct (preferably bullet point) manner. Be clear about dependencies and lay the document out accordingly. 9 | - Objective A (only achieved if Objective B is met) 10 | - Objective B - Objective C - Objective D - Etc. 11 | ###High-Level Requirements List the requirements that must be satisfied in order for the project’s goals to be realised. | Requirement | Comment | 12 | | ------------- |---------------------------------| 13 | |Requirement A |Delivery of A enables B to happen| 14 | |Etc. |Etc. |   ###Milestones and Deliverables *List the major project milestones and the deliverables from them* | Milestone | Deliverable | 15 | | ------------- |---------------------------------| 16 | |Milestone A |Deliverable 1 | 17 | |Milestone B |Deliverable 2 | 18 | |Milestone C |Deliverable 3 | 19 | |Etc. |Etc. | ###Project Plan ####Timeline Lay out the project plan at a very high level, possibly in the form of a Gantt chart image. 20 | ###Financial Estimates ####Estimate Provide a summary of the estimated costs to deliver the project. If the project is broken into phases then you should cost each phase separately. 21 | ##Risks and Assumptions ###Risk Analysis If you are creating a document as sophisticated as a Project Charter it is likely that there is a separate Risk Register (and possibly presentation slides and spreadsheets). You should reference any relevant business case documentation here for the audience. If not, call out the risks in a table with the column headings below (you should ideally use a spreadsheet): **Risk Id** – A unique identification number used to identify and track the risk in the risk register. There are different possible ways of classifying the Id but what is clear is that it is best if this is codified. For example, Risk Id RF### could relate to a Financial risk, which Risk Id RC### could relate to a Compliance risk. **Category** –Is the risk financial (cost and/or revenue), regulatory or compliance, timeline, resource, environment, or some other key category? Categorising risks groups them and aligns them with stakeholders who are best placed to assess/mitigate and stakeholders for whom the risk is greatest. **Description** – Describe the potential risk. For instance: Item A cannot be completed until Item B has been purchased but approval has been delayed, or Item A requires resources that have not been identified and the project is currently resource constrained. **Potential Impact** – A quantitative rating of the potential impact on the project if the risk should materialize. Impact in a Risk Register should be scored on a scale of 1 – 10 with 10 being the highest impact. **Probability** – The likelihood that the risk will occur at some point in the duration of the project. This should be quantitative like Potential Impact not qualitative (high, medium or low). If you use qualitative measures you cannot calculate a Risk Score, which is done by multiplying Probability and Impact and you can easily convert a number to a descriptor e.g. 1-3 = “Low”, 4-6 = “Medium” and 7-10 = “High”. **Likely Outcome** – The likely consequence or impact of the risk if it materialises. **Ranking** – This is the relative ranking of one risk in comparison to all others that have been assessed. This can be qualitative e.g. high, medium, or low, or it can be quantitative, especially if Rank is used as a sorting mechanism to decide what items most require mitigation. Remember that qualitative ranking will produce duplicate values; if you have two “High” ranking items then you should consider how you might decide which is more important? **Mitigation** – What signs or outcomes indicate the need to implement contingency plans and what are those contingency plans. It is likely that you will need to create a separate Contingency Planning document for each high impact risk. **Prevention Plan** – An action plan to prevent a given risk from occurring, often combined with the Contingency Plan described above. You should try to establish a prevention plan for every risk that you categorize, starting with those risks that have the greatest potential impact. **RACI Matrix** – For every risk, try to establish a RACI matrix. Who is **R**esponsible? Who is **A**ccountable? Who should be **C**onsulted? Who should be **I**nformed? ###Assumptions List all of the assumptions that are being made. For example: “to successfully meet its goals in a timely manner with benefits reflected in the current financial year, all parties have signed-off the budget and the project will begin on the scheduled start date.”   ##Project Organization Describe the key roles in the project, who fills them, and the responsibilities of each role. | Name | Role | Responsibilities | 22 | | --------- |-------------------|--------------------------| 23 | | Person |Executive Sponsor | Acts as a champion for the project within the business. Removes blockers and sits in the escalation chain directly above the project manager to ensure all issues are resolved in a timely manner. Recipient of the bi-weekly status report.| 24 | |Person | Project Manager | PM Responsibilities | |Person |Technical Lead |Tech Lead Responsibilities| |Etc. |Etc. |Etc. | 25 | *[You may wish to include an Org Chart here]* 26 | ###Project Advisory Board/Steering Committee List the members of the advisory board/steering committee and state the comms they will receive to keep them abreast of the project, as well as the frequency, location and method of their meetings. For example “the committee will meet in person at HQ on the first Monday of every month to review the output of the status reports and assess progress”. ###Project Stakeholders List the internal and external stakeholders of the project as well as the comms they will receive such as a weekly/monthly status report, timesheets etc. Be sure to call out *all* stakeholders. For example Finance may need to produce monthly project costing but may not be directly involved in the project. This is the section where they (and their role/responsibilities) get included in the project. ##Project Approval *This project has been reviewed and the Project Charter accepted by the following people, as indicated by signature below:* List all individuals whose signature is required, along with their titles and/or roles on the project. **Full Name** ............................................................................... **Title**.......................................................................................... 27 | 28 | **Signature**................................................................................. 29 | 30 | **Date**.......................................................................................... -- 31 | 32 | **Full Name** ............................................................................... **Title**.......................................................................................... 33 | 34 | **Signature**................................................................................. 35 | 36 | **Date**.......................................................................................... *[it is advisable to specify dates in dd-mon-yyyy format, which is the international standard]*  #APPENDIX A - REFERENCES List any documents referenced in this Project Charter Document Description Location Document name and version A brief description of the document Physical location of the document e.g. a folder on a Network drive, doc repository, or hyperlink. #APPENDIX B - GLOSSARY | Term | Definition | 37 | | ------------------------|----------------------------------| 38 | |Term used in the document|Its definition in lay terms | 39 | |Etc. |Etc. | -------------------------------------------------------------------------------- /project-management/project-post-mortem-meeting-guidelines.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/project-management/project-post-mortem-meeting-guidelines.docx -------------------------------------------------------------------------------- /project-management/project-post-mortem-meeting-guidelines.md: -------------------------------------------------------------------------------- 1 | #Project Post-Mortem Meeting *About to have a Project Post-Mortem meeting? This guideline identifies the key participants and their roles.* 2 | ##Post-Mortem Participants and Roles Each project post mortem should have one or more people in the following roles: ###The Facilitator Collates the documentation for the meeting to act as reference points. This would include the Project Charter, Project Plan(s), Project Status Reports, Key emails from stakeholders etc. Sets the date and time of the session and invites the necessary participants, who should represent all stakeholder groups and the delivery team. Participants should have a reasonable amount of time to prepare and to plan for attendance. Identifies any roles, other than simple attendee, to any participant who is expected to perform that role. For example, if someone is to perform a walkthrough of the project then that person needs to be notified in advance that this is their role and how long they are expected to take to perform their function. Acts as a central collator of any materials to be collected and distributed prior to the meeting. Acts as the meeting moderator to: 3 | - Control the flow and keep the meeting crisp and on-time. - Stop the meetings from being blocked by single issues - Ensure that all attendees get a fair share of voice if they have something to contribute - Suggests priority and severity ratings on tasks - Encourages timely decision-making (on-the-spot if possible) - Encourages and assists group discussions - Leads the meeting wrap-up where points discussed and actions agreed are reiterated for final consensus that these are the conclusions to be drawn - Ensures that the meeting is formally recorded and all attendees receive a copy of the minutes. One great technique is to collect email addresses as people walk into the meeting, project the minutes and action points as they are taken, and send the minutes to all attendees before they leave the room Prepares and distributes the Project Post Mortem Report. 4 | ###Project Manager 5 | - Delivers a walkthrough of the project, highlighting milestones, successes, issues that arose and their mitigation, and lists any outstanding tasks that ideally should be assessed from a resourcing standpoint. - Is responsible for all the project documentation collected prior to the meeting and therefore is jointly responsible with the facilitator for collating the documentation. - Participates in the session discussions and decision-making. - Usually produces or assists in the production of the Post-Mortem Report. - Manages the action items identified in the meeting. 6 | ###Team Members and business stakeholders - Prepare by listing their personal and team input. - Identify successes and issues, with reasons for both. - Participate in group discussions and decision-making. - Suggest overall process improvements for any future projects. -------------------------------------------------------------------------------- /project-management/project-post-mortem.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/project-management/project-post-mortem.docx -------------------------------------------------------------------------------- /project-management/project-post-mortem.md: -------------------------------------------------------------------------------- 1 | #Project Post-Mortem Template *Agile and similar methodologies run regular Sprint Retrospectives and tend not to have a big Project Post Mortem at the end. This template is for those teams that do need to submit a project Post Mortem report (Agile teams can use it too, although the Sprint Retrospective Template may be more relevant).* **Document Created:** \ **Author:** \ **Distribution:** \ **Document Revision History** | Revised By | Date | Comment | 2 | | ------------- |:-------------:| -----:| 3 | | Initials or name | Date modified | Reason for revision | 4 | | Initials or name | Date modified | Reason for revision | 5 | | Initials or name | Date modified | Reason for revision | 6 | | Initials or name | Date modified | Reason for revision | 7 | | Start Date | End Date | Project Manager | Client | 8 | | ------------- |:-------------:| :-----:| ---- | 9 | |dd-mon-yyyy |dd-mon-yyyy | Initials | Client/Stakeholder(s)| 10 |   ##Project Background \ ##Executive Summary Outline the project charter 11 | List the project success criteria 12 | Specify if the budget was on-time/on-budget and if not why not 13 | List the key milestones ##Analysis ###Successes List and describe key achievements, explaining what went well and why. Be specific and consider listing them in order of importance. - What worked and why - Major milestones and their deliverables - Processes and areas of business improved - New processes or components created during the project that were not direct project deliverables. For example *“We now have some software that connects System A with System B to make process C simpler in the future”.* 14 | ###Problem Areas List and describe key problem areas, explaining what didn’t go well and why. Be specific and consider listing them in order of impact. If there were technical challenges, explain them as if to a lay audience. - What didn’t work and why - Major problems and their direct impact - Processes and areas of business affected ##Project Risk Assessment The risk assessment section should link back to a Risk Register if one was created, as well as any contingency or mitigation plans if they are not contained within the Register. With specific regard to identifying improvements in future projects you might like to consider the following criteria: 1. Adherence to scope - what changes were made to the original scope after the project start date and what was their impact? 2. Adherence to process – was proper project management methodology followed and adhered to? 3. Team unity assessment – did the team work well together, was communication good/easy/regular/effective? 4. Project Planning – often directly related to adherence to process. Was the project properly planned or were there a number of things that should have been foreseen but weren’t, or weren’t properly scheduled, resourced or reported? 5. Project Management – was their effective project management in terms of managing expectations of stakeholders and the delivery team, early assessment and mitigation of risks, support in removing blockers etc? 6. Quality assessment – is the output of the project regarded by all stakeholders as high quality. If not, what is regarded as sub-standard, by whom, and why? ##Additional Comments Give any other comments, in particular feedback from stakeholders and the delivery team that is relevant. For example, *“on the nights the team worked late to complete a deliverable it would have been nice to have the company pay for pizza and taxis home”* ###Outstanding Tasks It’s an imperfect world where projects complete that still have outstanding tasks. Summarize and list all tasks related to the project that remain undone/ incomplete. Do this as if they were tasks for a later phase. 15 | ###Post Project Tasks Summarize and list all tasks related to the project that should be executed now that it is complete. For example *“training to be rolled out across the enterprise on new system.”* ##Lessons Learned This is the key section and the point of the project post mortem. Summarize and describe the key lessons from the project. -------------------------------------------------------------------------------- /project-management/requirements-capture.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/project-management/requirements-capture.docx -------------------------------------------------------------------------------- /project-management/requirements-capture.md: -------------------------------------------------------------------------------- 1 | ##Business Requirements For \ **Document Created:** \ **Author:** \ **Distribution:** \ **Document Revision History** | Revised By | Date | Comment | 2 | | ------------- |:-------------:| -----:| 3 | | Initials or name | Date modified | Reason for revision | 4 | | Initials or name | Date modified | Reason for revision | 5 | | Initials or name | Date modified | Reason for revision | 6 | | Initials or name | Date modified | Reason for revision | 7 |   ##1. Introduction ###1.1. Document Purpose The purpose of this document is to describe the business requirements of an application or software dependent process, completely, accurately and unambiguously in a jargon-free and technology agnostic manner. ###1.2. Intended Audience The intended audience are business owners of the proposed system and staff engaged in the delivery of the system, either as developers or as users. This document should be readable by non-technical stakeholders. They must be able to verify that their business requirements have been documented here to their complete satisfaction and understanding. 8 | ###1.3. Project Background List here any information about the circumstances that gave rise to the project if they are helpful in explaining the project purpose. ###1.4. Purpose of the Business Requirements This section describes why the Business Requirements are being documented – as a framework of understanding and a means of extracting information for the purpose of evaluating risks, timelines, required resource etc. 9 | ###1.5. Business Goals/Objectives to be achieved This section describes the major goals/objectives to be achieved with the implementation of a system that satisfies the stated requirements. ###1.6. Stakeholders Stakeholders are the individuals or groups who have a vested interest in this project and whose interests need to be considered throughout the project. This section lists the Stakeholders of the Application / Project for which these Business requirements are documented. 10 | ###1.7. Dependencies on existing systems This section describes the dependencies between the Application for which these Business Requirements are written and the other existing applications/systems in the total business ecosystem. ###1.8. References List any references (preferably hyperlink or specify location(s)) to previous documents, meeting minutes, correspondence etc. that are related to these Business Requirements and relevant for its intended audience. ###1.9. Assumptions Describe any assumptions that were made prior to or during the Business Requirements gathering and documentation.   ##2. Scope of the projects Describe (preferably list) the business functionality that is in/out of scope for Implementation. Highlight functionality that has been de-scoped in the requirements gathering process, or ruled in at a late stage. 11 | ###2.1. In Scope Deliverables ###2.2. Out of Scope Deliverables ##3. Functional Requirements This section describes the Functional requirements part of the Business Requirements. In classic Use Case methodology (UML), the Functional Requirements comprises Actor Profile Specification, Essential Use Case diagram and Essential Use Case specification in narrative. 12 | ###3.1. Actor Profiles Specification Describe all the Actors and their profiles within the context of the Business Requirements being documented. An Actor is a person, organization or an external system/sub-system/program that has interactions with the Application. Actors, by definition, are external to the system with which they are having interactions. Actors have goals that are achieved by Use Cases. Typically, Actors have behaviour and are represented by the roles they play in the Use Cases. An Actor stimulates the system by providing input and/or receiving something of measurable value from the system. 13 | ###3.2. Essential Use Case Diagram This section depicts the Business Requirements in the form of a Use Case diagram. Examples and explanations can be found here: http://www.uml-diagrams.org/use-case-diagrams-examples.html ###3.3. Essential Use Case Specifications This section describes each Essential Use Case in narrative text form. A Use Case typically has one basic, or standard course of action (flow) and one or more alternate courses of actions.   Use Case: \ Use Case Name Unique name for this Use Case Description Describe the Use Case Actors An Actor specifies a role played by a user or any other system that interacts with the subject. Business Rules List the business rules of Section 3.6 that this Use Case references. Mention only the Business rule Id here. Provide hyperlinks to the business rules of section 3.6. Basic Flows Describe the basic, desired process flow Alternate Flows Describe any alternate flows that might occur from time to time Non-Functional Requirements List requirements that are not of the system but of the process as a whole. For example if an offline notification is needed. Pre-Conditions What has to be in place for the process to begin Post-Conditions The situation that should exist after the process has successfully completed ###3.4. Function Hierarchy Diagram This section depicts the Business Requirements in the form of Function Hierarchy Diagram (FHD). In the Oracle Designer approach, the Functional Requirements are decomposed into a number of Business Functions. If you are not using this methodology you do not need to include this section or the Function Definition Report below. ###3.5. Function Definition Report This section describes each Business Function in narrative text form.   ###3.6. Business Rules List, number and describe the business rules applicable to the proposed system. Where the business rules are derived from multiple departmental groups you may enhance the coding of the rule Id to indicate source e.g. BRF#### for a rule from Finance as opposed to BRM#### for a rule from Marketing. | Business Rule Id | Rule Name| Description| Source 14 | | ------------- |:-------------:| -----:| -----:| 15 | | BR#### | \ | \ | \ 16 | 17 | Alternative Source examples: - Policy manuals - Strategic decision - Contractual obligation - Subject matter expert - External Sources (govt regulation for example) ##4. Data Requirements This section describes the Data requirements part of the Business Requirements. You may find it helpful to reference the information [here] (http://www.uml-diagrams.org/class-diagrams-examples.html) and [here] (http://creately.com/diagram-community/popular/t/erd), as well as other sources, before completing this section of the document. ###4.1. Data Architecture This section describes the Data Architectural requirements part of the Business Requirements. You would normally complete the Domain Class Diagram if you are using UML (Use Cases) or the Entity Relationship Diagram if you are following the Oracle Designer approach, but rarely both. ####4.1.1. Domain Class Diagram This section depicts the Data Architecture in the form of Domain Class Diagram. In the Use Case approach, the conceptual data architecture (structural aspects) for the Business Requirements is modeled using Domain Class Diagram. The Domain Class Diagram is used to model the conceptual classes, its attributes (fields) and operations (methods) and also the interrelationships (association, composition, aggregation and generalization) between the classes. Domain model is a representation of real world conceptual classes, not of software components. ####4.1.2. Entity Relationship Diagram This section depicts the Data Architecture in the form of Entity Relationship Diagram (ERD). In the Oracle Designer approach, the conceptual data architecture (structural aspects) for the Business Requirements is modeled using Entity Relationship Diagram (ERD). ###4.2. Data Volumes This section describes the expected approximate Data volumes (initial volume and annual growth %) for each conceptual Class or Entity. You may need the support of a DBA for this. ###4.3. Data Conversion This section describes at a high-level any data conversion requirements, namely the system, data source and destination. For example: “User data will be pulled from the Active Directory System and converted to enhance the Peoplesoft HR user record.” ###4.4. Data Retention and Archiving This section states the time frame for online Data retention before archiving and also the archiving requirements (in particular try to cover how archived data will be recovered if needed and what the time frame for recovery will be). ###4.5. Security/Privacy Implications This section describes the sensitivity levels of each class of data. The following criteria are used in determining the sensitivity level of each conceptual class/entity. • Non-sensitive information that would not reasonably be expected to cause injury (harm) if released to the public; • Protected A: information that, if compromised, could reasonably be expected to cause injury (harm), e.g. loss of privacy; • Protected B: information that, if compromised, could reasonably be expected to cause serious injury (harm), e.g. the conduct of a court proceeding would be adversely affected; • Protected C: information that, if compromised, could reasonably be expected to cause extremely grave injury (harm), e.g. loss of life. ###4.6. Data Definition Reports This section describes the Data Architecture / definition in a report format. ####4.6.1. Domain Class Definition Report This section is applicable only to Use Case approach. This section describes Data Architecture / definition (Domain Class model) in narrative text form. **Class Name** **Class Description** **Initial Data Volume (approx.)** **Annual Data growth rate (in approx. %)** Attributes (fields) of the class Name in name/description pairs as shown below: **Name :** \ 18 | **Description :** \ ####4.6.2. Entity Definition Report This section describes Data Architecture / definition (Entity Relationship model) in narrative. **Entity Name** **Entity Description** **Initial Data Volume (approx.)** **Annual Data growth rate (in approx. %)** Attributes (fields) of the Entity in name/description pairs as shown below: **Name :** \ 19 | **Description :** \ ##5. Non-Functional requirements This section describes the non-functional requirements part of the Business Requirements. A non-functional requirement is typically a special requirement that is not easily or naturally specified in the text of the Use Case’s or function’s event flow. Examples of non-functional requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or supportability requirements. ###5.1. Security Requirements This section describes the Security requirements part of the Business Requirements. ####5.1.1. Authentication This section describes the Authentication requirements part of the Business Requirements. ####5.1.2. Authorization and Access Controls This section describes the Authorization and Access Control requirements part of the Business Requirements at a high-level. Authorization is the process of determining if the person/group, once identified through the “Authentication process”, is permitted to have access to certain services. 20 | ###5.2. Availability Requirements This section describes the system availability requirements. 21 | ###5.3. Usability Requirements This section describes the system usability requirements. A usability requirement specifies how easy the system must be to use. Usability is a non-functional requirement, because in its essence it doesn't specify parts of the system functionality, but specifies only how that functionality is to be perceived by the user, for instance how easy it must be to learn and operate the system. 22 | ###5.4. System Help Requirements This section describes what kind of System Help features need to be built into the system. ###5.5. Performance Requirements This section describes system performance expectation levels (response times). ###5.6. Scalability Requirements This section describes how the system is expected to scale to new higher or lower levels. Both user and application scalability requirements are described here. Data scalability is not described here as it is already described in the “data volumes” section earlier. ####5.6.1. User Scalability How the system should scale as more and more users are added. 23 | ####5.6.2. Application Scalability How the system should scale to meet performance demands. 24 | ##6. Interface Requirements This section describes User and System Interface requirements for the proposed system. ###6.1. User Interface Requirements It may be helpful to reference screen and report designs in this section. ###6.2. System Interface Requirements Use this section to list all required APIs into and out of the system, note those that exist and can be leveraged separately from those that need to be built for the Application to meet the business requirements. ##7. Business/Technical Glossary List the business and technical terms used that might not be understood by all stakeholders and describe them in jargon-free narrative. -------------------------------------------------------------------------------- /project-management/risk-register.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/project-management/risk-register.docx -------------------------------------------------------------------------------- /project-management/risk-register.md: -------------------------------------------------------------------------------- 1 | #Introduction This document outlines the key information that should be documented for each risk. *To easily sort, filter and perform calculations, Risk Registers are best created as a combination of a document (of which this is a descriptive template) and a Spreadsheet. A sample Risk Register spreadsheet to accompany this document has also been created for you.* 2 | **Risk Id** – A unique identification number used to identify and track the risk in the risk register. There are different possible ways of classifying the Id but what is clear is that it is best if this is codified. For example, Risk Id RF### could relate to a Financial risk, which Risk Id RC### could relate to a Compliance risk. 3 | **Category** –Is the risk financial (cost and/or revenue), regulatory or compliance, timeline, resource, environment, or some other key category? Categorising risks groups them and aligns them with stakeholders who are best placed to assess/mitigate and stakeholders for whom the risk is greatest. 4 | **Description** – Describe the potential risk. For instance: Item A cannot be completed until Item B has been purchased but approval has been delayed, or Item A requires resources that have not been identified and the project is currently resource constrained. 5 | *The following are determined in a Risk Assessment* 6 | 7 | **Potential Impact** – A quantitative rating of the potential impact on the project if the risk should materialize. Impact in a Risk Register should be scored on a scale of 1 – 10 with 10 being the highest impact. 8 | **Probability** – The likelihood that the risk will occur at some point in the duration of the project. This should be quantitative like Potential Impact not qualitative (high, medium or low). If you use qualitative measures you cannot calculate a Risk Score, which is done by multiplying Probability and Impact and you can easily convert a number to a descriptor e.g. 1-3 = “Low”, 4-6 = “Medium” and 7-10 = “High”. **Likely Outcome** – The likely consequence or impact of the risk if it materialises. 9 | *The following are determined in a Risk Evaluation, when all the risks have been gathered and assessed.* 10 | **Ranking** – This is the relative ranking of one risk in comparison to all others that have been assessed. This can be qualitative e.g. high, medium, or low, or it can be quantitative, especially if Rank is used as a sorting mechanism to decide what items most require mitigation. *Remember that qualitative ranking will produce duplicate values; if you have two “High” ranking items then you should consider how you might decide which is more important?* 11 | **Mitigation** – What signs or outcomes indicate the need to implement contingency plans and what are those contingency plans. It is likely that you will need to create a separate Contingency Planning document for each high impact risk. 12 | **Prevention Plan** – An action plan to prevent a given risk from occurring, often combined with the Contingency Plan described above. You should try to establish a prevention plan for every risk that you categorize, starting with those risks that have the greatest potential impact. 13 | **RACI Matrix** – For every risk, try to establish a RACI matrix. Who is **R**esponsible? Who is **A**ccountable? Who should be **C**onsulted? Who should be **I**nformed? -------------------------------------------------------------------------------- /project-management/risk-register.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/documize/document-templates/83c00bc447065b50a6b88ddd1f96beb1497ae832/project-management/risk-register.xlsx --------------------------------------------------------------------------------