Describe the Form, Get the Form

Here is a pattern familiar to anyone who has run a configured PMIS for more than two years.

A process changes. The form in the system no longer matches how the work is actually done. Someone raises a change request. It is scoped, quoted, queued, and scheduled behind three other things. Six weeks later it arrives, by which point the team has developed a workaround, and the workaround is now the process. The form is updated anyway. Nobody uses the new field.

Repeat this a few times and an organisation stops asking. The configuration freezes at the point the implementation ended, the gap between the system and the work widens quietly, and the shortfall is eventually attributed to the platform.

Repeat the change request cycle a few times and an organisation stops asking. The configuration freezes, the gap between the system and the work widens quietly, and the shortfall is eventually attributed to the platform.

What changes

In PMWEB 2026, an adaptive form — its sections and its fields — can be generated from a plain-language description. In the demonstration, a safety inspection form was produced from a description of what it needed to capture.

The mechanics matter less than the change in cycle time. A form that would have been a change request becomes a task completed in the meeting where the need was identified.

The control that keeps this safe

The first reaction from anyone responsible for a large configuration is alarm, and it is the correct instinct. A system in which any user can generate forms is a system that will contain four hundred forms within a year, of which perhaps sixty are used and none reconcile for reporting.

Form-creation rights still apply. This is not every user redesigning the platform. It is the people who already hold that authority doing in minutes what previously took a cycle.

The distinction is worth being precise about when this is presented internally, because the objection will be raised and the answer is straightforward: the authority model does not change. What changes is how long it takes the people who already have that authority to act on it.

It is the same principle PMWEB's Intelligence Control Framework applies across the platform, stated as AI advises, the operator decides. Here the AI proposes the structure of a form. A person who holds form-creation authority decides whether it becomes part of the configuration.

What it means for a PMO

The interesting consequence is not speed. It is that process governance becomes iterative.

Under a change request model, every configuration decision carries the weight of being difficult to reverse. That makes people cautious in the wrong direction. They over-specify at implementation, because a field they might need later is cheaper to add now than in eighteen months, and the result is a form with fifty fields of which twenty are populated. The cost of that caution is paid every day by every user. it is wrong. A form that is not working in month two gets corrected in month two rather than surviving until the next major review, and the system stays close to the work.

The cost of a change request is not the change request. It is the over-specification that organisations adopt to avoid needing one.

What it does not solve

Generating a form is not governing one, and the distinction should be stated plainly rather than discovered later.

A generated form still needs naming conventions consistent with the rest of the system, so that reporting can find it. It still needs its fields mapped to the controlled value lists the organisation uses, or it produces free text where the rest of the platform produces structured data — and free text is precisely the substrate problem this series began with. It still needs a workflow, an owner, and a decision about who sees it.

None of that is generated. The bottleneck moves from building the form to governing it, which is a considerably better place for the bottleneck to sit, but it does not disappear and no organisation should plan as though it has.

The practical position

For a PMO, the sensible response is to treat this as a change in the economics of configuration rather than as a new feature.

It means the configuration standard becomes more important than it was, because the volume of configuration decisions is about to increase. Write down the naming convention, the value list policy and the approval route for a new form before the capability is enabled, not after. Organisations that do this get an iterative system. Organisations that do not get four hundred forms.

Write down the naming convention, the value list policy and the approval route for a new form before the capability is enabled, not after. Organisations that do this get an iterative system. Organisations that do not get four hundred forms.

Next week: what a project summary has to do before anyone can act on it.