Getting started
Video · 6 min read
The short answer
Watch: What does working with CSM on a construction AI system involve?
Watch the explanation, then explore the practical implications below.
From a useful demonstration to a dependable system
An app can look convincing while depending on one person who knows how it works. The business needs to know what happens when that person is unavailable, access changes or a connection fails. Dependability includes ownership, permissions, evidence, testing and maintenance.
AI-assisted coding can accelerate development. The resulting system still needs people who understand its behaviour and can assess changes. Technical expertise and knowledge of the real construction workflow need to inform the same design decisions.
Discovery: follow real work with the team
We start with representative examples rather than a hypothetical ideal process. In a tender handover, trace a requirement from the tender documents through a commercial commitment to the delivery team. Identify which version was used, who approved it and where qualifications or exclusions could be lost.
Your business owner provides priorities and authority to make decisions. Commercial, document-control and project colleagues explain the work and its exceptions. Technical contacts help establish appropriate access. CSM uses that evidence to define the problem and the practical requirements of an implementation.
Scope: make the first commitment clear
An agreed scope should state what is included, what is excluded, which systems are involved and which decisions remain with a person. It should also identify dependencies, responsibilities, costs and acceptance criteria. These make the result reviewable and help prevent assumptions becoming unplanned work.
For example, a first tender-handover implementation might prepare a draft register of commitments with source references and route it for review. Authorising a contractual interpretation or changing an agreed commitment would remain with the nominated person. The precise boundary is agreed for the implementation.
Build: test the assumptions behind the screen
Useful tests include missing attachments, conflicting instructions, outdated documents, changed permissions and failed connections. Agree what the system should do in each case: show the uncertainty, stop an action, request a missing input or notify an owner.
Check that restricted records stay restricted and that reviewers can trace a draft to its evidence. Test recovery as well as the normal path. A failed transfer should not quietly leave a team believing the workflow is complete.
User testing: can people complete the actual job?
The people who will use the system should test a complete activity. Can a reviewer see the source, correct an interpretation and understand what needs approval? Can the project team use the handover without rebuilding it in a separate spreadsheet?
Capture the reason for any workaround. It may reveal a missing field, an inconvenient step or an unresolved responsibility. Training should cover completing work, challenging an output and recovering when information is incomplete.
Controlled use: agree who supports the system
Before wider use, agree acceptance criteria, training and support responsibilities for that implementation. Name the people who monitor failures, manage access, approve changes and respond when the workflow is blocked. Define the fallback if the system is unavailable.
Support arrangements, response expectations and ongoing costs should be explicit in the agreed engagement. They depend on the scope; a demonstration should not be taken as a promise of a particular service level. Review the operational result together before extending the system.
Questions for your leadership team
What would a sensible first scope include?
Choose one workflow, identify its boundaries and name the decisions that must stay with authorised people.
What does your team need to contribute?
Identify a business owner, experienced users, representative records and the people who can grant appropriate technical access.
What would cause the system to fail in daily use?
Bring examples of incomplete documents, conflicting requirements, permission changes and connection problems.
How will you decide that it is ready?
Agree observable acceptance criteria for completed work, reviewability, exceptions and recovery.
Who is responsible after launch?
Confirm ownership of support, monitoring, access, changes and fallback procedures as part of the engagement.
Full video transcript
The full video transcript is included below for reference.
Video transcript
Someone in your construction team builds an app over a weekend to track site updates. It looks useful. People start relying on it. Then the person who built it is away, a connection breaks and nobody knows how to fix it.
The problem is the gap between a working demonstration and a system the business can depend on. AI assisted coding can be extremely useful but somebody still needs to understand the code, review the permissions, test the difficult cases and take responsibility for maintaining it. That is why the team behind the build matters.
At CSM, we bring software developers and machine learning expertise into the same conversation as the people doing the work. Kevin O’Brien leads our AI department and brings fifteen years of experience in AI alongside a computer science degree. You may not need that specialist capability full time inside your business. You do need it when deciding how the infrastructure integrations and controls should work.
Here’s how we approach an engagement: first, discovery.
We open real examples with your team. For a tender handover, we follow how requirements become commitments, how those commitments reach the delivery team and where information gets lost. We need a business owner, people who understand the workflow, representative records and the right technical access. Your commercial lead, document controller and project team tell us what good work looks like.
Second, we define the first implementation: what is included, what is excluded, which decisions stay with a person, what will count as success. Those points belong in an agreed scope alongside responsibilities and costs.
Third, we build and test the important assumptions.
A polished screen is useful but the difficult cases tell us whether the system missing documents, conflicting instructions, changed permissions and failed connections.
Fourth, we test the workflow with the people who will use it. Can they see the evidence, correct an error, understand what needs approval, complete the work without creating another spreadsheet beside the system? Then we move into controlled use with the acceptance criteria, training and support responsibilities agreed for that implementation. This is where our experience building commercial intelligence systems matters.
We have built them into over 40 businesses over the last five years. The value of that experience is recognizing the work behind the interface, connections, exceptions, ownership and the realities of daily use. We want you to understand what you are buying, what your team needs to contribute and how we will assess the result together. If you are exploring a system for your construction business, book a call with CSM.
We can show you a relevant example and work through what a sensible first scope would involve.
Start with one process that matters
Bring a workflow where delays, repeated work or unclear decisions are limiting the business. We can explore the outcome you want, what needs to change and where AI could help.