Skip to content
Hazen + AI | Troy Redding

Proposed approach

Five priorities I would assess first

This sequence is a starting point, not an implementation commitment. Selection depends on existing capabilities, data readiness and demonstrated need. I would compare a small portfolio covering firm knowledge, growth, regulatory work, project delivery and design quality.

01

Hazen Intelligence

First to assessFlagship candidate

Make project history, technical knowledge, standards, lessons and internal expertise easier to find and reuse.

Why assess first: High potential value across the firm with lower professional risk than technical decision automation.

Relevant experience: At PolicySight, I built RAG workflows with source grounding, retrieval evaluation, hallucination checks and human review.

Problem
Valuable project experience and technical knowledge can be hard to find when it is spread across years of reports, project files, standards and internal expertise.
What AI would do
Search approved Hazen sources and return relevant past projects, documents, standards, lessons and subject matter experts with links back to the source.
Likely users
Engineers, project managers, practice leaders and proposal teams.
Data needed
Approved project documents, internal standards, lessons learned, project metadata and expertise directories.
Main risk
Sensitive client information could be exposed to the wrong user or tool.
First pilot
One practice area with a bounded document set and clear permissions.
Success measure
Search time reduced, useful result rate, repeated use and source opening rate.
Approach
Extend or buy secure enterprise retrieval before considering custom model development.
Explore Hazen Intelligence
02

Proposal and RFP Intelligence

First to assess

Extract requirements, find relevant past work, prepare first drafts and check proposal completeness.

Why assess first: A repeatable workflow with measurable time savings and strong human review.

Relevant experience: At PolicySight, I built source grounded client research workflows connecting source material, analysis and human review.

Problem
Proposal teams spend significant time finding relevant experience, checking requirements and assembling first drafts.
What AI would do
Parse RFPs, extract requirements, find relevant past projects and approved content, and help prepare a first draft for human editing.
Likely users
Proposal teams, business development staff and technical leads.
Data needed
RFPs, prior proposals, approved resumes, project descriptions and standard content.
Main risk
Incorrect claims, outdated content or confidential material appearing in a draft.
First pilot
One proposal team and one proposal type.
Success measure
Proposal cycle time, requirement coverage, editing time and user acceptance.
Approach
Buy or extend enterprise tools and add Hazen specific retrieval.
03

Regulatory and Standards Intelligence

First to assess

Track changes in federal and state requirements and route relevant updates to the right practices.

Why assess first: Public source data, clear verification steps and direct value to technical teams.

Relevant experience: PolicySight combines policy monitoring, source research, analytics and stakeholder context for executive decisions.

Problem
Engineers must track changing rules, guidance and standards across many agencies and jurisdictions.
What AI would do
Monitor official sources, identify changes, summarize what changed, and route items to the right practice for verification.
Likely users
Engineers, regulatory specialists, practice leaders and quality staff.
Data needed
Public agency sources, standards metadata and internal topic ownership.
Main risk
A summary could be treated as authoritative when the source text says something different.
First pilot
One federal water topic plus a small set of state sources.
Success measure
Relevant changes identified, research time saved, source verification rate and missed item review.
Approach
Build the monitoring and routing layer using approved models and direct source links.
04

Project Controls Intelligence

Pilot

Use historical schedule, labor, cost and delivery data to identify project risk earlier.

Why pilot: Potentially high value, but usefulness depends on data quality and trust in the forecasts.

Relevant experience: At Metron, I built AI and Power BI covering schedules, materials, costs, risk and quality.

Problem
Delivery risks can become visible only after schedule, labor or cost problems are already difficult to correct.
What AI would do
Compare current project patterns with historical data and flag unusual schedule, staffing, budget or delivery signals for project managers to review.
Likely users
Project managers, PMO, finance and practice leaders.
Data needed
Historical schedule, labor, budget, change and outcome data.
Main risk
Weak or inconsistent historical data could create misleading warnings.
First pilot
Run the model in shadow mode on a small project group before any live alerts.
Success measure
Forecast accuracy, useful alert rate, earlier identification of delivery issues and PM trust.
Approach
Build the model on top of existing project and BI systems rather than replace them.
05

AI Assisted Design QA

Controlled pilot

Add another review layer that can flag potential issues without taking responsibility away from engineers.

Why controlled: The value could be high, but false positives, false negatives and professional liability require careful evaluation.

Relevant experience: I worked with engineers on battery performance and warranty models, using engineering specifications, liability constraints and human review to frame thresholds.

Problem
Technical review is important and time consuming, and some repeatable checks may be suited to automation.
What AI would do
Flag potential omissions, inconsistencies or rule violations for a qualified engineer to review.
Likely users
Design engineers and QA staff.
Data needed
Approved design documents, review checklists, standards and historical issue records.
Main risk
Missed issues or false confidence in an automated review.
First pilot
One narrow document type or repeatable check, not full design approval.
Success measure
Review time, useful finding rate, false positive rate and issues caught before final review.
Approach
Buy or partner first where mature tools exist. Do not build a broad design model from scratch before proving the use case.

What I would not prioritize first

Building a proprietary foundation model

Enterprise models already exist. Hazen's advantage is its data and expertise, not training a new general model.

Autonomous engineering approval

Licensed engineers keep final responsibility for engineering work.

Generic meeting transcription as a strategic program

Useful as a standard tool, but it does not need a strategy of its own.

A large collection of disconnected pilots

Many small tests spread attention and make it hard to prove anything.

The first year should prove that a small number of useful systems can improve work without weakening professional responsibility.

Build, buy, partner or wait

Build

When Hazen data or methods create a real advantage and the capability needs to be unique.

Buy

When the problem is common and a mature enterprise product already exists.

Partner

When a client, vendor or research partner brings data or expertise Hazen does not need to recreate.

Wait

When the value is unclear, the risk is too high, or the data is not ready.

Applied to the five priorities

Hazen Intelligence
Buy or extend
Proposal and RFP Intelligence
Buy or extend
Regulatory and Standards Intelligence
Build the source and routing layer using enterprise models
Project Controls Intelligence
Build on existing BI and project systems
AI Assisted Design QA
Buy or partner first