Project Summary: Enterprise Systems

Congratulations! It’s time to celebrate!

The system is live. Users are using it as designed and tested (and as they were trained). Go Live support activities are complete. All issues are acceptably resolved. Documents are finalized and approved. The team has met to debrief and capture learnings for future projects. The system has been handed off for ongoing operations. There’s only one thing left to do: prepare the Project Summary to summarize the project activities and signify the project is closed out.

This is an internal document but may be used for compliance purposes (SOX, GxP) and/or to inform others unfamiliar with the project.

This will echo the Project Document and will include a summary of deviations from the planned activities, scope, etc. from the Project Document.

Who creates: the Project Manager.

Who approves: the Business System Owner at a minimum. For controlled systems (SOX, GxP), additonal approvals may be required. The Business System Owner may want functional leads and/or the Executive Sponsor to sign off as well. For GxP systems, I recommend including Quality Assurance.

When: this is drafted a few weeks before project close out to confirm there are no outstanding items. Once finalized and signed, the project is officially closed out and complete.

What’s Included

Summary of the project: references the original Project Document and approvals, purpose of the summary document, general assessment of the project (successful or not), and any other high-level, pertinent information.

Project objectives: lists the project objectives from the Project Document and whether each objective was met. This may include additional explanations if necessary.

Implementation objectives: lists the implementation objectives from the Project Document and whether each objective was met. This may include additional explanations if necessary.

Acceptance Criteria/Success Factors: lists the acceptance criteria / success factors from the Project Document and whether each was met. This may include additional explanations if necessary.

Meetings: if meetings were detailed in the Project Document, a summary of what was done in comparison to what was planned is included in this section.

Issue tracking: summarizes how issues were tracked, who tracked them, whether issues were effectively resolved, and if there are open issues, how they are going to be managed after Go Live.

Project and system change control: summarizes what occurred during the project and the plans to manage in a controlled fashion after hand off for ongoing operations (if applicable). Note: whether required for SOX or for GxP purposes, I always recommend managing enterprise systems in a controlled fashion.

System documentation and documentation management: summarizes where system documentation is stored for future reference and if there is ongoing document management, how that will be handled. Note: if the documents are in the implementation partner’s system, all of the project documents and deliverables should be exported and stored in a company-owned/controlled location.

Deliverables: lists all of the deliverables defined in the Project Document, and others if generated during the project. If deliverables were not generated as defined in the Project Document, an explanation is provided.

Training / Go Live support: summarizes the training performed during the project. If there were deviations from the Project Document, an explanation is provided.

Standard Operating Procedures (SOPs), Quick Reference Guides: summarizes the procedures and guides (work instructions) generated during the project. If there were deviations from the Project Document, an explanation is provided.

Testing: summarizes the testing performed, by whom, when, and the purpose of each type / cycle of testing.

Production cutover: summarizes production cutover activities and may point to a production cutover summary document for more details, rather than including all of them in this document.

Data migration: summarizes the data migration and verification activities as defined in the Project Document and as executed. This section may reference a data migration summary document for more details, rather than including all of them in this document..

Go Live: summarizes the Go Live timeline including the Go Live memo. This may also include when and how users got access to the system and the users with elevated access as of project close out (recommended especially for SOX systems).

Disaster recovery / business continuity: summarizes how this is/was addressed for the system.

Open items: details any open items at project close out including the owner / responsible party for each item.

Approval: statement approving the summary document and declaring the project officially closed. Note: since most projects are now virtual, this approval is generally obtained using an eSignature tool like Adobe Sign or DocuSign.

Other Things to Note

The sections of the document should echo the Project Document and therefore may be different from what is noted above.

When drafting this document, include information that would be helpful to someone who is completely unfamiliar with the system and project, and would be helpful to understand what occurred during the project. Imagine everyone from the project is gone from the company and this document is the only thing left to provide the roadmap or history of what occurred.

Why Share This Now?

Back when I was an accountant, working for my dad’s accounting firm, we had a lot of small businesses as clients. The owners of the small businesses struggled with basic bookkeeping and accounting which meant that we couldn’t add value to them and their businesses because we were so focused on the fundamentals. We created a few accounting classes for them in the form of Accounting 101, 102, 201, and 202 so we could do more with them.

I’m applying the same principles here. If I can help my clients (prospective or current) help themselves with projects and project deliverables, then I get to elevate my role beyond the day-to-day and into a strategic and advisory role which, frankly, is a lot more fun!

Check out my blog post Project Deliverables: Enterprise Systems for the complete list of deliverables with links other blog posts.

Have Questions or Require Assistance?

Feel free to reach out to Terri with any questions you might have via email at terri.mead@solutions2projects.com or through the company website SolutionsProjects, LLC.

About the Author

Terri Hanson Mead, MBA, PMP, is a technology and compliance strategist for biotech, pharma, medical device, diagnostic, and digital health companies. Through her company, Solutions2Projects, she helps life sciences companies align technology roadmaps with corporate objectives and meet IT compliance requirements in a complex and regulated industry. As an expert witness, Terri provides pre-litigation consulting and expert witness services for failed technology projects, including enterprise systems.