From Manual to System: Turning the NPMO Process Architecture into Something People Use

In the first article of this series I argued that a Project Management Office without a Project Management Information System is a reporting department rather than a governing function. This article deals with the mechanics of closing that gap: how a written process framework becomes a system that people use because it is the path of least resistance, not because they have been instructed to.

The NPMO framework issued by Mashroat is comprehensive. It describes the processes an entity should run across the project life cycle, the roles accountable for each, the decisions to be taken at each stage gate, and the deliverables that support them. It is a serious piece of work and the entities adopting it are not short of guidance.

The difficulty is one that every organisation which has ever written a procedures manual will recognise. A process written in a document is an instruction. A process built into a system is a behaviour. Instructions are followed when people remember them, have time, and understand why. Behaviours happen by default.

The three components of a digitalized process

Any process in the NPMO framework, when properly digitalized, resolves into three components.

The record. What information is captured, in what fields, with what validation, referencing what other records. A variation request is not a memo. It is a record with an originating instruction, a cost impact, a time impact, a WBS allocation, a contract reference, supporting attachments, and a status.

The route. Who reviews the record, in what order, within what time limit, and what happens if they do not act. This is where the delegation of authority stops being a table in a policy document and becomes a set of rules the system enforces.

The evidence. What is attached, what is referenced, and what audit trail is created. In a digitalized process the evidence is not stored alongside the record. It is part of it.

PMWEB is built around exactly this structure. Records are created from configurable forms. Routes are configurable workflows with defined actors, sequences, conditions and escalation. Evidence is attached to the record and inherits its permissions, versioning and retention.

Configuration, not customisation

There is a distinction here that determines whether a digitalization programme succeeds or becomes a permanent development project.

If digitalizing a process requires software to be written, the entity has bought a development obligation. Every change to the process — and processes change, particularly in the first two years of a new entity — becomes a change request, a cost, a test cycle and a delay. Over time the organisation stops improving its processes because improving them is expensive. The system, which was bought to enforce good practice, ends up freezing whatever practice happened to exist on the day it was configured.

If digitalizing a process is a configuration activity performed by the entity's own PMO staff, the opposite happens. Processes are refined continuously. The system tracks the organisation rather than constraining it.

This is why the evaluation question for a PMIS is not "can it do X." Almost any platform, given enough budget and time, can be made to do X. The question is: who can make it do X, how long does it take, and what happens the third time the process changes.

Mapping the life cycle

A practical mapping exercise for an NPMO-aligned entity looks roughly like this. I present it as an illustration of method rather than as a prescription, because every entity's adoption of the framework has local characteristics.

Initiation and business case. Need identification, feasibility, benefits definition, initial budget estimate, stage gate approval. These become forms with defined approval routes and a permanent link to everything that follows, so that at any later point the question "why are we building this" has a documented answer.

Planning and design. Design brief, consultant appointment, design submissions and reviews, design change control, value engineering, cost planning, procurement strategy. The design review cycle in particular is a high-volume, high- latency process that benefits enormously from digitalization.

Procurement and award. Prequalification, tender issue, clarifications, evaluation, award recommendation, contract creation. The contract record created here becomes the parent for every commercial transaction over the following years.

Construction. Progress measurement, payment certification, variations, claims, RFIs, submittals, site instructions, inspections, non-conformance, safety observations, daily reports. This is where volume lives, and where a system either earns its place or does not.

Commissioning and handover. Testing records, punch lists, snagging and de-snagging, as-built documentation, O&M manuals, warranties, asset registers, training records.

Operation. The asset register, the warranty position and the maintenance history — the reason the handover documentation was collected in the first place.

The delegation of authority is the heart of it

Of everything described above, the component that most directly serves the governance objective is the encoding of the delegation of authority into workflow rules.

Consider a variation order. The entity's DOA might specify that variations up to a certain value are approved by the project director, above that by the executive committee, and above a further threshold by the board — with additional rules where the cumulative value of variations on a contract exceeds a percentage of the original sum.

In a document-based environment, compliance with that table depends on individual project managers knowing the rules and applying them correctly under time pressure while a contractor waits. Non-compliance is usually discovered by internal audit, long after the money is committed.

In PMWEB, the value in the record determines the route. There is no discretionary step. The variation cannot reach execution without passing through the authority level the rules require, and the record permanently shows that it did.

This single capability changes the character of governance in an entity. It converts a policy that is audited retrospectively into a control that operates continuously.

Why the phasing matters

A word of caution for entities beginning this journey. The instinct is often to configure the entire framework before going live, on the reasoning that a partial implementation is an inconsistent one.

In practice this is the most reliable way to produce an implementation that never goes live. The processes take months to configure, the organisation changes underneath them, and the first release arrives already out of date and unowned.

The approach that works is to prioritise by volume and pain. Identify the processes that generate the most transactions and the most disputes — typically payment certification, variations, submittals, RFIs and progress reporting — and

What the stakeholder should take from this

If you are assessing whether an entity's PMO is real, the diagnostic question is not whether it has a manual. Most do. The question is whether the processes in that manual exist anywhere other than the manual.

Ask to see a variation approved last month, and follow it back to the instruction that caused it and the authority that permitted it. Ask how long it took, and how that compares to the target. If the answer to both requires someone to go and look, the framework has been adopted on paper.

Next in the series: how accountability stops being a value and becomes a property of the record.