Aerial view of a transport infrastructure network

ALIOTH INNOTECH

Technology, management and expertise to move forward

Intelligent transport systems consultancy, project management and training for professionals and teams.

Explore our services

Three ways to move your projects forward

Roads and junctions in a transport network

ITS consultancy

Technical and strategic advice on intelligent transport systems. We help you assess needs and plan solutions for more efficient, connected mobility.

Let's talk about ITS
Team planning a project with sticky notes in a modern office

Project management

Planning, coordination and monitoring with a focus on scope, timelines and resources. Support to keep your project on track and aligned with its objectives.

Tell us about your project

Project management training

Practical methods and tools for everyday work. Training for professionals and teams looking to improve how they organise, lead and deliver projects.

Ask about training

ALIOTH INNOTECH

Insights

Questions, methods and tools to think through your projects.

Draft for review

Before choosing an ITS solution: five questions worth asking

Draft for review

Alioth Innotech · ITS and mobility · 3 min read

Start with the decision

When a new mobility need arises, it is tempting to start by comparing equipment, platforms or features. We suggest taking a step back: describe the decision that the operating team needs to make more effectively. This conversation helps distinguish essential requirements from attractive extras and creates shared evaluation criteria. The following questions are a working guide rather than a prescription for every setting.

1. What problem are we trying to solve?

A statement such as “we need more information” leaves too much open to interpretation. Specify who needs that information, in what situation and for which action. Detecting an incident earlier and coordinating a response, for example, is a different objective from studying traffic patterns. Describing a use case helps align expectations before developing requirements or requesting proposals.

2. How will we know things have improved?

Defining the intended outcome also means describing the starting point. What can we observe today, and what change would be useful? Different objectives require different measures. Agree how evidence will be collected, who will review it and over what period. Evaluation should go beyond checking that equipment has been installed or that a dashboard displays data.

3. Who will use and maintain the solution?

Operations, maintenance and service owners may have different needs. Involving them early helps identify support hours, required capabilities and tasks that must become part of everyday work. A demonstration can showcase a feature; talking with future users helps establish whether it fits the actual process.

4. What will it need to work with?

Before defining a purchase, review existing systems, information flows, responsibilities and constraints. What information comes in, what goes out and who responds when it is missing? The aim is not to anticipate every technical detail, but to make implementation dependencies visible. Important assumptions should be documented and assigned to someone who can verify them.

5. What must we learn before scaling up?

Where uncertainty remains, a limited trial can help test assumptions. To be useful, it should start with questions and evaluation criteria, not simply a list of equipment. Agree what will happen after the results: continue, adapt or stop. A trial without a subsequent decision can create activity without reducing uncertainty.

A practical first step

Bring together the people who define, operate and maintain the service. Prepare one page describing the problem, users, intended outcome, dependencies and unanswered questions. It does not replace technical analysis: it helps direct that analysis and supports better questions throughout the project.

Your project is on schedule. But is it achieving its purpose?

Draft for review

Alioth Innotech · Project management · 3 min read

Look beyond the schedule

Imagine a project that delivers every document on time. Its schedule is green, yet the receiving team still cannot perform the task that prompted the project. This hypothetical example invites us to distinguish delivery from outcome. Both matter: we need to control the work we have committed to and check that it remains appropriate for the need we are trying to address.

First conversation: what change do we expect?

A progress meeting can begin with a simple question: what should someone be able to do when we finish? The answer connects activities with their purpose. Naming a deliverable is not enough; describe the expected change for its users. If different people give incompatible answers, that disagreement deserves attention before the project moves further ahead.

Separate delivery from achievement

A useful exercise is to create two columns. List the committed products or services in the first, and the capability or improvement each should support in the second. This does not mean holding the project accountable for every later outcome: some will depend on external factors. It does help identify those conditions and agree who should take responsibility for them.

Second conversation: what evidence do we have?

The percentage of completed tasks describes activity, but it cannot answer every question about usefulness. Complement it with demonstrations, user reviews or acceptance tests suited to the setting. Agree in advance what you want to check. If a review reveals that a deliverable does not fit operations, that information needs to arrive early enough to support a decision.

Third conversation: what needs a decision?

A progress report becomes more useful when it separates facts, risks and outstanding decisions. For each decision, identify who can make it and what information they need. Not every deviation requires a new plan. Some call for a clearer requirement, others for a revised priority or an acknowledged dependency. Making the distinction explicit prevents the meeting from becoming a report-reading exercise.

Protect scope without losing the purpose

Revisiting objectives does not mean accepting uncontrolled change. When a new need appears, assess its impact on scope, time and resources, and use the agreed decision process. Purpose guides the discussion; change management makes the consequences visible. Keeping both in view helps avoid rigidity as well as the informal expansion of work.

For your next meeting

Set aside ten minutes for three questions: what change do we expect, what evidence do we have and what decision is missing? Record owners and next steps. This is a simple way to enrich existing progress reviews without replacing the controls the project requires.

From course to workplace: turning an idea into a practice

Draft for review

Alioth Innotech · Training · 3 min read

The next day matters too

At the end of a course, it is easy to collect concepts that seem useful. The difficulty comes when people return to full calendars, existing tools and ongoing commitments. We suggest designing a small application from the start of the learning process. There is no need to transform an entire organisation: choose a specific situation, try a practice and observe what happens before extending it.

Choose a recognisable situation

Before selecting a tool, ask participants to describe a difficulty in their work. It could be a meeting that ends without decisions, an unclear responsibility or a change that arrives without context. The more specific the situation, the easier it is to connect with the learning. In a university setting, a team project can provide opportunities to make decisions and review their consequences.

Turn the concept into an action

An idea such as “improve communication” is too broad for a first trial. Translate it into an observable action: end a meeting with decisions, owners and dates recorded in a shared place. The practice should be easy to explain and possible within the available time. Simplicity makes it easier to try, but does not remove the need to check its usefulness for participants.

Agree on space to experiment

Application does not depend on motivation alone. It may require access to information, permission to change a meeting or cooperation from other people. Identify these conditions before the course ends. In a company, speaking with the team lead can help find a real opportunity. At university, a lecturer can define an exercise and suitable review criteria.

Collect evidence without complicating the process

For an initial application, agree what you will observe and when you will review it. Can people identify the next step more clearly? Have responsibilities become clearer? Record difficulties and unintended effects too. The aim is not to prove that a tool always works, but to understand the conditions in which it adds value and what needs adapting.

Close the learning loop

A follow-up conversation allows participants to compare expectations with events. They can explain what they tried, what they encountered and what they would change. Sharing these experiences helps distinguish understanding a concept from applying it in context. If a trial does not achieve the intended outcome, revising the approach can still provide useful learning; every attempt does not need to be presented as a success.

Make a small, specific commitment

Before closing the next course, invite each person to complete this sentence: “Over the next two weeks, I will try this practice in this situation and review it with this person.” It provides a starting point for continuing the learning process and connecting it with real decisions.

FROM IDEA TO ACTION

Have a project in mind?

Tell us what you need. Let's talk about how Alioth can help you take the next step.

Contact Alioth