Modules by role: turning everything on kills adoption

There is a configuration decision that looks like a minor detail and defines the fate of a common data environment: which modules each role sees. The temptation is to turn everything on for everyone. It looks generous, it looks flexible, it looks like you are giving every user the maximum number of possibilities. In practice it is the fastest way to kill adoption.

I saw it up close configuring Forma for a large-scale airport infrastructure program. The pattern repeats in any project: a user logs into the platform for the first time, sees eight modules of which two are actually theirs, does not know where to start, concludes the tool is complicated and goes back to email. The platform did not fail for lack of features. It failed from an excess of visible features.

The matrix you design before inviting anyone

The alternative is boring and it works: a role by module matrix, designed before inviting the first user. The exercise is simple to describe and demanding to do well. You list the real roles of the project, not the job titles on the org chart: who reviews drawings, who manages cost, who coordinates models, who only needs to consult documents. You list the available modules. And you mark, cell by cell, what each role needs to do its job. Everything else stays off.

The drawing reviewer sees reviews, not cost. The person managing contracts and change orders sees the cost module, not model coordination. The read-only stakeholder sees documents and nothing else. Every screen looks like the job of the person looking at it, and that familiarity is what makes people come back tomorrow.

Every extra module is noise

The underlying idea is that every extra module is not generosity: it is noise. And noise gets paid in the only metric that truly matters in a CDE, which is adoption. A perfectly configured platform nobody uses is an expensive failure: the licenses were paid, the implementation was paid, and project information keeps traveling by email.

There is also a governance benefit that gets underestimated. When each role sees only its own, errors drop: nobody approves what they should not have approved or edits what they should not have touched, because the option does not even appear on their screen. The most robust permission is the module that was never turned on.

The matrix gets versioned too

One warning from practice: the matrix is not a document you make once and frame on the wall. Projects change, new roles appear, and modules that were not needed start being needed. In the airport program, no configuration change went straight to production: it was tested first in a test hub, validated with real cases and only then replicated to the production template. The module matrix followed the same circuit, because it is part of the structure, and structure gets governed the same way content does.

If your CDE has more modules turned on than happy users, the review you need is not a software review. It is a design review. And it starts with a table of roles and modules that fits on a single page.