Service
When an IT project ends in a dispute, the questions can involve both technical performance, whether the system did what it was required to do, and the causes and history of delivery failure: who did what, what the records show, and whether the parties met their obligations. That analysis has to be independent, technically sound and explained so that lawyers, mediators and tribunals can follow it.
Instructing solicitors and counsel acting for a customer or a supplier; in-house legal teams facing a failed programme; and mediators or arbitrators who need the technical history of a project set out neutrally. The work is technical expert analysis. It is not legal advice, and it does not take the place of your legal team.
An expert's duty is to the court or tribunal, not to the party paying. That principle shapes the work: conclusions follow the evidence, unhelpful findings are stated as plainly as helpful ones, and the analysis is written so that the other side's expert can engage with it. The Role of Experts in the Courtroom episode below discusses how that duty is framed across jurisdictions.
Dr Carlton's doctorate studied the failure of a very large public-sector IT programme in depth, and the resulting papers on situational incompetence and on competence versus confidence in project leadership describe the patterns that recur in failed projects. His current research at RMIT University's School of Law concerns the consequences of project failure: how accountability is apportioned, how courts weigh causation, and the role of alternative dispute resolution.
Why do IT projects still fail when the causes are well known? Using multi-grounded theory on a major Australian IT project, this paper examines the lack of domain expertise among senior management and vendor representatives, and reads the decisions of the people involved through the Kruger-Dunning effect.
A qualitative study of a large public-sector IT project whose cost overrun exceeded AUD 1 billion, drawing on 181 interviews and 5,000 pages of project data. It develops a theory of situational incompetence and proposes an instrument for gauging leadership competence as project size and complexity grow.
Why large projects fail, drawing on the research behind the author's doctorate and the patterns that recur across failed IT programmes.
Expert witnesses serve the court, not the party paying them, yet the rules differ sharply across major jurisdictions. The episode surveys those frameworks and asks how AI is beginning to reshape expert testimony.
On the growing number of documented cases of lawyers filing fabricated, AI-generated citations, and the governance gap between deploying AI tools and professional competence in using them.
How courts in different jurisdictions have responded to generative AI, from categorical prohibitions on AI-generated witness evidence to permissive positions, and what that divergence means for anyone preparing evidence.
Either. The analysis is the same whichever side instructs it, and the conclusions are the ones the evidence supports.
Yes. An early assessment of the technical merits, scoped to a defined bundle of documents, is often the most useful first step.
Instructions come from several jurisdictions. The technical analysis is the same everywhere; the form of the report and the expert's procedural obligations follow the rules of the forum, which are confirmed with the instructing team at the outset.
Technical dispute-resolution support is available: helping parties and mediators understand the technical facts so that a resolution can be reached on an informed basis. Whether that is appropriate in a matter where an expert role is also contemplated is agreed with the legal team.