AI for Major Projects

101: give AI a clear job

Begin with work that someone already needs to do: finding an approved requirement, checking a submission, preparing a report or identifying an exception. Name the user, the input, the expected output and the decision it supports. Explain where the current process causes delay, rework or missed information. A compelling demonstration is a starting point for investigation, not evidence that the project needs a deployment.

Different tasks need different methods. Document retrieval, prediction and generating narrative are not interchangeable capabilities. Compare the proposed AI approach with a clearer procedure, an improved report or ordinary automation.

Choose a first application you can evaluate

Choose a limited task with accessible examples, an involved user and someone accountable for the outcome. Consider how an incorrect answer would be detected and what it could affect. Avoid expanding the pilot across cost, schedule, procurement and engineering before one workflow has a clear purpose and evaluation method.

• Record the current process, effort, common errors and review requirements as the comparison baseline.
• Define useful improvement in terms the user recognizes, including the effort needed to check the output.
• State the pilot boundary, owner, decision date and evidence needed to continue, change direction or stop.
• Select representative examples, including awkward cases that a polished demonstration might omit.

Establish the data and access the task needs

Use the Data for Major Projects guide to establish definitions, source ownership and reporting periods. Decide which documents or records the application can use and how it will distinguish current, superseded and draft information. Confirm that the people using the application are entitled to see its sources and outputs.

For a reporting pilot, identify the exact period and harvest it should analyze. Keep a route from each material conclusion back to supporting records. Where inputs are missing or conflicting, define the expected response before testing. An answer that identifies the missing evidence may be more useful than a fluent conclusion that fills the gap without support.

Build a small pilot around the working process

Decide what to buy, configure or build after defining the task. Sketch the complete workflow, including preparation, human review and the handoff into existing systems. Keep the first version narrow enough that a project specialist can inspect its behavior and explain its limitations.

Illustrative pilot: draft a package-status narrative from a reviewed reporting snapshot. Require the draft to identify changes, cite the supporting records and mark missing explanations. Calculate numerical comparisons through reproducible rules, then check whether the narrative represents them correctly. Have the responsible report author review the draft before use.

Test the result before deciding to roll out

Agree acceptance criteria before reviewing the pilot's best outputs. Compare the application with the current process on the same examples. Examine factual accuracy, completeness, source traceability, handling of uncertainty and the effort needed to review and correct the result. Set accuracy, review-effort and improvement thresholds for the actual task.

• Test conflicting source versions, missing fields, ambiguous requests and cases outside the intended scope.
• Check that a reviewer can identify where an answer came from and challenge an unsupported conclusion.
• Include representative users and record disagreement instead of averaging away a serious failure.
• Record what failed, why it matters, what changed and which tests must be repeated.

Make ownership and review part of the implementation

A working pilot still needs an operating process. Name who maintains the sources, who checks material outputs, who supports users and who can stop the application. Define which actions remain proposals and which, if any, the system may perform. Match review and approval to the consequence of error and the project's existing responsibilities.

Train people on actual examples, including failure cases. Explain the limits of the application and the route for correcting it. Keep a usable fallback when the system or its inputs are unavailable. A rollout decision should include the ongoing work of support, evaluation and source maintenance, not only the initial configuration.

Current practice: a review agenda for October 2026

Treat new tools and features as candidates to test against the same project need. Keep a small set of representative evaluation cases and rerun them when the model, source collection, instructions or workflow changes materially. Record the version and date used for the comparison.

Prioritize improvements that make the workflow easier to inspect: explicit source references, clearly marked uncertainty, reproducible calculations and a reviewable record of proposed changes. When a demonstration introduces agents or automated actions, examine the permissions and failure recovery as carefully as the successful path.

Lessons from the field: earn the case for the next step

Distinguish an idea, a demonstration, a pilot and an operating application when sharing lessons. Record the users, conditions and evidence behind a result. Do not transfer a success claim to another project without checking its data, workflow and constraints.

Expand when the team can explain what works, what fails and who will operate the next version. If the pilot does not justify continued investment, retain the learning and stop or redesign it. The useful outcome is a better project process, including a clear decision about where AI does and does not help.