Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Failure Rates and Factors in Projects

Projects are very unlikely to be successful. In fact, empirically most projects fail. A highly popular failure index comes from Standish Group (2013, critics by Eveleens & Verhoef, 2010), an international IT development and consulting company. Unlike other studies, data of the Chaos Manifesto is provided not by customers but by their own staff. The authors distinguish between successful projects (delivered on time, on budget, with required features and functions), challenged (late, over budget, and/or with less than the required features and functions), and failed (cancelled prior to completion or delivered and never used). Based on over 50,000 cases, they view most projects as being not successful (Fig. 1). Looking back in time, percentage may vary, but on the average, there is an approximate trisection in the categories.

Fig. 1
figure 1

Shares of successful, challenged and failed IT projects between 1994 and 2012 (data from Standish Group, 2013)

Full size image

Such failure rates seem to be quite common. In 2008 IBM published the results of a survey among 1500 practitioners, covering strategic, organizational, operational and technology related projects. The proportions were quite the same: only 41% of all ventures met their objectives fully, 44% did not meet either time, budget or quality goals, the remaining 15% missed all goals or were stopped. Similar results are found in a survey of the federation PMI (2017) among 3200 project management practitioners. About 30% of the projects are said to be failures. It is doubtful if this distribution reflects reality as the estimated number of unreported cases might be much higher. However, the failure rates seem to be high in other domains as well.Footnote 1

The PMI study provides some insights regarding the challenging factors. Most projects suffer from scope creep or uncontrolled changes to the project’s scope (49%). Another 49% run out of budget and 43% run out of time. In an analysis of more than 5400 large IT projects (more than $15 million) by McKinsey and the University of Oxford (Bloch, Blumberg, & Laartz, 2012), 45% of the projects ran out of budget but only 7% ran out of time, whereas 56% delivered less value than predicted.

Plenty of meta-analytical studies, large-scale surveys and literature reviews revealed crucial factors regarding success and failure of projects (Belassi & Tukel, 1996; Bloch et al., 2012; Ika, Diallo, & Thuillier, 2012; PMI, 2017; Rietiker, Scheurer, & Wald, 2013; Standish Group, 2013; van der Panne, van Beers, & Kleinknecht, 2003). Four major characteristics appear to be recurrent:

Poorly defined/unclear/not shared objectives deal with the reason for projects. These endeavours are undertaken to solve certain problems for an organization. The desired outcome is usually not the product/solution/result of the project but gaining new possibilities, creating cheaper/better ways of value creation, getting rid of a painful problem or meeting expectations of customers. The latter are the key issue. Often stakeholders agree on the project and its results but not on the purpose. A soon as changes in the project are necessary, those differences become visible. According to Bloch et al. (2012) those disagreements cause most project failures and highest cost-overruns.

Communication addresses the demand for sharing information within the project team and among all stakeholders. Projects are by nature explorations of unknown land. Thus, no one involved has entire knowledge, especially when the outcome of a project is something that is “first of its kind”. Mostly, there is scattered expertise inside the organisation. The best way to produce new knowledge within a group is by sharing existing knowledge in order to combine, conclude and reason. Scholl (2014, cf. Wilensky, 1967) distinguishes several ways of undermining this distribution process:

  • Deficient transparency regarding repositories of knowledge (e.g. employees, experts, storages, documents) and flow of information (e.g. communication occasions, share points, and rules of trade)

  • Deficient sharing culture (e.g. information as a power tool, low openness to new ideas, lone wolf behaviour, organisational blindness)

  • Deficient usage of knowledge (e.g. low quality of information, information overload, high stability of existing processes, low acceptance of innovation, the so-called “not-invented-here-syndrome”)

  • Deficient knowledge management (e.g. non-existing policy/strategy, maladaptive incentive systems, unused storage systems, autocratic leadership style, inhibited communication among employees).

Top Management Support deals with resource allocation and resistance among employees. As stated in more detail later, projects are about something that is new and potentially frightening for the members of a social system who commonly compete for shared, scarce goods. Unlike project leaders, line managers can rely on their own staff, stable resources and approved routines. Projects are usually staffed by temporary workers, receive non-recurring resources and act outside the familiar processes. Projects operate with impunity, extracting energy, people and time from the usual system for something indefinite. Such activities are highly demanding for an organisation and require a strong intention based on a long-term vision, broad overview and power to be assertive. These factors can only be provided by top management. As long as the people who are ultimately in charge are not convinced, projects will suffer from a lack of security, integration and momentum.Footnote 2

Scheduling is about planning a project. That factor also arises from the impurity character. Because projects take place outside the familiar processes, and produce outcomes that are different from what already exists, they appear like an ongoing disturbance for an organisation. Scheduling is an attempt at integration: As long as the organisation knows what resources will be spent for how long in order to produce what outcome that must be implemented at which point, all people will be oriented regarding the duration and amount of interference. That helps to synchronize the routines with the uniqueness.

In our opinion, most of the cited studies lack scope and do not go far enough. They mainly focus on how a project should be conducted but disregard the context, genesis, and transfer of those endeavours. Actually, potential project failures start already before the project is kicked off. There is much more during the project life span than the four major factors mentioned above, and there is a lot to consider in the follow up when an organisation is confronted with the generated outcome. The most general cause of failure, however, lies in the reason for the existence of projects.

Purpose of Projects

Why do projects exist? In short, organisations prevent themselves from failure by trying to innovate.

Companies, public authorities, non-profit associations, clubs, unions—in the first place they all exist to create stability: They consist of a continuous group of members (e.g. the staff of Ford Motor Company), who processes steady routines (e.g. producing the same cars every day) with a given infrastructure (e.g. the factory with its machines), which leads over the years to a unique portfolio of outcomes (e.g. range of cars) and shared attributions among stakeholders (e.g. Ford as a brand). People inside the organization gain a lot of expertise because they perform more or less every day the same procedures (e.g. assembling cars). Together they build up specific rules, norms and values (corporate culture). Over the years, everyone knows his/her place in that system and what to do (e.g. role expectations for a blue-collar worker). Finally, the inner structure of an organization becomes balanced and stable,Footnote 3 whereas the membership and work become part of the employee’s identity.

By doing the same things over and over again an organisation gets very professional in what it is doing, thereby creating stability, quality, reliability and efficiency. The downside of this process, however, is the lack of ability to make changes. The more stability the less flexibility. When a system is profoundly adjusted and performing at its best, every change jeopardises these achievements. At the same time, an organisation cannot ignore changes in its environment, changes among stakeholders, and competitors. It has to adjust to new legal requirements, technological advancements and customer needs. To innovate is essential to survival. Rubera & Kirca published in 2012 their meta-analysis on how innovation (inputs like R&D expenditure, outputs like number of new products, cultural, radical and incremental innovations) is correlated with performance outcomes (firm value like Tobin’s q, market position like market share, and financial position like ROI). The effect is generally quite small (r = 0.14–0.16) but extremely robust (fail safe N = 1220–2560).Footnote 4

The major threat for a routinized system in times of change are implementations that do not work. When Ford changed from combustion engineering to electric mobility, when they changed the entire product line, assembly procedures and services within their daily business, no one knew whether it would work. Failure puts the organization’s survival at risk. For that reason, they founded a special institution to implement the innovation, an institution separate from the everyday routines. By definition, those endeavours are temporary and separated from daily business to create something new, innovative, unique (ISO 21500:2012). This is done by a team of experts with their own budget, structure and processes. Projects are made for gaining knowledge in a scientific way by trial & error. They serve as laboratories outside the main building: If something explodes, no one gets hurt.

Projects are not only endeavours that allow failure, but they are even appropriate for producing failure in order to learn from breaching limits. Given that characteristic, project failures are potential opportunities for gaining new knowledge. Therefore, failure rates should be rather high.

In the following paragraphs, we take a closer look at failure in the stages of the project life cycle. We will go through the Initiation stage, when new ideas are born, which potentially become a project. After that, we show the major failure factors in planning and conducting a project followed by transferring the results back to the organisation. The entire project life cycle is shown in Fig. 2.

Fig. 2
figure 2

Project life cycle

Full size image

Failure in Initiating a Project

At the beginning, an organization must decide what idea is worth developing in a project in order to be potentially integrated later on. There are numerous approaches in the literature on how ideas should be generated,Footnote 5 gathered and selected. They are presented in relevant manuals (e.g. Tidd & Bessant, 2013) and tool boxes (e.g. Carleton, Cockayne, & Tahvanainen, 2013). Unfortunately, there is no gold standard in the realization of ideas (van de Ven, Angle, & Poole, 2000). Rather, organizations are dependent on creating an innovation-promoting environment that increases the likelihood of an idea being recognized, selected, realized and established. The common instruments for creating such a setting can be distinguished in two dimensions (see Fig. 3):

  1. 1.

    If they focus on a single outcome or the general environment.

  2. 2.

    If they are occasional or continuous.

Fig. 3
figure 3

Two-dimensional model of innovation management

Full size image

Highly innovative organisations do not rely on a single method but link their idea/project management with other management activities (strategy, organisational development, controlling, resourcing) and install a comprehensive Innovation Eco System, applying a multiple method approach (Adner, 2006). The Global Innovation 1000-Study of Booz & Company verifies that with empirical data (Jaruzelski, Loehr, & Holman, 2011). Based on 600 surveys, authors show that companies with an integrated innovation system are of higher value (in some cases 30% and more) and growing faster (by 17% during the last 5 years) in comparison to other competitors without such a system.

However, most crucial is the transfer of an idea from its creator to the organisation in order to become a project. Following the assumption that people involved in a company do not lack suggestions for improvement but cannot be forced to tell them, all depends on an invitational, project supporting culture. Scholl et al. (2014) support this hypothesis with questionnaire data from more than 50 companies. Based on the Denison Organizational Culture Survey (Denison & Mishra, 1995) they uncovered the link between innovation project success and corporate values, such as involvement (r = 0.41), consistency (r = 0.29), adaptability (r = 0.30) and mission (r = 0.44).Footnote 6

Even when an idea is successfully transferred to an organisation, a planning process is needed to found a proper project.

Failure in Planning a Project

Projects cannot be planned completely in advance! But planning is necessary (see above)—and another step on the way to potential failure. A plan which is not elaborated in detail is a strategy. The following definition (von der Weth & Frankenberger, 1995, p. 361) is coming from military and business management (Berekoven, 1989; Fricke, 1993; von Moltke, 1912): “(1) Strategies are oriented towards an ultimate goal of an action process. In attaining subgoals or intermediary goals we cannot use the term strategy, e.g., strategies in chess playing do not aim at taking a chess-piece but at placing the other player into check-mate. Strategies have a methodological character—they contain information about how to proceed in order to reach the final goal under certain conditions. (2) Strategies define subgoals, distinctive features of proceeding (e.g., offensive, defensive) and in that way, limit the possible operations. (3) Suitable strategies structure and simplify the action. They help to sub-divide a problem into clear units of subproblems so that it becomes superfluous to reconsider over and over again the whole way of proceeding, unless a modification in strategy becomes necessary.”

According to this definition the classical way of planning projects with well-defined milestones as well as the more flexible process of planning in agile project management can both be regarded as more or less detailed strategies.

A great challenge to a project is the adequate level of resolution for strategic planning. This depends on task characteristics, such as the complexity, content and required accuracy of the result. These task characteristics are influenced by the resources of the organization and psychological factors. There exists neither common sense nor a set of fixed rules which allows the identification of an adequate level of resolution. This is a source of failure in many projects. But there are many empirical results on psychological factors which lead to an inadequate level of resolution.

Since the 1980s, research on complex problem-solving has identified some core variables for the explanation of failure. Projects can be regarded as complex problems (Dörner, 1996; Funke, 2003; Starker, 2012). A central problem for coping with complexity is making decisions which cannot be overlooked because of their influence on a dynamic process. Because the outcome of a project is not completely predictable, there always remains residual uncertainty, which reduces control. Low control leads to stress-related behaviour patterns which increase the probability of failure. Research of Dörner et al. (for an overview, Dörner, 1996) identified typical behaviour indicating low control in a complex and risky situation. He calls them “intellectual emergency reactions”. In a short term perspective, they decrease control, because they neglect critical information. In the long run, these behaviour patterns lead to an increased risk of failure. Some examples, which are typical for different stages of planning a project:

  • Goal setting. A lack of concreteness in goal setting conceals weaknesses of plans and leads to subjective control.

  • Information and models. “Encapsulation” means avoiding problematic aspects and concentrating on activities where easy success is possible. Simple mental models (e.g. only one reason for all problems) ease planning in the beginning of a project, on the long run such plans of-ten are wrong because they are far from reality.

  • Prognosis and scheduling. The belief that major changes in the future are not possible leads to more subjective control, makes planning and decision making easier as long as these major changes do not occur.

Self-efficacy is one of the central predictors in explaining differences between individual planners. People with lower self-efficacy have a lower level of perceived control in a complex and new situation. Because intellectual emergency reactions allow the improvement of control by neglecting critical information their probability in-creases for people with low self-efficacy. Team work is not a remedy for this for two reasons. (a) Mechanisms of group think undermine rational strategies for collaborative planning in complex projects (Badke-Schaub, 1993). Different levels of self-efficacy of team members lead to different individual strategies of planning which can lead to conflicts between team members. Moreover, (b) differences in self-efficacy lead to different opinions on the adequate amount of information and extent of planning for making decisions. These conflicts increase the risks of projects (Starker & von der Weth, 2007).

Failure in Conducting a Project

Finding a gold standard to apply to a project is a kind of holy grail in management research. Pavitt (2006) concludes research findings with the generalist statement: “There is no widely accepted theory of a firm, level process of innovation.” (cf. van de Ven et al., 2000, p. 87). According to literature, stage models are still dominant in practice. This might be justified as long as projects are simple or adapted from an external source. But if they are complex, stages tend to be muddled and overlapping. This is because phases of idea generation, selection, testing, accomplishing, and disseminating do not occur once but iteratively. To understand the pitfalls and conditions that lead to failure in projects, stage models simply do not work (more detailed in Kunert, 2015).

Projects are usually implemented by a team of people, who bring all the knowledge and competencies that are needed according to the plan. They experience numerous shortcomings and pitfalls, which mostly do not arise from poor management but rather from task complexity, time restrictions, group dynamics, and individual factors. Some of these pitfalls are examined in more detail below.

Ill Defined Tasks

It would be much more fruitful to look closely at the tasks to be performed. Project objectives are often poorly described and presented as dynamic, interdependent tasks. In contrast to well-defined problems (like the famous Tower of Hanoi task), organizations often lack knowledge about the target and the way to reach it. Therefore, they cannot define them very well. At the same time, both change during the project, because expectations vary or relevant information become available late. Last but not least, the several tasks are mostly not independent of each other because one goal influences many others.Footnote 7 To deal with that problem project managers are advised to apply the Quality Function Deployment Technique, known as House of Quality (Akao, 2004).

Time

The amount of time to complete a project is one of the most crucial factors in the implementation stage. The increasing need for time reflects an increasing complexity that has to be handled. In addition, the longer a project lasts, the more external, unforeseen factors influence the endeavour. Both effects interact with each other and lead to self-energising delays (Bloch et al., 2012; Henard & Szymanski, 2001; Pattikawa, Verwaal, & Commandeur, 2006). Kunert (2013) provides some insights on the dimensions of that problem. Data from an interview study with 45 participants and a subsequent survey with another 355 employees (2013) show a correlation between project success measures with duration of unplanned delays as a proportion of total project time of r = −0.56, which means 31% of the overall failure probability can be forecasted by that variable. Cooke-Davies (2002) concluded his research, stating that mean performance against budget is generally better than mean performance against schedule.

Team

Project teams face tremendous expectations and very little chance to meet them. On the one hand, they are supposed to coordinate themselves autonomously, share their knowledge willingly, perform instantly, and deliver first outputs within a short period of time. On the other hand, they have no time for team-building and related stages of team evolution (cf. Tuckman, 1965), for dealing with difficulties because of high heterogeneity, nor for sharpening unclear project orders.

First question to be answered often concern the size of the team. A small number of people promises less struggle in coordination, increased team-building, and decreased diffusion of responsibility. In turn, more people also means more knowledge and perspectives, more effective specialization and division of work, and less risk if someone quits. Several studies focused on this topic show that effects are highly heterogeneous (cf. Hülsheger, Anderson, & Salgado, 2009; Stewart, 2006). Statistically, more or less a zero-correlation evolves, showing a curvilinear effect, which means neither too few nor too many people are to be recommended. In conclusion, the optimal absolute team size cannot be stated, at most only a relative one. Depending on the task, demands and restrictions, a slight under-staffing works best because of motivational effects (Hudson & Shen, 2015).

Because the team size question cannot easily be addressed, the composition has become the focus of increasing interest. Unfortunately, many approaches on how to assemble a well performing (project) team have also failed. Several meta-analytical studies prove the team composition approach wrong (Bell, 2007; Horwitz & Horwitz, 2007; Stewart, 2006). The authors looked at competencies, personality traits, age, tenure, roles and many more factors. As has often been the case, only the average intelligence/general mental ability is highly correlated with team performance.

Much more promising is the team development approach. It follows the assumption that good teams are not built but emerge. The focus is on changes within the group. Most notable are interventions regarding reflection and role clarification (Salas, Rozell, Mullen, & Driskell, 1999), building communication ties (Balkundi & Harrison, 2006), and decision-making strategies (Guzzo, Jette, & Katzell, 1985).Footnote 8 But for all that a team needs time, which is the scarcest resource in a project.

Leadership

Usually project team members do not directly report to project leaders. Because projects are just temporary, line managers keep their administrative responsibility. It is a kind of labour leasing. That is why project leaders are usually in a weak supervisory position. At the same time, there is no standardized best way of leading projects. Phases of innovation (creativity, trial & error, gathering information) alternate with phases of implementation (prototyping, small series, data collection). In both cases, team members have different needs, and team leaders need to adapt their leadership behaviour to these needs. (cf. Rosing, Frese, & Bausch, 2011).Footnote 9

However, as Freitag, Kunert, Waack, & Tiede (2015) have shown, leadership style is only of minor importance. In a survey that addresses organizational culture and leadership styles simultaneously, organizational culture correlates strongly with innovation project success (r = 0.62) and leadership style becomes insignificant (r = 0.11). Such results indicate that team members are much more influenced by shared norms and values than by a person with low-level authority.

Motivation

When it comes to willingness to participate in a project, the frequently used term ‘valley of tears’ shows up (cf. van de Ven et al., 2000. That means, motivation starts high, drops dramatically and—in best case—rises again at the end. Kunert (2014) questions that picture. In an interview study, only 24% of the participants reported such a U-shape in their motivation over time (values start high, drop and end approximately at the starting point). Another 34% of the interviewees reported rising elation during the process (values start low and end high). In 24% of the cases the motivation declines (values start high and end low). The remaining 18% shows a wave-like deviation (values cross the average line at least two times). However, the progress of motivation is not so important, but the average level should be high (correlation with project success r = 0.54) and variance over time should be small (r = −0.44).

Emotion

There are case studies on the role of emotion in conducting long term projects. A typical field for this research is the course of great software implementation projects. It is possible to design models to describe the development of interdependence between emotions in organizations and the technical and organizational process of software implementation projects (von der Weth & Starker, 2010). These case studies show that the general phenomenon of resistance against change should be analysed in a more differentiated way. For this purpose, a general model for the role of emotion in complex projects was developed (Wäfler et al., 2010). At the moment, single decisions in three software implementation projects on communication, participation of the staff and integration of qualification measures into different phases of the project are being analysed. How do they influence emotion and, vice versa, how does emotion influence the quality of these activities (Schubach & von der Weth, 2011) Prerequisites of organizations and actors in such projects, in combination with consequences of decisions, have been collected in a data base (the principles are described in Seipel, von der Weth, & Abreu, 2016). Summarizing the practical outcome of this data base in a book like this one is not easy. The influence of decisions on the emotional state of the staff is different for different people: e.g., major technical changes generate new working processes. Anxious workers with low qualification levels are more relaxed when they get a detailed guideline for the new task in a project. Workers with high self-efficacy, good knowledge and high problem-solving ability feel constricted using the same guideline.

Failure in Transferring a Project

Even if the team was successful, produced deliverables within time & budget, the biggest challenge might be the integration of the outcomes in the organization. The roots of that problem date back to the very beginning of a project: If the definition of the needs to be worked on was poor, the project results will probably not be suitable. Furthermore, even the organization is not something totally stable, it evolves and develops. The longer a project lasts the more changes occur on the principal’s side. This can result in altered needs, declined or increased readiness for change, new stakeholder groups or varied project image/relevance. In light of this, the contact points between project and organization are of special interest. They open up possibilities for both parties to learn about and from each other over time (obstacles during the implementation on the organizations side are core subject of change management).Footnote 10 Therefore, several authors suggest an integration of project management and change management (e.g. Cooke-Davies, Crawford, & Lechler, 2009; Hornstein, 2015) in order to strengthen the strategic role of projects. However, only one third of PM professionals are actually doing this (PMI, 2017).

In the worst case, executives assign the project order and some months or years later the project manager presents the results. In the meantime, both are off the air. Instead, feedback should be the solution: the project manager should keep the organization informed, and the organization makes recommendations and decisions. Thus, the project involves the organization in discussions and decisions and, in return, the organization shares the responsibility with the project team. Such a process creates shared ownership, and shared learning. This approach is visualised in Fig. 4.

Fig. 4
figure 4

Project life cycle with contact points between project and organization

Full size image

Project Information

The most wanted feedback for a project team concerns the following: Are they still on the right track? Have the aims changed? Is the organization still supporting them? For this process to be successful, the project team have to make intermediate results, failures and learnings transparent. In addition, they should explain what the next steps are and what the future solutions might look like. By providing prototypes, creating quick results, or conducting a pilot program they show their capabilities. In addition, guest appearances by organization members can be helpful in getting some insights into project specific working styles.

Organizational Resonance and Decision

The need for reliable information is not only important for the project leaders. The organization as well should call for facts and updates to be assured that everything is going in the right direction. Furthermore, the several groups affected by a project cannot be addressed by the project team solely. The top managers also have to make sure that all stakeholders are still on board.

What happens as soon as this information is provided is quite similar to what Heller (1969, cf. Levin, 1946) describes as the discussion phase in survey feedback processes. People of the organization have to understand what they see and make up their mind if it fits to their expectations. After this, they should share impressions, assumptions and wishes. By discussing those points the whole group learns about itself, becomes aware of changes among the members, synchronizes itself and becomes able to decide whether the project should go on, must change, or will be closed. All that should not happen once but recurrently. The sessions are at best facilitated and documented. If the project is rather large and long-lasting, an advisory board could be established. This body would provide interim feedback and pave the way for resonance in other stakeholder groups. By applying such feedback processes on a regular basis, the organization will become actively involved in the project, able to have appropriate discussions, and make timely decisions.

Dealing with Failure in Projects

Once again, the first step in dealing with project failure is even before a new one starts. To evaluate finished ventures means to learn from history. Organizations that do so are of 13% higher probability to initiate a successful project (Kunert, 2013). According to the Standish group, more than 90% of their sample perform some type of project postmortems or closeout retrospectives. Nevertheless, learning effects are mostly quite limited because of poor documentation, focus on electronic and data based storage systems instead of contact-centred methods (like project mentors, advisory board, experienced team members), and too much belief of inerrableness among the new project members.

But the Chaos Manifesto of the Standish Group provides yet another highly valuable solution based on their failure data: Small projects are much more likely to succeed than big ones. The probability of ventures less than $1 million staff costs is about 76% but only 10% for more than $10 million (cf. Bloch et al., 2012). Small, short and cheap projects benefit from less complexity, less changes in environment, lower staff turnover, and easier integration in the daily business of the organization.

In the last 20 years, a revolutionary new project management style has emerged which follows that finding. It comes with names like scrum, agile, lean, rapid, RITE, or Design Thinking. The core features are shortened, iterative project life cycles of planning, executing and evaluating. A team develops solutions, not in one shot, but approaches the best outcome in many tiny steps (cf. Sutherland, 2015). These project management styles do not try only to prevent a project from failure, but aim to integrate the project for learning, development, and, therefore, reducing losses in time, budget and motivation. About 40% of PM professionals apply some kind of agile/ incremental/iterative project management practices, 27% are said to use scrum techniques (PMI, 2017).

Besides the change towards more agile approaches, an ongoing professionalization can be witnessed in this domain. Companies with several projects running at the same time establish a project management office (PMO). According to PMI (2017), PMO’s are primarily responsible for overarching tasks, such as establishing/monitoring project success metrics, standardization, developing core project management competencies/organizational project management maturity. Only secondarily do they deal with program management, portfolio management, management of project resource allocation or providing project managers.

Another highly effective way to raise success probability are people around the core team, who support the venture with expertise, power, or network resources. Based on Schumpeter (1912), similar but independent theories of crucial individuals in project environment emerged calling them promoters (Chakrabati, 1974) or champions (Schon, 1963). The positive effects of those people are evident in various studies (e.g. Gemünden, Salomo, & Hölzle, 2007, Hauschildt & Schewe, 2000, Rothwell et al., 1974). They cause less resistance, increased communication, more knowledge sharing, faster progress and better results. While all authors assumed that motivated employees step into that role spontaneously, Rudinger (2012) reports a successful evaluation of a training program for innovation promoters. It focusses on the communication skills, facilitation, conflict solution, and in-depth knowledge regarding innovation projects.

Despite everything mentioned above, a project remains a risky endeavour. To at least keep some overview, project leaders have to provide several status reports, time and budget indicators, as well as progress statements. Nevertheless, even the people inside cannot estimate all risks and failure factors. One playful way to integrate virtually all accessible information and to build an early-warning system are Project Stock Exchanges or Project Betting Systems. All employees of an organization are invited to assess their individual expectation regarding the success of a project. If the ‘market price’ drops or the odds rise, management knows something is going wrong, then they can gather additional information and react appropriately.

Failure in Learning from Failure

Projects are unique! How to learn from a failed project for the next project? Of course, not everything in a new project is new. The result of a project can be a new product, a new process or new knowledge. Novelty is related to content and outcome of a project. Moreover, a project changes participants. They have new or even a novel experience. But the processes and organizational structures for different projects can be similar or even standardized. So they can be changed in the case of failure. The modification of behaviour is more complicated. It requires reflection of the process and the ability and readiness to learn.

To evaluate finished ventures means to learn from history. Organizations that do so have a 13% higher probability of initiating a successful project (Kunert, 2013). According to the Standish group, more than 90% of their sample perform some type of project post-mortems or close-out retrospectives. However, learning effects are mostly quite limited because of poor documentation, focus on electronic and data based storage systems instead of contact centred methods (like project mentors, advisory board, experienced team members), and over- confidence among the new project members.

The following two scenarios assure that this process of learning fails:

No debriefing. Shortly after failure most people are depressed. It is not the adequate moment for a complete analysis of the reasons. But there should be a first comment on the actual state and possible reasons. Immediately after failure people begin to restore their self-esteem by constructing a positive story about their role in the process. Some days later there is a high risk that these stories are very different from the real processes leading to failure.

Looking for scapegoats. Most failure results in an error chain, which involves personnel, organizational and technical factors (Reason, 1988). In most cases the search for one or several people who made a mistake is misleading. People who are suspected of being at fault are looking for arguments to defend their positive role and are not ready to speak frankly about problems, misunderstandings and wrong decisions.

Case study

The company in this case studyFootnote 11 offers services in hardware, software and technical networks for law firms. They implement standardized products as well as customized solutions. The seven employees (two sales, five technical support) and two managing partners, all based in Berlin (Germany) run a stable company with mostly long term business relations. However, the IT market is highly competitive and demands constant innovation. Therefore, in that organization every member takes part in innovation workshops, is involved in several projects simultaneously and invests about 20% of working time in the implementation of ideas.

Most innovations were about new IT services, for example in-house server-based automated data mirrors and automated remote-control devices. Few projects focused on internal processes, for example an automated booking and reporting system. Most of the innovations were initiated by one partner, who also monitors, accepts or revises the outcomes. All projects were driven by a single employee and had to be done parallel to the core business. In a handbook, all process steps and formalities are deeply fixed.

An innovation survey (questionnaire and interviews throughout the company) revealed that:

  • far too many projects were initiated by management at the same time (over 20) with very long-time periods (on average 18 months instead of desired 9).

  • projects were much more complex for employees (in average 17 steps) than expected by management (seven steps).

  • management monitored poorly, especially the outcomes. The partners changed success and outcome expectations during the project or, even worse, at the end. That led to long durations and much frustration.

  • management offered too little assistance and encouragement, e.g. the bonuses were only paid for customer services and sales, not for innovation projects, hence all colleagues tried to minimize their effort in other’s projects.

  • projects were communicated as cost factors by management in their annual financial reporting; earnings in the long run were not connected to former initiatives.

In sum, this company had much more ideas than resources to implement them. Project leaders felt mostly left alone. The overall outcome was quite small compared to the investments: increasing unfinished or escalated or failed projects, and decreasing volume of sales with new products and services.

Transformation started with moderated survey feedback workshops, followed by a task force with quarterly meetings over 2 years. The partners committed themselves to start less projects, to fix the desired outcomes in a specification sheet, to report gains from former projects and to share financial gains with the project leader. Furthermore, innovation management was installed which acts as a process promoter. The innovation manager mediates between management and staff, hosts supervision meetings, initiates project mentoring, intervenes in crises, connects to resource holders and gives practical advice. By so doing, management tried to erase the stigma of blood, sweat and tears from innovation projects and to bring back fun and glory for successfully implemented ideas.

Conclusion

Projects cannot be prevented from failure. In fact, both are tightly interconnected. To eliminate all risks would mean removing the best a project has to offer: Discovering the unknown. Nonetheless, in the eyes of an organization this is an investment, therefore there must be some results for all that money, manpower, and fuss. What success means is probably one of the most crucial questions to be discussed. The project team might answer differently from the project leader, and the management board might think differently than all the other stakeholders and employees involved. Nonetheless, all of them have to accept the risky nature of projects: without failure there is no advancement.