How MIGSO-PCUBED is helping the engineering division of this leading train supplier stay on track.
The development of a train is a very complex process that involves a huge number of people with very different skills and who need to coordinate their work across multiple functional areas. The transport industry was traditionally dominated by national state-controlled operators and has now moved to a more open and competitive market. The competition is pushed by different drivers: New comers in the train manufacturing business entering in the competition on traditional markets, market becoming worldwide and open to competition, private operators challenging the state operators and increasing the competition. Cost and on time delivery being the key challenge in the transport manufacturing business.
Alstom, one of the world’s leading manufacturer of rail transport equipment and services, is at the vanguard of streamlining its engineering processes with the objectives to improve the engineering QCD (quality-cost-delay) performance.
One of the key challenges is to improve the planning performance in terms of delivery performance and also in quality and multi-function optimization. The company had already invested several years in developing a systems engineering approach that aimed to reduce problem complexity, improve design quality and increase productivity. But executives knew they could achieve better planning efficiency on projects.
Alstom signed its largest contract ever in 2013 with the Passenger Rail Agency of South Africa to supply 600 X’Ttrapolis Mega commuter trains (3600 cars) over a period of 10 years. The first 20 cars were to be produced at an Alstom plant in Brazil; the remainder is being manufactured in South Africa, with involvement from teams in France, Italy and Belgium. Alstom is partnering with South Africa-based rail company Gibela, which is providing technical support and spare parts over an 19-year period. The overall value of the entire contract is worth €4 billion.
Alstom brought in MIGSO-PCUBED to help facilitate the development of a new planning approach.
The overall objectives were to help improve the planning aspects of the company’s tenders and projects and to unify its scheduling practices across the engineering discipline and improve the alignment with all neighboring functions. The ultimate goal was to strengthen the organization’s entire planning culture. The test pilots for the initiative were the planners who worked on three distinct projects, one to deliver commuter trains to South Africa (PRASA), another to refine a smart line of urban trains, and another to deliver the first derivation of the smart trains for a city in Saudi Arabia.
The work of MIGSO-PCUBED followed three broad quests:
To understand the different project types, we planned a “return on experience” (REX) for each. As a starting point, we dug into each of the three projects with two primary goals:
One important step for obtaining this information and helping us understand what happened in new train projects was to have lengthy and detailed conversations with the planners and many members of the engineering team involved in those tasks that experienced delays during the project. For example, we found that negotiations with the supplier lasted more than twice the time scheduled. In this case, the difficulty arose because of under estimation of the negotiation loops and time with a new supplier, located overseas and not used to working with Alstom.
We also realized that the engineering activity was strongly influenced by other functions outside of engineering. In certain instances those interfaces presented potential sources for delay that influenced scheduling of the project.
The last phase of this part of the work required us to identify a logical rundown of activities in order to create a draft of what became known as the “Engineering Standard Planning Logic.” For this pursuit we held workshops with the “métiers” or various professionals within each function. Our purpose was to identify the standard activities we could place in the planning logic.
Rather than compile the planning logic based on theory, we dug down to uncover facts and examples — what really happened in the projects. That gave us the picture of “real life” and allowed us to understand the true chain of activities, including the impact of functions that involved suppliers or customers — all of which can have an impact on engineering lead time. And then, by following this route, we could see the whole picture, not only the engineering activities.
One challenge was defining the “right level” of activity to capture. A second challenge was getting people to recognize and list their “standard” activities. A third challenge was trying to model the processes where various métiers overlapped with each other — where, for example, the electrical expert needed something from the mechanical expert or vice versa and an exchange of information was required.
Often they didn’t have a clear idea of what their colleague from another métier needed in terms of format or maturity level of the information. That confusion could result in delays in decision-making.
As people explained the various activities and stages of work related to the engineering of a new train, we would draw it out on a whiteboard to help everybody visualize the logical chain of activities. Then we’d recreate the details in the software to make a digital visualization that could be printed out. Eventually, those diagrams grew to be a meter wide and three meters long. The process of putting on paper what people really do helped us identify best practices, such as anticipating the placement of specific orders, and helped us improve the synchronization of specific activities in order to work more efficiently.
When you tally up the number of components that make up a train, it runs into the hundreds — seats, lighting, climate controls, floor coverings, windows, doors, toilets, etc. We knew it would be nearly impossible to record the process for building every single one of those elements and come up with any meaningful way to create a schedule for them. So we organized related activities into schedule bricks on our giant diagram.
We also color-coded activities based on which profession, such as mechanical or electrical, was involved. As complex as the diagram became, that color-coding communicated on multiple levels: it allowed people to follow their work streams throughout the entire process and it enabled them to recognize where activities needed to be handed off and at which level of maturity the information needed to be for others’ use. It depicted interactions involving areas not only under the purview of engineering but also the ones that have an impact on the lead time of the engineering activities, such as sourcing or external suppliers responsible for delivering a component.
People began to realize that during a hand-off of information, they were overestimating how much they would be expected to supply. Often, they would delay providing anything until it looked solid, mature and finished. Typically, all that was really needed was an estimate or only a piece of information and not the whole lot. Suddenly, the interfaces that had posed delays previously could be handled quickly and efficiently, with expectation that more information would be provided later in the process. Having identified and quantified these intermediate levels of maturity for information to be provided also turned out to be a great help in another way: Planners could anticipate shifts in the schedule and set up alternative action plans as early as possible.
We went through an iterative process of revising the diagram. Eventually, we arrived at a place where everybody could agree that the activities described for all projects of a given type — such as development of a new train — were complete, were displayed in the right order and could be signed off by everybody in the engineering organization.
Throughout the project, we shared the different steps of advancement of this standard logic with planners from various Alstom engineering sites around the world to see whether they agreed with our compilation and recognized the same logic in their projects. We sought input from all the various “métiers” of engineering and functions outside of engineering. Gaining consensus gave weight to what we were doing. Even as we continued making progress, we had already begun the process of getting buy-in from potential future users.
That document became what’s now known as the “Engineering Standard Planning Logic,” a master template that describes the logical sequence of activities that transpire in a particular type of project, such as developing a new train. It doesn’t capture an actual schedule; there is no time involved; only the logic of activities. When a project concerns development of a new train, this is the starting point that lays out the important elements of the work, the sequence it will follow and the interfaces that will occur.
Given a specific context, the planners now try to capture the best performance that métiers and other functions can achieve. This is done by adding up the amounts of time for each activity that we have identified in the Engineering Standard Planning Logic and then reconciling the total with the whole picture. The overall logic provides an agreed-upon estimate of the average duration of each major activity per type of project.
From the métier or professional’s point of view, the standard planning document clarifies what they need to do for a given type of project. It also provides them with visibility of what the other métiers can expect from them and what they have agreed to. Also, the document has made visible the complexity of the matrix because it shows the large number of interactions involved in a train project. It has become clear that not everything related to design is on the shoulders of engineering. The lead time of engineering is influenced, among others, by the lead time of other functions or suppliers both internal and external.
The Alstom “test pilots,” those planners who have been working alongside MIGSO-PCUBED for their respective projects, are continuing to share the process for creating standard planning logic and the use of the resulting templates with their scheduling colleagues in the company’s sites around the world — Italy, India, Spain, France and elsewhere. Although the project is still going on, we see great promise in what has been accomplished.
Dian Schaffhauser contributed to this article.
As a promoter of sustainable mobility, Alstom develops and markets systems, equipment and services for the railway sector. Alstom manages the widest range of solutions in the market – from high-speed trains to metros and tramways – and associated maintenance, modernisation, infrastructure and signalling solutions. Alstom is a world leader in integrated railway systems. It recorded sales of €6.2 billion and booked €10 billion of orders in the 2014/15 fiscal year. Headquartered in France, Alstom is present in over 60 countries and employs 32,000 people today.
Loved what you just read?
Let's stay in touch.
No spam, only great things to read in our newsletter.
Choose your language
A monthly digest of our best articles on all things Project Management.
Our website is not supported on this browser
The browser you are using (Internet Explorer) cannot display our content.
Please come back on a more recent browser to have the best experience possible