Project Documentation Guidelines

The following are some of the Guidlines for creating effective Project Documentation

1. Start with a clear outline: Before you begin documenting your project, create an outline that includes all the main sections and subsections. This will help you stay organized and ensure that you cover all the necessary information.
2. Use clear and concise language: Your documentation should be easy to read and understand. Use simple language and avoid jargon or technical terms that your audience may not be familiar with.
3. Include relevant information: Your documentation should include all the information that someone would need to understand and use your project. This may include things like installation instructions, configuration options, and usage examples.
4. Provide context and background: Make sure to provide context and background information about your project. This can include the purpose of the project, its history, and any relevant industry trends or standards.
5. Use diagrams and visuals: Visual aids can help make your documentation more engaging and easier to understand. Use diagrams, screenshots, and other visuals to illustrate key concepts and processes.
6. Keep it up-to-date: Your documentation should be kept up-to-date with any changes or updates to the project. Make sure to review and update your documentation regularly.
7. Get feedback: Finally, be open to feedback from others. Share your documentation with colleagues, users, and other stakeholders to get their feedback and suggestions for improvement.

Project Documentation Format

1. Conception & Initiation

(i). Business Case (Why we should do the Project)

A business case provides justification for undertaking a project, programme or portfolio. It evaluates the benefit, cost and risk of alternative options and provides a rationale for the prefered solution.

Business Case Should inlude the following;

1. Project Name
2. Project Sponsor (Optional)
3. Project Manager
4. Date of Project Approval
5. Summary/Strategy
6. Option Considered
7. Benefits
8. Timescales
9. Costs
10. Expected ROI (Return on Investment)
11. Risks

(ii). Project Charter (How are we going to deliver the project)

Is a formal, typically short document that describes your project entirely; including what the objectives are, how it will be carried out and who the stakeholders are.

Project Charter Should include the following;

1. Project Name
2. Project Manager
3. Project Sponsor
4. Opportunity
5. Goals
6. Objectives
7. Deliverables
8. Stakeholders
9. Summary project Status
10. Milestones
11. Summary of Cost
12. Risks
13. Risks
14. Scope
15. Success Criteria

2. Definition & Planning

(i). Schedule

Its a timetable showing the forecast start & finish dates for activities or events within a project.

The following should include in activities

1. Design
2. Review
3. Build Prototype
4. Test Prototype
5. Prototype passes compliance
6. Mass Production
7. Product Launch
8. Close Project

The following should include in Resources

1. Software Used
2. Material Used

(ii). Budget

A project Budget is the total cost of all the tasks, activities and supplies associated with an entire projec.

Should have the Following

1. Category
2. Item Description
3. Supplier
4. Purchase Order
5. Rate
6. Date
7. How much Money Spend

(iii). Risks and Issues Logs

Used to record the details of project risks or issues identified.

Should include;

1. Risk No
2. Risk Description
3. Impact
4. Probability of happening again
5. Date Raised
6. Mitigation
7. Target Resolution Date
8. Risk Raised (Name of who identified the Risk)
9. Owner (Person responsible to manage the risk)
10. Severity (Level of impact or harm the issue may cause to a project or organization)

3. Launch or Execution & Performance & Control

(i). Change Request Document

Is a form used to request, approve and track project related changes.

Project Change Form

1. Project Name
2. 2. Date
3. Change Number

---

Request

1. Originator Name
2. Describe the proposed change
3. Reasons for the desired change
4. Anticipated Impact
5. Desired Outcome

---

Evaluation

1. Receiver Name
2. Potential change Synopsis
3. Estimated Impact
4. Decision

(ii). Defects Log / Issue Tracker

Errors or something is not working as expected

Should have the following

1. Defect ID
2. Defected Date
3. Status
4. User impact
5. Business Impact
6. Subject
7. Reported by
8. Defect / Issue Description
9. Internal Update
10. Assigned to
11. How it was fixed
12. Open / Closed
13. Where is it fixed

4. Executive Status Report

Is a document that provides an overview of the progress, status, and performance of a project or a business to executive-level stakeholders. Highlights most important things at a given time. Describe the progress of a project within a specific time period and compares it against the project plan.

A Monthly Project Status Report Should have the following

• Actual Date
• Status period between this planned date and between this actual date
• Milestone Status, Start and Finish
• Issue / Risks

5. Project Close

Lesson Learned Log

This captures and share knowledge about what has worked well and what could have been done differently during the planning, management and delivery of an improvement project

Lesson Learned Log Should have

• Project Name
• Project Manager Name
• Project Description
• ID , Date Identified, Subject Issue, Situation
• Recommendation & Comments Follow up

6. Closure Report

Is a document which formalizes the closure of the project provides confirmation that the criteria for customer acceptance have been met & requests sign-off from the project sponsor to close the project.