A consultancy run by a practitioner
Callaghan IT Services Ltd was incorporated in 2013 as the trading vehicle for Adam Callaghan's independent consultancy work. The company is based in the UK, holds outside-IR35 status, and operates as a one-person practice with engagements typically running as long-form consultancy assignments rather than short-term contracts.
Adam has worked in IT since 1997. The first decade was spent in-house — designing, building, and running infrastructure across SQL Server farms, Active Directory, Exchange, Citrix, VMware, and the network and storage estates that supported them. The next seven years were spent as Infrastructure and Projects Manager at Jelf Group, integrating over fifteen business acquisitions into a corporate network of 35 sites and 1,100 users.
Since 2013, the work has been delivered through Callaghan IT Services on a contracting basis, predominantly through long-running engagements with UK Shared Business Services and the Ministry of Defence, alongside shorter engagements with private-sector clients including Pro Global Insurance Solutions and the Arts and Humanities Research Council.
The work has been consistent across that arc: solution architecture for complex IT estates, delivery leadership on programmes that need it, and hands-on engineering when the situation calls for someone who can do the work rather than just specify it.
Engagements built around delivery, not design alone
Most architecture practice ends at design sign-off. The artefacts are produced, peer-reviewed, and approved, and the architect moves to the next engagement. What happens next — the actual build, the supplier coordination, the migration weekends, the operational handover — is left to whoever is closest to it. The result is a familiar pattern: well-designed solutions that don't quite get delivered, or get delivered in a form the operational team can't sustain.
Callaghan IT Services is built on the opposite assumption. Engagements are structured around delivery, not around design alone. The work begins with architecture — solution design, target topology, supplier selection, business cases, the full artefact set — and continues until the solution is in operation, the operations team has the runbooks they need, and the business is using what was built. That commitment to delivery is what produces the cross-disciplinary breadth: the willingness to step into project management when a PM offboards, to write the training material the business actually needs, to physically deploy network kit on a migration weekend, or to build the tooling rather than just specifying it.
The pattern is recurrent across recent engagements. On the network simplification programme, that meant taking over project management when the original PM offboarded early, working the firewall migration weekends to provide technical expertise and recover migrations when they ran into trouble, and physically deploying and cabling network devices alongside the supplier delivery team. On the contact centre migration, it meant effectively running project management for most of the programme's life when no PM was in post, while still owning the security review of the supplier's build documentation, the SSO and provisioning dependencies, and the network and identity considerations for real-time voice. On the change governance transformation, it meant building the JPD-based front-door portal directly rather than specifying it for someone else to build, then producing the comprehensive training material and operational collateral that took users end-to-end through submission, triage, discovery, approval, and transition into delivery.
The practical effect for clients is that engagements absorb whatever role the project requires, regardless of what the original statement of work said. Where a project lacks a PM, project management gets done. Where a design needs hands-on engineering on a migration weekend, the engineering gets done. Where a deployment needs supporting collateral — runbooks, training material, governance documentation — the collateral gets produced. The work is delivery-shaped rather than role-shaped, and the engagement contract is the starting point rather than the constraint.
-
Architect with intent.
Solutions are designed to be built, not just to be defensible. Every artefact serves the eventual operational state, not the design review.
-
Deliver to completion.
Designs that get filed are designs that have failed. Engagements run until the operational team owns what was built — not until the design is signed off.
-
Step in where needed.
Project management, supplier coordination, hands-on engineering, training, governance — the work is whatever the project requires, and the role label is secondary to the outcome.
How engagements are structured
Engagements are delivered through Callaghan IT Services Ltd on a UK contracting basis. The company holds outside-IR35 status and operates exclusively under that classification. Standard arrangement is via a contracting agent or direct procurement, on either day-rate or fixed-fee terms depending on the engagement shape.
Long-form consultancy
Embedded into a programme or portfolio for an extended period, taking on architecture and delivery leadership across multiple workstreams.
Project-based delivery
Discrete project with defined scope, typically architecting a solution and seeing it through implementation.
Advisory
Short-form engagement to review a design, produce a business case, or provide a second opinion on a solution proposal.
SC cleared. Available for engagements at OFFICIAL classifications, including SUKEO where required.
Cross-disciplinary by design
Engagements typically draw from several of these areas at once.
Solution architecture
Networks and infrastructure
Identity and security
Cloud, virtualisation, and DR
ERP and business platforms
Programme and delivery
For new engagements and procurement enquiries
For new engagements, procurement enquiries, or initial conversations about an upcoming programme.
Contact →