Using PRINCE2® at Banedanmark: an automated PA system Case Study

Banedanmark is the organization responsible for the Danish railway. With over 3,000 trains running on the Banedanmark rail network every day, Banedanmark is responsible for 40,000 daily arrivals and departures at stations across Denmark. More than 196 million passengers and 8 million tons of freight are transported annually on the network. Announcing delays, track changes and cancellations – both expected and unexpected – as well as arrivals and departures are an essential part of the passenger information needed for operating the railway.

In collaboration with Banedanmark, the consultancy company, Globeteam A/S, designed and implemented a new and automated announcement management system, NOBI (Danish abbreviation for ‘New And Better Information’) using PRINCE2®. This system is in use at more than 200 stations and handles approximately 3,500 announcements per day. This means that Banedanmark can now make more announcements with accurate information - for the benefit of all train passengers. Furthermore, 70% of the announcement needed to fulfil Banedanmark’s service standard has been automated, which in turn enables the staff to focus their work on disruptions and other traffic information channels.

The initial project ran from January 2012 to February 2013, with additional functionality being implemented as separate projects until 2017.

One of Banedanmark's core objectives is to deliver timely and accurate traffic information to customers on how trains are running both during normal operations and when changes occur.

To ensure that the passengers are kept up to date with accurate traffic information, Banedanmark needed to replace their existing PA system, which managed announcements through loudspeakers at the train stations. The previous system was not updated in terms of scalability, the possibility for management reporting and integration or data exchange with Banedanmark's other information systems. Furthermore, the system was purely manual and therefore time-consuming to utilize.

The main purpose of the new system was to:

• Increase the quality of announcements
• Acquire a stable and easy-to-use system that supports employees in their workflow and is future proof in relation to expansion with new features
• To automate the time-consuming announcements allowing the employees to focus on the content of the communication to passengers, providing guidance when necessary.

Choosing a project management methodology

At the start of the project, Banedanmark were implementing their proprietary project management method based on PRINCE2. The experiences from using the method were still very limited and at that time, only a few project managers at Banedanmark were certified in PRINCE2.

At the project kick-off meeting with Banedanmark, it was decided to manage the Globeteam NOBI Project using PRINCE2. Although some of the naming conventions and approaches between the organizations did differ, the underlying structure and principles made it possible to gain a common understanding of the project management approach. The areas that needed to be clarified were mostly centred around the project organization and roles and responsibilities (as described below).

Project Organization 

Globeteam’s project members involved in delivering the new PA system were organized as a PRINCE2 project on the supplier side but were also part of a larger Banedanmark project on the customer side, where Globeteam was one of several suppliers. This ‘project within a project’ is one of several possible approaches described in the ‘Tailoring PRINCE2 to a commercial customer/supplier environment’ section of Managing Successful Projects with PRINCE2. The approach used in this context is shown in figure 5.1.

Figure 5.1 – The customer/supplier project organizations. The project manager in the overall Banedanmark project (shown in orange) is the Senior user in the Globeteam NOBI project (also shown in orange).

The focus of this case study is the Globeteam NOBI project. As seen in figure 5.1, the project manager in Globeteam’s delivery project would also act as a team manager in the overall Banedanmark project - reporting to the Banedanmark project manager. It is a fairly complex setup with the potential for confusion and misunderstandings.

Navigating in a project organization like this one highlights the importance of understanding the responsibilities connected to a PRINCE2 role and how that role fits into the PRINCE2 project organization as a whole. It would lead to gaps and overlaps in responsibilities to merely look at job titles and using a one-size-fits-all template for project organization. After the roles and responsibilities were clarified, this setup worked well in practice.

The Globeteam project organization also consisted of a development team located at the Globeteam Offshore Development Center in Vietnam, managed by a Danish team manager on location. This setup allowed us to work around the clock on some parts of the development. The issues handed over to the Vietnamese developers at the end of the day would often have been solved as the Danish developers showed up for work the next morning.

We confronted the typical challenges often reported in this type of setup: minor language barriers and cooperation hampered by being in different time-zones. Overall, however, using the Vietnamese development team helped us deliver the project much faster than we would otherwise have been able to.

Shortly after the kick-off meeting, the work started on the project plan. A key benefit of using PRINCE2 was achieved by using the technique ‘Product-based planning’ to develop the project plan. By clearly identifying the project deliverables, the technique clarified the scope boundaries and provided the foundation for change control and helped to avoid uncontrolled changes or ‘scope-creep’. It was used as follows:

Based on a description of the end product in the contract with Banedanmark, the overall solution was initially divided into 11 workstreams - or project areas - with the option of 2 further workstreams to be included in the project later on. These workstreams were the first level in the product breakdown structure and were named ‘IT architecture’, ‘Client development’, ‘Test’ etc.

As the end product was broken further down into deliverables - as a group activity with the project team - 41 deliverables were identified.

Figure 5.2 – Although the text for each deliverable is not readable here, this Figure provides a schematic view of the full Product Breakdown Structure with work streams in darker grey and optional work streams in orange (Click to enlarge).

While the Product Breakdown Structure was created, important details of the deliverables were uncovered and documented: Maybe a certain configuration was carried out in one deliverable and should not be duplicated in a different deliverable, etc. This documentation served as the initial draft for the product descriptions, which were completed after the completion of the project plan. The product descriptions contained the quality requirements for each deliverable that had to be met, for the deliverable to be approved.

Following the identification of the deliverables, the dependencies between the deliverables were mapped out in a ‘product flow diagram’. Again, it was carried out as a group exercise, first identifying the deliverables that had no prerequisites and then iteratively working our way through the dependencies until we had the complete product flow diagram.

Figure 5.3 - Group exercise: Mapping out deliverable dependencies on a whiteboard with the project team.

Once the product flow diagram was created, the whole project team had a common understanding of how the project was expected to be delivered as it showed the path – as a sequence of deliverables - from project start to hand over of the end product.

To support communication and control of the project, the project controls in the form of stages, deadlines and other tolerances were established, thereby turning the product flow diagram into a project plan.

To gain a precise an estimate as possible, the time required to create each deliverable was estimated by the resources that were expected to create them. Upon having estimated all deliverables, the critical path method (CPM) was used to identify the deliverables that determined the duration of the project and thereby potential bottlenecks in the plan. Any delay of the deliverables on the critical path would delay the project, whereas delay of other deliverables could potentially be absorbed without affecting the project end date.

Carrying out the development of the project plan as a group activity with the project team ensured that the project plan – once completed - would be deemed feasible and have the acceptance of the project team.

The project plan was subsequently divided into three delivery stages:

• Specification
• Development
• Test and deployment

As the purpose of a project plan is to support communication and control throughout the project, special consideration was put into how project- and stage plans should be visualized and how progress should be communicated.

Software such as Microsoft Project is great at keeping track of deliverables, dependencies and project progress but not always effective as a communication tool to a broader audience. An example would be when a complex Microsoft Project plan is copied into a PowerPoint presentation and shown at a project board meeting. Key messages easily get lost in the detils and editing is challenging. A different tool was needed.

The main idea was the project documentation should be visual wherever possible and provide ‘pointability’. It should be possible to easily point at any component or ‘moving part’ in the project documentation and say, “This is the component I’m talking about right now”. For this reason, custom-made stage plans were made in Microsoft Visio where all individual deliverables and dependencies could be seen clearer than in typical off-the-shelf project management software. Also, the deliverables were colour-coded to show progress and status, providing both detailed information and an overview of stage progress at a glance.

Figure 6.3 - Monitoring progress: When printed as a poster or included in a PowerPoint presentation, this stage plan format clearly shows completed deliverables in green, deliverables not yet started in grey, and internal milestones as circles (Click to enlarge).

The foundation provided by product-based planning was used in all subsequent project documentation and reporting. It provided a strong common thread from the initial contract with Banedanmark to the deliverables, the project plan and on to the scheduling and management of day-to-day activities. This common thread also supported reporting to the project board and the project financials as a whole, as the supporting IT systems were set up to match this common thread.

Although this thorough approach required some extra initial planning and configuration of IT tools, it made the different parts of project management support and reinforce each other instead of pulling the project management in separate, and slightly different, directions.

Furthermore, the overall Banedanmark project progress reporting format was also adopted and used by Globeteam, enabling Banedanmark to compile higher level progress reports with minimum effort.

Utilizing the output from the product-based planning technique, the common thread was carried over to the maintenance of the project business case. Each deliverable had an estimated required effort and thereby an estimated cost to produce since the cost was calculated directly based on hours worked.

The time tracking software used in the project was set up to match the product-breakdown structure, meaning that all hours worked and registered were mapped to the corresponding deliverables. This approach became very effective when combined with Earned Value Management (EVM).

Earned Value Management is a technique for measuring financial project performance and progress in an objective manner. It made it possible to automatically generate a number of financial overviews such as cost per workstream or cumulative project costs – the so-called s-curve (named after its typical shape).

Figure 7.1 – Cost per project workstream (green) compared to the total estimated cost of the deliverables in that workstream (red)

Figure 7.2 – Cumulative project cost per week: the s-curve

The financial reporting could have been expanded upon to include project performance and variances in project performance, which is a key benefit of Earned Value Management. This was, however, not requested or utilized in this project. Should the need for more detailed reporting arise, the data would have been readily available with the chosen approach.

Special ad-hoc reporting requests were made to show, for example, the effort used on certain types of tests or the extra effort required for troubleshooting during a hurricane described later in the case study. These ad-hoc reports could be generated almost without extra work given the chosen setup.

Mapping time tracking to the Product Breakdown Structure combined with Earned Value Management showed to be a powerful tool. The extra work required for the initial setup and maintenance of data was regained later on when special reporting requests were made and could be addressed with very little effort.

PRINCE2 as the method for overall project management helped to keep track of deliverables, the progress through the stages and the project as a whole. However, PRINCE2 as a method does not address the development method of the individual deliverables. For that, a separate approach had to be chosen.

When developing customer-oriented software deliverables in the NOBI project, the agile methodology Scrum was used. In Scrum, the production of a deliverable is timeboxed rather than having to meet a number of pre-defined quality criteria. The customer plays a vital role in the Scrum team, prioritizing the requirements that the team works on in the alotted time.

This approach was especially beneficial when developing user-oriented deliverables such as user interfaces. Using several product iterations with frequent feedback from users, ensured a broad acceptance of the design of the user interface, and the solution as a whole.

When a Scrum based deliverable is completed (that is, the alotted time is up), PRINCE2 adresses how that completed deliverable is managed in the overall project. The two approaches thereby complement each other seamlessly and do not – as it is sometimes described – compete with each other as the ‘new’ and the ‘old’ project management method. This approach of combined methodologies worked extremely well in practice.

The Globeteam NOBI project was technically complex and used software developed in-house in combination with newly released commercial software having a fundamentally novel approach to, for example, the management of databases. These components were to be combined on an overall platform affecting hundreds of thousands of users daily, providing critical information. On top of that technical challenge, several project challenges had to be addressed during the project.

Traditionally, it is common in Denmark to have a project manager from the customer side as well as a project manager from the delivery side in customer/supplier projects. The customer project manager is sometimes also called ‘the commercial project manager’ and the supplier project manager is sometimes called ‘the technical project manager’.

This approach is often specified in the initial contracts and is the foundation for the subsequent proposed organizational setup. In practice, the commercial project manager would often have the final say, although confusion and misunderstandings could arise between the two project managers. The approach is also not in accordance with PRINCE2 as there can only be one project manager per project.

Although both carrying the title of project manager, the roles and responsibilities between the two project managers in this traditional setup are not equal. The customer project manager is expected to be responsible for – amongst other things - specifying the needs of those who will use the project’s products, for monitoring whether the solution will meet those needs within the constraints of the Business Case and for user liaison with the project management team. This matches the role and responsibilities of the role of Senior User in PRINCE2.

The term customer project manager is still in common use in Danish IT projects and can be a common source for misunderstandings. When the customer project manager is understood to be the senior user, the project organization makes sense, and everything falls into place from a PRINCE2 perspective. This again highlights the importance of seeing past the titles and focusing on the responsibilities associated with a given role, avoiding gaps and overlaps in the project organization.

During deployment of the new PA system, Denmark was hit by the hurricane St. Jude with the highest winds ever recorded in Denmark, peaking at gusts of 120.8 mph (194.4 km/h), which led to massive damages on trains and train equipment as well as platforms and PA equipment. The train disturbances also led to a huge workload on the PA system, resulting in operational disturbances.

All in all, the preparations were adequate, as the hurricane only led to an extra workload of 40 hours, which is quite small considering the size and scope of this extremely rare event.

The project was greatly supported by the initial risk assessment with Banedanmark which was carried out at the beginning of the project, detailing how passenger information should be handled under various circumstances. The risk of a PA system potentially not supplying enough information to passengers was covered by the broader risk management in the overall Banedanmark project. This allowed the Globeteam NOBI project to focus on risks regarding the specific deliverables in the project and not general operational risks, which was an effective use of the time spent on risk management.

In PRINCE2, the difference between a risk and an issue is clear: An issue is – in short – an unplanned event that has occurred and requires management action, whereas a risk is an uncertain event that could happen in the future. In practice, those clear distinctions can easily become blurry.

In February of 2013, NOBI became operational, initially running in parallel with the existing PA system. When the system was switched on, expectations were high as it was time to show the fruits of our labour. The first hours of operations were fine but as late evening approached, a number of error messages started to appear and eventually the system stopped working. The developers needed to be scrambled to work on the challenges overnight. One of the developers who had been key in the initial design could not be raised, however.

Later that night we learned that his wife was in the final stage of labour and he was just moments away from becoming a father for the first time! This had not been shared with the project team as he had recently completed all deliverables that he was responsible for. As he now needed to be consulted with, this meant that we would be unable to solve the problem right away, as initially hoped.

As this was an unexpected event – at least seen from the project perspective – it was clearly an issue and needed to be addressed as such. We would need to involve Banedanmark, explain the issue, provide alternatives and recommendations, potentially escalate the issue to the project board and wait for their decision.

As the project manager, I went through the project documentation pondering the best way to carry out these actions as I was reviewing the risk register. We had considered a multitude of situations where resources could become unavailable or deliverables delayed. At the end of the risk register, there was a catch-all resource risk: A key resource becomes unavailable due to any other reason which leads to a delayed deliverable. Potential risk responses were listed: Keeping extra resources on stand-by, extra training of other resources and several other options. After careful deliberation, it had previously been agreed that these options were not cost effective.

Should a key resource become unavailable the affected deliverables would have to be delayed correspondingly. Since this risk now occurred, the following steps were pre-approved, enabling us to act swiftly. The following morning, Banedanmark was briefed about the risk that occurred and an estimate for the completion of the deliverable was given, meaning the problem would be resolved in a few days. Since there were two PA systems running in parallel, overall operations were not affected.

What initially seemed like a complex issue, was undramatically handled as an occurred risk with pre-approved steps.

Successes in Project Management

Despite the technical complexity and the project challenges mentioned above, the greatest success of the project work was how uneventful it was carried out ­– the challenges could not shake the project.

It has been quoted that the hallmark of a good chef is not the advanced details in the dish but being able to do the simple things really well. This was also the aim of the project management in the NOBI project: using the basic approaches described in PRINCE2 very efficiently and effectively.

Keeping track of deliverables, estimates, scheduling, project finances as well as risks and issues are often seen as the more basic building blocks of a project, but they easily (and often) start to misalign in a dynamic environment with tight deadlines.

It could start off as simple as deliverables having slightly different names in the initial contract, project plans, and progress reports. Misunderstandings and subsequent effects quickly follow, leading to disagreements on product approvals and delays. A deliberate effort was put into not allowing such misalignment to happen as the complexity would quickly become uncontrollable.

An effort was also put into creating as simple visual overviews of e.g. progress as possible while providing enough information for all the conversations and discussions that needed to be taken. The aim was to rather err on the side of clarity than to leave the potential for confusion and misunderstandings. As a consequence of this, the use of physical project board meetings could be reduced significantly after a few months as the progress reporting was deemed sufficient.

“In collaboration with Globeteam, we had a reliable schedule for the project with detailed delivery plans, where all dependencies were mapped. The plan made it easy to keep track of how far the project had progressed”.
Kristina Kildegaard, Project manager at Banedanmark

Successes for the Customer 

Following the deployment of the completed PA system, several key benefits were achieved by Banedanmark:

• 70% of all passenger announcements have been automated. Banedanmark is kept informed that all required announcements to passengers are carried out thereby reducing the number of tasks employees need to focus on. This gives them more time to focus on challenging announcements, for example, providing travelling alternatives to customers.
• Banedanmark can measure the quality of passenger information across many more stations, and that the goals of Banedanmark's service standards are met to a much higher degree than before - both in terms of the number of announcements and announcement content.
• High usability and support for existing workflows, including the ability to use single announcements and create announcement templates, announcements to many stations at once, and configuration of repeated announcements.
• Higher quality of information regarding planned changes because NOBI makes it possible to schedule announcements to a much higher degree than possible before.
• The speakers provide the same information as the screens on the stations as they use a common database regarding train destinations, delays, and track usage.
• Higher sound quality on platforms, as the automatic announcements are pre-recorded in a studio.

Having started in January 2012, the NOBI system became operational in February 2013. The project was not without challenges as there were numerous technical and organizational challenges to overcome as well as issues, risks, and changes to manage.

Looking back, I believe the use of PRINCE2 showed to be of great benefit for the project because PRINCE2 provides a method for robust project management. All the building blocks of the project were easier to keep aligned as the approaches in PRINCE2 reinforced each other and were used to show a coherent and consistent picture of the project at any given time.

From the outside, it can be hard to tell the difference between a number of loosely attached project management tools on one hand and the project documentation created by using PRINCE2. Behind the scenes, however, several key benefits were achieved:

• This was both the case when using product based planning and when spotting an issue in the project organization caused by having two project managers.
• Using clear and simple visualizations wherever possible to support the conversations. A lesson learned is to ‘dare’ to be clear and simple in communications to a point where one could fear almost being seen as naive or as communicating the obvious. Miscommunication and misunderstandings can happen the most unexpected of places surprising everyone involved.
• It was essential in a technically complex project as the NOBI project that any lack of clarity or misunderstandings could be discovered and adressed before it could affect the project, as it could otherwise quickly lead to rework and very costly delays. Also developing project- and stage plans as group activities facilitated by the project manager helped reduce ambiguity or any misunderstandings.

Following the initial project, several add-on modules were developed by Globeteam. For example, ‘Automatic announcements’ enabling announcements to be tied to a certain train and automatically carried out at the corresponding platform upon arrival.

The system and the additional modules remain in operation today and handle 3,500 calls daily.

"The automation of announcements has been a great success because we jointly with Globeteam performed a thorough analysis of both the project approach and the solution. The employees were so confident in the solution that they even called before the system was rolled out to them and asked if they could start using it”.
Kristina Kildegaard, Project manager at Banedanmark

Ulf Livoff, Globeteam project manager for the NOBI project.

With a background in computer science and engineering, Ulf has worked as a business consultant and project manager on a variety of IT projects since 2004.

Having seen the benefits of the structured approach to project work offered by PRINCE2, Ulf has been an accredited PRINCE2 trainer since 2012.

Office of Government Commerce (2009) Managing successful projects with PRINCE2, 2009 edition. London, TSO (The Stationery Office)