A Proof of Concept is often viewed as a relatively simple exercise: configure some representative requirements, let users try the software, and determine whether the solution is a good fit.

But that description understates what can happen when an organization puts a functioning Management of Change (MOC) application in front of real users.

In an earlier article, Before You Commit: Why a Proof of Concept is the Smarter Way to Evaluate MOC Software, we discussed how a PoC can change the software-selection question from “Do we think this solution will meet our requirements?” to “We have used it. Does it work for us?”

There is another important benefit.

A well-designed PoC does not simply validate the requirements an organization already knows about. It can reveal requirements the organization did not yet know it had.

Training, data migration, integration, reporting, multilingual support, and other implementation considerations can become much clearer once people begin working with an actual system.

The PoC can therefore become more than a software evaluation. It can help shape the roadmap for the enterprise implementation.

The Requirements You Discover May Be More Important Than the Requirements You Started With

Most MOC software projects begin with requirements focused on the MOC process itself.

What types of MOC are required? What information should be collected? What lifecycle should each type follow? What checklists are needed? Who participates? What approvals are required? What actions should be generated?

A PoC is an effective way to answer those questions because stakeholders make decisions while interacting with a functioning application rather than trying to anticipate everything on paper.

But as users work through representative changes, another category of questions begins to emerge.

How will occasional users remember how to use the application? What existing information needs to be migrated? Which information belongs in MOC and which should remain in another enterprise system? What does management actually need from reporting? What will be required to deploy the solution across facilities operating in different languages?

These may not have been prominent in the original MOC requirements.

They can become important considerations for the enterprise implementation.

Training Becomes an Ongoing Requirement

Training can look relatively straightforward during software selection: develop training materials, train administrators and users, and perhaps establish a train-the-trainer program before go-live.

Then users begin working with the PoC.

An employee who works with MOCs regularly may become proficient quickly. But an engineer or operations employee who participates in an MOC only occasionally may need assistance months after formal training has been completed.

The PoC may therefore reveal that training is not simply a pre-deployment activity. Some users may benefit from short, on-demand instructional content available when they actually need to perform an activity.

This could include brief videos or other resources covering tasks such as initiating an MOC, completing scoping, responding to an assigned action, or reviewing and approving a change.

What began as an implementation training requirement can evolve into a requirement for ongoing, on-demand user support.

Data Migration Becomes Much Clearer

A PoC usually begins with a limited amount of representative information. That may be sufficient to evaluate the application, but it is not necessarily sufficient for production.

As stakeholders begin using the system, questions about existing data quickly become more concrete.

What information is required for the production environment? What historical information needs to remain accessible? What open records or activities need to be carried forward?

The exercise may also reveal that migration does not mean copying everything from an existing environment into the new system.

Some information may need to be migrated. Other information may be better maintained in an existing authoritative system and referenced when required. Some historical information may simply need to remain available for records purposes.

The PoC helps turn “we will need to migrate the data” into a much clearer understanding of what the production system actually needs.

The PoC Reveals Where Information Should Live—and How Systems Need to Connect

Document management provides a good example.

An organization’s controlled Document Vault or document library and an MOC project folder serve fundamentally different purposes.

The controlled Document Vault is the authoritative location for approved information, providing the necessary controls for document revision, version, approval and access.

The MOC project folder is a working environment. It may contain redlined drawings, sketches, data books, draft documents and other collaborative or work-in-progress information associated with the change.

For example, a redlined P&ID may be maintained in the MOC project folder while a modification is being developed. Once the change is implemented and the drawing is formally revised and approved, the controlled revision belongs in the organization’s Document Vault.

Working through that process in a PoC can reveal that a requirement such as “integrate with our document management system” needs considerably more definition.

The same principle applies to ERP, asset-management platforms and other enterprise systems.

The important question becomes:

“What information should MOC own, what should it reference, and what should come from another authoritative system?”

That is a much more useful starting point for defining integration requirements than simply determining whether two systems can technically exchange information.

Reporting Becomes a Defined Workstream

Reporting is another area where an apparently simple requirement can become considerably more specific once stakeholders begin working with the PoC.

A specification may state: “The solution shall support dashboards and Power BI reporting.”

But once users and management see actual MOC information, the discussion changes.

MOC owners may need operational information about open MOCs, assigned activities, overdue actions and items awaiting approval. Site management may want to understand bottlenecks and implementation status. Corporate Process Safety leadership may be interested in enterprise KPIs, trends and comparisons across facilities.

The PoC helps distinguish between operational reporting within the MOC application and broader enterprise analytics and business intelligence.

For organizations that use platforms such as Microsoft Power BI, it can also help define how MOC information should fit into the organization’s existing reporting environment.

What initially appeared to be a simple requirement for “Power BI reporting” may therefore become a defined reporting workstream within the larger implementation.

Discovering this during the PoC allows the organization to begin defining its reporting strategy before enterprise deployment rather than after the system is already in production.

Multilingual Support Becomes a Localization Strategy

A similar discovery can occur when an organization operates internationally.

An initial requirement may simply state: “The application must support multiple languages.”

Once the PoC is considered in the context of broader deployment, that requirement can become much more specific.

The organization may need to consider configured field labels, instructions, choices, notifications, reports, training materials and other elements of the user experience across different languages and facilities.

The PoC can therefore turn a general requirement for multilingual capability into a clearer localization strategy for subsequent site deployments.

From MOC PoC to Enterprise Implementation

Taken individually, none of these discoveries necessarily seems surprising.

What is significant is that they can emerge from a relatively focused MOC PoC.

The organization may have started by evaluating lifecycle configuration, forms, checklists, business rules, roles and approvals. It can finish the exercise with a much clearer understanding of several additional implementation requirements.

The progression might look something like:

Not every organization will follow exactly this sequence, and not every PoC will uncover the same requirements.

That is precisely the point.

A good PoC helps the organization discover its requirements.

MOC also does not operate in isolation. Changes can affect process safety information, hazard analyses, procedures, training, safeguards, startup readiness, corrective actions and other operational processes.

As the organization gains experience with the platform, it may identify opportunities to connect MOC with these related business processes. Those opportunities can then be evaluated based on experience rather than assumption.

Start Small. Learn. Then Scale.

A Proof of Concept begins with a deliberately limited scope.

That does not make it disconnected from the eventual enterprise implementation. In many cases, the limited scope is what allows the organization to learn before making larger commitments.

The organization may start by asking whether the software can support its MOC process.

By the end of the exercise, it may have learned considerably more: how users need to be supported, what information needs to be migrated, where different types of information should reside, which enterprise systems need to connect, what management expects from reporting, and what will be required to support multiple sites and languages.

These discoveries should not be viewed as evidence that the PoC has uncovered unexpected problems.

They are evidence that the PoC has done its job.

Important implementation questions have surfaced while the project is still relatively small and while there is time to make informed decisions about the eventual deployment.

The PoC has moved the organization from evaluating software to understanding what successful implementation will actually require.