A Real-Time Collaborative Gantt-Kanban Hybrid

Project planning tools usually ask teams to choose between two useful views. A Gantt chart explains sequence, duration, dependencies and milestones, while a Kanban board makes current work, bottlenecks and team capacity visible. The prototype explored by the Chalmers Electronic Lean Research Team, or Celean, brings these perspectives into one shared workspace so that planning and execution can inform each other continuously.

The value of this approach lies in the connection between a planned schedule and the work actually moving through a process. A task can appear as a bar on a timeline, a card in a workflow column, and a dependency in a project network without being copied into separate systems. That shared representation gives researchers and industry partners a practical way to examine digital visual planning, lean coordination and collaborative decision-making.

Bringing Two Planning Views Together

A Gantt chart is well suited to questions such as when a project phase should begin, which activities depend on earlier work, and whether a milestone is at risk. Its weakness is that it can become a static management document. Once work starts to vary from the original plan, teams may update dates manually or keep an informal picture of progress elsewhere.

Kanban offers a different perspective. Cards move through stages such as ready, in progress, review and complete. Work-in-progress limits expose overloaded parts of a process, and a blocked card can prompt an immediate conversation. Kanban can be less effective when a project contains long lead times, fixed delivery dates or complex technical dependencies that require a time-based view.

The hybrid prototype treats these views as connected interfaces rather than competing methods. Moving a card can update its position on the timeline, while changing a planned date can flag a scheduling consequence on the board. The purpose is not to make every project look identical. It is to let different roles use the representation that best supports their decisions while relying on the same underlying information.

What Users See In The Prototype

The central screen can be imagined as a synchronised project canvas. A left-hand area presents a hierarchical list of work packages, activities and deliverables. The centre displays a time scale with bars, milestones and dependency links. A linked board shows the same activities as cards arranged by workflow state, with fields for owner, priority, estimate, blockers and evidence of completion.

Selecting a card highlights its corresponding timeline bar, dependencies and related tasks. Selecting a bar opens the operational details behind the schedule. This visual connection reduces the need to search through separate records when a manager asks why a milestone has moved or when a team member needs to understand the next constraint.

The prototype also supports collaborative signals. A user might add a note to a card, adjust an estimate, identify a dependency or mark a task as blocked. Presence indicators show who is viewing or editing the project, while a lightweight activity history records significant changes. These features make the workspace more than a reporting dashboard; they create a trace of how planning decisions develop over time.

Visual design has a practical role in this setting. Long sessions with dense timelines can produce eye strain, especially when colour is used to distinguish status, risk and ownership. Teams testing interface options may find guidance on night mode programs useful when considering contrast, brightness and evening work patterns, although accessibility should be assessed within the prototype itself.

Real-Time Coordination Without Noise

Real-time collaboration does not mean that every change should interrupt every participant. An effective prototype needs a clear distinction between events that require attention and routine updates that can remain in the activity stream. A newly identified blocker may deserve a visible alert, while a small description edit can be recorded quietly.

The system can use an event-based model in which each change is treated as a discrete action: a card moves, a date changes, a dependency is added, or an owner is reassigned. The shared view then refreshes for connected users. This approach supports traceability and makes it possible to reconstruct how a schedule changed, rather than preserving only the final state.

Conflict handling is important when several people edit the same project. A simple last-change-wins approach may be acceptable for low-risk text fields, but it can create confusion if two planners alter a milestone or dependency simultaneously. The prototype can reduce this problem through field-level updates, visible edit notifications and a short review window for high-impact changes.

Permissions also shape collaboration. A delivery team may update card status and estimates, while a project lead controls baseline dates or approval gates. Industry partners may need access to selected work packages without seeing sensitive commercial information. These boundaries should be tested as part of the user experience, because a technically shared system can still feel fragmented if people cannot understand who may change what.

From Static Schedule To Flow Management

The hybrid view becomes especially useful when planned work and actual flow begin to diverge. Suppose a design review is scheduled to finish on a Friday, yet its card remains in progress because a specialist input has not arrived. The board makes the blockage visible, while the timeline shows which downstream activities may be affected.

This connection supports more meaningful conversations than a simple percentage-complete field. A task may be technically active but waiting for approval, consuming review capacity or generating rework. By linking workflow state to dates and dependencies, the prototype can expose the operational cause of a schedule variance rather than merely highlighting the variance itself.

The approach also makes work-in-progress limits relevant to milestone planning. If too many activities enter testing at once, the timeline may still suggest that all of them can finish on schedule. The Kanban side reveals the capacity problem, and the schedule side shows its likely effect on delivery. Teams can then defer low-value work, add capacity, resequence activities or renegotiate a date based on shared evidence.

Metrics should support learning rather than encourage superficial speed. Useful measures may include cycle time, blocked time, completed work per period, schedule variance, dependency waiting time and the number of changes made after a baseline is agreed. Comparing these measures with team observations can help researchers assess whether the visualisation improves coordination or simply creates another layer of administration.

Research Questions Behind The Interface

A prototype of this kind raises questions that are both technical and organisational. Does a combined view help users detect emerging risks earlier? Do teams make different sequencing decisions when workflow data is visible beside the plan? Does real-time editing improve coordination, or does it create pressure to keep the system constantly updated?

The answers are unlikely to come from screen testing alone. A meaningful evaluation could combine observation, interviews, interaction logs and project outcomes. Researchers may compare how groups respond to the same scenario using a conventional schedule, a Kanban board and the integrated prototype. The focus should include decision quality, shared understanding and the effort required to maintain accurate information.

Industry collaboration gives the research a realistic setting. In a manufacturing environment associated with organisations such as Volvo, dependencies can cross engineering, procurement, production preparation and quality activities. A prototype that works for a small software team may need different rules when physical components, formal approvals and supplier lead times are involved.

The system should therefore accommodate different planning horizons. A team may need a detailed view for this week, a rolling forecast for the next month and milestone coordination across a longer programme. Progressive disclosure can prevent the screen becoming overwhelming: show the immediate flow first, then reveal dependencies, history and higher-level schedule detail when a user needs them.

Applying The Concept In Australian Workplaces

Australian project environments provide useful test cases because work is often distributed across cities, regions and time zones. A team coordinating engineering work between Melbourne and Sydney may share a standard business day, while collaboration with Perth introduces a significant time difference. A live workspace can preserve decisions and blockers for colleagues who are not present in the same meeting.

Construction, infrastructure, mining and energy projects also create conditions where schedule dependencies and field status need to coexist. A Brisbane-based project office may coordinate with a regional site, subcontractors and suppliers whose updates arrive through different channels. In Western Australia, fly-in fly-out rosters can make handovers particularly important; a visible activity history can help the incoming crew understand what changed and why.

Australian workplace customs matter as well. A short daily stand-up, a weekly planning session and a practical preference for clear accountability may shape how the prototype is adopted. Teams should avoid turning the tool into a surveillance display. Cards and timelines are most useful when they support early escalation and problem-solving rather than assigning blame for every missed date.

Local market conditions can add further variation. Public infrastructure programmes may involve formal reporting, staged approvals and multiple delivery partners, while smaller Australian manufacturers may need a lightweight tool that fits around existing enterprise systems. The hybrid design should permit integration with identity management, document repositories and enterprise resource planning without requiring every user to become a specialist planner.

Adoption Recommendations For A Pilot

A pilot should begin with a bounded workflow rather than an entire enterprise portfolio. Select a project with visible dependencies, a manageable number of participants and a genuine need to coordinate planned and active work. Establish a baseline before configuration so that the team can compare the prototype with its existing planning practices.

The following recommendations can keep an evaluation focused and credible:

• Start with one delivery stream and a small set of workflow states that the team already understands.
• Define which fields are authoritative, especially planned dates, actual dates, ownership and completion evidence.
• Use clear rules for work-in-progress limits, blocked status and escalation of overdue activities.
• Test collaboration across office and site-based participants, including people working different Australian time zones.
• Record both performance measures and user effort, such as update time, meeting duration and duplicate data entry.
• Include accessibility checks for colour contrast, keyboard navigation, text size and low-bandwidth conditions.
• Review the activity history with participants to identify whether it supports learning, accountability and handover.

A pilot should also include a short governance cycle. At regular intervals, the project team can review which fields are being maintained, which alerts are ignored and where the visual model fails to match actual work. Researchers can then distinguish a usability problem from a process problem. For example, missing updates may indicate that the workflow is too complicated, or that staff do not agree on when a task is considered active.

Feedback from collaborators should be connected to the wider research programme rather than treated as isolated product comments. The project contact page provides a route for organisations interested in the work to connect with the team and discuss relevant collaboration or demonstration contexts.

Practical Value For Future Project Systems

The prototype’s strongest idea is its shared language. A timeline can describe commitments, a Kanban board can describe flow, and a collaboration layer can explain how decisions are made. When these elements refer to the same work items, teams have a better chance of understanding both the plan and the conditions affecting delivery.

There are limits to what software can resolve. A visual system cannot remove supplier uncertainty, unclear authority or unrealistic deadlines. It can, however, make those conditions easier to see and discuss. Its success should be judged by whether teams identify problems earlier, coordinate with less duplication and make changes with a clearer understanding of their consequences.

For Celean’s research agenda, the Gantt-Kanban hybrid offers a practical environment for studying digital visual planning in action. It connects lean principles with enterprise information, prototype interaction design and the realities of collaborative industry work. The most useful next step is a controlled pilot in which one Australian or international project tracks flow, schedule changes and user effort together, turning the shared board into evidence for better planning decisions.