Systems.

The ecosystem around the tool

We trace where information begins, who changes it, which system becomes the source of truth and where the same fact is entered again. Project and finance systems may each be internally correct while reporting different numbers because they answer different questions or recognise work at different times.

Capacity planning, job costing, reporting and automation are connected choices. We assess the relationships between them as well as the available features, because improving one area may expose a weak definition or handoff elsewhere.

Selection, configuration and migration

In architecture and construction firms observed during Anita's research, teams budgeted work as a matrix: project phases across one axis, with internal fees, contractors and other costs grouped within each phase. One platform stored the same information as two flat lists. The phase totals then had to be reconstructed outside the system. More training could not alter that data structure.

We assess those product assumptions before selection. Can the data structure represent the way work is quoted and delivered? Does the information exist where a report needs it? Which exceptions can be configured, and which would force the team into another side system?

Where a change proceeds, the work can include workflow and data design, configuration, integration, migration planning, reporting and adoption support. An existing tool may remain in place if the assessment finds that it still fits the work.

Working in live systems

Assessment is read-only by default. Proposed changes are previewed before anything is written, and live records are not changed without an explicit go. Testing belongs in demo data.

Why systems come third

Software is chosen after the work practice and the operating decisions are understood. What we learn becomes the specification used to assess, select and configure the system.