# Tenhaw services and use cases Tenhaw is a UK AI consultancy and AI delivery partner based in London. We build AI products and workflows, design operating models and develop your team's capability. We also lead programmes across your teams and suppliers. Index: https://tenhaw.com/llms.txt Full corpus: https://tenhaw.com/llms-full.txt Illustrative resources are teaching examples, separate from delivered client evidence. Cite the native page below. ## AI Readiness Audit Source: https://tenhaw.com/services/ai-readiness-audit Last updated: 2026-11-05 { "slug": "ai-readiness-audit", "rung": "01", "name": "AI Readiness Audit", "track": "Way in", "tagline": "Find the AI workflows worth funding. Test them with your team.", "metaTitle": "AI readiness audit consultancy | £44,000 fixed", "metaDescription": "Tenhaw's four-week AI readiness assessment tests workflows in your tenancy. Working prototypes and a costed investment plan for £44,000 fixed, excluding VAT.", "summary": "Tenhaw's AI Readiness Audit is a four-week AI readiness assessment across your product, internal processes, operations and software delivery. We work with your team to test two or three promising workflows as working prototypes against your real data, inside your own tenancy. The fee is £44,000 fixed, excluding VAT.\n\nBring the work your people know best, including the exceptions that make it interesting. Their examples and feedback shape what we test. You leave with the prototypes and a costed plan in three-month increments, capped at twelve months, ready for your board to decide what to fund. The code lives in your repositories; you own the deliverables on payment, whether or not you continue with us.", "summaryLink": { "text": "Our specialty-insurance case study follows discovery in month one and a two-week proof of concept in month two, showing how understanding the workflow shaped the build.", "href": "/case-studies/specialty-insurance-agentic-lead", "label": "See how discovery informed an insurance build" }, "banner": { "title": "See workflow discovery in practice", "detail": "Workflow discovery at Placing Platform Limited (PPL) shaped a working proof of concept, built in two weeks with a client engineer.", "link": { "label": "Read the PPL proof of concept", "href": "/case-studies/specialty-insurance-agentic-lead" } }, "priceLabel": "Fixed price · £44,000", "priceLow": 44000, "priceHigh": 44000, "timeline": "4 weeks", "commitment": "Agreed scope and deliverables, fixed fee", "howItEnds": "The audit ends with working prototypes, a board readout and a costed plan. Code lives in your repositories from day one. Any further work is a separate decision and agreement.", "badge": "Start here", "teamShape": "James Rooney leads every audit personally, with a senior operator exploring the work alongside your teams and a build engineer developing the prototypes with your engineers.", "engineerNote": "A build engineer pairs with your engineers to develop and test the two or three agreed prototypes in your tenancy. The fee is based on five days of partner input, twenty days from a senior operator and nine engineer days. Published day rates are £1,560 for James Rooney and £1,250 for each senior practitioner; the £44,000 is a fixed fee for the agreed deliverables.", "rolesLede": "If you are appointing a Head of AI, the audit can help define the work they will lead. If they are already in post, we can work with them to test priorities and shape the investment case.", "roleEngagementNote": "The audit is a four-week engagement with agreed deliverables and a fixed fee. You work with senior practitioners, screened to BS7858 standard before client access and contracted to written confidentiality and data-handling terms. They are accountable to James Rooney as well as to you. There is no introduction fee or permanent-placement conversion clause. Either party can end a fixed-price engagement on written notice, with fees due for work performed and committed costs incurred up to termination.", "roles": [ { "title": "Support for a Head of AI", "alsoCalled": [ "Head of AI", "AI strategy lead", "Chief AI Officer" ], "detail": "The four weeks establish which opportunities deserve attention, what your data and platform can support, and what your people need to make progress. A new AI leader can use that evidence to shape their priorities, team and budget. The audit can also help you write the role specification while you recruit a permanent leader." } ], "rightFor": [ "Boards deciding which AI opportunities deserve investment", "Engineering teams exploring how AI could improve software delivery", "Product teams choosing where AI could help their customers", "Teams trying to understand a stalled Copilot or Gemini rollout", "Businesses mapping informal AI use and the work it supports", "Organisations reviewing overlapping tools bought by different functions", "Leadership teams bringing different views of AI readiness into one plan", "Buyers seeking operational AI due diligence before an acquisition or investment", "Sponsors testing the scope and assumptions of a proposed programme" ], "notFor": [ "Teams with a current assessment and one well-defined workflow to test: consider a proof of concept", "Teams choosing licences against an already agreed specification: a procurement exercise may fit better", "Organisations seeking formal legal, regulatory or certification assurance: use the relevant specialist", "Sponsors whose investment decision is settled and who cannot act on different findings" ], "deliverables": [ "Two or three working prototypes, built with your engineers against real data in your tenancy, with measured accuracy, an assessment of confidence in the results and an estimated run cost for each", "A heat map of opportunities across product, internal processes, operations and software delivery, ranked by expected return and feasibility", "A record of data, platform, risk and regulatory constraints, including what would need to change", "A view of how AI could improve software delivery, using your current delivery data as the baseline", "A practical assessment of the skills, time and support your people need to use the proposed workflows", "Changes to roles, decisions, incentives and working practices that would help adoption", "A costed plan in three-month increments, capped at twelve months, with dependencies and review points", "An investment case your finance team can examine, with assumptions and confidence attached to the figures", "Prototype code and written findings you own on payment of the applicable fees, with production work scoped separately" ], "phases": [ { "label": "Week 1", "detail": "Explore the work together. Your team walks us through real tasks across product, internal processes, operations and software delivery: the routine steps, the handoffs and the cases that need judgement. We review delivery data, map AI tools already in use and agree the access and risk constraints. Those conversations refine the questions each agreed prototype needs to answer." }, { "label": "Weeks 2–3", "detail": "Build something your team can try. Our engineer pairs with yours on two or three workflows, agreed in writing before the audit starts, using real data in your tenancy. Your colleagues bring typical and difficult cases to the tests. We measure accuracy, assess confidence in the results and estimate run cost per unit of work. Their feedback helps us understand what works, what needs attention and what to investigate next." }, { "label": "Week 4", "detail": "Turn the findings into a decision. We explore which roles and decisions would change, what governance is needed and how people would adopt the workflow. We then present the prototypes and a costed plan to your leadership, with the assumptions, risks and evidence available to examine. Your board can decide what to fund, what to revisit and where to stop." } ], "boardOutputs": [ "Which domains and workflows to fund first, with the evidence behind the order", "The first three priorities, their expected return and the confidence in each estimate", "Build and running-cost estimates in a plan of three-month increments, capped at twelve months", "The decisions people retain, the proposed changes to their work and the support they need", "The constraints to resolve before further automation, with dependencies and review points", "What to defer or stop, with a reason for each recommendation" ], "blocks": [ { "eyebrow": "Your board readout", "title": "The evidence behind the plan", "lede": "Seven sections connect what we learn with the decisions ahead. Your team can follow each recommendation back to the workflow, test or assumption behind it.", "items": [ { "label": "Heat map by domain and workflow", "detail": "A view of the candidates examined across product, internal processes, operations and software delivery. Each is ranked by expected return and feasibility, with the supporting evidence, so you can compare where to invest." }, { "label": "Constraint register", "detail": "The data, platform, risk and regulatory limits affecting each candidate. It distinguishes limits to work within from changes you could make, with costs where they can be estimated." }, { "label": "Decision inventory", "detail": "Which decisions an agent could take on and which stay with a person. Each recommendation considers the consequences of a wrong decision and how readily it could be reversed." }, { "label": "People and adoption", "detail": "What colleagues find useful, where they need more support and how roles, incentives or working practices could help. Their experience of the prototypes informs the recommendations for each function." }, { "label": "A costed plan", "detail": "A sequence in three-month increments, capped at twelve months, with build and estimated running costs, dependencies and points to review what you have learned." }, { "label": "The investment case", "detail": "Expected value in currency, with the assumptions and confidence behind each figure. Your finance team can use its own numbers to explore how the case changes." }, { "label": "What to leave out", "detail": "Candidates to defer or stop, and the reason for each. This gives your team a record to return to if the data, costs or business priorities change." } ], "note": "You receive the written readout and a session with your leadership to see the prototypes, examine the findings and discuss the next step." } ], "faq": [ { "question": "What is an AI readiness audit?", "answer": "An AI readiness audit helps an organisation decide where AI could create useful, measurable value and what would need to change to achieve it. It examines the work, the available data, the risks and the support people need.\n\nTenhaw's audit covers product, internal processes, operations and software delivery. Over four weeks, we build two or three working prototypes with your team and turn the findings into a sequenced, costed plan. The fixed fee is £44,000, excluding VAT." }, { "question": "What does the audit actually look at?", "answer": "Four connected areas: the product your customers use, the internal processes that run the business, operations and software delivery. We follow real workflows with the people who know them, review the data and examine the tools already in use.\n\nThat might mean exploring how a customer finds an answer, how a team gathers information for a decision, or how engineers test a change. We compare opportunities within and across the four areas so your board can decide where to invest first." }, { "question": "How much does an AI readiness assessment cost in the UK?", "answer": "Tenhaw's AI Readiness Audit costs £44,000 fixed for an agreed four-week scope, excluding VAT. We agree the business areas, access and two or three prototype workflows before work starts. Organisation size shapes where we focus the four weeks; it does not create a different price band.\n\nPre-agreed expenses are charged at cost, and model and platform use sits on your own accounts. The fee covers the agreed deliverables. If you request a scope change, we agree it and any fee or timeline changes in writing before the additional work starts. When comparing assessments, check the deliverables, engineering time and client involvement as well as the fee." }, { "question": "Should we start with the audit or a proof of concept?", "answer": "Choose the audit when you need to decide where to invest across the organisation. It explores four areas, tests two or three candidates and gives your board a costed plan.\n\nA proof of concept fits when you already have one workflow in mind and want to find out whether the approach works. It costs £20,000–£55,000 fixed over two to four weeks, excluding VAT. Your team can use either engagement to learn before committing to a production build." }, { "question": "Who from Tenhaw actually does the work?", "answer": "James Rooney leads every audit personally, supported by a senior operator and a build engineer. The operator explores workflows with your teams; the engineer pairs with your engineers to build and test the prototypes.\n\nThe fee is based on five partner days, twenty operator days and nine engineer days across the four weeks. Associates come through work James knows at first hand or referrals from people he has delivered with. Everyone completes BS7858-standard screening before client access, with written confidentiality and data-handling terms. Your Statement of Work names the people and their responsibilities." }, { "question": "Should we hire a Head of AI or run an audit first?", "answer": "It depends on the decision you need to make. If you need permanent leadership, the hire matters. An audit can help define that role by establishing the opportunities, constraints and investment priorities they would inherit.\n\nIf your Head of AI is already in post, we can work with them over the four weeks to test their priorities and develop the plan with your teams. The audit provides evidence and delivery support while responsibility for the permanent role remains with your organisation." }, { "question": "What is included in the £44,000 audit price?", "answer": "The agreed four weeks of work: two or three working prototypes, a heat map across the four domains, a constraint register, a decision inventory, an assessment of people and adoption, and an investment case. You also receive estimated running costs and a plan in three-month increments, capped at twelve months, presented to your leadership.\n\nCode is built in your repositories, and you own the deliverables on payment of the applicable fees. VAT, pre-agreed expenses at cost and model or platform use on your accounts are separate. The fee is fixed for the agreed scope; client-requested changes are agreed in writing before additional work begins." }, { "question": "Can the audit sort out the AI tools we have already bought?", "answer": "It can help you decide what to keep, improve, consolidate or retire. We map the tools people use, including informal use, to the workflows they support. Your colleagues can explain why they chose them, what helps and where they still have to work around a limitation.\n\nWe examine overlap and running costs alongside the opportunities for new work. The plan records the recommended changes and their reasons. Tenhaw does not sell software licences." }, { "question": "What does an AI readiness audit deliver in four weeks?", "answer": "Two or three working prototypes and the evidence to decide what to do next. Each prototype runs against your real data in your tenancy, with measured accuracy, an assessment of confidence in the results and an estimated run cost per unit of work.\n\nThe written readout covers opportunities, constraints, decisions, people and adoption, the investment case and candidates to leave out. A costed plan sets out the next steps in three-month increments, capped at twelve months. Preparing a prototype for production is a separate scope." }, { "question": "How do you assess whether a data estate is ready for agentic AI?", "answer": "We trace the data a real workflow needs: where it lives, who can access it, how complete it is and whether an answer can be checked against its source. Your teams help us find the exceptions and dependencies.\n\nThe prototypes then test those conditions in practice. We examine retrieval quality, missing context, permissions and links back to the source, and record what would need to improve before relying on the workflow. Findings apply to the data and workflows examined, with wider questions recorded for follow-up." }, { "question": "How do you work out where AI will not deliver value?", "answer": "We compare the possible benefit with the data, risk, effort and running costs involved. Some candidates have too little volume to justify a build. Others need better information, a different process or a decision that should remain with a person.\n\nYour team's examples help us understand which constraint matters. We record candidates to defer or stop with a reason, so you can revisit them if circumstances change. A simpler process improvement may be the useful outcome." }, { "question": "Which stakeholders need to be involved in an AI readiness audit?", "answer": "The people doing the work and engineers who can pair on the prototypes are central. Their examples, judgement and feedback help us choose and test the candidates. We also need an executive sponsor empowered to decide within the agreed scope, the platform or data owner, and someone from risk to agree the classification and controls before prototyping.\n\nFinance helps examine the cost baseline and investment assumptions. We agree the people, access and time needed during scoping so each team can plan its contribution." }, { "question": "How do you baseline current operating costs so AI savings can be measured later?", "answer": "We record volume, elapsed time, people involved and rework for the workflow as it runs today, then work with your team to express that baseline in currency. Finance can check the assumptions and the value assigned to people's time.\n\nPrototype results and estimated model and platform costs help us explore potential improvements against that baseline. Time released is capacity; it becomes a cash saving only if expenditure changes. The audit estimates the opportunity, while realised savings need to be measured after adoption in live work." }, { "question": "What security constraints are examined before an AI build starts?", "answer": "We establish where the data may go, who may access it and which actions the prototype is allowed to take. That includes identity and access controls, scoped permissions, approved locations for model inference, data-handling requirements and the evidence your risk team needs.\n\nThe prototypes run in your tenancy on your contracts, within the controls agreed with your platform and risk owners. Those colleagues help us identify what can be tested and what needs another decision before work proceeds." }, { "question": "Can an audit tell us whether our engineering team can build AI-native?", "answer": "It can show how your engineers work with the approach on the selected workflows, and where further support would help. We review how software is delivered today and pair with your engineers while building the prototypes.\n\nThat gives us practical evidence about requirements, implementation, testing and review. Their feedback helps identify useful changes to tools and working practices. Four weeks provides a view of the work examined, which you can use to plan further learning and delivery." }, { "question": "How does this compare with an AI strategy engagement from a large consultancy?", "answer": "Compare the scope you need with the people and deliverables in each proposal. Tenhaw's audit is a four-week engagement at £44,000 excluding VAT, with James Rooney, a senior operator and a build engineer contributing an agreed allocation of time. It includes prototypes built with your engineers and a costed investment plan.\n\nA larger firm may suit a broader international programme or a need for several specialist disciplines. Ask each supplier what it will test, what your team receives, who does the work and what involvement it needs from you. Our pricing page provides the rate card and published framework comparisons for context." }, { "question": "How do you make sure an audit ends in engineering work rather than slides?", "answer": "Prototyping is part of the agreed scope, with an engineer allocated to build it. During weeks two and three, our engineer pairs with yours on two or three workflows using your real data and repositories.\n\nThe tests and your team's feedback inform the plan presented in week four. You can inspect the code and results as they develop, and you own the deliverables on payment even if the audit is the only engagement you buy." }, { "question": "What is the return on £44,000 spent before committing to a build?", "answer": "The audit helps you make a better investment decision. It can identify a promising workflow, expose a costly dependency or show why a proposed build should stop. The value of that decision depends on the work and spend under consideration; we do not promise a financial return from the audit.\n\nYou receive a cost baseline, prototype measurements, running-cost estimates and a plan with assumptions your finance team can examine. Together, those give you a way to judge the next investment before making it." }, { "question": "Can the audit be used as AI due diligence before an acquisition?", "answer": "Yes, as an operational assessment scoped to the target or business unit, at the same £44,000 fixed fee over four weeks, excluding VAT. We examine the work, systems, evidence of value and dependencies within the agreed scope.\n\nAccess to the people doing the work, engineers and relevant data is needed for the prototypes. We check whether that involvement is practical within your transaction timetable before you commit. Legal, financial and regulatory due diligence remain separate specialist work." }, { "question": "Is an agent readiness audit the same as an AI readiness audit?", "answer": "Tenhaw's service was originally called an Agent Readiness Audit. It now covers AI opportunities more broadly across product, internal processes, operations and software delivery. An agent is one possible approach to a workflow.\n\nThe agent-specific work remains in the decision inventory: what a system could act on, what a person should decide, and how consequences and reversibility shape that choice. The engagement runs four weeks at £44,000 fixed, excluding VAT, and tests two or three candidates as working prototypes." }, { "question": "Can you audit a programme our current AI supplier is already building?", "answer": "Yes. We can examine the workflows, assumptions and proposed investment alongside your team and supplier. We agree access, responsibilities and scheduling before starting, including how to avoid disrupting ongoing work.\n\nThe audit tests two or three candidate workflows and compares the findings with expected value, feasibility and running costs. Your board receives a costed plan and recommendations about what to continue, change or stop. Tenhaw does not sell licences, and you can take the findings forward with your existing supplier." }, { "question": "What happens in the weeks after the audit readout?", "answer": "The engagement ends after the agreed four weeks. Nothing renews automatically. You have the prototype code in your repositories, the written findings and a costed plan with review points. You own the deliverables on payment of the applicable fees.\n\nYour team can take the plan forward, use another supplier or agree further work with Tenhaw. That could mean a focused proof of concept, operating-model design, a production build or programme support. Each is a separate scope, and a decision to stop is also a valid next step." }, { "question": "How many hours a week does the audit ask of our teams?", "answer": "There is no single weekly allowance: it depends on the workflows, access arrangements and number of engineers pairing with us. We agree the expected involvement before you commit so your teams can make room for it.\n\nWeek one needs colleagues to walk through their work and help us understand the data. Weeks two and three need engineering time for pairing and colleagues to review prototype results. Week four needs the relevant leaders, with finance and risk input, to examine the findings and decide what follows." }, { "question": "Is the readout a document or a session with our board?", "answer": "Both. You receive a written readout in seven sections and a session with your leadership in week four. We show the prototypes, explain the findings and work through the investment choices with you.\n\nBring the people who will own the decisions, alongside the finance and risk colleagues whose input the plan needs. They can examine the assumptions, ask about difficult cases and agree which questions still need answering." }, { "question": "Is the heat map a score out of five, or is there evidence behind it?", "answer": "Each placement names its evidence. We rank the workflows examined by expected return and feasibility, using the workflow observations, available data, constraints and prototype results.\n\nThe two or three prototyped candidates have measured accuracy and an assessment of confidence in the results. Other candidates may have less direct evidence, which is made clear. Your team can see why a workflow sits where it does and which assumption or test could change its position." }, { "question": "Is four weeks long enough for an organisation our size?", "answer": "Four weeks can answer a useful, bounded set of questions in a large organisation. Before starting, we agree which business areas and workflows to examine across the four domains and which two or three candidates to prototype.\n\nIt is not an exhaustive assessment of every operating company at once. We use the scoping conversation to establish whether the questions that matter can be answered within the time available. If they cannot, we say so before you commit and discuss a more focused starting point." }, { "question": "What if our board challenges the numbers in the investment case?", "answer": "That is a useful part of the readout. Each value is stated in currency with the assumptions, confidence and arithmetic available for review. Your finance team can change the inputs and see how the case changes.\n\nJames Rooney leads the audit personally and can explain how the findings support the recommendation. The prototype results are there to examine too. A challenged assumption may change the order of investment or identify the next thing to test." }, { "question": "If the audit says do not proceed, do we still pay the £44,000?", "answer": "Yes. The fee pays for the agreed assessment, prototypes and findings, including a recommendation to stop where the evidence supports it. You retain the written findings and own the deliverables on payment, whether or not you proceed.\n\nA stop recommendation may apply to one workflow while others remain worth pursuing. The readout explains the reasons and the conditions that would justify revisiting the decision." }, { "question": "Does the costed plan go stale if we sit on it for six months?", "answer": "Some assumptions may need refreshing. The plan marks review points within its three-month increments, capped at twelve months, so you can check what has changed before funding the next stage.\n\nModel pricing, platform costs, data access, business volumes and team capacity can all affect the case. Your team can revisit those inputs alongside the baseline and constraints recorded during the audit. The age of the plan matters less than whether its assumptions still fit the work." }, { "question": "Do the prototypes cost us anything to run after the audit ends?", "answer": "Model inference, compute and other platform use are charged on your own accounts during and after the audit. Those costs are separate from the £44,000 fee. You control the prototypes in your tenancy and can switch them off when you choose.\n\nThe audit includes an estimated run cost per unit of work for each candidate. Costs at production volume depend on the workload and the additional controls, monitoring and support needed for live use, so the prototype estimate is a starting point for that budget." }, { "question": "Can we put the audit prototypes straight into production?", "answer": "No. They are built to test the selected workflows against your real data and provide evidence for an investment decision. A production system needs a separately agreed scope for hardening, assurance and operation.\n\nYour engineers can build on the code in your repositories. The costed plan identifies the build work, dependencies and estimated costs involved in taking it forward, including the volumes and error tolerance the workflow needs to support." }, { "question": "What if our data access is not ready when week two starts?", "answer": "We check access dependencies during scoping and address identity, permissions and risk classification early in week one. Your platform and data owners help us establish what can be reached and when, because the prototypes use your real data in your tenancy.\n\nIf access is delayed, we flag the effect on delivery in writing and work with your sponsor to agree how to proceed. We do not assume the original end date is achievable regardless of the delay. The fee remains fixed for the agreed scope; any requested scope change is agreed in writing before additional work starts." } ] } ## Agentic Proof of Concept Source: https://tenhaw.com/services/agentic-proof-of-concept Last updated: 2026-11-05 { "slug": "agentic-proof-of-concept", "rung": "02", "name": "Agentic Proof of Concept", "track": "Way in", "tagline": "Build and test one AI workflow in your own tenancy.", "metaTitle": "Agentic AI proof of concept consultancy", "metaDescription": "Build an agentic AI proof of concept with Tenhaw in your tenancy. £20k–£55k fixed over 2–4 weeks, with your engineers and a costed production plan.", "summary": "Tenhaw's Agentic Proof of Concept builds and tests one enterprise AI workflow in your own tenancy for £20,000–£55,000 fixed, excluding VAT, over two to four weeks. One or two Tenhaw engineers pair-program with your people, using your data and repositories. You receive the working proof of concept, its requirements and an assessment of what production readiness would take, scoped and costed as a separate decision.", "summaryLink": { "text": "At Placing Platform Limited (PPL), Tenhaw built a working PDF-to-business-intelligence proof of concept on Azure in two weeks, paired with a client engineer. The write-up follows the requirements, pipeline and the engineer's reported 70% confidence in running the process unaided at the end of the build.", "href": "/case-studies/specialty-insurance-agentic-lead", "label": "Read the PPL proof of concept" }, "banner": { "title": "A two-week insurance proof of concept", "detail": "Tenhaw built a working PDF-to-business-intelligence proof of concept on Azure, paired throughout with PPL's engineer.", "link": { "label": "Read the PPL proof of concept", "href": "/case-studies/specialty-insurance-agentic-lead" } }, "priceLabel": "Fixed price · £20k–£55k", "priceLow": 20000, "priceHigh": 55000, "timeline": "2–4 weeks", "commitment": "Fixed price, fixed deliverable", "howItEnds": "On a date, with a fixed-price deliverable: a working system, the requirement corpus, and a costed scope for production as a separate decision. Nothing rolls on.", "badge": "Fastest proof", "teamShape": "One or two Tenhaw engineers, pair-programming with your people throughout.", "engineerNote": "Yes, and they are the whole team. One or two forward-deployed engineers at the published senior practitioner rate of £1,250 a day, each one someone James Rooney has already delivered alongside.", "rolesLede": "This rung buys an outcome. One role, scoped to a workflow, not a headcount.", "roles": [ { "title": "Forward-deployed AI engineer", "alsoCalled": [ "agentic engineer", "AI build lead", "LLM engineer" ], "detail": "One or two engineers build against a single real workflow in your environment, pair-programming with your people from the first day so the method stays behind. You are buying a working thing and the method behind it, not an engineer by the day. If what you want is a senior person sitting in your stand-up for six months, that is the build team, and if you want one holding delivery without us building anything, that is programme and delivery management." } ], "rightFor": [ "Organisations that already know which workflow they want to attack", "Leadership teams who need something working to unlock the real budget conversation", "Businesses where a plan will not persuade the sceptics but a demonstration might", "Teams who want their own engineers to learn the method by doing it" ], "notFor": [ "Organisations still deciding where to invest: take the audit first", "Anyone expecting a production deployment in four weeks: this is a proof of concept, and hardening it for production is a longer, separately scoped job", "Workflows where the underlying data does not yet exist in any usable form" ], "deliverables": [ "A working agentic system against one real workflow, in your environment", "The full requirement corpus as structured markdown, yours to keep and extend", "A documented gap-and-contradiction analysis, surfaced before any code was written", "Your own engineers able to run the method, measured, not assumed", "An assessment of what productionising it would take, scoped and costed" ], "phases": [ { "label": "Days 1–3", "detail": "Turn the existing requirements (PDFs, diagrams, decks) into a structured markdown corpus, map the relationships, and run the gap-and-contradiction pass before any code exists." }, { "label": "Days 4–5", "detail": "Resolve the gaps with your subject-matter experts, and record explicitly what we are proceeding without, and why." }, { "label": "Week 2", "detail": "Build against the whole requirement set, paired with your engineers, with a security review roughly every fifth prompt. Record passes, failures and cases needing human review against the agreed acceptance examples." }, { "label": "Weeks 3–4", "detail": "Retest the agreed examples, fold user feedback back through the same corpus, and scope what production readiness would require." } ], "boardOutputs": [ "A working thing your executives can use, not a deck about a working thing", "A measured read on how much of the method your own people absorbed", "A costed scope for productionisation, as a separate decision", "Evidence of whether this workflow is worth pursuing at all" ], "faq": [ { "question": "What is an agentic proof of concept?", "answer": "A short fixed-price engagement, two to four weeks at Tenhaw, that takes one real workflow and builds a working agentic system against it, in your environment and against your data. The point is to replace an argument about feasibility with a working thing people can use. It is not a production deployment; productionising is scoped and costed separately." }, { "question": "How can a proof of concept take only two weeks?", "answer": "By treating the requirements as the source code. Every requirement is converted into structured markdown, mapped for relationships, and interrogated for gaps and contradictions before any code is written; the build then runs against the whole requirement set at maximum model reasoning rather than file by file. The full method is published at tenhaw.com/the-tenhaw-way/building-with-ai." }, { "question": "Will our own engineers learn anything, or do you hand over a black box?", "answer": "The build is pair-programmed with your engineers throughout, deliberately. On a recent engagement the client engineer who paired on a two-week build finished it saying they were 70% confident they could run the process unaided. Seventy per cent after a fortnight is the measured figure, and it is the difference between buying a proof of concept and starting to acquire a capability." }, { "question": "What does an agentic proof of concept cost?", "answer": "Tenhaw prices agentic proofs of concept between £20,000 and £55,000 as a fixed fee for two to four weeks, depending on the complexity of the workflow and the state of the underlying data. The price is agreed before the work starts and does not move." }, { "question": "Can we contract your engineers by the day instead?", "answer": "No. Tenhaw is not a staffing agency and does not place people by the day into someone else's plan, which is what lets us publish a rate card and stay accountable for the outcome. Senior people are supplied on an engagement with partner oversight behind them. If you want a single senior lead rather than a build, the closest thing on the ladder is programme and delivery management, where one lead runs delivery and governance without Tenhaw building any of it." }, { "question": "What happens if the proof of concept fails?", "answer": "You get a documented answer to a question that would otherwise have cost far more to answer, plus the requirement corpus and gap analysis, which retain value regardless. A proof of concept that establishes a workflow is not viable has done its job, and we would rather tell you that in week three than in month nine." }, { "question": "What decides whether we pay £20k or £55k?", "answer": "The complexity of the workflow, and the state of the data underneath it. Those set the two variables the price is built from, whether one or two Tenhaw engineers are on it and whether it runs two weeks or four, costed from the published senior practitioner rate of £1,250 a day. A tangled workflow with scattered data needs more of both and sits nearer £55,000; a well understood one with its data already in a single place sits nearer £20,000. Either way the number is fixed in writing before anyone starts, and the deliverable is fixed alongside it." }, { "question": "What do you need from us during a proof of concept?", "answer": "Access, experts and engineers. The system is built in your environment against your real workflow, so we need that environment and the workflow's data from the first day. Your subject-matter experts are wanted around days four and five, once the gap-and-contradiction pass has surfaced what the written requirements contradict or leave out. And engineers of your own to pair with ours throughout, because your people finishing able to run the method is a measured deliverable rather than a hope. Data is the one hard prerequisite, and where it does not yet exist in any usable form, a proof of concept is the wrong place to start." }, { "question": "What happens week by week in a proof of concept?", "answer": "Days one to three turn your existing requirements, the PDFs, diagrams and decks, into a structured markdown corpus, map the relationships and run the gap-and-contradiction pass, all before any code exists. Days four and five resolve those gaps with your subject-matter experts and record explicitly what we are proceeding without, and why. Week two is the build, paired with your engineers, with a security review roughly every fifth prompt, with results recorded against the agreed acceptance examples. Weeks three and four retest the agreed examples, fold user-testing feedback back through the same corpus, and scope what production readiness would require." }, { "question": "Does a proof of concept commit us to anything afterwards?", "answer": "No. It ends on a date agreed at the start with a fixed-price deliverable, nothing rolls on, and there is no retainer waiting on the other side. You keep the working system, the full requirement corpus as structured markdown, and a costed scope for what productionising it would take, all of it yours to extend or to hand to somebody else. Whether to build for production is a separate decision, and it is a better decision for being made with a working thing and a real number in front of you rather than bought in advance." }, { "question": "When is an agentic proof of concept the wrong thing to buy?", "answer": "In three situations, all of them cheaper to spot now. An agentic proof of concept is the wrong buy when you do not yet know which workflow to attack, and the audit is the better answer there at £44,000 fixed over four weeks. It is wrong when what you actually need is a production deployment, because this ends in a proof of concept and hardening one for production is a longer, separately scoped job. And it is wrong where the data underneath the workflow does not yet exist in any usable form, because the fortnight then goes on building the source rather than the system." }, { "question": "Can a proof of concept cover more than one workflow?", "answer": "No, and the narrowness is the point. One real workflow, in your environment and against your data, is what makes a fixed price over two to four weeks honest rather than a guess, and it is what leaves you with a measured result instead of two half-built things. A second workflow is a second engagement, scoped and priced on its own inside the £20,000 to £55,000 band. If choosing between candidates is the real problem, take the one whose result would settle the argument in the room, because that is where a working system earns the most." }, { "question": "Our requirements are out of date. Can we still start?", "answer": "Yes, and that is the normal starting point. Nothing gets built before the requirements are dealt with. Whatever exists, the PDFs, diagrams and decks, is turned into a structured markdown corpus with the relationships mapped, then interrogated for gaps and contradictions. What that surfaces becomes the agenda for the sessions with your subject-matter experts, and anything still unresolved is recorded as something we are proceeding without, and why. So there is no tidying exercise to run before we start. The corpus is the tidying, and it is yours to keep and extend whatever you decide about the build." }, { "question": "What does a forward-deployed AI engineer do on a proof of concept?", "answer": "They build, in your environment, next to your people. One or two of them are the whole team on this rung, at the published senior practitioner rate of £1,250 a day, each one someone James Rooney has already delivered alongside. The day-to-day work is turning the requirement corpus into a working system against your real data, pairing with your engineers from the first day so the method stays behind, and running a security review roughly every fifth prompt. If what you want instead is a senior person sitting in your stand-up for six months, that is the build team rather than this." }, { "question": "Do real users test the system before the proof of concept ends?", "answer": "Yes, in weeks three and four. Week two produces the first working build, paired with your engineers, and the fortnight after it folds user-testing feedback back through the same requirement corpus rather than patching the code around it, recording passes, failures and cases requiring human review against the agreed acceptance examples. That is also why the engagement ends with something your executives can use rather than a deck about one. It remains a proof of concept, so the testing answers whether the workflow works, and what a production rollout would take is scoped and costed as its own decision." }, { "question": "What do we show the board at the end of a proof of concept?", "answer": "Four things: a working system your executives can use rather than a deck about one, a measured read on how much of the method your own people absorbed, a costed scope for productionisation as a separate decision, and evidence of whether this workflow is worth pursuing at all. Boards tend to underrate the last one, because evidence that a workflow is not worth pursuing is far more useful before a build is budgeted than after. And if the difficulty is that a plan will not persuade the sceptics in the room, a working system usually does." }, { "question": "Who builds the production version after the proof of concept?", "answer": "Whoever you choose. You finish holding the working system, the requirement corpus and a costed scope for production, so the options are real ones: your own engineers, a different supplier entirely, or a Tenhaw agentic build team at £70,000 to £85,000 a month. Weeks three and four exist partly to produce that scope and that number, so the production question gets answered with a working thing and a real cost on the table. Your engineers having paired with ours throughout is what makes the first option a genuine one rather than a courtesy." }, { "question": "Who pays if a fixed-price proof of concept overruns?", "answer": "We do. The number is agreed in writing before anyone starts and it does not move, and the deliverable is fixed alongside it, so an overrun is our problem rather than a change request pointed at you. That is a sane promise rather than a gamble because of where the unknowns surface. The requirements are interrogated for gaps and contradictions in week one, before any code exists, and whatever cannot be resolved is written down at the time. Fixed-price work goes wrong when that discovery lands in week three, and this sequence is built to stop it." }, { "question": "A software vendor offered us a free proof of concept. Why pay for yours?", "answer": "Because a free vendor pilot is scoped to prove that product, and Tenhaw has no model, platform or licence to resell or take a margin on. What the fixed £20,000 to £55,000 buys is a working system in your own environment against your own data, one or two engineers pairing with yours while it is built, and the requirement corpus that produced it. If you were always going to buy that product anyway, let the vendor prove it and keep your money. What neither exercise can settle from outside is whether the workflow is worth automating at all, and that turns on volumes and the cost of an error, which only your operation knows." }, { "question": "Will a proof of concept still work at our real volumes?", "answer": "Not on its own, and Tenhaw scopes that gap rather than glossing it. A proof of concept is built to answer one question, whether this workflow can be done at all, in your environment, against your data, inside two to four weeks. Throughput, error handling and identity carry deliberate shortcuts at that stage, which is why weeks three and four end with a costed assessment of what productionising would take rather than a claim that you are finished. The £20,000 to £55,000 buys the first answer cheaply. What sets the second is your peak volume and how unevenly it arrives, which your operations people already know and no fortnight can discover." }, { "question": "Can a proof of concept run on masked or synthetic data?", "answer": "Masked data usually works, synthetic data usually does not, and since Tenhaw builds inside your environment under your own policies, with UK data residency by default and EU available, the choice is yours to make. The test is whether the mask preserves the features the decisions actually turn on. Replace a customer name and nothing changes; flatten the messy free text and the result flatters itself. Synthetic records fail that test because they are generated from the rules you already know, so the exceptions quietly vanish. The one hard prerequisite is data that exists in usable form, and whether your masked copy still carries the awkward cases is a question for your data owners." }, { "question": "How do we agree what counts as working before we sign?", "answer": "In writing, before the fee is fixed. Tenhaw prices a proof of concept at £20,000 to £55,000 against a fixed deliverable, so what counts as working has to be settled first, and the reference it is settled against is the requirement corpus. Your existing documents are turned into structured markdown, interrogated for gaps and contradictions, with anything your subject-matter experts cannot resolve recorded explicitly as something the build proceeds without. Acceptance is then measured against that, rather than against somebody's memory of a meeting. What the corpus cannot decide for you is which specific cases must be right rather than what percentage, because that is a judgement about consequence your process owner owns." }, { "question": "How long does it take to get a proof of concept into production?", "answer": "It is a separate phase with its own dedicated team, and its length is set by what the system has to do in production rather than by how quickly the proof of concept came together. Weeks three and four of your own engagement exist partly to produce the number for the specific thing you have just watched work, which is why the costed assessment is a deliverable of the fixed fee rather than a follow-on proposal. Three things move it: the integration surface, the non-functional requirements your estate imposes, and how accurate the workflow must be before it runs unchecked. The last is a risk decision rather than an engineering one." }, { "question": "If the system breaks a month after you leave, who fixes it?", "answer": "Your own engineers, and Tenhaw shapes the two to four weeks so that is realistic rather than a hope. They pair on the build from the first day, the code sits in your repositories as it is written, and the requirement corpus behind it is structured markdown they can read and extend, so a fix is a change to something they already know rather than a call to us. Be clear-eyed about what you are running, though. It was built to answer a question quickly, so it is a thing to learn from while you decide rather than one to leave unattended in front of customers. How much attention it needs meanwhile depends on who is using it, and how often." }, { "question": "Our engineers could try this themselves. Why pay for two weeks of yours?", "answer": "If you have engineers who have already shipped an agentic system and can be freed for a fortnight, run it yourselves, because Tenhaw publishes the method free, failure modes included. What £20,000 to £55,000 buys is that the fortnight actually happens at a fixed price, with one or two engineers at the published senior practitioner rate of £1,250 a day whose only job for two to four weeks is this one, and a gap-and-contradiction pass run by somebody with no stake in which answer it produces. Internal attempts stall on the first of those far more often than the second. Whether your people can genuinely come off their current commitments is the thing to test before you decide." }, { "question": "Whose AI model licences does the build run on?", "answer": "Yours, wherever you have an approved enterprise tenancy. Tenhaw does not resell or mark up models, platforms or licences, so the build runs inside your infrastructure on your own contracts, and nothing you specify becomes revenue for us. Where there is no approved stack, the default is named up front as Claude Code with OpenAI models and Gemini, best tool for the case, swapped for your preferred stack on request. The £20,000 to £55,000 is the fee for the work, costed from the published £1,250 senior practitioner day rate, with no licence margin underneath it. Whether your existing agreements cover the models this workflow needs is worth checking early, since procuring a new one can outlast a two-week build." }, { "question": "Does the fee come off the price if we go on to a build?", "answer": "No, and the reason is worth knowing. Tenhaw prices the proof of concept standalone at £20,000 to £55,000, fixed, ending on the date agreed at kickoff. A fee credited against a later build would quietly put a price on the recommendation to stop, and a proof of concept that establishes a workflow is not viable has done its job. What you carry into the production decision instead is a working system, the requirement corpus and a costed scope, so the next number is a real one whoever ends up spending it. Which route that turns out to be depends on engineering capacity you have and we cannot see from here." }, { "question": "Should we pick our biggest workflow or our simplest one?", "answer": "Neither, quite. Tenhaw's test is three conditions: the workflow's data already exists in usable form, its requirements exist in writing even if they are years out of date, and its subject-matter expert can be in the room on days four and five. Those are what let a fixed price hold over two to four weeks. Add one more test of your own, that your people can check the output quickly, because a result nobody can verify inside a day cannot be user-tested in weeks three and four. The biggest workflow in the business usually fails the first condition, and the simplest one rarely settles the argument you are running the exercise to settle." } ] } ## Agentic Design Team Source: https://tenhaw.com/services/agentic-design-team Last updated: 2026-11-05 { "slug": "agentic-design-team", "rung": "03", "name": "Agentic Design Team", "track": "Delivery", "tagline": "A pair who design the AI-native operating model, and the agentic systems to run it at scale.", "metaTitle": "Target operating model consulting, for AI", "metaDescription": "A design pair who build the target operating model for an AI-native organisation: structure, roles, decision rights and governance, with the agentic architecture designed alongside it.", "summary": "An Agentic Design Team is a pair of senior Tenhaw practitioners, one operating-model lead and one agentic architect, who design what your organisation needs to run agents at scale. The work is AI-native organisation design: the target operating model and the technical architecture are designed together, deliberately, because separating them is why scaling stalls. It runs at £35,000–£55,000 per month, typically over two to four months.", "summaryLink": { "text": "The operating-model half has run at scale: a target operating model co-designed, piloted and proved for 500 teams at HSBC, with James’s engagement complete and the wider rollout in progress.", "href": "/case-studies/hsbc-gps-operating-model", "label": "Read the HSBC write-up" }, "banner": { "title": "Target operating model design", "detail": "The design pair works with your leaders on structure, roles, decision rights and governance, alongside the architecture needed to support them.", "link": { "label": "The full guide: a target operating model for an AI-native organisation", "href": "/guides/target-operating-model-for-an-ai-native-organisation" } }, "priceLabel": "£35k–£55k / month", "priceLow": 35000, "priceHigh": 55000, "priceUnit": "MON", "timeline": "2–4 months", "commitment": "30 days' notice either way", "howItEnds": "Monthly, cancellable on 30 days' written notice either way. It ends on the sequenced build plan, which you can execute with us, yourselves or a third party.", "badge": "Design first", "teamShape": "Two senior practitioners, an operating-model lead holding the interim Head of AI seat and an agentic architect.", "engineerNote": "No build engineer: this rung designs what gets built rather than building it. Both practitioners are at the published senior rate of £1,250 a day, and the architect signs the architecture off with your CTO.", "rolesLede": "Two seats, held for two to four months. Between them they cover the half of a Head of AI job that is about how the organisation works, and the half that is about what it runs on.", "roles": [ { "title": "Interim Head of AI", "alsoCalled": [ "Head of AI", "AI transformation director", "interim Chief AI Officer", "target operating model lead" ], "detail": "The operating-model lead holds the seat a Head of AI holds: what humans own, what agents own, who is accountable when an agent gets something wrong, and what governance has to exist before anything is deployed. Two to four months rather than a permanent appointment, and one of the outputs is the specification for the person you eventually hire into it." }, { "title": "Enterprise AI architect", "alsoCalled": [ "agentic architect", "principal AI architect", "AI platform lead" ], "detail": "Owns the platform, data foundations, integration and security the build will depend on, and gets the architecture signed off with your CTO rather than handed to them. Paired with the operating-model lead deliberately: an architecture designed without knowing which decisions move to agents optimises for the wrong things." } ], "rightFor": [ "Organisations whose pilots worked and cannot scale past the team that built them", "Businesses that need the operating model and the technical architecture designed together", "Groups where several functions are about to build incompatible things", "Leadership teams facing role redesign, governance and platform decisions at once" ], "notFor": [ "Single-team pilots: this is organisation-level design", "Organisations that have not yet established where agents create value", "Anyone wanting architecture without operating-model work, or the reverse; separating them is why programmes stall" ], "deliverables": [ "Target operating model for an AI-native organisation, with roles defined by the decisions they own", "Agentic system and infrastructure architecture: platform, data foundations, integration and security", "Governance framework making agent decisions auditable rather than theoretical", "Accountability mapped across the model before a single agent is deployed", "Human-in-the-loop boundaries defined per decision class, with escalation paths", "A sequenced build plan your teams, ours, or a third party could execute" ], "phases": [ { "label": "Weeks 1–3", "detail": "Current-state truth. How decisions actually get made, what the data and platform will support, and where the structure will fight the technology." }, { "label": "Weeks 4–8", "detail": "Design in parallel. Operating model and technical architecture developed together, because a target model the infrastructure cannot support is a document, not a design." }, { "label": "Weeks 9–12", "detail": "Governance and assurance. Audit trails, escalation paths, model risk, and the human-in-the-loop points your risk function and your regulator will both ask about." }, { "label": "Final weeks", "detail": "Sequencing and handover. The build plan, the adoption plan, and named internal ownership for every element." } ], "boardOutputs": [ "An operating model your executives can each see their own role inside", "An architecture your CTO signs off rather than inherits", "A governance framework that survives contact with audit and risk", "A build plan executable by us, by you, or by a third party" ], "faq": [ { "question": "What is an AI-native operating model?", "answer": "An organisational design in which AI agents perform a meaningful share of the work, and the structure, roles, decision rights and governance are rebuilt around that fact rather than bolted onto the existing hierarchy. It specifies what humans own, what agents own, how agent decisions are audited, and who is accountable when an agent gets something wrong. AI-native organisation design is another accurate name for the same work." }, { "question": "Is this target operating model (TOM) design?", "answer": "Yes. The deliverable is a target operating model in the same sense a Big Four engagement uses the phrase: structure, roles, decision rights, governance and the sequenced plan to move to them. Two things distinguish ours. It is designed for an organisation in which AI agents perform a meaningful share of the work, and the technical architecture is designed alongside it by the same pair, because a target model the platform cannot support is a document rather than a design. If you have bought TOM work before, the shape will be familiar; the decision rights will not be." }, { "question": "Why design the operating model and the infrastructure together?", "answer": "Because a target operating model the platform cannot support is a document rather than a design, and an architecture built without knowing which decisions move to agents optimises for the wrong things. Separating the two is one of the most reliable ways to produce a programme that stalls at the point of scaling." }, { "question": "Do you provide an interim Head of AI?", "answer": "Yes, with one caveat about scope. Designing how the organisation works around agents is one job, and running the delivery is another, though most organisations advertise the two together as Head of AI. This rung supplies the first, as an operating-model lead alongside an agentic architect, for two to four months. If what you need is the delivery half, that is programme and delivery management at £18,000 to £35,000 a month, or the Agentic Build Team if the thing also has to be built. Either way it is an engagement rather than an appointment, and writing the specification you recruit against is part of the work." }, { "question": "Why a team of two rather than one?", "answer": "The two disciplines are different. Operating-model design is about decision rights, accountability and adoption; agentic architecture is about platform, data, integration and security. One person covering both does one of them badly. Two senior practitioners is the smallest team for the work." }, { "question": "How do you decide what humans own versus what agents own?", "answer": "By the consequence and reversibility of the decision, not by task complexity. Agents take decisions that are high-volume, observable and cheaply reversible. Humans retain decisions that are consequential, contested, or hard to undo. The boundary is written down explicitly per role, and the escalation path across it is part of the governance framework." }, { "question": "Do you build the system as well, or only design it?", "answer": "Design only, and deliberately so. This rung designs what gets built rather than building it, so there is no build engineer on it. The two seats are an operating-model lead and an agentic architect, and the architect gets the architecture signed off with your CTO rather than handing it to them. What you get is a target operating model with roles defined by the decisions they own, the platform, data, integration and security architecture, a governance framework that makes agent decisions auditable rather than theoretical, human-in-the-loop boundaries defined per decision class with escalation paths, and a sequenced build plan. Building it is a different rung with a different team." }, { "question": "How is the £35k–£55k monthly fee worked out?", "answer": "From the published rate card, not from a negotiation. The team is two senior practitioners, an operating-model lead and an agentic architect, both at the published senior rate of £1,250 a day, and engagement prices derive from the rate card at twenty billable days a month, excluding VAT. Two senior seats on that basis sit inside the published band, and where a given month lands in it follows how much of each seat the work needs. There is no junior pyramid underneath the pair. It bills monthly, typically over two to four months, and either side can end it on 30 days' written notice." }, { "question": "What happens month to month on a design engagement?", "answer": "The work runs in four phases. Weeks one to three establish current-state truth: how decisions actually get made, what your data and platform will support, and where the structure will fight the technology. Weeks four to eight design the operating model and the technical architecture together. Weeks nine to twelve cover governance and assurance: audit trails, escalation paths, model risk, and the human-in-the-loop points your risk function and your regulator will both ask about. The final weeks are sequencing and handover, with the build plan, the adoption plan and named internal ownership for every element. A shorter engagement runs the same sequence compressed, and every month is expected to show measurable value." }, { "question": "Do we have to build with Tenhaw after the design phase?", "answer": "No. The engagement ends on a sequenced build plan your own teams, ours, or a third party could execute, the architecture is signed off with your CTO rather than handed to them, and you own all the work product. If you want Tenhaw to execute it, the next step on the ladder is the Agentic Build Team, three people at £70,000 to £85,000 a month; if you would rather build with the engineers you already have, the plan is written to be executable without us. The design work is priced to stand on its own, not to seed the next sale." }, { "question": "How do we stop each function building its own agent platform?", "answer": "That is one of the clearest cases for this engagement. When several functions build independently you get incompatible platforms, governance that contradicts itself and integration work paid for twice, and unpicking that afterwards costs more than designing it once. The pair, an operating-model lead and an agentic architect, set the platform, data foundations, integration and security architecture centrally, define which decisions move to agents and who is accountable for them, and end on a sequenced build plan your functions execute against rather than around. It runs at £35,000 to £55,000 a month, typically over two to four months, and the architecture is signed off with your CTO rather than handed to them." }, { "question": "Our AI work is one team and one pilot. Are we too small for this?", "answer": "Probably, and we would rather say so now. This rung is organisation-level design. It earns its price when several functions are affected, when structure and platform decisions have to be taken together, and when governance has to exist before anything scales. A single-team pilot does not need a target operating model, and neither does an organisation that has not yet established where agents create value. Better starting points are the AI Readiness Audit, four weeks at £44,000 fixed, which finds where AI does and does not pay, or an Agentic Proof of Concept at £20,000 to £55,000 over two to four weeks. Come back to design work when scaling is the actual problem." }, { "question": "How do you show measurable value in a month of design work?", "answer": "By making each month end in something you would still want if we stopped there, rather than in progress towards a document at the end. The test is whether a decision your leadership was stuck on can now actually be taken: which decisions move to agents, what the platform has to support, what your risk function will accept. Design work goes wrong when all of its value arrives in the final week. Engagements here are retainer-shaped rather than milestone-shaped, and a month that delivers no measurable value is reported as a failed month rather than folded quietly into the next one." }, { "question": "What happens if our CTO disagrees with the architecture?", "answer": "Then it is not finished, and that is deliberate. The architect signs the architecture off with your CTO rather than handing it to them, so disagreement is meant to surface during weeks four to eight, while the operating model and the architecture are still being designed together, rather than at a final readout. An architecture your CTO will not own is a document rather than a design, and it will not survive the first real build decision. If the disagreement turns out to be irreconcilable, the engagement is monthly and cancellable on 30 days' written notice either way." }, { "question": "What does a full design engagement cost in total?", "answer": "Between roughly £70,000 and £220,000 excluding VAT, depending on how long it runs. The pair is priced at £35,000 to £55,000 a month and the work typically takes two to four months, so two months at the bottom of the band is about £70,000 and four months at the top about £220,000. Where a given month lands in the band follows how much of each seat the work needs, and there is no junior pyramid underneath the two. It bills monthly rather than as a lump sum, either side can end it on 30 days' written notice, and nothing obliges you to build with us afterwards." }, { "question": "If we give notice after month one, what do we actually have?", "answer": "Everything designed to that point, and all of it is yours. The engagement is retainer-shaped rather than milestone-shaped, so each month is expected to deliver measurable value on its own, and a month that delivers none is reported as a failed month rather than folded into a later deliverable. After the first weeks you would hold the current-state work: how decisions actually get made across the organisation, what your data and platform will genuinely support, and where the structure will fight the technology. That is useful whoever does the rest of it. Notice is 30 days either way, in writing, and you own all the work product." }, { "question": "Could our own enterprise architects do this instead?", "answer": "If they also hold a mandate over how the organisation works, yes, and you should keep the money. Capability is rarely the constraint. Most enterprise architecture functions own platform, data, integration and security and carry no authority over decision rights or accountability, so the architecture gets designed against an operating model nobody has agreed, which is why this rung is a pair rather than one architect. Where your architects are strong, the better shape is designing alongside them rather than around them, because they know the estate better than we will in three months and they are still there after we go." }, { "question": "We already have a target operating model. Does that shorten the work?", "answer": "Often, and it is the first thing we test. Weeks one to three set current-state truth against how decisions actually get made, so a model that is honest about structure and accountability is a real head start. Two things usually have to be rebuilt, because the model was never written to answer them. Roles are defined by the tasks people do rather than by the decisions they own, and nothing in it draws a boundary between what a human decides and what an agent decides. Where the existing model is sound the design phase is narrower and the engagement lands nearer two months than four. Bring it to the first conversation, which is the cheapest way to find out how much survives." }, { "question": "How much executive time does a design engagement need?", "answer": "Concentrated in weeks one to three, when Tenhaw's operating-model lead establishes how decisions actually get made across the functions in scope, and that is leadership's own time rather than something the pair can do on their behalf. Your CTO carries the heaviest share, because the architecture is signed off with them across weeks four to eight rather than presented at the end, and risk and audit arrive around weeks nine to twelve when the governance framework is written. The engagement runs two to four months at £35,000 to £55,000 a month, and the larger demand is not diary time. The design forces decisions leadership has been deferring. How many hours that costs follows how many people hold those decisions today." }, { "question": "What if two directors both think they own the same decision?", "answer": "That is one of the things weeks one to three exist to surface. Tenhaw's operating-model lead maps how decisions actually get made today rather than how the organisation chart says they are made, so a contested one shows up in the current-state work instead of at a final readout. Accountability is then mapped across the model before a single agent is deployed, and the final weeks attach named internal ownership to every element, so the decision leaves with one person against it. Where it stays genuinely contested, the pair cannot grant authority your executive committee has not settled, and that is the part a two to four month engagement cannot compress." }, { "question": "We already have a transformation programme running. Where does this fit?", "answer": "Beside it, feeding it. Tenhaw's design pair carries no build engineer and no delivery management, so instead of competing to run your programme, it produces the target operating model, the architecture your CTO signs off, the governance framework and a sequenced build plan your programme executes against. The place the two collide is the plan, with two roadmaps pulling at the same teams, which is why the engagement ends on one sequence with named internal ownership for every element. If the programme also needs someone running delivery, that is a separate rung at £18,000 to £35,000 a month. Whether the AI work sits inside your programme governance or alongside it turns on who holds the platform decisions." }, { "question": "Can you design this for one division rather than the whole group?", "answer": "Yes, provided the division genuinely holds its own decisions and its own platform. Tenhaw prices it at £35,000 to £55,000 a month whether the scope is a division or a group, because this is organisation-level design rather than team-level, and a division that owns its data, its integration points and its budget meets that test. It goes wrong where a division has to design on top of group platform, identity and security decisions it does not control, because the model then encodes choices someone else can overturn. Weeks one to three apply that test directly, and whether it passes turns on how much of the platform your group holds centrally." }, { "question": "How do we get a rolling monthly engagement through procurement?", "answer": "Most procurement teams want a ceiling and an end date, and both exist here. Tenhaw's design pair runs at £35,000 to £55,000 a month across two to four months, so a purchase order can be raised against the months you have approved rather than as an open commitment, and the exit date is agreed at kickoff rather than left to drift. The contract is monthly and cancellable on 30 days' written notice either way, and you own all code, documents and work product as it is produced. What your finance team treats as committed spend usually turns on whether they book the notice period alongside the approved months." }, { "question": "Can two people design an operating model for a group our size?", "answer": "Scale sits in the sequencing rather than in how many people draw the model. The operating-model half of Tenhaw's pair has run at that scale, on a target operating model co-designed, piloted and proved for 500 teams at HSBC, in James Rooney's transformation role there, with James’s engagement complete and the wider rollout in progress. The pair designs and your own people carry the volume, which is why weeks one to three test how decisions actually get made across the functions in scope, and the final weeks attach named internal ownership to every element. What sets the workload is the breadth of scope rather than the size of the organisation." }, { "question": "Do you need access to our production data to design the architecture?", "answer": "Rarely, because this rung designs rather than builds. Tenhaw's agentic architect owns platform, data foundations, integration and security, and that design work runs off documentation rather than live systems: architecture and integration documentation, data catalogues, identity and security policies, and read access to schemas rather than to production records. Where something genuinely has to be seen live, it is seen on your own infrastructure under your own policies, with UK data residency by default and EU available, and the 24-hour personal-data-breach notification sits in the DPA either way. Both practitioners are screened to BS7858 before any client access. How much of the estate opens at all follows how far the architecture reaches." }, { "question": "Can our engineers keep building while the design runs?", "answer": "Usually yes, and often they should, because two to four months with nothing shipping is its own risk. Tenhaw's pair has no build engineer in it, so nothing on this rung stops your teams delivering. The care is needed on irreversible commitments: platform selection, identity and access patterns, the integration layer, anything expensive to unpick if the architecture lands somewhere else. Those are what the agentic architect settles with your CTO across weeks four to eight, so they are worth holding. Reversible work carries on as normal. Which of your in-flight items sits on which side of that line is one of the things weeks one to three sort out." }, { "question": "What if we have already committed to an AI platform?", "answer": "It becomes a constraint the architecture is designed around, and weeks one to three test how hard a constraint it is. Tenhaw's agentic architect owns the platform, data foundations, integration and security half of the pair, and works from what your estate will genuinely support, so a platform you have already bought is taken as given unless it cannot carry the decisions the operating model moves to agents. Where it cannot, that gap becomes sequenced work in the build plan rather than an assumption nobody checks. Your CTO signs the architecture off, so any decision to replace something is theirs. Which way it lands depends on what the platform is being asked to do." }, { "question": "Who keeps the operating model current after you leave?", "answer": "Your own people, by name. Tenhaw's final weeks are sequencing and handover, and each part of the operating model, the architecture and the governance framework leaves with a person in your organisation attached to it, so named internal ownership for every element is a deliverable rather than a closing slide. One output of the interim Head of AI seat is the specification for the permanent person you recruit into it. The engagement is monthly on 30 days' notice either way and you own all the work product, so nothing about maintaining it depends on us. How much upkeep it needs then follows how fast your agent estate grows behind it." } ] } ## Agentic Build Team Source: https://tenhaw.com/services/agentic-build-team Last updated: 2026-11-05 { "slug": "agentic-build-team", "rung": "04", "name": "Agentic Build Team", "track": "Delivery", "tagline": "Build enterprise AI with an embedded team your people learn from.", "metaTitle": "Embedded AI engineering team for enterprises", "metaDescription": "Tenhaw embeds an AI lead, engineer and adoption lead in your organisation. £70k–£85k a month, with partner oversight and a planned handover.", "summary": "Tenhaw's Agentic Build Team embeds three senior practitioners in your organisation: an agentic lead, an engineer and an adoption lead, under James Rooney's partner oversight. The enterprise AI delivery engagement runs for six to twelve months at £70,000–£85,000 per month, excluding VAT. We build in your tenancy and repositories, measure value each month and pair with your people while helping recruit and prepare the permanent team to take over. The exit date is agreed at kickoff; either party can end the monthly engagement on 30 days' written notice.", "summaryLink": { "text": "For six months James Rooney held the interim agentic lead seat at Placing Platform Limited (PPL), showing the client how to move from traditional delivery to an agentic operating model and leaving them ready to roll it out across Product, Engineering and QA.", "href": "/case-studies/agentic-ai-in-insurance-operating-model", "label": "Read the PPL operating-model case study" }, "banner": { "title": "Six months of embedded leadership", "detail": "James Rooney held the embedded lead role at Placing Platform Limited (PPL), including a two-week working proof of concept.", "link": { "label": "Read the PPL operating-model case study", "href": "/case-studies/agentic-ai-in-insurance-operating-model" } }, "priceLabel": "£70k–£85k / month", "priceLow": 70000, "priceHigh": 85000, "priceUnit": "MON", "timeline": "6–12 months", "commitment": "30 days' notice either way", "howItEnds": "Monthly, cancellable on 30 days' written notice either way. The exit date and the taper are agreed at kickoff, and you own all deliverables, documentation and code on payment.", "badge": "Full delivery", "teamShape": "Three forward-deployed practitioners (interim agentic lead, engineer, adoption lead) under partner oversight from James Rooney.", "engineerNote": "Yes. One forward-deployed engineer building in your repositories at the published senior practitioner rate of £1,250 a day, alongside the interim agentic lead at the same rate and the adoption lead at the associate rate of £950. Three people, and the team does not get bigger than that.", "assuranceNote": "All three are screened to BS7858 standard before they touch your estate, and there is no pyramid of juniors behind them. Liability is capped per engagement in the SOW, with confidentiality and data protection treated separately. Insurance figures are published in full on the security page. We hold no client production data and work inside your estate under your controls, which is what limits the exposure these lines answer for, and cover levels can be increased for a specific engagement where your supplier standard requires it. Name the limit your supplier standard requires, on any call, and the increased cover is in place at that limit within three working days, with the premium priced into the engagement.", "rolesLede": "Three seats, held for the length of the engagement, inside your management structure, not alongside it. This is the rung you reach for when the permanent team does not exist yet and the work cannot wait for it.", "roles": [ { "title": "Interim agentic lead", "alsoCalled": [ "interim head of AI delivery", "AI delivery lead", "agentic delivery lead" ], "detail": "Runs the delivery from inside your management structure with a real reporting line, real decision rights and accountability for the value delivered each month. It is the seat organisations most often try to fill permanently and cannot fill quickly, and holding it on an engagement is how the work starts before the search finishes. James Rooney most recently held exactly this role for six months inside Placing Platform Limited (PPL)." }, { "title": "Forward-deployed engineer", "alsoCalled": [ "AI engineer", "agentic engineer", "senior software engineer, AI" ], "detail": "Builds and ships inside your estate, in your repositories, pair-programming with your engineers so the method transfers while the work is live rather than at a handover workshop afterwards." }, { "title": "Adoption lead", "alsoCalled": [ "change lead", "business change manager", "AI adoption manager" ], "detail": "Owns the part that usually fails, which is getting people to actually work the new way, measured rather than assumed. It is the role most often cut from a business case and most often the reason the business case does not land." } ], "rightFor": [ "Organisations that need the capability built, not described", "Boards that have appointed a Head of AI and need a delivery team under them now", "Businesses whose internal teams are at capacity but whose agenda is not", "Leadership teams whose last transformation stalled on politics rather than technology", "Anyone who wants their own engineers upskilled by working alongside ours" ], "notFor": [ "Organisations wanting advice they can take or leave: this team holds accountability", "Businesses unwilling to give the team genuine decision rights and access", "Programmes needing hundreds of people mobilised across many countries" ], "deliverables": [ "Agentic workflows built and shipped inside your estate, delivering measurable value every month", "Adoption owned explicitly and measured", "Your own engineers pair-programmed into the method, with the transfer measured", "Governance, audit trails and human-in-the-loop gates built in rather than retrofitted", "Partner oversight from James Rooney, not an account-management layer", "A dated exit with the capability owned by your permanent team" ], "phases": [ { "label": "Month 1", "detail": "Embed properly: real reporting line, real decision rights, real access. A team without authority is an expensive advisory function." }, { "label": "Months 2–4", "detail": "Ship something that matters into production, with the governance around it, to prove the pattern in your environment rather than in a demo." }, { "label": "Months 5–9", "detail": "Scale the pattern, upskill your engineers alongside ours, and recruit the permanent team while the work is live rather than after we leave." }, { "label": "Final 60 days", "detail": "Deliberate exit: documented handover, permanent team in post, and a decreasing-involvement taper agreed at kickoff rather than negotiated at the end." } ], "boardOutputs": [ "Agentic workflows running in production with named business owners", "Measurable value every month, which you can hold the team to from month one", "A permanent internal team in post and operating", "A dated exit plan, agreed at kickoff" ], "blocks": [ { "eyebrow": "The commitment, with a consequence", "title": "What happens if a month fails", "lede": "Engagements are structured around measurable value delivered every month. A commitment with no consequence attached is a slogan, so this is what happens in the month it is not met.", "items": [ { "label": "A failed month is called a failed month", "detail": "Each month the team commits in writing to a measurable amount of value, priced in currency. A month that ends with no measurable value delivered is reported to your sponsor as a failed month, in those words, in the same pack as everything else. It does not get renamed a discovery month." }, { "label": "The report says why, not that it was complex", "detail": "The report names what was committed, what actually shipped, and the specific cause: whether it sat with us, with a dependency someone else owned, or with a decision that did not get made. It states what changes next month, and it goes to the sponsor inside the same reporting cycle rather than at the next steering committee." }, { "label": "You can end it, on 30 days' notice", "detail": "Retainer engagements are terminable by either party on 30 days' written notice under our published terms of business. Two failed months without a credible cause is a reasonable moment to use that, and we would rather you did than defend a bad engagement to month nine." }, { "label": "You keep everything either way", "detail": "On payment of the applicable fees you own all deliverables, documentation, designs and code created for you, including anything built during a month that failed. Tenhaw asserts no ownership over anything in your environment." } ], "note": "The notice period and the ownership position are in the standard terms every engagement is contracted under, and the monthly commitment is written into the Statement of Work.", "noteLink": { "href": "/terms", "label": "Read the terms of business" } }, { "eyebrow": "The exit", "title": "Built to leave", "lede": "A build engagement is structured so that ending it is straightforward, and that structure is in place from the first day rather than assembled at the end. Four things make it real.", "items": [ { "label": "The work lives in your estate", "detail": "Working software is deployed on your infrastructure, in your repositories, under your controls and your organisation's policies. When the engagement ends there is nothing to migrate off our estate, because nothing was ever on it." }, { "label": "Your people learn the method by doing it", "detail": "Your own permanent engineers pair-program with ours for the whole build rather than for a handover fortnight at the end, and the transfer is measured. Recruiting the permanent team is an explicit deliverable, and the final sixty days are a documented handover with a decreasing-involvement taper." }, { "label": "The method is published in full", "detail": "The delivery method the team runs is published on this site, free to adopt without hiring us. Nothing the engagement depends on is proprietary knowledge that leaves when we do." }, { "label": "The exit is contractual", "detail": "Thirty days' notice either way, an exit date and taper agreed at kickoff, and on payment you own all deliverables, documentation and code. The end of the engagement is written down before it starts." } ], "note": "The first three hold for the whole engagement while it runs. The fourth is in the standard terms and the Statement of Work before the engagement begins.", "noteLink": { "href": "/the-tenhaw-way/building-with-ai", "label": "Read the published method" } } ], "faq": [ { "question": "Who is actually on an agentic build team?", "answer": "Three forward-deployed practitioners: an Agentic Lead who owns the operating model and decision rights, a Forward-Deployed Engineer who builds and ships inside your estate, and an Adoption Lead who owns the part that usually fails, getting people to actually work the new way. James Rooney provides partner oversight on every engagement. Everyone on the team is someone he has already delivered alongside, screened to BS7858 standard before any client access, and every person on your engagement is senior." }, { "question": "What is an interim agentic lead?", "answer": "An interim agentic lead is a senior practitioner who runs an organisation's agentic delivery from inside its management structure for a defined period rather than as a permanent employee. At Tenhaw the role sits at the front of the Agentic Build Team: real decision rights, a real reporting line, accountability for the value delivered each month, and a dated exit with the capability owned by your permanent team. James Rooney most recently held that role for six months inside Placing Platform Limited (PPL), showing its Product, Engineering and QA teams how to move from traditional delivery to an agentic operating model." }, { "question": "Can we take the agentic lead on their own, without the rest of the team?", "answer": "Not from this rung. A build team is three people because shipping needs three: someone holding delivery, someone building, and someone owning adoption. If what you want is one senior person holding delivery, governance and supplier management while other people build, that is programme and delivery management at £18,000 to £35,000 a month, and it can be run fractionally from around three days a week. We would rather point you at the cheaper rung than sell you two people you do not need." }, { "question": "How often does the team deliver something?", "answer": "Measurable value is delivered every month, and the team commits to it in writing and reports against it. There is no distant go-live to wait for, so you can judge the work on evidence within the first thirty days. A month that delivers no measurable value is reported as a failed month, and that is the commitment we ask to be held to from month one." }, { "question": "What stops us becoming dependent on Tenhaw?", "answer": "The exit is designed at kickoff rather than negotiated at the end. The team pair-programs with your engineers throughout, recruiting your permanent team is an explicit deliverable, and the final sixty days are a documented handover with a decreasing-involvement taper. On a recent engagement, a client engineer who paired on a two-week build finished it 70% confident they could run the process unaided." }, { "question": "How much does an agentic build team cost?", "answer": "£70,000–£85,000 per month for a team of three under partner oversight, typically on a 6–12 month engagement. That is comparable to a mid-sized consultancy engagement team, but resolves to three senior practitioners accountable for the outcome rather than a pyramid of juniors." }, { "question": "How is the price of an agentic build team worked out?", "answer": "From the published rate card, so the monthly figure is built out of day rates rather than negotiated. The interim agentic lead and the forward-deployed engineer sit at the senior practitioner rate of £1,250 a day, the adoption lead at the associate rate of £950, and engagement prices derive from the rate card at twenty billable days a month. £70,000 to £85,000 a month is those three seats held for the length of the engagement, with partner oversight from James Rooney inside the fee rather than an account-management layer added on top. All rates exclude VAT and are published in full, so every component of the monthly figure is visible." }, { "question": "Can we make the build team bigger if we need more capacity?", "answer": "No, and that is deliberate. The team is three people, an interim agentic lead, a forward-deployed engineer and an adoption lead, under partner oversight from James Rooney, and it does not get bigger than that. Capacity grows on your side instead. Your own engineers pair-program with ours for the whole build rather than for a handover fortnight at the end, and the transfer is measured, so more of your people can do the work while the engagement is running rather than after it ends. If the programme needs hundreds of people mobilised across many countries, this is the wrong rung and we will say so." }, { "question": "How long does an agentic build team engagement last?", "answer": "Typically six to twelve months, as a monthly retainer with thirty days' notice either way and an exit date agreed at kickoff rather than left open. The shape is consistent. Month one is spent embedding properly, with a real reporting line, real decision rights and real access, because a team without authority is an expensive advisory function. Months two to four ship something that matters into production with the governance around it. Months five to nine scale the pattern, upskill your engineers and recruit your permanent team while the work is live, and the final sixty days are a documented handover with a decreasing-involvement taper." }, { "question": "Do we keep the code if we end the engagement early?", "answer": "Yes. On payment of the applicable fees you own all deliverables, documentation, designs and code created for you, including anything built during a month that failed, and Tenhaw asserts no ownership over anything in your environment. Everything is deployed on your infrastructure, in your repositories, under your controls, so ending early leaves nothing to migrate off our estate because nothing was ever on it. Either side can terminate on thirty days' written notice under the published terms of business, and the ownership position sits in the standard terms every engagement is contracted under rather than something to negotiate on the way out." }, { "question": "What does a forward deployed engineer actually do?", "answer": "A forward-deployed engineer builds and ships inside your estate rather than writing recommendations about it. The work happens in your repositories, on your infrastructure, under your controls and your organisation's policies, and the engineer pair-programs with your own engineers for the whole build rather than for a handover fortnight at the end, with the transfer measured. On an Agentic Build Team it is one of three seats, alongside the interim agentic lead and the adoption lead, and it bills at the published senior practitioner rate of £1,250 a day. Because nothing was ever built on our estate, there is nothing to migrate off it when the engagement ends." }, { "question": "Why not just hire three permanent people instead?", "answer": "Often you should, and a permanent internal team in post and operating is one of the board outputs this engagement is judged on. The build team covers the gap before that, when the permanent team does not exist yet and the agenda will not wait for the search to finish. Three senior practitioners at £70,000 to £85,000 a month is a monthly retainer either side can end on thirty days' notice, with measurable value you can hold the team to from month one and an exit date agreed at kickoff. Recruiting your permanent team then happens across months five to nine, while the work is live rather than after we leave." }, { "question": "Do we still pay for a month you report as failed?", "answer": "Yes. Engagements are retainer-shaped rather than milestone-shaped, so the monthly fee stands, and what changes is what you are told and what you can do about it. A month that ends with no measurable value delivered is reported to your sponsor as a failed month, in those words, in the same pack as everything else, and it does not get renamed a discovery month. On payment you own all deliverables, documentation, designs and code created for you, including anything from a month that failed. Either side can end the engagement on thirty days' written notice, and two failed months without a credible cause is a reasonable moment to use it." }, { "question": "Who from our side needs to be involved in month one?", "answer": "A sponsor who can give the team a real reporting line, real decision rights and real access, because month one is spent embedding properly and a team without authority is an expensive advisory function. Practically that also means whoever owns the repositories and environments the work will run in, since everything is deployed on your infrastructure under your policies, and the engineers who will pair with ours through the build. All three practitioners are screened to BS7858 standard before they touch your estate. Beyond that, month one is ours to run, and by months two to four the team is shipping something that matters into production." }, { "question": "Is partner oversight part of the monthly fee or extra?", "answer": "Inside it. Partner oversight from James Rooney sits within the £70,000 to £85,000 rather than an account-management layer added on top, and there is no pyramid of juniors behind the three seats. In practice it means the monthly value commitment, the failed-month report and the exit taper all sit with the partner whose name is on the engagement rather than with a client-service tier relaying messages between you and the people doing the work. He most recently spent six months embedded as an interim agentic lead inside Placing Platform Limited (PPL), so the method the team runs is one he has run himself." }, { "question": "We already have a Head of AI. Does a build team still fit?", "answer": "A board that has appointed a Head of AI and now needs a delivery team under them is one of the situations this rung is built for. The three seats sit inside your management structure rather than alongside it, so the interim agentic lead runs delivery with a real reporting line into your Head of AI and accountability for the value committed each month, rather than competing for the mandate they already hold. The engineer builds in your repositories and the adoption lead owns the change, with partner oversight from James Rooney rather than an account-management layer, and a dated exit that leaves the capability with your permanent team." }, { "question": "Are governance and audit trails built in or added later?", "answer": "Built in. Governance, audit trails and human-in-the-loop gates are on the deliverable list rather than a later phase, and the first production release in months two to four ships with the governance around it rather than following on behind. That matters because retrofitting an audit trail onto a live agentic workflow is a rebuild, and because your risk function will want to see how a decision was reached before it lets the workflow scale. Everything runs on your infrastructure under your controls and your organisation's policies, so the evidence sits in your estate from the start." }, { "question": "Who agrees what counts as measurable value each month?", "answer": "You and the team, in writing, and the monthly commitment is written into the Statement of Work rather than left to a conversation. It is a measurable amount of value priced in currency, so it is a number your sponsor recognises rather than a list of activity, and the team reports against that same number in the same pack every month. If it is not met, the report states what was committed, what actually shipped and the specific cause, and it reaches the sponsor inside the same reporting cycle rather than at the next steering committee. How outcomes get priced is part of the delivery method published free on this site." }, { "question": "What is a forward deployed engineer?", "answer": "A forward deployed engineer is a software engineer who builds inside a customer's organisation, in that customer's repositories and cloud tenancy rather than advising from outside it. Tenhaw holds that seat on an Agentic Build Team. On the PPL engagement a two-week proof of concept turned PDFs into business intelligence, pair-programmed with a client engineer who finished 70% confident of running it unaided. It differs from a consultant, who recommends and hands over, and from a contractor working a ticket queue, because the engineer carries a real reporting line and is accountable for a system that runs. The title came out of enterprise software, where vendors put engineers on customer sites to build against live systems." }, { "question": "Do our own engineers review and merge the code your engineer writes?", "answer": "If that is how your repositories work, yes. The Tenhaw forward-deployed engineer builds inside your repositories, on your infrastructure, under your controls and your organisation's policies, so your branch protection, review rules and merge gates apply to that work just as they do to your own team's. Most of it is written in a pair with one of your engineers, at the published senior practitioner rate of £1,250 a day, so the reviewer has usually already seen it. On payment you own all deliverables, documentation and code. What is worth settling before month one is who holds the approver role when your own engineers are the ones pairing, because the same person cannot be both the build and the check." }, { "question": "Our releases go through a change advisory board. Does that slow the cadence?", "answer": "It shapes what gets committed rather than stopping it. Everything a Tenhaw build team ships is deployed on your infrastructure, in your repositories, under your controls and your organisation's policies, so your change process governs the release rather than ours. What the team commits to each month is a measurable amount of value priced in currency, not a weekly production push, so a board that sits monthly becomes a named dependency in that commitment. If a release slips because the board did not sit, the report names that as the specific cause rather than calling the month complex. Where your board meets quarterly, the sequencing is worth agreeing before kickoff rather than discovering it in month three." }, { "question": "Do our engineers need AI experience to pair with yours?", "answer": "No, and Tenhaw does not assume any. The forward-deployed engineer pair-programs with your engineers on the real system for the whole build rather than running a handover workshop at the end, and the delivery method they are learning is published free on this site, so your people can read it before anyone turns up. The toolchain runs inside your estate, typically Claude Code with OpenAI and Gemini models, chosen per case rather than as a house standard. What matters more than prior AI experience is that the engineers you nominate know your systems and are genuinely freed up, because the transfer is measured and it can only be measured on people who are actually in the pairs." }, { "question": "What if our engineers push back on pairing with an outside team?", "answer": "That is the adoption lead's job, and it is why Tenhaw holds a third seat rather than selling two builders. That seat sits at the published associate rate of £950 a day and owns getting people to work the new way, measured rather than assumed. It is the role most often cut from a business case and most often the reason it does not land. Pushback is usually about time rather than principle, since the pairing happens on live work in your repositories rather than in a training room, and the method is published in full so your engineers can judge it before they meet anyone. Where it is about the mandate instead, that is a sponsor decision." }, { "question": "What does procurement actually sign for a build team?", "answer": "A Statement of Work on Tenhaw's published terms of business, with the monthly value commitment written into it rather than left to a conversation. It carries thirty days' written notice either way, and ownership of all deliverables, documentation, designs and code passing to you on payment, including anything built in a month reported as failed. Liability is capped per engagement in that SOW, with confidentiality and data protection handled separately, and insurance figures are published in full, with cover increased for a specific engagement where your supplier standard requires it. There is no minimum term to negotiate down, because the engagement is monthly. How long your own third-party risk review takes usually sets the start date." }, { "question": "What if our permanent team is not hired when you are due to leave?", "answer": "It surfaces long before the final sixty days, because recruiting your permanent team is an explicit Tenhaw deliverable rather than a hope, and it runs across months five to nine while the work is live. A permanent internal team in post and operating is one of the board outputs the engagement is judged on, so a search that is not landing appears in the monthly report with its specific cause rather than at the exit. If the date arrives anyway, the engagement is monthly on thirty days' notice either way, so extending is a decision taken in the open rather than a default. Which seat is still unfilled matters more than the delay itself." }, { "question": "How much of our engineers' time does the pairing take?", "answer": "Enough that it has to be planned rather than absorbed. The Tenhaw forward-deployed engineer pairs with your engineers on live work in your repositories for the whole build, so it is delivery work rather than training stacked on top of it, but the people you nominate need to be genuinely freed up rather than nominally available. For scale, on the PPL engagement a client engineer who paired through a two-week proof of concept finished 70% confident of running it unaided. The transfer is measured, and it can only be measured on whoever is actually in the pairs. How many engineers you put through depends on how much of the capability you want held internally at the exit." }, { "question": "Our data is a mess. Do we need to fix that before a build team starts?", "answer": "Usually not first, and Tenhaw does not require a finished data programme before month one. The first production release lands in months two to four and is scoped against the estate you actually have, with the governance around it, rather than waiting on a platform rebuild. Where data quality is genuinely what blocks the value it does not stay vague, because the monthly report names it as the specific cause of a missed commitment, and two failed months without a credible cause is a reasonable moment to use the thirty days' notice. What that leaves open is which of your data problems actually blocks the first workflow, as against the ones you have been meaning to fix anyway." }, { "question": "Your team builds with AI tools. Why does that still cost £70,000 a month?", "answer": "Because the tools are the cheap part and the accountability is not. Tenhaw publishes the delivery method those tools are used inside, free to adopt without hiring anyone, so £70,000 to £85,000 a month does not buy a technique. It buys three senior practitioners inside your management structure with a real reporting line and real decision rights, committing in writing each month to a measurable amount of value priced in currency, where a month that delivers none is reported to your sponsor as a failed month in those words. Partner oversight from James Rooney sits inside that fee. How much of that delivery, adoption and governance load your organisation already carries is the part only you can price." }, { "question": "Can we try the build team for one month before committing?", "answer": "Effectively yes, because it is a monthly retainer on thirty days' notice either way, but one month judges the wrong thing. Month one on a Tenhaw build team goes on embedding properly, with a real reporting line, real decision rights and real access, and the first thing that matters ships into production in months two to four. If you want evidence before a six to twelve month engagement, the cheaper instruments are the AI Readiness Audit at £44,000 fixed over four weeks, which ends in working prototypes, or an Agentic Proof of Concept at £20,000 to £55,000 over two to four weeks. Which one fits depends on whether your uncertainty is about the problem or about us." } ] } ## Programme & Delivery Management Source: https://tenhaw.com/services/programme-management Last updated: 2026-11-05 { "slug": "programme-management", "rung": "05", "name": "Programme & Delivery Management", "track": "Oversight", "tagline": "We will govern the programme whether or not we are building any of it.", "summary": "Tenhaw provides programme and delivery management for agentic transformation programmes, including programmes delivered entirely by other suppliers. In the words most buyers use, you are hiring an AI programme director, an interim delivery director or a fractional AI delivery lead, supplied as an engagement rather than a permanent hire or an agency placement. We will govern a mixed estate of systems integrators, internal teams and specialist vendors as readily as we own the full stack, and we will say when another supplier is better placed to build something. It draws on a decade running delivery at HSBC, Anglo American and Discovery, and runs at £18,000–£35,000 per month.", "priceLabel": "£18k–£35k / month", "priceLow": 18000, "priceHigh": 35000, "priceUnit": "MON", "timeline": "Programme duration", "commitment": "30 days' notice either way", "howItEnds": "Monthly, cancellable on 30 days' written notice either way. Bought on its own with no build commitment attached, and handed over to your own people on an agreed date.", "badge": "Supplier-agnostic", "banner": { "title": "The lowest-risk way to work with us", "detail": "This rung is bought on its own. There is no requirement that Tenhaw builds any of the programme, and clients do appoint us to governance only. At the bottom of the band, £18,000 a month is roughly three days a week of a senior programme lead at the published day rate with partner oversight on top, and it is cancellable on 30 days' notice either way. If you want to see how we work before committing to anything larger, this is the cheapest way to do it." }, "teamShape": "One senior programme lead, an AI programme director or delivery director depending on the shape of the programme, with partner oversight from James Rooney and scaling with programme size. Available fractionally, from around three days a week.", "engineerNote": "No build engineer, deliberately: this rung governs whoever is building, including when that is nobody from Tenhaw. The lead is at the published senior practitioner rate of £1,250 a day, with partner oversight on top.", "rolesLede": "This is the rung you arrive at when you are searching for a person, not a project. It is the only one that supplies senior delivery leadership without Tenhaw building anything, and the only one you can buy part-time.", "roles": [ { "title": "AI programme director", "alsoCalled": [ "programme director", "AI programme manager", "transformation programme manager" ], "detail": "Owns the whole programme across every supplier in it, including the ones we are not. Governance a board can steer with, probabilistic forecasts built from real throughput rather than single invented dates, cross-supplier dependency management, and supplier performance reported without commercial self-interest filtering it, ours included." }, { "title": "Interim delivery director", "alsoCalled": [ "delivery director", "head of delivery", "interim head of AI delivery" ], "detail": "Steps into a delivery leadership seat that is vacant, newly created or in trouble, usually because a permanent search will take six months and the programme will not wait that long. The first four weeks establish what is genuinely in flight against what the board currently believes, which is where the gap normally sits." }, { "title": "Fractional AI delivery lead", "alsoCalled": [ "fractional AI lead", "part-time AI delivery lead", "fractional programme manager" ], "detail": "The bottom of the band, £18,000 a month, is roughly three days a week of a senior programme lead at the published day rate with partner oversight on top. That is enough to run governance, forecasting and supplier management on a single programme, and it is the right shape for an organisation that needs delivery discipline rather than another full-time salary." } ], "rightFor": [ "Programmes running across multiple suppliers with nobody owning the whole", "Organisations who have already chosen their build partners and need governance over them", "Boards that need a programme director in post this month rather than at the end of a six-month search", "Businesses wanting a fractional AI delivery lead instead of another full-time hire", "Boards receiving programme reporting they do not trust", "Businesses where the delivery discipline, not the technology, is the constraint" ], "notFor": [ "Programmes that already have credible delivery leadership in place", "Organisations wanting a supplier who will only report favourably on its own work", "Anyone after a contractor placement or a CV for a preferred-supplier list: this is an engagement with partner oversight behind it", "Single-team initiatives that do not need programme-level governance" ], "deliverables": [ "Programme governance a board will actually steer with, not a status pack", "Probabilistic delivery forecasting from real throughput, not single invented dates", "Cross-supplier dependency management, including where we are one of the suppliers", "Supplier performance reporting to one standard, Tenhaw's own workstreams included", "Risk and issue management with escalation that resolves rather than records", "Benefits tracking against outcomes priced in currency" ], "phases": [ { "label": "Weeks 1–4", "detail": "Establish the truth: what is actually in flight, what each supplier has committed to, where dependencies sit, and what the board currently believes versus what is real." }, { "label": "Ongoing", "detail": "Run the governance. Forecast probabilistically, surface slips before deadlines, manage cross-supplier dependencies, and report to the board in confidence intervals rather than traffic lights." }, { "label": "Continuous", "detail": "Hold suppliers to account, ourselves included. Where a Tenhaw workstream is behind, it appears in the same report as everyone else's." }, { "label": "Handover", "detail": "Build the internal capability to run this without us, and hand it over on an agreed date." } ], "boardOutputs": [ "One view of a multi-supplier programme, independently governed", "Delivery dates as probabilities you can plan against", "Supplier performance reported without commercial self-interest filtering it", "Early warning on slips, while there is still time to act" ], "blocks": [ { "eyebrow": "The monthly pack", "title": "What the board receives each month", "lede": "Four sections, in this order, every month, with the figures drawn from your programme's own delivery data.", "items": [ { "label": "Delivery dates as intervals, not as a date", "detail": "Every commitment carries a p50 and a p85 completion date simulated from the programme's own throughput, with the whole set simulated together rather than epic by epic. A single date with no interval around it tells a board nothing about whether to act." }, { "label": "Supplier-by-supplier performance, ours included", "detail": "Each supplier's committed against delivered work, in the same table, to the same standard. Where a Tenhaw workstream is behind, it appears in that table exactly as everyone else's does. Where we hold both the governance and a build role, the board is told so explicitly." }, { "label": "Risks and issues with named owners", "detail": "Every risk carries a named human owner, a current escalation state, and the date it was last moved. Items that have not moved since the last pack are shown as not having moved rather than restated." }, { "label": "Benefits tracked in currency", "detail": "What each outcome was priced at, what has been realised so far, and what is now forecast at close, with the gap named while there is still a quarter left to act on it." } ], "note": "The cadence, the forecasting method and the outcome validation this pack reports against are published in full, so you can hold the reporting to a standard that existed before your engagement did.", "noteLink": { "href": "/the-tenhaw-way", "label": "Read the delivery model" } } ], "faq": [ { "question": "Will Tenhaw manage a programme it is not building?", "answer": "Yes, and it is a deliberate part of the offer. Tenhaw provides programme and delivery management across mixed estates of systems integrators, internal teams and specialist vendors, with no requirement that we build any of it. Delivery governance is where the practice originated and it stands on its own." }, { "question": "Can you supply an AI programme manager without building anything?", "answer": "Yes. This rung is sold on its own and clients do appoint us to governance only. You get an AI programme director or senior programme manager, with partner oversight from James Rooney, running governance, probabilistic forecasting, dependency management and supplier performance reporting across whoever is building the thing. The fee is £18,000 to £35,000 a month depending on programme size and supplier count. The bottom of that band is about three days a week of a senior lead plus oversight, and the top is a full-time lead with delivery support as the supplier count grows." }, { "question": "Can I hire a fractional AI delivery lead?", "answer": "Yes. You get a senior delivery lead on a part-time engagement, typically two to three days a week, at a fixed monthly fee with thirty days' notice either way. The person is contracted by Tenhaw rather than employed by you or placed by an agency, screened to BS7858 standard before they touch your estate, with James Rooney accountable for the work alongside them. At the published rate card, three days a week of a senior programme lead with partner oversight lands at the bottom of the £18,000 to £35,000 band." }, { "question": "How do you avoid a conflict of interest when you are also a supplier?", "answer": "By reporting on our own workstreams in the same pack, to the same standard, as everyone else's, including when we are the ones behind. Where we hold both roles we say so explicitly to the board, and clients can and do appoint us to governance only, which keeps the governance entirely independent of the build." }, { "question": "What does programme management for an AI transformation cost?", "answer": "Tenhaw prices programme and delivery management between £18,000 and £35,000 per month depending on programme size and supplier count, with partner oversight included. It is deliberately the lowest-cost rung, because delivery governance is often where a programme is won or lost. It is bought on its own with no build commitment attached, and it runs monthly on 30 days' notice either way, so what you commit to is a month at a time." }, { "question": "Why does an agentic consultancy offer programme management?", "answer": "Because most agentic programmes fail on delivery discipline rather than on technology, and because that discipline is the deepest part of our track record: a decade running delivery at HSBC across 150+ teams and a $102M budget, at Anglo American across three continents, and at Discovery under a fixed launch date. Agentic transformation is a change programme with AI in it, and the change part is where programmes die." }, { "question": "Can you take over a programme that is already in trouble?", "answer": "It is the most common reason we are called. The first four weeks establish what is genuinely in flight versus what the board currently believes, which is usually where the gap is. We will tell you what we find, including when the answer is that the programme should be descoped or stopped rather than rescued." }, { "question": "What does the monthly board report contain?", "answer": "The same four sections every month, with every figure drawn from your programme's own delivery data. It opens with delivery dates as intervals. Each commitment carries a p50 and a p85 date simulated from real throughput, because a single date with no interval around it tells a board nothing about whether to act. Then supplier performance, committed against delivered, in one table to one standard, with Tenhaw's own workstreams appearing in it exactly as everyone else's do. Then risks and issues, each with a named human owner, an escalation state and the date it last moved. Finally benefits in currency: what each outcome was priced at, what has been realised, and what is forecast at close." }, { "question": "Can we bring programme governance back in-house later?", "answer": "Yes, and the engagement is designed to end that way. A handover date is agreed rather than left open, and the last phase of the work is building the capability inside your organisation to run the governance, the forecasting and the supplier management without us. It runs monthly and is cancellable on 30 days' written notice either way, with no build commitment attached, so there is nothing to unpick when you take it back. The pack and everything produced under it is yours, and the cadence and forecasting method behind it are published in full, so your own people can keep running what the board has been steering with." }, { "question": "What do we get for £18,000 a month versus £35,000?", "answer": "The band tracks programme size and supplier count. At £18,000 a month that is roughly three days a week of a senior programme lead at the published senior practitioner rate of £1,250 a day, with partner oversight from James Rooney on top, which is enough to run governance, probabilistic forecasting and supplier management on a single programme. As the programme scales and more suppliers come into it, the lead goes full-time and picks up delivery support, and that is what carries the fee toward £35,000. There is deliberately no build engineer in the fee at either end, since this rung governs whoever is building, including when that is nobody from Tenhaw." }, { "question": "Why pay for governance instead of putting the money into more delivery?", "answer": "Because more build capacity does not fix a programme nobody is steering, and it usually just puts more work in flight. Governance is deliberately the cheapest rung we sell, £18,000 to £35,000 a month, and the fee buys no engineer at all, because the job is to govern whoever is building, including when that is nobody from Tenhaw. What you get for it is forecasting a board can plan against, dependencies managed across every supplier in the programme, and slips surfaced while there is still time to act on them. If the real constraint turns out to be engineering capacity rather than delivery discipline, we will say so and point you at a different rung." }, { "question": "Our systems integrator offered to run the PMO. Why not let them?", "answer": "You can, but you are then asking a supplier to report on its own delivery to your board. This rung exists to be independent. It governs mixed estates of systems integrators, internal teams and specialist vendors, and clients do appoint us to governance only, with no requirement that we build any of the programme. Every supplier's committed against delivered work lands in one table to one standard, and where a Tenhaw workstream is behind it appears there exactly as everyone else's does. Where we do hold both governance and a build role, the board is told so explicitly rather than left to work it out." }, { "question": "Who do you need access to in the first four weeks?", "answer": "The people who know what is genuinely in flight, and the delivery data itself rather than the status pack written about it. Weeks one to four exist to establish the truth: what each supplier has committed to, where dependencies actually sit, and what the board currently believes against what is real, which is normally where the gap turns out to be. In practice that means each supplier's delivery lead, your own team leads and the sponsor, plus read access to the tooling the work runs in. Access matters more than diary time, because a forecast built from real throughput needs the underlying data, and a status pack is only ever as honest as what sits beneath it." }, { "question": "What if a supplier will not share their delivery data?", "answer": "Then that is a finding in its own right, and the board sees it as one. Forecasts here are built from real throughput, so where a supplier will not provide theirs we report what has actually landed in your environment against what they committed to, and we name the gap rather than colouring it in. It goes into the pack as a risk with a named owner and an escalation state, and it stays visible until it moves. If the position holds, the fix usually belongs in the contract rather than in the governance, and we will say that plainly to your commercial team rather than quietly working around it." }, { "question": "We already have a programme director. Do we still need this?", "answer": "Probably not. Programmes with credible delivery leadership already in place sit at the top of our own not-for list. Two situations still earn the fee. One is a board that does not trust the reporting it receives, which is a governance problem rather than a personnel one. The other is a multi-supplier estate where each supplier governs its own patch and nobody owns the whole, in which case the work sits above the individual programmes rather than replacing anyone in them. A thirty-minute call is usually enough to establish which of those you have, if either." }, { "question": "How much of our team's time does the governance take each month?", "answer": "Less than the reporting you are almost certainly doing today. The figures in the monthly pack come out of your programme's own delivery data rather than out of every team assembling a status update, so what your people spend time on is the conversations that produce decisions: dependency calls, risk reviews where an item actually moves, and the board session itself. Each risk carries one named owner and the date it last moved, so the effort lands on the person who owns the item while it is live rather than on everyone every week. If governance is generating more slide production than decisions it has failed, and fixing that is our job." }, { "question": "Can you cover a vacant delivery director seat while we recruit?", "answer": "Yes. The seat is vacant, newly created or in trouble, a permanent search runs to six months, and the programme will not wait that long, which is the usual reason the interim delivery director role exists. We can be in post this month with one senior programme lead and partner oversight from James Rooney behind them, running governance, forecasting and supplier management while your search continues. Because it runs monthly on thirty days' notice either way, it ends when your permanent hire lands rather than on a fixed term, and building the capability to run this without us is the last phase of the work rather than an afterthought." }, { "question": "How early would the board hear that a benefit is going to be missed?", "answer": "While there is still a quarter left to act on it, which is why benefits sit in the monthly pack rather than in a closure report. Each outcome is carried in currency: what it was priced at, what has been realised so far, and what is now forecast at close. A widening gap therefore shows up as a trend across consecutive packs instead of as a surprise at the end, and it arrives with a decision attached rather than as a red square on a slide. Sometimes that decision is to refocus the work, and sometimes it is to descope or stop it, which we will recommend when it is the honest answer." }, { "question": "Isn't this just an expensive project manager?", "answer": "It is a programme director's seat rather than a project manager's, and the difference is scope. Tenhaw's lead owns the whole programme across every supplier in it, including the ones we are not, holding each to what it signed up to against what has landed, and managing the dependencies between them, which no single supplier's project manager can do. The lead is at the published senior practitioner rate of £1,250 a day with partner oversight from James Rooney on top, drawing on a decade running delivery at HSBC, Anglo American and Discovery. If one team is the whole programme, a good delivery manager is cheaper and enough. This rung is built for the case where nobody owns the whole." }, { "question": "What happens to the governance if we change build supplier mid-programme?", "answer": "The governance barely changes. An incoming supplier joins the same table, to the same standard, as everyone already in it. Tenhaw governs mixed estates of systems integrators, internal teams and specialist vendors with no requirement that we build any of it, so a change of builder is a commitment and dependency problem rather than a rebuild of the reporting. What honestly changes is the forecast. Dates here are simulated from your programme's own throughput, and a supplier with no history in your environment has none to simulate from, so the interval starts wide and tightens as work lands. How long that takes depends on how much of the work in flight transfers rather than restarts." }, { "question": "Will you govern a transformation programme that isn't about AI?", "answer": "Yes, though Tenhaw builds and prices this rung for agentic transformation programmes at £18,000 to £35,000 a month. Our position is that an agentic programme is a change programme with AI in it, and the change part is where programmes die, which is why the discipline behind this rung predates the technology: a decade running delivery at HSBC across 150+ teams and a $102M budget, at Anglo American across three continents, and at Discovery under a fixed launch date. Where there is no AI or automation anywhere in the scope, a general programme firm will usually be the better buy and we will say so. What settles it is whether the hard part is the technology or the delivery discipline." }, { "question": "Do we have to move our delivery data into your tools?", "answer": "No, and there is nothing to buy or migrate. Tenhaw works inside the tooling your programme already runs in, under your own policies, and the monthly pack is produced from that delivery data rather than from a parallel system we install and you later lose. Every figure in it therefore traces back to a record your own people can open, which is what makes the reporting challengeable rather than something a board takes on trust. The cadence and the forecasting method behind the pack are published in full, so nothing underneath the numbers is proprietary to us. What varies between clients is whether the tooling records work at a level anyone can count." }, { "question": "Could a programme dashboard do this instead of paying for a person?", "answer": "A dashboard shows you the numbers. It will not chase the supplier whose commitment quietly moved. Tenhaw's £18,000 to £35,000 a month buys a senior programme lead with partner oversight from James Rooney, and what earns the fee is the part no tool does: holding each supplier to what it committed to, managing dependencies between them, carrying every risk to a named owner until it moves, and telling a board plainly when the honest recommendation is to descope or stop. If your delivery data is already clean and someone senior reads it every week, a dashboard is genuinely cheaper. The test is whether anyone today owns the whole programme rather than their own part of it." }, { "question": "Our board wants one date, not a range. Does this work for them?", "answer": "They get dates, just two of them. Tenhaw reports every commitment with a p50 and a p85 completion date simulated from your programme's own throughput, because one date on its own says nothing about how much room is left, whereas a p85 that has drifted three weeks across two packs is still something a board can act on. Boards that need a single number to say out loud generally commit externally to the p85 and manage internally to the p50. The honest change is that some dates move at the first pack, and the forecasting method is published in full, so your people can challenge how a number was produced rather than argue with the number itself." }, { "question": "How does this sit with the PMO we already have?", "answer": "Usually above it rather than instead of it. Tenhaw governs the whole programme across every supplier in it and owns the forecasting and the reporting standard, while your PMO keeps running the machinery it already runs. The pack is built from your delivery data, so it sets a standard rather than adding another reporting round on top of the ones you have. The handover phase of the engagement builds the capability to run all of it in-house on an agreed date, and an existing PMO is normally where that lands. Where your board already trusts and acts on the reporting it gets today, you do not need this." }, { "question": "Do you govern our internal teams as well as outside suppliers?", "answer": "Both, and they sit in the same table. Tenhaw is built for mixed estates: systems integrators, internal teams and specialist vendors, each reported committed against delivered to one standard, with our own workstreams in there too where we are building something. Internal teams are often the harder half, because an external supplier usually has commitments written into a contract, while an internal team frequently has neither the commitment written down nor throughput anyone has kept. What Tenhaw does not hold is line management over your people, so escalation runs through your sponsor, which is why the sponsor is one of the first people the engagement needs." }, { "question": "What if the board sees the pack and nothing changes?", "answer": "Then the governance has failed, and Tenhaw will say so rather than keep invoicing for reporting. The pack exists to produce decisions, which is why every risk carries a named owner and the date it last moved, and why items that have not moved are shown as not having moved rather than quietly restated. If the same items keep reappearing and no decision follows them, the constraint is your decision-making rather than your delivery discipline, and more governance will not fix that. It runs monthly on 30 days' notice either way, so stopping is cheap. Whether a stalled forum can be unstuck or has to be replaced is a question about your organisation, not about the pack." }, { "question": "Are the first four weeks just a paid review of ourselves?", "answer": "No, and they are not billed as a separate study. Tenhaw charges the same monthly fee from day one, £18,000 to £35,000 depending on programme size and supplier count, with no discovery charge on top. What those four weeks produce is the baseline everything afterwards is forecast and reported against: what each supplier has actually signed up to, where the dependencies between them sit, and how much throughput history exists to forecast from. Because it is cancellable on 30 days' notice either way, a first month that finds the programme healthier than the board feared is a cheap answer to have. How much of that month is fact-finding depends on how many suppliers already report to a common standard." } ] } ## AI agents and workflow automation Source: https://tenhaw.com/use-cases/ai-agents-and-workflow-automation Last updated: 2026-11-05 { "slug": "ai-agents-and-workflow-automation", "name": "AI agents and workflow automation", "title": "Connect document and system handoffs with AI", "metaTitle": "AI agents and workflow automation", "description": "Build AI workflows around your systems, approvals and people. Tenhaw helps you test one useful process and develop the team to run it.", "summary": "A document arrives, someone checks three systems, and the next team waits for an answer. That is a useful place to explore AI. Tenhaw works with the people doing the job to design a workflow that gathers information, prepares the next action and brings the right decisions back to them. Start with one process and test it against the cases your team actually handles.", "buyer": "For operations and technology leaders joining up work across documents, systems and teams, with a clear owner for the result and people available to shape the first version.", "outcomes": [ { "title": "Your team can follow each handoff", "detail": "Give each stage a clear input, output and owner. Show reviewers where information came from and what needs their attention before work moves on." }, { "title": "Approvals stay part of the workflow", "detail": "Agree which actions the system may take, which need a person and how exceptions return to the team. Build those decisions into the process." }, { "title": "The first build informs the next decision", "detail": "Test completion, errors, review effort and running cost against an agreed starting point. Use the results to decide what deserves further investment." } ], "approach": [ { "title": "Map the work with its owners", "detail": "Bring the ordinary cases and the awkward ones. We trace the handoffs, permissions and decisions, then choose a useful slice for a proof of concept." }, { "title": "Build inside your environment", "detail": "Connect the necessary data and tools within your agreed access controls. Pair with your engineers and test the workflow with the people who will review its output." }, { "title": "Plan how the team will operate it", "detail": "Define the review queue, monitoring, support responsibilities and release criteria. A continuing build engagement develops the software and the working practices around it together." } ], "evidence": [ { "title": "Documents became business intelligence at PPL", "detail": "At Placing Platform Limited, the London market digital placing platform, Tenhaw paired with a client engineer to build a working proof of concept in two weeks. PDFs became structured, enriched data feeding a dashboard the business already used, on Azure.", "href": "/case-studies/specialty-insurance-agentic-lead", "label": "Read the PPL document workflow case study" } ], "serviceSlugs": [ "ai-readiness-audit", "agentic-proof-of-concept", "agentic-build-team" ], "relatedGuides": [ { "href": "/guides/end-to-end-agentic-workflow-implementation", "label": "Design an end-to-end agentic workflow" }, { "href": "/guides/mcp-tool-calling-and-system-integration", "label": "Connect agents to existing systems" } ], "faq": [ { "question": "Can a workflow agent reuse a decision our team has already approved?", "answer": "Yes, within the scope and conditions attached to that approval. We define what the approval covers, when it expires and which changes require another review. The workflow keeps the decision with the relevant case so later steps can check it." }, { "question": "How do reviewers pick up a case an agent has paused?", "answer": "Through a defined review step containing the source material, the proposed action and the reason for the pause. Reviewers need enough context to decide, correct or return the case, with the result recorded before processing continues." }, { "question": "What should we bring when scoping an automation across two teams?", "answer": "A few completed cases, the people responsible for each handoff and examples of where work gets stuck. Those inputs help establish the boundaries, identify decisions that need an owner and choose a first workflow both teams can test." } ] } ## Enterprise AI assistants Source: https://tenhaw.com/use-cases/enterprise-ai-assistants Last updated: 2026-11-05 { "slug": "enterprise-ai-assistants", "name": "Enterprise AI assistants", "title": "Help your operations team find policy answers", "metaTitle": "Enterprise AI assistants and knowledge access", "description": "Help colleagues find and check answers in company information. Tenhaw designs enterprise AI assistants around permissions, sources and real questions.", "summary": "Your team knows the answer is somewhere in the business. Finding the right document, version and owner can take longer than the decision itself. We help you design an internal AI assistant around the questions people need answered, with access rules, source references and a way to handle uncertainty. A focused proof of concept gives your team something concrete to evaluate.", "buyer": "For product, operations and technology teams exploring an assistant for internal knowledge, specialist guidance or finding information across an agreed set of company sources.", "outcomes": [ { "title": "People can inspect the source of an answer", "detail": "Make the supporting passage and document easy to open. Colleagues can check the context and apply their judgement to the decision in front of them." }, { "title": "Access follows the person asking", "detail": "Design retrieval around identity and document permissions. Test access boundaries alongside answer quality so the assistant fits the way your organisation shares information." }, { "title": "You can assess usefulness on real questions", "detail": "Agree a set of questions with the people who know the material. Check whether the assistant finds relevant evidence, answers appropriately and recognises gaps." } ], "approach": [ { "title": "Choose the decisions the assistant will support", "detail": "Start with a recognisable task and a manageable source collection. Identify the content owners, the users and the information each needs to do their work." }, { "title": "Test retrieval before widening the scope", "detail": "Our approach uses retrieval-augmented generation, or RAG, where useful: find relevant material, then use it to support the response. Test missing, outdated and conflicting information too." }, { "title": "Build the operating routine with your team", "detail": "Plan how sources get updated, questions get reviewed and changes get tested. Keep the evaluation examples and ownership clear as the assistant develops." } ], "evidence": [ { "title": "PPL tested a practical document pipeline", "detail": "Tenhaw's working proof of concept at Placing Platform Limited extracted and enriched PDF information for business intelligence. A client engineer paired throughout the two-week build, connecting the implementation to the people responsible for the data.", "href": "/case-studies/specialty-insurance-agentic-lead", "label": "Read the document-to-BI proof of concept" }, { "title": "Our retrieval approach is published", "detail": "The guide explains how we would design source access, permissions and evaluation for an enterprise knowledge assistant, including the questions to settle before choosing the technology.", "href": "/guides/retrieval-rag-and-permission-aware-knowledge-access", "label": "Explore our approach to enterprise retrieval" } ], "serviceSlugs": [ "ai-readiness-audit", "agentic-proof-of-concept", "agentic-build-team" ], "relatedGuides": [ { "href": "/guides/retrieval-rag-and-permission-aware-knowledge-access", "label": "Retrieval, RAG and permission-aware knowledge access" }, { "href": "/guides/guardrails-hallucination-and-accuracy-control", "label": "Evaluate answers and handle uncertainty" } ], "faq": [ { "question": "How should an enterprise assistant handle two conflicting policies?", "answer": "It should surface the conflict and the relevant sources for review. The content owner decides which policy applies. Version, publication date and ownership help the assistant recognise differences, while evaluation examples check that it escalates the conflict appropriately." }, { "question": "Can we try an internal assistant before designing its chat interface?", "answer": "Yes. We can evaluate retrieval and responses using a set of real questions before investing in the interface. That gives the team evidence about the sources and answers, which then informs where the assistant belongs in their working day." }, { "question": "How do we agree which questions an internal assistant should answer?", "answer": "Choose questions connected to a defined task, with source material and an owner who can assess the answer. Include frequent requests, difficult exceptions and questions that should be referred to a person. That becomes the initial scope and evaluation set." } ] } ## AI product development Source: https://tenhaw.com/use-cases/ai-product-development Last updated: 2026-11-05 { "slug": "ai-product-development", "name": "AI product development", "title": "Build an AI product around a real customer need", "metaTitle": "AI product and application development", "description": "Turn a useful AI product idea into a tested application. Tenhaw brings product discovery, engineering and adoption together with your own team.", "summary": "The interesting part of an AI product is what it helps someone do. We work with your product and engineering teams to choose that job, test the assumptions and build a first version people can try. Your feedback shapes the next release, while the requirements, code and operating knowledge stay connected as the product develops.", "buyer": "For organisations building an AI application, adding a useful AI feature to a product, or bringing in an embedded team to move an agreed opportunity into delivery.", "outcomes": [ { "title": "The product starts with a useful job", "detail": "Turn the idea into a specific user task, a clear first release and evidence that would justify further investment. Give product owners a decision they can act on." }, { "title": "Engineers and users shape the same build", "detail": "Keep the requirements, difficult examples and test results together. Engineers can work against the full context while users help decide whether the result is useful." }, { "title": "Your team can develop the product further", "detail": "Build in your repositories and environment, with pairing, documented decisions and an agreed handover. Ownership of the deliverables transfers on payment under the engagement terms." } ], "approach": [ { "title": "Make the first product decision testable", "detail": "Explore the user's task, the available data and the surrounding process. Use the readiness audit or a scoped proof of concept to test the most consequential assumptions." }, { "title": "Build against shared requirements", "detail": "Structure the source material, resolve gaps with the business and define acceptance examples. Use AI-assisted engineering with code review, security checks and automated, manual and user testing." }, { "title": "Develop the product and its support together", "detail": "An embedded build team brings engineering and adoption into the work. Agree release decisions, support responsibilities and the capability your permanent team needs to take forward." } ], "evidence": [ { "title": "PPL built and tested a useful first version", "detail": "Tenhaw and a PPL engineer built a working document-to-business-intelligence proof of concept in two weeks. Requirements became structured markdown before the build, and the engineer practised the method throughout.", "href": "/case-studies/specialty-insurance-agentic-lead", "label": "See how the PPL proof of concept was built" }, { "title": "James ran the Discovery+ visual rebrand team", "detail": "In his role at Discovery, James made delivery risk visible through capacity-based forecasts. The team was one of six on the launch, which met its fixed date across Discovery+ and Eurosport.", "href": "/case-studies/discovery-plus", "label": "Read James's Discovery+ delivery case study" } ], "serviceSlugs": [ "ai-readiness-audit", "agentic-proof-of-concept", "agentic-build-team" ], "relatedGuides": [ { "href": "/guides/ai-native-sdlc-and-product-delivery", "label": "AI-native software delivery" }, { "href": "/the-tenhaw-way/building-with-ai", "label": "Our published AI engineering method" } ], "faq": [ { "question": "How do product managers turn AI experiments into backlog decisions?", "answer": "Record the assumption, the user task and the evidence from each experiment. Product managers can then decide which outcome to pursue, what needs another test and what should leave the backlog. The build follows that decision with acceptance examples attached." }, { "question": "What do we capture when a tester rejects an AI-generated result?", "answer": "The input, the expected behaviour, the observed result and the requirement it failed, within the project's data-handling rules. That gives the team a repeatable test case and helps distinguish a requirement gap from a model, retrieval or application problem." }, { "question": "How do we decide whether an AI feature belongs in the customer journey?", "answer": "Test it against a task customers already need to complete. Look at the usefulness of the result, the effort of checking it and how people recover from an error. Those observations inform the product decision and the support it will need." } ] } ## AI training and adoption Source: https://tenhaw.com/use-cases/ai-training-and-adoption Last updated: 2026-11-05 { "slug": "ai-training-and-adoption", "name": "AI training and adoption", "title": "Build your team's AI skills on work that matters", "metaTitle": "Practical AI training and adoption", "description": "Help your team use AI on real delivery work. Tenhaw combines practical pairing, shared working methods and adoption within its delivery engagements.", "summary": "A useful AI skill is one your team can apply again next week. We help product managers, engineers, testers and leaders learn through the work in front of them: shaping requirements, building, checking results and deciding what changes. Practical learning sits inside Tenhaw's readiness, design and build engagements, so the method develops alongside the people who will use it.", "buyer": "For leaders whose teams have access to AI tools and need a shared way to use them, or who want their people to develop capability while a real delivery problem gets addressed.", "outcomes": [ { "title": "People practise on familiar work", "detail": "Use the team's own requirements, examples and decisions. The people who understand the work help shape the method and can see where their judgement matters." }, { "title": "The method becomes something colleagues can reuse", "detail": "Turn practices that have been tried together into working guides, examples and review habits. Make it easier for another colleague to follow the same approach." }, { "title": "Leaders can see what is changing", "detail": "Look at how people complete a task, assess the output and improve it. Use that evidence to decide where further coaching, access or changes to responsibilities would help." } ], "approach": [ { "title": "Choose a task worth learning through", "detail": "Find a piece of work with a clear owner and a result the team can assess. Agree which roles need to participate and where learning fits into delivery." }, { "title": "Practise the method alongside the team", "detail": "Pair on requirements, implementation and review as appropriate to the engagement. Explain the decisions while making them, then give people room to try the next step themselves." }, { "title": "Make adoption part of the operating model", "detail": "Agree responsibilities, review points and how the practice will be supported. Readiness establishes priorities, design shapes the working model, and a build team develops capability through delivery." } ], "evidence": [ { "title": "Microsoft EMEA put Copilot into programme reporting", "detail": "In James’s three-month contractor role inside Microsoft, he embedded Copilot in biweekly programme reporting. Reported use grew from roughly 10% to all EMEA country leads and the leadership cohort involved. This was cohort-level reported adoption within programme delivery, rather than a Microsoft-wide result.", "href": "/case-studies/microsoft-emea-programme-delivery-copilot", "label": "Read the Microsoft EMEA delivery and adoption case" }, { "title": "PPL learnt the method through a real build", "detail": "During Tenhaw's six-month PPL engagement, a client engineer paired throughout a two-week working proof of concept. At its end, the engineer reported 70% confidence that they could follow the process independently. An eight-week project then developed operating guides across Product, Engineering and QA, with each step practised on live work.", "href": "/case-studies/agentic-ai-in-insurance-operating-model", "label": "Read how PPL developed its AI working practices" } ], "serviceSlugs": [ "ai-readiness-audit", "agentic-design-team", "agentic-build-team" ], "relatedGuides": [ { "href": "/the-tenhaw-way/building-with-ai", "label": "Try the published AI engineering method" }, { "href": "/guides/ai-native-sdlc-and-product-delivery", "label": "Connect AI learning to software delivery" } ], "faq": [ { "question": "Can product managers and testers learn alongside engineers?", "answer": "Yes. Their work meets at requirements, acceptance decisions and feedback, so practising together helps each role understand the others. At PPL, the operating-method project covered Product, Engineering and QA, with design, build, testing, review and deployment practices developed on real work." }, { "question": "What should participants bring to practical AI training?", "answer": "A real task, relevant examples and the authority to discuss how the work is done. Participants also need the agreed tools and access for that task. Their difficult cases help make the practice useful, and the engagement scope determines which activities we work through together." }, { "question": "How do we teach a new starter the AI working method?", "answer": "Give them a small task, a worked example and someone to review it with. The operating guide should explain the decisions and checks as well as the steps. Comparing the new starter's attempt with the example shows where the guide or coaching needs improvement." } ] }