Twelve weeks of workshops, and a way of working your teams keep
Three workshops a week, one for each perspective: the user, the business, the technology. Different people in the room each time, the same use case moving through all of them. Every three workshops produce something you keep — a prototype, a decision, a constraint resolved, an ownership change. At the end your own teams run it without me.
- Price on request
- 12 weeks
- Remote or on-site
- English or German
A successful pilot changes surprisingly little
Most AI programmes buy a pilot. The pilot works, everybody is pleased, and nothing about how the organisation makes decisions has changed. Six months later the second use case starts from zero, with the same arguments, the same missing constraint list and the same surprised finance conversation.
This programme is built the other way round. The use cases are real and the prototypes are real, but the deliverable is the working process: three perspectives, two gates, one repository, and people who have now done it twelve times.
Three months is the shortest honest version. It is long enough for a decision to be taken and reversed, for a constraint to be discovered and worked around, and for the second use case to be started by your own people while I am still in the building. It is short enough to sit inside one budget cycle.
Three workshops a week, one use case moving through all of them
The same three sessions every week, in the same order, with different people in each. The order is the point: a use case nobody will use does not get better with a better model, and one with no business case will not survive the quarter[1][5].
The user
“Who is this for, and what does the day look like afterwards?”
- Users and personas, named, not assumed
- The journey as it should be, end to end
- What people do today and what breaks
- Which part of it AI is actually allowed to touch
In the room: Product owners, business analysts, designers, service and support
The business
“What is it worth, what is in the way, and who signs?”
- The value chain the use case sits in
- Constraints that are real: legal, contractual, political
- The business case, with the numbers written down
- What success is measured by, before anyone builds
In the room: Finance, business owners, legal, compliance, leadership
The technology
“Can it be built, run and defended?”
- Architecture, data access and the layer decision
- How it is built, reviewed, tested and deployed
- Security, certification evidence, audit trail
- What it costs to run and who is on call
In the room: Engineering, platform, data, security, operations
Two gates, crossed in week two and week three
Work does not move between perspectives on goodwill. Each gate has a written condition and a date. Failing one is cheap in week two and catastrophic in month six, which is the entire argument for running them this early.
What happens, week by week
This is the default shape. It moves with what the first two weeks find: if a constraint turns out to be a legal fact rather than a habit, weeks six and seven change, and that is the programme working rather than failing.
Result: a current-state map that all three perspectives signed, and a first list of candidate use cases.
Result: a scored shortlist with the reasoning attached, and an agreed first project. Gate one.
Results: use-case briefs, value cases, constraint lists, and the first decision records in the repository. Gate two.
Result: one repository containing the journeys, the value case, sample data, decisions, and infrastructure as code.
Result: a journey prototype that can be put in front of eight real users, plus what to ask them.
Result: a constraint prototype and a decision record for each constraint: fact, workaround or removed.
Result: a technical prototype running on real data, with the evaluation set and the first measured numbers.
Results: user findings, a corrected business case, an evaluation set, and an evidence pack that exists as a by-product.
Result: a written decision: go, stop, or narrow. Stopping here is a good outcome and is priced as one.
Results: MVP scope, roadmap, ROI model and the funding case, ready to file[11].
Result: the organisational change written down: roles, ownership, gates, and what to stop doing.
Result: the second use case started by your own people, and a written record of where they needed help.
Every block of three workshops leaves something behind
Every block of three workshops produces something that exists after the workshop. These are the four shapes they take.
Four different shapes
A journey prototype for the user, a constraint prototype for what is in the way, a technical prototype on real data, and an evidence pack from testing all three.
Written, with reasons
Decision records for every choice that would otherwise be re-argued: the layer, the constraint, the scope, the go or stop. With what would change the answer.
Including what is not code
Journeys, value cases, sample and labelled data, source documents, infrastructure, implementation, evidence. One place, one owner per directory.
The part that lasts
Who owns what, which gates exist, what may merge without a specialist, and which meetings stop happening.
The repository gets built in week four and carries the rest
By the end of month one everything lives in one place, with an owner per directory. This is the change that saves the most time over the following two months, and the one teams push back on hardest in week four[6][7].
docs/journeys/docs/decisions/business/value-case/data/samples/data/labelled/input/source-documents/infra/app/evidence/Different people every week, on purpose
The programme rotates combinations deliberately. The point is that the handover gets practised by the people who have to do it afterwards, not performed once for an audience.
| Session | Core attendees | Joins for part of it |
|---|---|---|
| Perspective one · the user | Product owners, business analysts, designers, service and support | The people who actually do the work being changed |
| Perspective two · the business | Finance, the business owner, legal or compliance where relevant | The sponsor, for the decisions |
| Perspective three · the technology | Engineering, platform, data, security | Operations, for anything that will be on call |
| Monthly review | One person from each perspective, plus the sponsor | Everyone, for the decision at the end of month three |
What exists on the last day
Everything below is in your repository, owned by your people, and produced during the programme rather than written up afterwards.
A working process, run twelve timesIncluded
Three perspectives, two gates, one repository, and the people who have now done it often enough to run it themselves.
Prototypes in four shapesIncluded
Journey, constraint, technical, and the evidence from testing them on real people and real data.
MVP scope, roadmap and funding caseIncluded
What to build first, what it returns, what it costs to run, and whether AWS funding covers part of it[11].
Organisational change planIncluded
Roles, ownership, quality gates, and the list of things to stop doing.
The second use case, already movingIncluded
Started in week twelve by your own people, with me in the room but not running it.
Price on request, and here is why
Every other page on this site has a price on it, because a workshop is a workshop. This one does not, and I would rather say why than hide behind a form.
Thirty-six workshops at my normal rate of €2,000 each is the arithmetic, and the written results sit on top of that. But the honest answer is that the shape moves: some organisations need twelve weeks with three sessions, some need eight weeks with four, some need two use cases in parallel and some need one done properly. Quoting the arithmetic would be quoting a programme I have not scoped yet.
So the first conversation is free and it is about scope, not about price. If the answer turns out to be that you should buy three workshops rather than thirty-six, I will say so, and the Discovery Workshop page has that price on it already.
What people ask before booking.
Three workshops a week is a lot. Is that realistic?
Each session is two to four hours with different people, so no individual is in more than one a week plus the monthly review. The load per person is roughly half a day a week, which most teams can carry for a quarter.
What if we only have one use case?
That is the normal case and it works well. The second use case in week twelve is the test that the process took, and it can be a small one.
Do you build the production system?
No. The programme ends with a working prototype, a scoped MVP and a plan. Building it is your team's job, or an implementation partner's, which is deliberate: the point is that you can.
What if the decision in week nine is to stop?
Then you have spent one quarter instead of two years, and you have a working process and a team that knows how to use it. That is the outcome the gates exist to produce.
Can it run remotely?
Yes, and most of it usually does. The first two weeks and the last week are much better on-site. Vienna or anywhere in Europe, travel outside Vienna at cost.
Do you need access to our systems?
To real data, yes, ideally anonymised samples from week two. To production systems, no. The technical prototype runs in your own account with your people.
Is this ISO certification?
What size of organisation is this for?
It needs enough people that the three perspectives are actually different people. Below about forty staff the enablement workshops usually fit better than the programme.
Linda Mohamed
I design and build AI and cloud systems on AWS and hybrid platforms, and I teach how they work. I have organised the AWS User Group Vienna for more than seven years, co-organise AWS Community Day DACH, teach AI architectures at Hochschule Burgenland, speak at conferences in Europe and the US, and maintain ai-solutions.wiki. Based in Vienna. Remote or on-site, in English or German.
Where the facts come from.
Prices, service names and limits change. The linked official pages are the reference; figures on this page were checked in September 2026.
- ISO/IEC 42001:2023, AI management systems
- ISO/IEC 27001, information security management
- ISO 9001, quality management
- Regulation (EU) 2024/1689, the EU AI Act
- NIST AI Risk Management Framework
- CNCF TAG App Delivery: Platforms White Paper
- CNCF TAG App Delivery: Platform Engineering Maturity Model
- DORA: DevOps Research and Assessment
- AWS Well-Architected Framework
- Amazon Bedrock AgentCore: observability
- AWS: AI services overview
- ai-solutions.wiki: from AI proof of concept to production
- ai-solutions.wiki: build vs buy for AI
- ai-solutions.wiki: total cost of ownership for AI
- Training Magazine: 2025 Training Industry Report
Start with one conversation.
30 minutes to look at your idea, your data and the right starting point. Or book 15 minutes if you only have a question.
- Whether a quarter is the right size for you
- Which use case would go first
- Who would need to be in each session
- Whether a shorter programme would do the job
Vienna, Austria · remote across Europe · [email protected]
