Building together

Listening to different positions to build a shared understanding and a shared responsibility.

On one page

We work with those who know, carry out, maintain, decide and receive the result. We frame the problem together, represent the domain, choose a first complete path and learn with artefacts that can be examined.

01Starting from a concrete situation. The first conversation can start from a concrete situation, an open question or an ambition still looking for its best form:
02Active listening. Listening actively means handing back a representation.
03Framing together what deserves to change. The same difficulty may allow different answers.

An intelligent system enters work that already has its own language, knowledge, tools, adaptations, responsibilities and consequences.

Building it well requires listening to those who know different parts of that reality:

the people who do the work;
those who decide;
those who maintain the applications;
those who govern data and security;
those who receive the result;
those who answer when an exception appears.

Each position sees something different. Working together brings those perspectives into one place, makes their relations visible and turns them into decisions that can be built and revised.

Starting from a concrete situation

The first conversation can start from a concrete situation, an open question or an ambition still looking for its best form:

a process that accumulates waiting;
information that is hard to establish;
a recurring decision;
business logic spread across places;
reporting that requires reconstructing data;
a project that loses its memory;
a technology that deserves evaluation;
a physical operation.

We walk through a real situation from the input to the result.

We study:

what happens;
which people take part;
which systems are involved;
which decisions appear;
which rules and exceptions exist;
which information is reconstructed;
which authority each action needs;
which signal allows the work to be considered complete.

The usual case shows the path. The difficult case reveals the knowledge and the responsibilities the design has to take in.

Active listening

Listening actively means handing back a representation.

During the work we:

gather perspectives;
clarify terms;
formulate questions;
relate sources and examples;
make disagreements visible;
represent states, decisions and exceptions;
share that interpretation;
let the team correct it.

Listening produces artefacts:

maps;
glossaries;
sources;
knowledge models;
decisions;
paths;
hypotheses;
risks;
criteria for the result.

These objects turn the conversation into a common basis for building.

Framing together what deserves to change

The same difficulty may allow different answers.

A slow process may need:

better information;
an interface;
an integration;
a rule;
a change of policy;
a model;
an automation;
an agent;
a workflow;
a reallocation;
the removal of a step.

Together we frame:

the result;
the baseline;
the constraints;
the side effects;
the authority;
the operational capacity;
the conditions for success;
the questions that still have to be resolved.

The proposal becomes a hypothesis of improvement that can be put to the test.

Representing domain knowledge

Specialists contribute something an isolated source rarely contains in full:

meaning;
context;
exceptions;
history;
consequences;
priorities;
responsibilities.

We represent that knowledge through entities, relations, states, rules, decisions, vocabulary, evidence, constraints, questions and criteria.

The representation has to be understandable for the team and usable by software, models and agents.

DocuLogic, KIR, graphs, schemas and contracts help keep that continuity between human knowledge and systems.

Designing the responsibilities

The team decides which part belongs to a rule, a calculation, a model, an agent, a workflow, an application, a person or a machine.

Building together means that each decision uses the right knowledge, keeps a clear responsibility and can be reviewed by those who will live with its consequences.

Authority is designed action by action. The person intervenes with a defined function: to contribute knowledge, decide, authorise, correct, stop or change the policy.

Human participation is prepared with context and alternatives so that it contributes to the result.

Choosing a first complete path

A first useful version runs a case from the input to a signal of result.

It can be small in scope and contain:

a source;
a representation;
a decision;
a tool;
an intervention;
an action;
a verification.

The complete path uncovers necessary integrations, assumptions, states, waits, permissions, points of failure, acceptance criteria and human load.

Learning appears earlier and rests on real behaviour.

Building through shared artefacts

The solution takes shape out of the real work, the team’s knowledge and a first path we can examine together.

We share schemas, domain models, architectures, prototypes, interfaces, contracts, traces, evaluations, simulations and maturity criteria.

Each artefact answers a question.

A map helps discuss the process. A prototype reveals interaction and state. A trace shows what happened. An evaluation makes comparison possible. A simulation examines conditions that are hard to reproduce.

The conversation becomes more precise when it has something concrete to look at.

Testing with the team

We share artefacts and complete paths from the earliest iterations so as to learn with the team.

We test usual cases, exceptions, incomplete data, contradictions, permissions, waits, retries, failures, changes of state, human interventions and results.

Domain people help interpret what is observed.

An output that is technically correct may still be insufficient for the work. An interface may add load. A rule may be coherent and yet not represent the intention. An automation may simply move the effort somewhere else.

Testing connects behaviour and consequence.

Learning and unlearning together

Each iteration may change the question, the representation, the scope, a rule, a model, an interface, an integration, a responsibility, a policy or the criterion of success.

The change is recorded with its reason.

Unlearning together means being able to withdraw an idea while keeping the project’s continuity. The evidence and the earlier decisions make it possible to understand what changed and why.

Transferring capability

The system has to be understandable and able to carry on.

Transfer includes architecture, code, knowledge models, contracts, configuration, evaluations, decisions, documentation, operation and maintenance criteria.

We work so that the team knows:

what each part does;
which sources it uses;
what can be changed;
what is observed;
what needs review;
how it recovers;
which limits still hold.

Collaboration builds a result, and it also increases the organisation’s capacity to govern it.

What the client can expect

01Direct attentionConversations bring together people able to discuss both the problem and the construction.
02Questions that clarifyEnquiry looks for meaning, assumptions, examples and consequences.
03Reasoned decisionsProposals explain the function of each component and the alternatives considered.
04Early constructionArtefacts and complete paths make it possible to learn before extending the scope.
05Technical depthWe can work from sources, semantics and models through to software, integration, agents and physical systems.
06Transparency about maturityExploration, prototype, evaluation and operation are communicated as different states.
07Capacity for revisionCorrections and exceptions can change the design without erasing its history.
08A human answerContact and collaboration happen directly with people at 3.14.

Good collaboration turns different perspectives into a shared understanding, and that understanding into a system people can use, examine and go on improving.