Factory Readiness Assessment
Know what to change before you scale.
We examine how ready your organization is to run a Software Factory. You get an evidence-backed baseline that shows the first constraint and what should happen next.
Evidence-backed | client-specific | recommendation, not a pitch
The deliverable
What you hold at the end
The result is written for your organization, not for a market category.
Readiness baseline
A defensible view of where the organization stands today, tied to evidence you can inspect.
Constraint map
Which constraint actually limits you first: delivery, architecture, product, organization, or the way decisions get made.
Outcome hypothesis
A client-specific outcome, baseline, target, and named data source for the work that follows.
Prioritized roadmap
A clear recommendation: training, a Factory pilot, direct rollout, or a deliberate sequence of them.
Scope
What we examine
We follow one real value stream from intent to production and look at what carries it, what slows it, and who decides.
Business outcome and value stream
The outcome the organization is trying to reach, and the value stream that has to deliver it. We follow one path from idea to production and look at where the work waits.
Delivery and DORA signals
Deployment frequency, lead time, change failure rate, time to restore. We work with the delivery signals your setup already produces, and we say plainly where a signal is missing or too thin to read.
AI-assisted development and change confidence
How much of the work already runs with agents, and how confident engineers are when they change the system. Where confidence is low, we look at what sits behind it.
Architecture and context readiness
Whether the codebase, its boundaries, its tests, and its written rules give an agent enough context to work safely.
Product and engineering decisions
Who decides what gets built, how intent reaches the team, and how much rework comes from specs that arrived unclear.
Organization steering and governance
How budget, staffing, security, and compliance set the frame engineering works in, and who can clear a blocker once we name it.
Assessment output
An illustrative constraint profile
The assessment reads the six dimensions together. A strong signal in one area does not cancel a constraint in another.
- Business outcome and value stream
- Delivery and DORA signals
- AI-assisted development and change confidence
- Architecture and context readiness
- Product and engineering decisions
- Organization steering and governance
Evidence
How we collect evidence
A self-assessment opens the conversation. On its own it is not proof, so we check what we hear against several sources.
Anonymous conversations with engineers
We talk to the people doing the work, one to one. We do not attribute what we hear back to the person who said it.
Architecture and SDLC checklist
Your team completes a written checklist before the session. It gives us the starting picture and shows where answers inside the organization differ.
Artifact review
System diagrams, agent rules, incident process, observability, org structure, and source access, as far as they exist and can be shared. We compare what people describe with what the artifacts show.
Follow-up interviews
Where checklist, artifacts, and conversations disagree, we go back and ask. Those gaps are where we dig.
The work
From evidence to an executive decision
The exact duration and on-site share are confirmed in the proposal for your context.
-
01
Frame the outcome
Define the business outcome, the value stream, the current pressure, and the decision this assessment must support.
-
02
Read the system
Look at delivery signals, AI use, change confidence, architecture, context readiness, and how product and engineering decisions get made.
-
03
Find the constraint
Build the evidence-backed baseline and identify which constraint limits progress before recommending a solution.
-
04
Decide the route
Deliver the roadmap, pilot recommendation, measurement plan, and executive readout.
Your result
A decision product you keep
The baseline and roadmap are yours, whether or not we deliver the next step.
Generic discovery
A provider gathers enough context to sell its preferred service.
- The recommendation is predetermined.
- Evidence stays vague or provider-owned.
- Training becomes the automatic next step.
- Business impact has no named source.
Factory readiness
The organization gets a plain read and a clear next decision.
- The weak constraint determines the recommendation.
- The client owns the baseline and roadmap.
- Training is one possible route, not the default.
- Every proposed outcome names how it will be measured.
Measurement plan
Engineering signals plus a business outcome
The assessment does not pretend that engineering activity alone proves value.
- Where you are now
- Baseline
- What should change
- Target
- Where the evidence lives
- Source
- When the result is reviewed
- Cadence
Preconditions
What we need from you
The assessment produces a usable answer when these are in place before we start.
A named business decision
One decision the assessment has to inform. Without it we produce a document, and a document changes nothing.
Access to a real value stream and its delivery signals
A live stream rather than a tidy example, together with whatever delivery signals it produces: repository history, CI runs, ticket flow, incident records.
The relevant stakeholders
Engineering, product, architecture, and the leadership that owns budget and mandate. The people who would act on the result should take part in producing it.
Artifacts and system access
Diagrams, rules, dashboards, and access to the code we are talking about, within the agreements and access rules you set. We work with what exists, not with what should exist.
Price
A fixed price for a result you own
The fee covers the diagnosis, roadmap, and executive readout. You own the result whether or not we deliver the next step.
Before you commission the assessment
Who is this for?
Engineering organizations that have moved beyond isolated AI experiments and need an evidence-backed decision about training, a pilot, or wider rollout.
Who is this not for yet?
It is not the right starting point for a tool demo, a generic AI benchmark, or an organization without a named decision, a real value stream, and leaders prepared to act on the result.
If the immediate need is shared engineering practice rather than an organizational diagnosis, Team Training may be the smaller next step.
What happens in the first conversation?
We clarify the business decision, the value stream, the current constraint, who owns the outcome, and which evidence is likely to be available. We then say whether the assessment fits and what must be resolved before a proposal makes sense.
Does the assessment always lead to training?
No. It can recommend training, a Factory pilot, direct rollout, or a sequence. The evidence decides the route.
What do you need access to?
The business outcome, the value stream, your delivery signals, AI usage, the architecture and context setup, and the people who make the decisions. We agree the exact access list before work starts.
What happens after the executive readout?
You own the baseline, constraint map, outcome hypothesis, roadmap, pilot recommendation, and measurement plan. You can proceed with us or use the result independently.
How long does the assessment take?
The duration depends on the value stream, available evidence, stakeholder access, and on-site needs. The proposal names the working period, inputs, sessions, and executive decision date before the engagement begins.
Next steps
Use the evidence in the next engagement
Build shared practices with Team Training
Use the assessment baseline to point a hands-on training at the constraint that matters first.
Explore Team TrainingTest one value stream in a Factory Pilot
Use the agreed outcome, baseline, and measurement plan to scope a working Factory slice.
Explore the Factory PilotMake the next decision with evidence
Commission the Factory Readiness Assessment and leave with a baseline, the real constraints, and a prioritized route forward.