Model-based vs Document-centric Project Structures

Author: Zeb Geary

Date: July 2024

Audience: Organization and Project Admins

Products Applicable: Jama Connect®

Use Case

Model-based vs Document-centric Project Structures

Best Practice

Regardless of industry or company size, when deploying Jama Connect, teams must decide how best to structure information in their Jama Connect projects. Typically, the following two approaches are considered:

• Model-based Product Structure: Projects are structured to align with the hierarchical breakdown of product definition (e.g., system/subsystems) and/or the organization of teams/disciplines.
• Document-centric Structure: Projects are structured to align with documentation (i.e., export) needs, whereby the project's Explorer tree is organized as if the Table of Contents for the document.

In the example below, the Model-based Product Structure is organized by levels of requirement abstraction and disciplines. Contrast that with the Document-centric Structure, where components in the Explorer are essentially "documents".

Model-based Product Structure	Document-centric Structure

Teams that do not require documentation outside of Jama Connect prefer the Model-based Product Structure. However, in some cases, like when transitioning from MS Word, even teams that do not require documents attempt to control the impact of change and reduce new-tool resistance by mimicking the document-style organization of requirements in their project. This may be a short-term transition solution that helps increase adoption by building out a familiar structure into their projects. Long-term, they will tend to restructure projects to take advantage of logical groupings by requirement types, levels of abstraction, and disciplines.

Teams requiring documents from Jama Connect, such as regulated companies generating documents for their quality/audited systems, may feel the only option is to implement the Document-centric Structure. However, as described below, there is another option for these teams. This option provides the benefits of a Model-based Product Structure while still producing the desired documentation attributed to the Document-centric Structure.

For teams that need to generate documents from Jama Connect, consider the purpose of the documents:

• Are documents serving simply as a hand-off with another team? In this case, there may be some flexibility in the export format, allowing teams to organize Jama based on "how we work" vs. the document.
• Are documents generated for auditing purposes or required per Operating Procedures? Here, the documentation needs and format may outweigh other needs or preferences.

Even if Jama Connect is used to generate audited documents, it may still be worth exploring options to support both document needs and alignment with "how we work" (e.g., requirements grouped by levels of abstraction, teams, etc).

An approach to accommodate both makes use of Advanced Filters. Advanced Filters can query across the project for items in varying locations and of different types. With this approach, teams can consider using the structure to accommodate their preferred organization within projects (for ease of use, permissions and locating data) while using an Advanced Filter to query across the project and export documents.

As an example, the Medical Device Framework provided with our Medical Device Services Offering is configured to accommodate functional and discipline-based organization of items while meeting documentation needs using Advanced Filters. The Model-based Product Structure shown above from the Medical Device Framework is organized around the levels of abstraction using a Systems Engineering V-Model approach. Documentation needs are handled by Advanced Filters, shown below. Note, below, that the Project Overview set found in the project structure is included in each filter using a Filter Rule. 

Continuing to use Medical Devices as an example, the framework also provides a document-centric project structure to simulate a device's design history file (DHF). This document approach allows teams to work in Jama Connect to create, review, and export documents for submission to the Quality Management System (QMS). This is a straightforward approach that includes contextual information like Introduction, Scope & Objective, and Reference sections that compliments the traceable information (requirements, risk) that is commonly seen in industry.  Report templates can then be configured to match final format and content, so when exporting the document from Jama Connect, it complies with the organizations's documentation requirements.  This is especially critical in regulated industries, as external auditors will be reviewing documents against the organization's procedures and requirements.

Please note that although the examples above call out Medical Devices, the decision on how to structure the Jama Explorer tree applies to any organization using Jama, no matter the industry.

Different teams using a single instance of Jama Connect may have different needs and therefore require different project structures. Jama Connect can accommodate these differences, project to project. Additionally, as teams continue to use Jama Connect, their needs may change and so may their organizational preferences. Over time, projects can be updated to accommodate the changing needs of the team. This means that no matter the approach decided upon initially, adjustments and improvements can be made.

Need help determining how best to configure you instance of Jama Connect or need assistance optimization your use of Jama Connect? Jama Software can help. Please see the following Solutions Offerings*:

• Data Model & Configuration Consultation
• Optimization Session

*Please note, Solutions Success Program required. Please speak with your Jama Software Customer Success Manager for more information. 

Please feel free to leave feedback in the comments below.