Ticketing and Payment System Development

Table of Contents

Executive Summary ………………………………………………………………………………………… 1

Introduction……………………………………………………………………………………………………. 1

Critical Success Factors …………………………………………………………………………………… 3

Framework …………………………………………………………………………………………………. 3

Factors related to the project…………………………………………………………………………. 3

Factors related to the project manager and the team members …………………………… 4

Factors related to the organization …………………………………………………………………. 5

Factors related to the external environment…………………………………………………….. 5

Sub conclusion ……………………………………………………………………………………………. 6

Project Organization ……………………………………………………………………………………….. 6

Scope…………………………………………………………………………………………………………. 6

Project organization of NBB ………………………………………………………………………… 7

Integration of 3 systems ……………………………………………………………………………….. 8

After the restructuring………………………………………………………………………………….. 9

Sub conclusion ………………………………………………………………………………………….. 10

Stakeholder management ……………………………………………………………………………….. 10

Stakeholder mapping …………………………………………………………………………………. 10

Project partnering………………………………………………………………………………………. 12

Sub conclusion ………………………………………………………………………………………….. 13

Conclusion …………………………………………………………………………………………………… 13

References……………………………………………………………………………………………………. 15

Articles …………………………………………………………………………………………………….. 15

Books ………………………………………………………………………………………………………. 16

Reports …………………………………………………………………………………………………….. 16

News Articles……………………………………………………………………………………………. 17

Lectures……………………………………………………………………………………………………. 17

1

Executive Summary

In this paper, we will investigate and discuss ‘Prosjekt nytt billett- og betalingssystem’ translated ‘Project new ticketing and payment system’, an IT-project running from 2000 – 2009, commonly referred to as Flexus. The project has received heavy critique for major cost overruns, time delays and for resulting in an unsatisfactory product which has mainly been out of order. The paper analyses how important aspects of project management, such as critical success factors, project organization and stakeholder management, affected the result of the project.

We investigate the most critical success factors based on a framework proposed by Belassi and Tukel (1996). With the lack of top management support and shortcomings in terms of defining a clear project goal, the project failed to satisfy some of the most crucial success factors. In addition, deficient competence among project managers and insufficient communication with crucial interest groups as customers contributed to one of the largest scandals in public transportation Norway has ever seen.

Furthermore, we find evidence of insufficiently defined organizational structure in the early phases of the project, lacking both organizational maps and written chains of commands. Combined with inexperienced managers and lack of a steering group the project faced a difficult starting point. The project went through a comprehensive restructuring phase in 2006, resulting in a new and expanded project group, increased funding and an improved structure. This clearly improved the progress.

We mapped relevant stakeholders using Newcombe’s framework (2003), and identified suppliers as the most critical group. As previously mentioned, the project had an insufficient organizational structure. This contributed to inadequate information and knowledge sharing between the project and its key stakeholders, contributing to negative perceptions of the product long before maturity.

Introduction

‘Project new ticketing and payment system’, hereby referred to as ’NBB’ was a joint project between the main providers of public transport in Oslo and Akershus: Stor-Oslo Lokaltrafikk (SL), AS Oslo Sporveier (OS) and Norges Statsbaner AS (NSB), running from approximately year 2000 to 2009, according to Aftenposten Aften August 26th, 2008. The goal was to implement a new ticketing system that would allow travellers in Oslo and Akershus to use all three providers of transport seamlessly with one ticket on one electronical card. News media has generally referred to the project as ‘the Flexus project’ or only ‘Flexus’.

OS initiated the new project with a tendering for the development of the system in 2000 and SL and NSB quickly followed suit with their separate tenders. In 2003 GRA 24161 Project Management 16.12.2015

2

Sporveisbilletter AS1 (SB), SL and NSB signed contracts for system delivery with three different suppliers, with French ‘Thales e-Transactions CGA S.A.’ (Thales), Australian-Belgian ‘ERG’ and with Swiss ‘Ascom’, respectively. Although OS, SL and NSB used three different suppliers and three different electronical ticketing systems, they planned for the different solutions to work together so that travellers experienced them as one system (Kommunerevisjonen 2/2009, 15).

1 Sporveisbilletter AS was a subsidiary of AS Oslo Sporveier founded in 2003 to handle the conclusion and management of the contract for the new ticketing system.

2 Sporveien’s website tells us that the main body of OS changed its name to ‘Kollektivtransportproduksjon AS’ (KTP) in 2006 and later to ‘Sporveien’ in 2013 The remaining administrative part of OS merged with SL in 2008 to form the new ‘Ruter AS’ (Ruter) and received ownership over the NBB project (Ruter AS 2008, 5).

Before this, from around 1992 to 1996, SL, OS and NSB ran another joint project with the same goal, but with the use of only one supplier to make one common ticketing and payment system common for all three companies. They established the company ‘Billettsystemer AS’ (BS) in 1992 to run the project, and signed a contract with ‘Scanpoint Technology AS’ (ST) for delivery. BS terminated the contract in 1996, and in 1998, courts sentenced BS to pay 29 MNOK to ST in compensation for breaking the contract. Adding to the 100 MNOK in running costs, the three companies wasted a total 129 MNOK over the period on a ticket system that never saw daylight (Haakaas 1999).

After the parties signed the contract for the subsequent project, NBB, in 2003, they postponed delivery multiple times, and exceeded costs significantly: OS initially reported that the new ticket and payment system would be ready for implementation in 2004, but they postponed the final date substantially; first to the last quarter of 2005. After they missed this target as well, they promised January 2006, although the expected date operated with internally was some time in 2007. Equipment for using the system was installed on stations and in trams, busses etc. in 2005, but was not ready for testing before 2007. In 2006, the project management was replaced and a new implementation date in 2007 was announced. Technical problems continued throughout 2007 and 2008, the full implementation was further postponed to 2008 and 2009, and finally in 2009 customers were gradually migrated to the new system (Stenseng and Haakaas 2009).

As written in Aftenposten.no, September 11th 2011, Ruter AS2 took over the responsibility for NBB in 2009. During the upcoming years, customers were gradually transferred to the new electronical ticketing system. The ‘Flexus’ name, however, did not last. According to Aftenposten.no, March 1st 2011, NSB rolled out their own system with dedicated NSB cards in 2010, and Ruter terminated the name in 2011. Ruter and NSB’s digital travelling cards are now issued separately, but work interchangeably across platforms so customers only need one of the cards. GRA 24161 Project Management 16.12.2015

3

Summing up, the NBB project is a failure. Including the previous project terminated in 1996, total costs have an estimate of 600 MNOK, the first project costing almost 150 MNOK and the NBB project potentially costing as much as 450 MNOK; more than double the budget (Slettholm 2012). Implementation was delayed more than five years. To this day, installed ‘Flexus’ equipment (doors/gates at subway entrances) still stands completely unused and validation/payment terminals have become almost superfluous, as the more successful ‘RuterBillett’ app for smart phones has taken over most of the volume (Eidem and Bjørklund 2014).

Our discussion will focus on three topics: critical success factors, the project organization and stakeholder management.

Critical Success Factors

First, it is important to draw a clear distinction between the two terms Success Criteria and Success Factor. Some management literature treats these expressions as synonyms. Cooke-Davies (2002) defines Criteria as the measures by which success or failure of a project or business will be judged. Furthermore, a Factor is defined as input to the management system that lead directly or indirectly to the success of the project or business. In order to be consistent and in line with our chosen topic, we will focus solely on Success Factors throughout this paper.

Framework

Hypothetically, one could almost make an infinite list of factors assumed to influence the level of success of any given project. In order to narrow down such a list, Belassi and Tukel (1996) proposed a comprehensive framework to systemize the factors:

 Factors related to the project

 Factors related to the project manager and the team members

 Factors related to the organization

 Factors related to the external environment

This framework is comprehensive in that sense that any factor will belong in at least one of the above mentioned categories. Furthermore, it is important to keep in mind that several factors may fit in multiple categories. In relation to the case we are studying, for example one success factor such as funds invested will be related to the organization in terms of how much the organization is willing to spend on the specific project. Due to the government ownership, we believe it is safe to assume that the very same factor will also be related to the external environment such as the state of the economy and hence government financials.

Factors related to the project

This category comprises factors that can be linked to the specific project, such as size and value. Furthermore, an important factor related to the project is the urgency, or the GRA 24161 Project Management 16.12.2015

4

planned time horizon. A short time horizon will often force project managers to work overtime, and hence this alone could be a potential source to cost overruns, (Belassi and Tukel 1996). Project NBB was initially planned to last from 2000 – 2005, but quite early in the process it became visible that this time span was excessively short. Luckily for the project management team there were no monetary penalties due to extension of the deadline. On the flipside, this may have contributed to the project lasting for more than twice the estimated time, and hence led to significant cost overruns.

Another critical factor that might have played an important role in the failure is the project’s uniqueness. The transformation from traditional paper tickets to electronic tickets was perceived as too complex to be managed by the existing competence at Oslo Sporveier, leading to a decision to outsource the majority of work to external consultants (Dagbladet May 4th 2012). This decision has been subject to debate. Leader of Public Transport Production, Rune Aasen, argues in the same Dagbladet article that the use of external consultants led to unnecessary high costs, given that sufficient expertise in fact was present in another close related state-owned department.

Moreover, Karlsen et al. (2006) point out the importance of having a clear project goal as the third most important success factor. Project NBB was initiated by the three entities Oslo Sporveier (OS), NSB and SL, which had separate plans (Krogstad 2010). OS used unit fee, NSB charged for the actual distance travelled, and SL operated with 88 different price zones. This inconsistency in the overall goal of how to construct the new pricing-scheme led to several problems which we later will discuss, and illustrates an improper management of a critical success factor. This could be a partial explanation as of why the project failed.

Factors related to the project manager and the team members

This category of success factors comprises characteristics and skills among the team members and managers. The possession of the necessary technical and administrative skills among managers is of high importance in order to secure a successful project (Pinto and Slevin 1989). As previously mentioned, the electronic ticket system was of such a complex character that most of the project was outsourced. The project managers, Magne Glomnes and Jørn Hanssen, were senior employees in OS lacking appropriate IT-experience, but still found capable to lead such a project. The municipality audit was quite clear in their judgement and claimed that these two managers “did not understand what they were doing”. The lack of insight and knowledge in this complex project led the managers to rely on assessments from vendors, resulting in unnecessary and expensive investments (Kommunerevisjonen 2/2009, 9).

Furthermore, it is of our impression that the managers could have experienced a psychological phenomenon named escalation of commitment. This phenomenon could be defined as the ability to continue on a course and increase the investments based on GRA 24161 Project Management 16.12.2015

5

previous decisions, ignoring new evidence suggesting that the previous decisions were wrong (Staw and Ross 1989). This provides one explanation of why the project was not modified or even terminated, even though the project received numerous indications that early plans proved almost impossible to implement (Hultgren 2011).

Factors related to the organization

Top management support has been found to be one the most important success factors in order to secure successful execution of projects (Tukel et al. 1995). The same factor was found to be the most important one in private as well as public organizations, in an empirical study conducted by Karlsen et al. (2006).

The municipal audit from 2009 states that as a criterion for a successful project, the internal project team needs to possess both relevant capacity and competence.

As previously pointed out, the project management team lacked essential knowledge or competence in terms of IT-systems, and additionally none of the top managers had any experience from electronic ticketing systems (Kommunerevisjonen 2/2009, 8). Instead of hiring or consulting with the appropriate knowledge, top management decided to travel around the world on field trips to visit cities with similar ticket systems. The costs of these travels amounted to over 1MNOK (Stenseng and Haakaas 2011) and still the municipality audit (2/2009) concluded that the management did simply not understand the electronic ticketing system, implying that the project management was incapable of leading such a project.

In the aftermath of project NBB, the transport councilor has been a target for heavy critique. Mostly for his lack of involvement in the project even after huge cost overruns and time delays became visible. This seems as a violation of the most important success factor, namely top management support, and could be an important factor to explain the failure of this project.

Moreover, the municipality audit further raises the question concerning the resource allocation, or the assigned capacity, in the project as a whole. The group director later admits to underestimation of the needed capacity, and not realizing the problem before it was excessively late. This could be a sign of boiling frog syndrome, (Boltchover 2005) explaining the inability to adapt to threats that increase with small increments over time.

Factors related to the external environment

Factors related to the external environment consists of factors which are external to the organization, but still have an impact on the project success or failure, (Belassi and Tukel 1996). The implementation of a new ticket system would affect a huge amount of customers as well as employees in the organization who are not a part of the project. Prior to such a large project, the project team should conduct market research among users, as well as consultation with experts. Furthermore, it is important to provide GRA 24161 Project Management 16.12.2015

6

information about the procurement and implementation of the new ticket system to both users and employees, (Robertsen 2004), (Kommunerevisjonen 2/2009). According to the project manager, he admits that the procurement and implementation in the early phase of the project was conducted without providing the necessary information to the users. In an interview with the project manager referred to in the municipal audit, he points out several flaws. The lack of information, in addition to a troublesome implementation of the system resulting in several errors (Hultgren 2011), led to negative perceptions and attitudes towards the project from employees as well as customers. The information manager in Ruter stated in an interview with (Slettholm 2011) that the negative associations subsequently led to the change of name from Flexus to Ruter Travel card, admitting the connotations to Flexus had become a burden.

Sub conclusion

As previously mentioned, it is possible to make an extensive list of critical success factors. Thus, there are several factors that we have not discussed. However, we believe to have highlighted the most critical ones with respect to this specific project, and structured them in a systematic manner. In our discussion we have pointed out some indications that several of these factors were violated. It is also worth mentioning that a new project manager was appointed around year 2005. This manager realized numerous mistakes committed by his predecessor, such as failing to provide information to the customers. He subsequently tried to mitigate the problem of negative associations, but realized this was quite difficult at such a late stage, (Kommunerevisjonen 2/2009, 29). We find it necessary to mention this, in order to provide a more balanced presentation of project NBB. So as a sub conclusion, we have seen unsuccessful attempts to cover for previous mistakes, but in total the vast violation of several critical success factors most likely contributed to the failure of the Flexus project.

Project Organization

How a project is organized has a major impact on the results and the process itself. A project management system provides a framework for launching and implementing project activities within a parent organization (Larson and Gray 2011, 65).

In the context of choice of project organization, Andersen (2000) distinguishes between the external and internal structure. External is the relationship between a project and a parent organization. Internal is the relationships between a project manager and the participants. Hobbs and Ménard (1993) argues that it is no right way to organize a project, but that the choice of project organization should depend on seven factors, some of them are size, strategic importance and novelty and need for innovation.

Scope

This part will review the project organization of NBB within Oslo Sporveier, both external and internal. NBB had an initial project organization, but the need for GRA 24161 Project Management 16.12.2015

7

restructuring became apparent after both cost overruns and implementation difficulties became evident. In this paper, we will mainly address the initial project organization, but also include the organization after the restructuring process. Project NBB also included an integration of ticket systems of OS, NSB and SL, the 3 separate actors of the public transport industry in the Oslo-region. Which we also find necessary to cover.

Project organization of NBB

The initial phase of organizing started in year 2000, and the project was given the name NBB (Krogstad 2010, 41). The core of the project organization consisted of three people employed full-time, and had an average staff of 3-4 people until the restructuring in 2006 (Kommunerevisjonen 2/2009, 17). According to Jessen (1996), there are three different external organizational structures:

 The “fully incorporated” structure

 The “split authority” structure

 The “full authority” structure

The literature on this project states that the structure is not well documented. There are no organizational maps or written chain of commands in the early phases of the project (Krogstad 2010, 42). Magne Glomnes was the project director, Jørn Hansen was the project manager, and Carl Sandstad was a project participant (Ahmad and Tufan 2010, 66). However, this project exhibits signs of being a “full authority” structure. The three full-time employees were fully devoted to NBB and were clearly organized as a separate unit within the company. The main advantages of this structure is that the project manager has full authority over the project and its resources, and that the participants have the project as their sole commitment (Andersen 2000). The main disadvantage is that it could be difficult to get access to certain experts and competence, and that the project may take on a life of its own, without the control of the parent organization. The project structure seems very centralized, in terms of decision-making.

One could classify the team structure as Frame’s (1995) speciality team structure. This is a team structure where all team members have their own special field of competence, which is their main reason for their participation. Glomnes has a background as a railroad engineer, and he had previously worked with procurement of signaling systems. Hansen is a civil engineer and contributed with general IT knowledge. Sandstad has a legal background, and had the main responsibility of contracts (Ahmad and Tufan 2010, 66).

The project clearly did neither have the necessary knowledge nor the competence of ticket systems at the beginning of the project. OS chose to build the competency in-house by sending managers on study trips around the world. The municipality audit from 2009 criticized the lack of specific knowledge of electronic ticket systems. At a later stage, this created an information asymmetry between the project group and GRA 24161 Project Management 16.12.2015

8

Thales, the supplier (Kommunerevisjonen 2/2009, 18). One alternative solution to this could have been to outsource by engaging consultants, but this was restricted by the parent organization. This was explained by an organization-wide policy of limited use of consultants at a general level, and the advantage of having in-house competency was perceived as strategically important for subsequent service and maintenance of the system (Ahmad and Tufan 2010, 76-77). In addition, they claimed that it was no guarantee that the consultants could help to close the information gap completely.

Furthermore, the project did not have a steering group. As explained by Karlsen in a lecture on Project Management (26.10.2015), the advantages of having a steering group would have been better monitoring of the project, closer links with stakeholders and increased control of costs and overall work of the project. However, the project did have a reference group, consisting of representatives from marketing, IT, real estate and labor union (Kommunerevisjonen 2/2009, 17). Nevertheless, one important group was not part of the reference group, namely the users. Both employees and passengers were excluded. In the above mentioned lecture, Karlsen stated that “Representatives from the users should participate in the reference group”, hence the omission of users led to a sub-optimal reference group.

The method used for this IT-project was the waterfall method (Krogstad 2010, 42). Balaji and Murugaiyan (2012) defines the waterfall method as a “sequence of stages in which the output of each stage becomes the input for the next”. This implies that planning and structure is essential, since it is costly and time-consuming to move back in stages. Moreover, another implication is that the system is not presented to the user until it is finished. When using the waterfall method, user-participation in the reference groups is particularly important. Munassar and Govardhan (2010) points out that the method does not reflect the iterative nature of exploratory development and software is delivered late in project, delays discovery of serious errors. In other words, users should be involved early to ensure user-friendliness and discover errors to minimize costs.

Integration of 3 systems

OS, NSB and SL have been trying to integrate their ticket systems since 1992 (Ahmad and Tufan 2010, 65). However, the first attempt ended in abortion and legal sanctions to their common supplier at the time. In 2000, they decided to have 3 separate suppliers of electronic systems, and have a higher level translation system to integrate these. This tended to decentralize the decision-making, in opposition to the actual project group which was centralized. The ultimate goal was a seamless integration of the three systems, resulting in a customer experience of using only one ticket system all across the Oslo region (Krogstad 2010, 48). GRA 24161 Project Management 16.12.2015

9

Figure 1. Interoperability. Source: Eastern Norway County Network (2004, 7)

Once the development of the new systems started, the complexity of the integration became apparent for the project group. The interoperability issue became a key problem at this stage (Krogstad 2010, 49). Interoperability is the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged (HIMSS 2013). The main issue here was that the billing system for the three companies was completely different. As previously mentioned, NSB charged their customers based on distance travelled, SL operated with 88 different price zones and Oslo Sporveier used a fixed pricing-scheme, regardless of distance and zones. These difficulties (costs and time) could have been significantly reduced, if external advice had been listened to and the companies coordinated their pricing schemes in advance of developing a new ticket system (SKØ 2005). Furthermore, the municipality audit (2/2009) claimed this could have been foreseen with a higher degree of competence and better planning.

After the restructuring

Due to a failed trial run of the system in 2005, the CEO of OS decided to exchange and expand the project group (Krogstad 2010, 55). It was decided to allocate more resources due to the strategic importance of the project, as thousands of employees and travelers were affected by this project (Kommunerevisjonen 2/2009, 20). The internal team structure was changed to Frame’s (1995) isomorphic team structure. Andersen (2000) points to several advantages with this structure: It is organizationally simple, makes it easy to identify who is responsible, and allows for parallel work. It became clear that with more resources, higher competence and a more defined structure, this project group was better equipped than the previous to handle the complexity of this project. The municipality audit (2/2009, 21) agreed that the shortcomings of the old structure was being properly mitigated by the new project organization. At most, almost 150 people was involved in the project (Krogstad 2010, 56). GRA 24161 Project Management 16.12.2015

10

Figure 2. New organizational structure. Source: Municipality Audit (2/2009, 20)

Sub conclusion

The project organization of NBB initially seemed to have three major flaws: Not enough resources, low level of competence needed and no user involvement. This could come from an underestimation of the strategic importance and the complexity of the ticket system. A new ticket system could affect the entire organization, most importantly the customers, and their willingness to use public transportation. The “full authority” structure, without use of a steering group, may have resulted in the parent organization losing the necessary control over the project and its progress. This in turns led to major cost overruns and time delays, which could have been significantly lower, if the initial organization of the project had been equal to the organization after restructuring.

Stakeholder management

The need to identify stakeholder management is vital as it is considered one of of the most crucial success factors for a project (Freeman 2002). In a project like NBB stakeholder management is highly relevant because it is a project created by companies fully owned by the local and national government. This part of the paper seeks to identify and acknowledge stakeholders, as well as to classify their influence on and interest in the project.

Stakeholder mapping

We base our stakeholder mapping on the article presented by Robert Newcombe (2003). In his article, Newcombe presents the concept of stakeholders. Stakeholders in projects are defined as “groups or individuals who have a stake in or an expectation of the project’s performance”. He also explains how different stakeholders interact, both with the project and among each other. Furthermore, the article provides a method for stakeholder mapping, and explains how different stakeholders can be perceived as GRA 24161 Project Management 16.12.2015

11

multiple clients with different levels of predictability, interest and power. As the number of stakeholders involved in a project increases, the complexity and difficulty increases as well. Different stakeholders may have differing incentives, all depending on their level of interest, power and predictability.

Stakeholders’ interaction with the project can be divided into two distinct arenas. First, the culture arena, where project participants share values towards the project and shape or constrain changes. Second is the political arena, where powerful individuals and interest groups exercise power to achieve their objectives. This is often in conflict with other stakeholders’ objectives.

Stakeholder mapping can be broken into four phases (BSR 2011), namely identifying, analyzing, mapping and prioritizing. In short, listing relevant groups, organizations and people with an interest stake, understanding their perspective, visualizing relationships between objectives, ranking stakeholder relevance and identifying issues.

We have mapped the internal and external stakeholders, with the purpose to ensure that all interest groups are being accounted for. With external stakeholders, we refer to groups or entities who influence and are influenced by the project, but are not a direct part of it. Internal stakeholders are defined as groups or entities who are committed to the project.

Figure 3. Illustration of stakeholders GRA 24161 Project Management 16.12.2015

12

After identifying the stakeholders, we utilize the power/predictability and power/interest matrix in order to analyze the different stakeholders’ importance for the project management team. HighLowLowHighA: Few ProblemsB: Unpredictable but managebleA: Minimal effortB: Keep informedCustomers, GovernmentEmployees, MediaEmployees Customers, Government, MediaC: Powerful but predictableD: Greatest danger or opportunitiesC: Keep satisfiedD: Key playersNSB, AS Oslo Sporveier, SLSuppliersSuppliersNSB, AS Oslo Sporveier, SLPredictabilityInterestPowerPowerLowLowHighHigh

Figure 4. Power/predictability matrix Figure 5. Power/interest matrix

The matrices reflect the status at the beginning of the project. We have mapped the most relevant stakeholders and analyzed them in the matrices, in order to illustrate how they can be used. There are several groups the project management team should pay attention to, especially section D in the power/predictability matrix and section C in the power/interest matrix.

From section D in the first matrix, we see that suppliers could represent a danger or an opportunity by using their substantial power to torpedo projects strategies. In the second matrix, the most demanding group to manage is the suppliers, given that if their interests increase the group will become key players.

In addition, it is important to mention that the mapping of stakeholders should be done repeatedly throughout the project’s lifetime in order to capture potential changes, and hence increase the probability of successful stakeholder management.

Project partnering

The study put forward by Karlsen (2008) discusses stakeholder management in different types of relationships. We try to define different types of relationships, as relationships are clearly not the same (Granovetter 1985). As mentioned earlier in this paper, a partnering relationship between OS, SL and NSB did exist. However, a partnering relationship could bring several difficulties (Alderman and Ivory 2007) as we discuss in the following.

Karlsen highlights 5 different types of relationships with respect to different characteristics concerning collaboration and integration; classical market, through a third party, open and direct, integrated team and partnership. Partnership is the most relevant form of relationship in the NBB project, as it is a collaborative project between three separate companies. A partnering relationship should contain a high degree of collaboration and integration. Based on the findings in the municipal audit GRA 24161 Project Management 16.12.2015

13

(Kommunerevisjonen 2/2009), we see clear signs of malfunctioning collaboration, and one could argue that this may have been an important factor contributing to the failure of this project.

Karlsens research concludes that the most important factors for building relationship between a project and its stakeholders are; trust, uncertainty and control, culture and language, resources and knowledge and goal congruence. As pointed out in the article in Dagbladet May 4th 2012, the NBB project did not utilize internal resources and knowledge. Instead, the project relied heavily on services from external consultants subsequent to the restructuring process. This in turn led to dissatisfaction among important stakeholders which felt overseen, claiming they should have been more involved in the project. Furthermore, this led to distrust of the capability of the project management team, failing to map the relevant internal competence, before deciding to outsource.

Larson and Gray (2011) states that in order to manage a project successfully, the manager needs to build an alliance between stakeholders, in order to influence the cooperation between each stakeholder. Cohen and Bradford (1990) illustrates the law of reciprocity as currencies. An issue in the NBB project was the information task-related currency. It did not seem that all stakeholders were aware of the lack of knowledge in the project management team, and therefore where not able to change the project management team before it was already seen as a failure.

Sub conclusion

The stakeholder management of the NBB project seems to have two primary flaws, lack of knowledge sharing between the project management team and the three partnering firms, and letting suppliers take such a large role in the project. We argue that this could be a result from the lack of clearly defined guidelines and roles of all stakeholders.

Conclusion

Throughout this paper, we have investigated the NBB project with focus on three aspects, namely critical success factors, project organization and stakeholder management. From the moment we started working on this subject, we were aware that the project had been a major failure, and we were excited to investigate the reasons why from a Project Management perspective.

In the first part, we highlighted numerous critical success factors, and discovered several violations of these. The lack of top management support in addition to missing a clear project goal, are examples of factors contributing to the failure of the NBB project. Furthermore, missing involvement with the users/customers led to a product failure as well. GRA 24161 Project Management 16.12.2015

14

In the second part, we explained the importance of the project organization, and explained how it may have affected the outcome of the NBB project. We disclosed evidence of clear underestimation of the strategic importance and the complexity of the electronic ticket system, which led to major cost overruns and time delays. Complex projects such as NBB also requires a high level of competence, which clearly was not fulfilled. The progress of the project improved significantly subsequent to the reorganization, further emphasizing the importance of appropriate project organization.

The latter part of the paper concerned stakeholder management. This section highlights several flaws in the relationship between the project management team and important stakeholders. The lack of knowledge sharing/transfer between these groups and allowing for a high level of autonomy among vital suppliers stands out as main reasons for the dysfunctional stakeholder management.

This project is only one of many public IT-projects over the last decades considered failures, mostly due to lack of satisfactory project management. This highlights the importance of sufficient experience of project management, and the ability to incorporate theory based approaches into practice. GRA 24161 Project Management 16.12.2015

15

References

Articles

Ahmad, M. and Tufan, H. 2010. “Nytt elektronisk billett og betalingssystem i Oslo – En studie av beslutninger.” University of Agder

Alderman, N. and Ivory, C. 2007. “Partnering in major contracts: Paradox and metaphor.” International Journal of Project Management (25): 386–393

Balaji, S. and Murugaiyan, Dr. M. 2012. “Waterfall vs V-Model vs Agile: A comparative study on SDLC.” International Journal of Information Technology and Business Management 2 (1): 26-30

Cooke-Davies, T. 2002. ”The real success factors on projects.” International Journal of Project Management 20 (3): 185–190

Granovetter, M. 1985. ”Economic Action and Social Structure: The Problem of Embeddedness.” American Journal of Sociology 91 (3): 481–510

Jessen, S.A. 1996. “The nature of project leadership, revised edition.” Scandinavian University Press, Oslo

Karlsen, Andersen, Birkely and Ødegård. 2006. “An empirical study of critical success factors in IT projects.” Int. J. Management and Enterprise Development 3 (4): 297-311

Karlsen, J T. 2008. ”Forming relationships with stakeholders in engineering projects.” European J. Industrial Engineering 2 (1): 35-49

Krogstad, J. 2010. ”Ikke akkurat på skinner.” University of Oslo, Reprosentralen.

Munassar and Govardhan. 2010. “A Comparison Between Five Models Of Software engineering.“ IJCSI International Journal of Computer Science Issues 7 (5)

Newcombe, R. 2003. ”From client to project stakeholders: a stakeholder mapping approach”. Construction Management and Economics 8 (21): 841-848

Pinto, J K and Slevin, D P. 1989. “Critical success factors in R&D projects.” Research Technology Management (Jan-Feb): 31-35

Ross, J and Staw, B. 1989. ”Understanding Behavior in Escalation Situations.” Science 246 (4927): 216-220

Tukel, O I and Belassi, Walid. 1996. “A new framework for determining critical success/failure factors in projects.” International Journal of Project Management 14 (3): 141-151 GRA 24161 Project Management 16.12.2015

16

Tukel, O I and Rom, W O. 1995. “Analysis of the characteristics of projects in diverse industries.” Journal of Operations Management 16 (1):43-61

Books

Andersen, E. 2000. “Managing Organization – Structure and responsibilities”. Gower handbook of project management, Turner, R.

Cohen, A R and Bradford, D L. 1990. ”Influence Without Authority”. John Wiley & Sons.

Freeman, R E. 2002. ”Stakeholder Management: Framework and Philosophy.” Corporate Communication – A Strategic Approach to Building Reputation, Brønn, P S and Wiig R. Gyldendal Norsk Forlag: Oslo.

HIMSS. 2013. “Dictionary of Healthcare Information Technology Terms, Acronyms and Organizations.”

Hobbs, B. and Ménard, P. 1993. “Organizational Choices for Project Management.” The AMA Handbook of Project Management, Dinsmore, P. New York: AMACOM

Larson, E. and Gray, C. 2011. “Project Management: The managerial Process.” New York: McGraw-Hill Companies

Reports

BSR. 2011. “Stakeholder Mapping.” Accessed December 12, 2015. http://gsvc.org/wp-content/uploads/2014/11/Stakeholders-Identification-and-Mapping.pdf

Eastern Norway County Network. 2004. ”Samordning av takst-og billettsystemene, delrapport fra fase 2.” Accessed December 16, 2015. http://www.ostsam.no/file=8591

Kommunerevisjonen. 2009. ”Nytt billettsystem – Kontroll og oppfølging.” Accessed December 16, 2015. https://www.oslo.kommune.no/getfile.php/Innhold/Politikk% 20og%20administrasjon/Budsjett%2C%20regnskap%20og%20rapportering/Rapporter%20fra%20Kommunerevisjonen/Rapporter%20fra%20Kommunerevisjonen%202009/02-2009%20Nytt%20billettsystem%20-%20kontroll%20og%20oppfølging.pdf

Ruter AS. 2008. “Årsrapport 2007 – Styrenes årsberetninger og regnskaper for AS Oslo Sporveier og Stor-Oslo Lokaltrafikk AS”. Accessed December 16, 2015. https://ruter.no/globalassets/dokumenter/aarsrapporter/arsrapport_2007.pdf

Sporveien Oslo AS. 2013. “Sporveiens historie”. Accessed December 12, 2015. https://www.sporveien.com/inter/omktp/artikkel?p_document_id=2586103

SKØ. 2005. ”Bedre samordning av kollektivtransporten i Oslo og Akershus. Forslag til tiltak på kort sikt (2006-09).” Oslo: report from working group. GRA 24161 Project Management 16.12.2015

17

News Articles

Aftenposten. 2009 “Flexus en skandale” Aftenposten.no, January 26.

Bolchover, D. 2005. ”What is boiling frog syndrome?” The Times. March 26.

Dagbladet. 2012 ”Millionene renner ut på omstridt billettsystem.” Dagbladet.no, May 4.

Eidem, M and Bjørklund, I. 2014. “App med napp hos reisende”. DN.no, December 22.

Haakaas, E. 1999. “Dømt til å betalt 29 millioner for kontraktbrudd”. Aftenposte Aften, February 2.

Herbjørnsrud, Dag. 2003. “Slik skal snikerne på T-banen stanses”. Aftenposten Aften, August 26th.

Holm, P A and Slettholm, A. 2011. “Flexus er døende – NSB og Ruter vil ha egne kort.” Aftenposten.no, March 1.

Hultgren, J. 2011. ”Sperringene ute av drift.” Aftenposten.no, August 10.

Robertsen, K. 2004. ”Hvor egnet er brukerundersøkelser som styringsverktøy for offentlig tjenesteproduksjon?” Magma, May.

Slettholm, A. 2012. “Flexus skandalen ble aldri anmeldt”. Aftenposten Aften, January 18.

Stenseng, S and Haakaas, E. 2008. ”Reiste verden rundt.” Aftenposten.no, October 15.

Stenseng, S and Haakaas, E. 2009. “Stemplet som udugelig – Kommunerevisjonen med kraftig kritikk av Sporveiens prestisjeprosjekt.” Aftenposten Morgen, January 22.

Lectures

Karlsen J.T. 26.10.15 – Lecture on Project Organization