Keywords

1 Introduction

The global software spending is growing rapidly [12]. Especially R&D spending on software has increased by 65% between 2010 and 2015 [43], driven by innovations depending more and more on electronics and software [13]. While software has become increasingly important for companies, estimating the cost of software is difficult. The annual losses from software projects are measured in billions of euros [11, 36], and software project overruns are common [9, 14, 16].

Software cost estimation (SCE) and project management (PM) are both inseparable parts of a software project, and project management should always consider estimation [17]. Therefore the reasons for overruns may also reside in SCE, PM, or other project areas [6, 24, 35, 38]. Considering the gravity of the problem and the known positive effect of using methodologies on project success [52], both SCE and PM professionals have developed a plethora of methodologies to aid in guiding the project to a planned conclusion. In the area of SCE, hundreds of estimation methodologies have been developed [22, 34], some of which have been proven to produce accurate results, when used properly [40, 42]. Yet, overruns are common [9, 14, 16].

Recent studies show that there are severe deficiencies in applying SCE methodologies in organisations [3, 20, 30, 33, 45], although the problems have been known for decades [15, 27]. The situation is significantly better in the area of PM, where 95% of the projects report using PM methodologies [50]. This difference in the extent of use of methodologies is surprising, because SCE research is methodology heavy, having 84% of the studies focusing on methodologies [22]. At the same time PM research has undergone a major shift towards topics like management and business, having only 16% of the recent articles focusing on methodologies [25]. Especially Top Management Support (TMS) has been an important topic for PM research, and it has been found to be even the most important success factor for projects [50]. The body of knowledge regarding top management support in PM is extensive, and contains clear advice for top management for how to support projects, including refreshing project procedures and appropriate project management assignment [53].

Considering the previous, the estimation related problems are not connected only to methodologies, but also to how these methodologies are applied in organisations. Although SCE research is still mainly focusing on methodologies, recently topics like estimation bias [18,19,20], organisational inhibitors and distortions [30, 33], and top management participation [45], have become focus of the research. This paper continues on this highly relevant path of examining other than technical factors in SCE.

The research objective of this paper is to address the role of top management in SCE, and to answer the following unanswered questions:

  • RQ1 What are the real life top management support practices for SCE and how do they appear in an organisation?

  • RQ2 How much effort top management invests in participating in SCE?

  • RQ3 Which persons or items are affected by top management actions?

  • RQ4 What is the impact of TMS for SCE on project success?

In the scope of our study, when a reference to top management is made, we refer to the highest up manager, who is aware of the estimate on the basis on their responsibilities related to the studied projects. This paper provides in-depth findings from three projects in three case companies. Based on the study of 18 interviewsFootnote 1, the paper contributes to the scientific literature by reporting on the current practice of top management participation in software cost estimation, and the effects of this participation in organisations. Additionally, the impact of top management participation in SCE on project success is addressed. Understanding the role of top management in SCE may better justify project managers, other software professionals and researchers to pay more attention to top management’s role in software cost estimation.

The remainder of the study is structured as follows. Section 2 presents the background and related work of software cost estimation and top management support for project management. Section 3 describes the case study subject and research design. It is followed by the presentation of findings in Sect. 4. Section 5 discusses the results and Sect. 6 concludes the study.

2 Background

The purpose of software cost estimation, or effort estimation, is to provide the management and project leadership a clear enough view of the project to make good decisions about how to control the project to hit its targets [34]. SCE has already been studied for over half of a century, c.f. [37], and hundreds of different estimation methods have been developed [5, 22]. Still, despite of the long and extensive work on the area of SCE, many software projects fail to meet estimates.

Software cost estimation research has heavily focused on estimation methodologies; leaving organisational issues with relatively little attention. According to Jørgensen’s and Shepperd’s [22] systematic literature review, organisational issues have been discussed only in 16% of the reviewed articles (Table 1). Furthermore, the interest towards organisational issues is decreasing. The recent study of SCE research trends shows also that the research focus has remained consistently on estimation methodologies and techniques between 1996 and 2016 [48].

The previous may be problematic, because the SCE challenge seems to reside elsewhere than in estimation methodologies. Researchers and practitioners largely agree on this point [22, 27, 30, 34], getting support from recent studies [30, 44, 45]. Also, major industrial software development frameworks, such as CMMI [1], ITIL v3 [2] and PRINCE2Footnote 2, continue along the same lines, emphasising the importance of estimation, without giving specific advice, which estimation techniques to use. Thus, while the estimation problems seem to reside on the application of the methodologies in an organisation, the research is still focusing on the methodologies themselves, leaving a gap between the actual problem and the means to fix it.

Much of the work performed in organisations is organised as projects which is understandable because the results of projects are critical for organisations [7, 49]. Considering the importance of PM, also PM has been intensively studied for over decades which has resulted into an extensive body of knowledge. However, whereas the SCE research is still focusing on methodologies as its primary line of research, the PM research has undergone a significant shift from methodologies towards other topics, such as leadership and business. According to Kolltveit et al. [25] (Table 2), PM research related to Task and Transaction perspectives, representing technical methodologies, has decreased from 68% to 18% over the time, measured in the number of published articles. This shift of focus seems natural, since organisational issues are reported to be even more important factors in project success than technical ones [10, 29, 52]. Also, top management’s interest in PM is increasing along with the number of PM related articles published in top management and business journals [26].

Table 1. Distribution of published SCE articles among research topics [22].
Full size table

Regardless of the methodology heavy mainstream of the SCE research, some of the recent research has also been attending to non-technical problems, such as human bias, organisational inhibitors and distortions, as well as top management participation. Jørgensen et al. have conducted a broad and widely cited work on human bias, originating from different sources. Their studies have covered e.g. the impact of the first impression [19], customer expectations [23], irrelevant or misleading information [18], and wording [21] on the estimate. Magazinius et al. have published their results regarding intentional distortions  [30,31,32] and organisation inhibitors [33] in SCE. Additionally, among the studies of organisational factors, Rahikkala et al. [44, 45] have studies top management participation in SCE, and Ahonen et al. [3] have found problems in the reporting effort in projects.

Table 2. The distribution of published PM articles among different perspectives [25].
Full size table

To summarise, although both SCE and PM are inseparable parts of a software project [17], only PM research takes a holistic view, and examines the organisational context of the respective area to any great extent. SCE continues to focus on methodological problems. This is a noteworthy observation, because the problems for software project overruns reside both in SCE and PM [6, 35, 38]. Understanding the organisational context of SCE may better help to overcome many organisational problems related to SCE, and to eliminate related sources of estimation error. This paper continues examining the organisational context of SCE, and addresses specifically the top management’s role, which has been found to be of critical importance in PM.

3 Research Process

3.1 Research Approach

The study is based on three anonymous case companies and projects. For each company, we interviewed stakeholders involved in the projects (Table 3) and analysed 18 documents related to the project, including project plans, design documents, and minutes of meetings.

This study is based on a qualitative research approach [8]. We use a case study research strategy and interviews as the main tools of inquiry. The qualitative research approach was selected to allow us to get an in-depth understanding about the phenomenon under the study lens. The case study research strategy was used as the researchers have no control over the study subject [51]. As Patton [39] states, case studies are well capable of shedding light on phenomena occurring in the context of real-life. This study is of exploratory type, finding out what is happening, seeking new ideas, and generating hypotheses and ideas for new research [46]. The research uses a multiple case study design following a replication logic [51]. The unit of analysis is a single software cost estimate. The study is focused on the experiences gained during the preparation of the cost estimate. The conceptual framework of the study assisting in answering the research questions is presented in Fig. 1. Additionally, we have employed the list of 16 top management support practices suggested by Rahikkala et al. [45] for studying top management participation practices.

Table 3. Interviewees of the research.
Full size table

An interview protocol consisting of questions related to top management participation in SCE was created, following the guidelines by Runeson and Höst [47]. The one hour interviews were conducted as semi-structured [46] by two researchers, and the discussion was recorded. The recordings were transcripted and sent to the interviewees for review. All case subjects participated in the study voluntarily and anonymously, and the collected data was treated as confidential.

For the analysis of data, we used nVivo 10. All transcripted interviews, notes done during the interviews, in addition to the auxiliary materials, were imported into the software. The analysis was conducted in a series of steps [46]. First the texts were coded by the researchers, whereafter iteration followed, until conclusions were reached.

Fig. 1.
figure 1

The conceptual model of this research.

Full size image

3.2 Case Companies and Projects

‘Small Global’ is a software producing firm of about 100 persons. The company’s line of business consists of selling consultancy and support services in addition to software products to businesses. The company is global; it has customers and offices in several countries. The selected project, referred to as Developer Tool (DT), was about producing a visual design tool for developing applications. The end-result is a commercial product. The project followed a waterfall-style software engineering method, but the actual development work was divided into sprints. The estimation was done by using work breakdown structure (WBS) and expert estimation.

The DT project started with a prototype where technical challenges were studied. After the prototype project, a project aiming at the release of version 1.0 was planned. The product owner crafted a design document for the product, and based on that document, the project manager created a project plan with time and effort estimates. Initially, the project was estimated to take three months with a team of four people. The project completed nine months after the deadline with a team of approximately six persons.

‘Large Multinational’ produces software and consultancy for a wide area of business sectors. The company has tens of thousands of employees around the world. The selected project, referred to as Operational Control System (OCS), is a business intelligence reporting system for following certain control activities. The software was ordered by a long-term customer of the company.

Also this project followed a waterfall-like software development process. The estimation was done by the developers using expert estimation, whereafter the values were filled into a structured sheet. The project manager prepared the final estimates based on the results from expert estimation. The OCS project was planned according to certain preconditions: the customer had a fixed budget and schedule for development. The project lasted 10 months, and the size of the project was approximately 30 man-months. The project concluded successfully on time and budget.

‘Tech Giant’ is selling products with software to global business-to-business markets. The company has tens of thousands of employees around the world. We studied the Network Management Product (NSP) project of Tech Giant. The project produced a new release of a tool for managing the network. The project produced a new release of the system. The NSP has been in use for several years.

The project was part of a continuous development cycle involving just under 100 people. A new release of the system is developed every three months. The development methodology it used was based on Scrum with two week sprints. The development teams were distributed over several locations. The cost estimation was conducted in two phases: firstly, rough planning for the whole three month release in the product management function. Secondly, the backlog items were estimated in the scrum teams, the main responsible being the program manager. The backlog items were estimated using expert estimation. The project concluded successfully and delivered over 85% of the planned scope, which is the goal for all releases.

4 Findings and Results

This section presents the findings identified during the analysis of the data as described in the research methodology section. The findings are grouped into the following five categories according to the conceptual framework (c.f. Fig. 1): (1) Project boundaries, (2) Participation practices, (3) Participation effort, (4) Practical impacts, and (5) Impact on project success. The Project boundaries were separated clearly from the participation practices because, from this study’s point of view, they are related to creating prerequisites for the estimation and the project rather than directly to the estimation itself.

4.1 Project Boundaries: Scope, Cost and Schedule

Software cost estimation is fundamentally about estimating the size of the software for a given scope. The size is then converted into a schedule and budget, based on different factors, like the composition of the development team. However, there are usually boundaries for an acceptable scope, cost or schedule, originating from the business environment. Based on these boundaries, the decision makers, project management and estimators try to find an optimal balance between the previously mentioned three dimensions. This section summarises boundaries for the studied projects and estimation.

At Tech Giant, who operates in a three month release cycle, the schedule was fixed. Also the cost (resources) was fixed to a great extent, although there were some additional resources available for situations, where overruns seemed probable. Large Multinational reported that their customer also operated under a predefined system update cycle and budget framework, also fixing the schedule and cost. At Small Global, the Senior Business Manager and other team members reported that the schedule was fixed. The Senior Business Manager also reported that the planned scope was a minimum viable and nothing could not have been dropped out, making also the scope of the project fixed. Thus, for Tech Giant and Large Multinational, the only variable element was the scope, and for Small Global the resources. Additionally, the senior managers monitored the progress of the projects against the estimate regularly, and made adjusting decisions based on the situation, where deemed necessary.

Table 4. Exercised top management support practices.
Full size table

4.2 Participation Practices

First of all, top management did not exercise seven of the sixteen studied support practices at all, as shown in Table 4. Practices 1–16 are adapted from [45]. Additionally, the presence of three practices, ‘TM ensures the involvement of the project manager during the estimation stage’, ‘TM ensures ongoing estimation skills training programmes’ and ‘TM recognizes that the estimates are inaccurate in the beginning of the project’, was indirect, meaning that the presence of the practices could not be tracked back to any specific TM actions related to the studied projects. ‘TM recognizes that the estimates are inaccurate in the beginning of the project’ was not relevant for Tech Giant, as they are in a continuous three month release cycle, and the delivered scope must be constantly at least 85% of the planned scope. Large Multinational and Small Global had improved the accuracy with a specification phase, but this was a standard practice in both companies, like the involvement of the project manager during the estimation phase was for all three companies. Large Multinational and Tech Giant had arranged training for SCE earlier, but there were no ongoing training programs during the studied projects.

In all projects the senior managers reported that they had studied and approved the estimates. At Small Global, the Senior Business Manager studied the estimate in detail, as part of the project plan, while at Large Multinational and Tech Giant, the senior managers studied the estimates only on a summary level. Certain items in the estimates were also challenged by the senior managers in the OCS and NSP projects, which resulted in better estimates for the items in question. Considering the list of predefined 16 practices at hand, studying the estimates is close to ‘TM ensures that the estimate relies on documented facts rather than guessing and intuition’ and ‘IT executive studies and approves the estimate’. However, as studying and approving the estimates does not fit precisely under either of the previous, we decided to report it as a new TM support practice for SCE, ‘TM studies and approves the estimate’. ‘TM is knowledgeable of estimation procedures’ was present in the OCS project, where the Business Manager reported having been well aware of the estimation practices. This was, according to the Business Manager, coincidental rather than a result of planned actions. The presence of the four remaining support practices was strong in all case projects. The interviewees reported that the management considered the estimates having a high importance. However, none of the interviewees specified concrete examples of how the importance was demonstrated during the case projects, which means that the importance has most likely been established before these particular projects. At Large Multinational, the estimate was used for preparing an offer for a customer, who made the order decision based on it. At Tech Giant, a business plan, product roadmap and customer commitments were made based on the estimates. At Small Global, a GO/NOGO decision of the project was made based on the estimate. However, the Senior Business Manager at Small Global reported that the decision of making the product was practically made, and the estimate was used for reassuring that the scope was small or minimum viable, and that the delivery was possible in the targeted schedule. Thus, the estimate was connected to significant financial interests at Tech Giant and Large Multinational, and for making important planning decisions at Small Global.

When asked, all interviewees reported that realism and accuracy were always sought during the estimation. Furthermore, each interviewee also concluded that there was no push from the management to make the estimates smaller, and the management did not try to negotiate the estimate smaller. The Line Manager from Tech Giant says that estimates are accepted as facts, and the scope is reduced, if necessary. The Business Manager from Large Multinational says that the price can be negotiated with the customer, but not the estimate itself. However, although all interviewees at Small Global report that there was no push from the management, they also say that there was still a pressure to make the estimate smaller, conveyed by the Senior Business Manager in form of a strict deadline. The Project Manager, who was responsible for making the estimate, says that he experienced a high pressure and started to doubt his own estimates and eventually made them smaller.

As described earlier in this section, all of the projects had clear targets, or business goals, consisting of the scope, budget, and schedule. In the OCS and NSP projects the estimates were also accepted as facts which steered the planning. However, in the DT project, the Project Manager described that he made the estimate smaller because of the perceived pressure. The Senior Business Manager also told that the purpose of the estimate was to verify that the fixed scope was possible to be delivered within the target schedule, with higher resources, if necessary. The decision of executing the project was practically done. The previous signals that, in addition to creating estimates, the management seem to have expected the estimation to result into a plan, how to hit the targets, even though this seems not to have been consciously understood and intended.

In the NSP project, there was a continuous commitment to deliver at least 85% of the target scope, and at Large Multinational the normal practice was to use the estimate also as a commitment. At Small Global, the Project Manager says having been committed to the estimate in the beginning, but during the re-estimations in the later phases of the project he describes as having been afraid of giving estimates, because the estimates were taken literally by the management. Thus, estimates seem to have been implicitly taken as commitments by the management, although there was no explicit agreement on this.

In addition to the findings related to the 17 support practices reviewed earlier, resource provisioning for SCE emerged from the discussions. According to the interviewees’ subjective perception, all projects had enough time and resources for preparing the estimates. At Small Global and Large Multinational, there was a separate specification phase prior to the actual implementation phase. The requirements engineer at Tech Giant reports that pre-studies are conducted, when necessary, to gain adequate understanding of the features. However, also this support practice was indirect of nature, and could not be attributed to any top management actions specific for the studied projects.

4.3 Participation Effort

According to the evidence discovered during the interviews and review of the documents, top management’s effort for participating in SCE was low in all case projects. In terms of time and effort, the most significant contribution was the follow-up of the progress against the estimate. This, however, is primarily connected to project management, and not to SCE. Additionally, the senior managers studied the estimate in all projects. However, as an investment of time and effort, this was relatively small. The effort related to all other participation practices could not be attributed to the studied project in particular. The practices had emerged in a longer period of time and become established routines, which do not need attention for each new project. The interviewees in all projects also confirmed that the top management did not participate directly in the estimation.

4.4 Affected Items

As concluded earlier, top management sets boundaries for the project and estimation in form of budget, schedule and scope. This, however, is not influencing the estimation itself. Furthermore, the indirect support practices ‘TM ensures the involvement of the project manager during the estimation stage’, ‘TM recognizes that the estimates are inaccurate in the beginning of the project’, ‘TM ensures ongoing estimation skills training programmes’, ‘TM ensures adequate resources for estimation’ and ‘TM is knowledgeable of estimation procedures’ did not have any direct effects on estimation, which could have been attributed to the studied projects.

The awareness related practices, ‘TM recognizes that estimates are critical to this organization’s success’, ‘TM understands the consequences of an erroneous estimate to the project success’, ‘TM can distinguish between estimates, targets and commitments’ and ‘TM takes the output of an estimate as given without debate’ did not have any tangible effects either in their positive occurrences. However, in the DT project the Project Manager reported that he had made the estimates smaller, because of the awareness of the target schedule. Furthermore, he reported that his willingness to give re-estimates during the project had decreased and he had started to give upper bound estimates, because the estimates were taken literally and interpreted as commitments. So, the awareness related support practices seem to have tangible effects on people or SCE related artefacts only, when the effects are harmful.

‘TM studies and approves the estimate‘ was the only support practice that had direct positive impacts on estimation as a result of top management actions. After studying the estimates, managers challenged some parts of the estimate in the OCS and NSP projects. This lead to re-estimation, and improved the effort estimates for those particular functionalities.

4.5 Impact on Project Success

Cost estimation is an inseparable part of any software project [41], thus the cause of an overrun may reside in SCE, PM or other areas [6, 35, 38]. Not even the best project management can control a project if it has to meet unrealistic goals, while chaotic project control will usually overshoot set limits, making cost estimation meaningless. In this study our aim was to find evidence from the real-life experiences of how management’s actions impact SCE, which further influences project success. Of the studied projects, two, OCS and NSP, delivered on time, scope and budget, and one project, DT, suffered from significant cost and schedule overruns.

In the two successful projects, top management’s participation in SCE has been minimal, and we found very little evidence of their actions’ impact on persons or artefacts during the estimation. On the other hand, top management seemed to have understood well that a realistic and unbiased estimate is critical for the success of a project and organisation. We found plenty of evidence of this understanding in both projects, although this understanding did not manifest into any concrete actions. For example, the software developer in the OCS project told that top management did not try to negotiate the estimate in any direction, customer agreements and offers are depending on the estimates. The requirements engineer in the NSP project said that top management was seeking realistic estimates—nobody wants to betray themselves, and everybody understands that without realistic estimates things will fail.

Top management’s efforts for participating in SCE were equally low in the studied runaway project. But where the senior managers refrained themselves from any interference in SCE in the two successful projects, top management seemed to have influenced the estimation results by emphasising the importance of the targeted release date, and that the scope was small or minimum viable. The project manager reported having made the estimates smaller under this pressure. Additionally, implicitly interpreting estimates as commitments influenced the project manager’s willingness to give estimates, and he reported having given upper bound estimates after noticing this. Although the reasons for the experienced project overruns may have been many, one of the reasons seem to have been top management induced pressure to make the estimate conform to the target delivery date. The Senior Business Manager of Small Global also attributes the overrun both to SCE and project execution.

5 Discussion

5.1 Implications for Practice

Our study clearly shows that a project can conclude successfully with no, or with very little, direct top management participation in software cost estimation. On the other hand, this study presents evidence that top management’s incautious interference may lead to undesired outcomes, and influence the project success negatively. The most important distinctive factor between a positive and negative top management participation seems to be to not create bias. Not creating bias manifests through understanding the negative impact of poor estimates on project and organisation success, and therefore avoiding influencing the estimation to any direction.

Previous studies have found plenty of evidence about the negative effects emerging from influencing estimation. Magazinovic and Pernstål [33] have found that management goals affect the results of estimation. Furthermore, Magazinius et al. [30] found that personal agenda, management pressure and attempt to avoid re-estimation may affect an estimate. The previous studies also show that cognitive bias may affect estimators: e.g. high or low expectations influence even experienced estimators [4], first impression may dictate a significant part of the estimation result [19], and even the wording may have a significant impact on the estimate [21]. The estimators may not even notice the influence of the expectations, or consider it to be very low [23]. The findings from the studied runaway project show, in accordance with the above mentioned studies, that it is indeed easy for top management to influence the estimation and project success in a negative way. Thus, in the light of our findings and previous studies, it seems advisable for top management to stay outside of estimation to minimise any biasing effect they may induce.

The most tangible top management participation practice in SCE was ‘TM studies and approves the estimate’. Although the general recommendation seems to be staying outside of the estimation, we cannot reject the potential importance of this support practice. Studying the estimate may be a necessary action to ensure that the estimate is prepared professionally and with due care. Some other studies support the potential importance of studying the estimate: e.g. Rahikkala et al. [45] report that the extent of use for ‘Top management ensures that the estimate relies on documented facts rather than guessing and intuition’ correlates positively with project success, and Lederer and Prasad [28] recommend that computing management should study and approve the estimate.

The remaining three top management support practices that were present during the estimation, ‘TM ensures the involvement of the project manager during the estimation stage’, ‘Top management ensures adequate resources for estimation’ and ‘Top management ensures ongoing estimation skills training programmes’, are indirect of nature, and were not directly related to any of the studied projects. Additionally, none of these practices could be tracked back to any specific top management actions, implying that these practices were among the presumably many results of top management actions to create an overall framework for software development. Thus, because of the lack of direct top management participation, these practices cannot be considered as top management support practices for SCE, and do not seem to justify for top management’s attention during SCE.

Finally, this study shows that top management invests very little time in SCE. In light of the previous findings this was expected, and even recommended, because the successful conclusion of a project did not need significant participation from top management. As is natural considering the low extent of top management participation, the footprint of their actions is also low. The results of top management actions tend to have a negative impact on project success, which was the case in the studied runaway project. The only exception for this was studying the estimate, which triggered re-estimation of certain items in the two successful projects, resulting in more accurate estimates.

5.2 Implications for Theory

The current SCE literature sparsely contains studies addressing management aspects of software cost estimation [22], and, to our best knowledge, this is among the first studies to report on experiences related to top management participation practices in SCE. This paper contributes to the body of knowledge by showing that no, or very little, direct actions are required from senior management for a successful project delivery. On the contrary, the results indicate that top management must understand SCE’s delicate nature prone to bias, and stay outside of the estimation to avoid any negative effects they may induce. This study also shows, from the perspective of top management that many known negative effects from biasing the estimation can also be caused by firms’ top management.

Furthermore, our results show that the time top management invests in SCE is low, as well as the footprint that their actions leave on SCE related artefacts and actors. Considering the previous, the responsibility of improving SCE seems to move back towards project management and technical experts. However, as the literature has shown, methodologies are not a silver bullet, and a holistic view considering techniques, people and procedures is needed for producing more useful estimates.

5.3 Validity, Limitations and Further Research

The qualitative case study methodology involves the researchers themselves as the instrument of the research, which poses a risk that the results are biased by the researchers’ subjective opinions. As countermeasures to the validity threats, we have employed six strategies outlined by Robson [46]: prolonged involvement, triangulation, peer debriefing, member checking, negative case analysis and audit trail. Additionally, we have tried to maximise the richness of the data set by selecting different case companies and projects, improving the transferability of the results. However, as this study is explorative of nature and has not been widely examined prior to this study, generalisation of the results must be done with caution.

Overall, this study provides evidence that top management participation in SCE is low and that their participation is not needed for successful estimation. Although we believe that the results of this study can be transferred to similar settings, the situation can still vary from context to context. For example, we may have overlooked the role of some company properties, like size or maturity. Therefore, further studies in different project and company contexts are needed to see if the same phenomena are repeated, or new phenomena discovered. Quantitative studies would also provide certainty in how commonly the reported phenomena are repeated in organisations. The importance of top management studying and approving the estimate was also left unanswered in this study.

6 Conclusions

This study examined top management support for SCE by using a case study approach and interviewing 15 experts involved in three software projects in three organisations. Top management support practices for SCE were studied by employing a list of 16 predefined practices. The results show that 8 from the 16 studied practices were not present in any of the projects, and that ‘Top management studies and approves the estimate’ was the only tangible practice present (RQ1). This study also found evidence that the time and effort top management invested in SCE was low (RQ2), and the items or persons affected by their actions were only a few (RQ3). However, the results show further that some of the top management actions induced undesired bias on estimation, and affected project success negatively (RQ4).

The main implications from the results for managers, software experts, project managers and academia are the following:

  1. 1.

    No, or very little, direct top management participation in software cost estimation is required for the successful conclusion of a project.

  2. 2.

    ‘Top management studies and approves the estimate’ was the only concrete top management participation practice.

  3. 3.

    Top management actions may induce undesired bias on estimation, and affect project success negatively.

  4. 4.

    Senior managers must recognize the importance of seeking realism in estimation, and avoid inducing accidental bias in cost estimation.

Finally, the aforementioned also serve as a good starting point for further research.