Configuration / Specification Documents: Enterprise Systems

Documentation has saved me on so many occasions that I’ve lost count at this point, and the most powerful project document for use in ongoing operations, when done correctly, is the Configuration Document. Sometimes these are called Design Specifications. Regardless of the title, the purpose of the document is to capture the configuration settings and parameters along with context. Note: for the purposes of this post, I will refer to design specifications and configuration documents as Configuration Documents.

This provides folks who may not have been a part of the implementation project with the guide to how the system was set up, and why. The better the explanations and the more detailed the info, the more effective the tool.

As changes are made to the system, the Configuration Document is updated to reflect the changes.

It is possible to break down the configuration into multiple documents if it makes sense to do so. In my last project, we had Design Specification documents for each of the custom elements as they were fairly detailed. The main Configuration Document pointed to the sub-documents and the sub-document Design Specifications pointed to the Configuration document to provide a more complete picture.

I’ve been called into clients to assist with issues and the first document I look at is the Configuration Document. I can’t always remember why we decided on a setting or a process, but if we created a Configuration Document, it’s much easier to assess the situation. I even wrote about it in a blog post in 2017.

Who creates: the internal Business Analyst, assuming there’s one on the project team. If not, sections can be assigned to the functional leads and the Project Manager can be responsible for consolidating into a single document (or set of documents). Note: this is a client document and should not be left to the implementation partner to create.

Who approves: for controlled systems (SOX, GxP), approvals are generally required. For others, it depends on internal business process requirements and what was defined in the Project Document. Systems subject to SOX have documents that are approved by the functional leads and Business Sponsor. Validated system (GxP) documents are approved by functional leads, the Business Sponsor, and QA in alignment with document control procedures.

When: this document is generated after the initial Go Live period and prior to project close out. This is an ongoing operations tool for the client / customer to manage and control the system and should be revision controlled.

What’s Included

Purpose: defines what is included in the document and why the document exists.

Scope: details what is and is not within the scope of the document and for the most part, what is in and outof scope for the system, too.

Document owner: specifies who is responsible for ensuring that the document is maintained and updated for the life of the system. This isn’t necessarily (and generally isn’t) the person who will be updating it, rather it’s the person who will be approving, at a minimum. Typically, this is the Business System Owner.

General notes: I like to see assumptions and context provided for all project and system documents to provide readers / consumers with a complete picture of the document, the scope, and it’s purpose. This is the section for all of this and for anything that may provide greater clarity, assuming it’s not captured elsewhere in the document.

Related documents: a system doesn’t operate in a vacuum and references to other documents included in the Configuration Document should be noted to make it easier to manage the system. If there are document dependencies (like the FRS), having it referenced in the document makes it easier for change management.

Configuration: I like to see the configuration settings captured in screenshots with explanations. If the configuration is subject to change control (for SOX or GxP validated systems), I include a statement to this effect in each section. This makes it easier for administrators (and functional leads) so they don’t have to guess what is simply maintenance versus what should be managed through change control. I also include dependencies. For example, if configuration in one part of the system is logically linked to another part, it’s helpful to have this called out so that someone who is not familiar with the configuration and business processes is more easily able to see this connection and avoid unnecessary and preventable issues.

Other Things to Note

At first glance, this may appear to be a lot of work and if there are constant changes to the system, the work may feel like it’s not adding value. Most of the systems I work on, or have worked on, have been subject to some level of compliance requirements and that means change control. A critical step in every change control process is assessing the impact of changes. If there is a Configuration Document, and there are good explanations for each configuration section, the impact assessment process becomes manageable.

How long is this document? It depends on the complexity of the system and the thoroughness of the explanations. I’ve created documents that are 50 pages (screenshots can take up a lot of space) and up to 130 pages. Some Design Specifications (sub-documents) might only be 3–10 pages.

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.