ALGI Advisory e.U
Article · Technical project stabilisation
An automation project in crisis: clarify the technical issues and regain control
A delayed production line cannot be brought back under control simply by issuing a new schedule. First establish which technical tasks remain open, which skills are missing and which decisions are blocking progress. Project stabilisation combines this clarification with operational leadership and reliable communication.
Establish the actual technical status
When deadlines keep moving, everyone involved needs a shared picture of the work remaining. Statements such as “the software is almost finished” or “only minor issues remain” are too vague for effective project control. What matters is which function has been demonstrated under which conditions, and what remains outstanding.
On an automated production line, mechanical systems, control systems, robotics, material flow and quality inspection may depend on one another. A single working station therefore does not demonstrate the performance of the entire line.
- Which requirements have been met and verified?
- Which functions are incomplete, unstable or not yet tested?
- Which technical interfaces need coordination?
- Which information or decisions are missing?
- Who can take technical and organisational responsibility for the remaining tasks?
Clarification should involve the available documents, the team and the actual equipment. Conflicting statements and missing evidence are recorded as open issues.
Bring technical clarification and operational leadership together
Secure the required expertise
A critical project needs the right skills for its outstanding tasks. This may involve bringing in experienced specialists, reassigning roles and making better use of knowledge already held within the team.
Break the work into verifiable steps
A deadline is credible only when the required work, prerequisites and dependencies are understood. Small, verifiable results make the project easier to manage and reveal obstacles early.
Enable decisions
Technical questions must not remain indefinitely unresolved between participants. They need a clear point of contact, a defined decision path and visibility of the consequences of delayed clarification.
Communicate progress honestly
The client and end customer must be able to see what has been achieved, what remains open and what support is needed. A clear report creates a shared working basis.
A useful question for project control: What must be demonstrated before the next project step can sensibly begin? This question connects technical outcomes with scheduling.
Build a realistic plan from the remaining work
A new plan should start with the technically required scope of work. This includes not only development and programming, but also integration, testing, fault correction and preparation for agreed acceptance procedures.
Each major work package should have a defined outcome, an owner and clear prerequisites. If a quality inspection function is not yet stable, for example, clarify which parts, variants and operating states are needed to demonstrate it. Such criteria must match the actual assignment.
The plan remains a working tool. New findings are incorporated, and their effects on sequence and deadlines are made visible. An open issue is not resolved merely by giving it a more favourable status in a report.
Practical example: recovery leadership for a robotised production line
Starting point
A fully automated production line for electric mobility was severely delayed. Mechanical systems, automation, robotics and vision-based quality inspection had to work together as a complete system. Missing expertise and inadequate project leadership had hindered progress, and the end customer’s confidence had deteriorated.
His personal contribution
Alexander Girkinger took over leadership of the project recovery. His contribution included rapidly understanding the situation, rebuilding a specialist team involving existing staff, establishing a realistic schedule and providing operational leadership on site. Daily reporting supported coordination with the client.
Another focus was rebuilding a dependable working relationship with the end customer. Problems and next steps needed to be communicated clearly and openly.
The outcome achieved
In the project described, positive preliminary acceptance by the end customer was achieved after approximately three and a half months. The production line subsequently enabled supply of the required parts, and the supply contract was extended.
This anonymised example is based on Alexander Girkinger’s account of the project. Preliminary acceptance refers to a specific project milestone. The stated duration is an outcome of this individual case and does not constitute a general commitment for other crisis projects.
What other projects can learn from the example
Technical depth and leadership must work together. A newly assembled team needs clear tasks; a realistic plan requires a sufficiently understood scope of remaining technical work. Communication, in turn, must reflect actual progress.
Before bringing in external support, clarify the assignment and authority. Who can prioritise tasks? Which decisions remain with the client? How are suppliers and the end customer involved? The clearer these interfaces are, the more effectively operational project leadership can work.
Appropriate support may consist of limited technical clarification, coordination of individual work packages or agreed leadership of a project recovery. Scope and responsibility depend on the specific situation.
Frequently asked questions about project stabilisation
When is an external technical perspective useful?
When actual progress remains unclear, deadlines are repeatedly postponed or the team lacks essential expertise and capacity. An external perspective can establish a clear picture of causes, dependencies and the support required.
Is a new schedule enough?
Only if the remaining scope and its prerequisites are sufficiently understood. Unresolved technical questions and missing responsibilities cannot be addressed simply by adding more dates.
Which information helps with an initial discussion?
A short description of the plant, the current schedule, known obstacles and the decision ahead are useful. Existing task lists, test results and contact people support the initial assessment.
Related reading
Clarify technical requirements early
How to describe functions and interfaces before implementation.
Read the automation planning articleTechnical review and assessment of the current situation
For a structured assessment of technical assets, risks and required action.
More about technical review
