Project Management Tips

Good IT project governance requires application and system documentation regardless of the project management framework used (e.g., adaptive, predictive, Agile). In this post, the term “project implementation documentation” is used as a catch-all to cover all aspects of documentation across application lifecycle.

Some of the reasons for producing implementation documentation include but not limited to:

• Meet federal, state, or other regulatory requirements.
• Design reviews and approvals.
• Track design and development code changes.
• Manage defects.
• Document the application’s business logic and code to support future application bug fixes, modifications, or enhancements.

Projects without adequate implementation documentation are at risk of requirements gaps, incorrect design specifications, high defects, and not being maintainable.

The storage of project documents is usually in a project or organization asset library to make it available to stakeholders, project leadership, and project team members. If the project asset library is an ALM, project tracking, or testing application, such as Jira, Microsoft DevOps, IBM RTC, GitLab, Version One, or HP ALM, it may be difficult for project members to access the documentation due to user licensing costs or the need for special application training. An easy storage approach for implementation documentation is to use SharePoint, Google Drive, or a file server. However, the PMO, or the organization’s IT department, may define and manage the project asset library. Specialized deliverables such as code, may require unique version control repositories like Microsoft’s GitHub.

Many organizations and integrators have project templates to help reduce documentation preparation work and to standardize the content. If the integration vendor, IT department, or PMO does not have templates for the project to use, check ISO, PMI, ISACA, or IIBA websites for templates, or do an Internet search.

Below is a list of commonly used implementation deliverables or working documents. This list can serve as a checklist for your projects. I often modify and include this list in the Project Management Plan (PMP), or in a separate deliverable document, used to gain executive project management agreement on the scope of deliverable documentation. The project you are managing may need different types of documentation not listed below based on the project’s characteristics.

The document list below is arranged alphabetically.

1. ADA Accessibility Report
2. API Design Guidelines
3. Application Architecture plan
4. Application UI and Workflow
5. Approval by the Client Security Team
6. Architecture diagram
7. Backlog
8. Budget Tracker
9. Business Process Method Strategy Document
10. Business Functional Document (FRD)
11. Business Process Flow Diagrams
12. Business Requirement Document (BRD)
13. Change Enablement KT Sessions
14. Change Enablement Plan
15. Change Enablement Project Kickoff
16. Change Enablement Project Plan
17. Change Enablement Stakeholder analysis
18. Change Enablement Training Materials
19. Change Enablement Training Sessions
20. Change Enablement UAT Support
21. Change Order Process and Request Form
22. Client Kickoff Deck
23. Code Peer Review Checklist
24. Coding Standards and Best Practices
25. COTS Setup & Configuration workbook
26. Cutover plan
27. Data Conversion Source to Target Mapping
28. Data Dictionary
29. Data Migration Approach & Plan
30. Data Migration Scripts
31. Data Process Flows
32. Deployment Checklist
33. Document management policies
34. Epics
35. ERD diagrams
36. Feature/Function/Task Release roadmap
37. Feature-function Test Run Defect reports
38. Go Live Communications Plan
39. Governance Document
40. Integration and Interface Process Design
41. Integration Technical Specifications
42. Integration Solution Architecture
43. Integration UAT Results
44. Internal Architecture Review Board Assessment
45. Internal Project Team Kickoff Deck
46. KPI List
47. KRI List
48. Load Testing/quality Reports
49. Map & Gap Matrix and Documentation
50. MBE reporting
51. Operation SOPs
52. Operations Monitoring Reports
53. Password Policy
54. Penetration testing/qualifying Plan and Reports
55. Performance Testing/quality Plan and Reports
56. Policy on Meeting Recordings vs Meeting Notes
57. Post Go-live User Survey
58. Production Release Signoff
59. Program Code Documentation
60. Project Assessment Scorecard w/ Improvements
61. Project Development Defect QA Dashboard
62. Project Discovery Deck
63. Project Issues Log
64. Project Management Plan
65. Project Team Handbook
66. Project Team Register
67. Project Road map
68. Project Risk log
69. Project Schedule
70. RACI
71. Readiness Assessment Survey
72. Release Notes
73. Report Design Documents
74. Reporting Architecture
75. Resource Plan
76. Sandbox and Application Migration Strategy Plan
77. Security ATO Review & Signoff
78. Security Guide and SOPs
79. Signoff of UAT Test Runs
80. Signoff on Sprints
81. SIT Testing/quality Reports
82. Stakeholder Register
83. Steering Committee Reports
84. System & Interface Administration Guide
85. System Prototype Demos
86. Table & Attribute Naming Standard
87. Technical Design Document (TDD)
88. Testing/quality Plan
89. Timesheet Sheets
90. Traceability Management Document
91. Train the Trainer Guide
92. Training Environment
93. Training Plan
94. Training Schedule
95. UAT Kickoff Deck Template
96. UAT Sign Off – Go / No Go – EOD
97. UAT Testing/Quality cases
98. UI/UX Design Document
99. User Guide
100. User Quick Reference Guide
101. User Roles & Responsibilities Descriptions
102. User Sprint Survey
103. User Stories
104. Web Interface Security Assessment
105. Weekly Status Reports
106. Work Tasks

Hope you find this list useful in planning your projects.