The Challenges of Agile Project Management in the World of Public Transportation
Being part of a SaaS (Software as a Service) company means being part of a structure that evolves with the software’s technical developments. However, it is important not to lose sight of the market for which the software is developed.
An Article by Camille Bouin.
I work in the public transportation sector, specifically in Demand-Responsive Transport (DRT), a flexible transportation service that is an alternative to cars and taxis, and adapts to different audiences and use cases, while reducing the environmental impact of transportation. I work for Padam Mobility, which offers a transportation optimisation algorithm and a suite of interfaces necessary for operating a DRT service: user interfaces to facilitate user travel, a driver interface suitable for any type of operation, and a management interface for operators and transport authorities.
In this sector, I have noticed that managing digitalisation projects in a constantly evolving software context leads to high complexity.
The objective of this article is to understand the interactions and analyse the challenges between the digitalisation of DRT and software developments, in order to provide solutions.
First, we will look at the management of transportation projects, and then we will focus on technical projects in a second step. Finally, we will understand their parallel modes of operation.
Transportation Project Management
My core business is the management of projects to set up Demand-Responsive Transport services in rural and suburban areas.
In this sector, projects can present complex challenges in many ways:
- The evolution of digitalisation tools for managing DRT services and the change management challenges that this entails,
- The political challenges of local governments and the resulting deadlines,
- The challenges of carriers in a context of a shortage of labour,
- The pressure of public opinion from end users of the service on politics and carriers,
- The scalability of service offerings and demand depending on current events,
- Financial constraints and variations in allocated budgets.
Project management, both in terms of content and change management, or monitoring and meeting deadlines, is therefore a daily challenge. Furthermore, public tenders can take time to validate, and obtaining final launch dates for projects can be complicated. Once the project has begun, project teams often have to be able to deliver the DRT offer within a 2-3 month timeframe depending on the complexity of the project.
The challenges mentioned above are often multiplied with the volatility of the market and the growing importance of taking environmental impact into account in the transportation sector. This last point has a strong impact on the software évolutions that need to be developed to meet customer needs.
Technical Project Management
To answer to the constant changes in the DRT market, the software must remain in constant evolution.
The software development strategy of a SaaS company, by nature, must be done with the goal of responding to a need common to all or the majority of users, and not a unique or specific need. Based on this principle, there is therefore no technical team dedicated to a specific client.
Most often, project management is done in parallel, within product teams (with a focus on identifying needs) and development teams (with a focus on providing the solution itself). These teams are organized using the agile method, with short development cycles of about two months, divided into two-week sprints. While project management using the agile method is more advanced and allows for some speed of evolution, the complexity of the software adds difficulties in development, making some changes uncertain both in terms of their deadlines and their technical feasibility.
But what interactions can we observe between a SaaS model based on agile management of technical changes, and the management of DRT deployment projects?
Two Parallel Operations
The two parallel management modes with different challenges and deadlines can quickly lead to inconsistencies and difficulties in completing projects.
A concrete example is the integration of DRT systems into a broader MaaS (Mobility as a Service). In this context, the digitalisation of DRT must find its place in standard transportation norms and be able to integrate into broader route planning software. It then becomes necessary to standardise and norm a mode of transportation that, by definition, was extremely flexible.
The implementation of a DRT service must therefore be done by adapting to norms, or by creating new ones. Technical developments must then be based on these norms under creation to be tested. Task interdependencies are often too strong to be able to follow a precise schedule. Still in this idea, it is possible that some software becomes obsolete, even unusable just after its release, as soon as a change occurs in the MaaS or DRT market. In this case, the technical project is jeopardised.
In Canada, DRT projects usually come to fruition when they are linked to online payment tools for ticketing. A technical project to set up integrated ticketing with DRT tools was already launched at Padam Mobility to meet needs in another market, the United Kingdom. However, the expectations and needs of the Canadian market did not necessarily coincide with all planned developments. This reality tended to endanger the DRT deployment project.
In these two examples, the challenges of DRT projects or technical developments do not necessarily converge or are very interdependent. This requires finding appropriate solutions to avoid jeopardising all projects.
Resolution Suggestions
To address the difficulties mentioned earlier, there are several levers of action. They must, however, be implemented while ensuring that the integration is complete between the agile technical project and the project to provide a digital solution for DRT.
For the DRT project to be successful, such as in the case of ticketing, it is crucial to carry out a precise assessment of the new need and to focus on the ongoing technical project. The sprint or mid-sprint meeting will be ideal to present the new needs and find an approach to integrate them into the ongoing development. The project’s agility is extremely interesting in the sense that it allows the development to evolve according to the evolution of the need.
The iterations and exchanges take place according to a precise schedule combining the time constraints of both projects. The interactivity of the solution allows for meeting tight deadlines. A first version of a development takes into account the MVP (Minimum Viable Product) of the newly arrived customer’s need without losing sight of the final version, which remains on the roadmap for future cycles.
Let’s keep in mind that DRT projects present unpredictable and evolving constraints that induce significant temporal risks in projects.
In conclusion, in the DRT sector, the agility of technical projects and listening to customer needs are the two key elements for achieving the simultaneous success of both types of projects carried out in parallel.
This article was originally published by Padam Mobility.
