Case Study Results
In this section we analyze the collected data from the 41 case studies in detail and seek to find answers for the research questions raised.
The Nature and Sources of Project Uncertainties
To identify uncertain situations in projects, the interviewees were asked to think about situations in their project that surprised them. The situations related to uncertainties during project implementation vary widely across the 41 cases. In general, we classified the identified sources into six categories (see Table 3).
The most frequent category of project uncertainties is related to a project's stakeholders. About 38% of the identified uncertainty scenarios are related to specific characteristics or activities of stakeholders. Two less frequent categories of uncertainties are linked to the organizational and the external contexts in which projects are implemented. Specific project characteristics and malmanagement are the least frequent events related to uncertainties. In particular, malmanagement was a category of uncertainty that was surprising. In these cases uncertainties were caused by improper management procedures that neglected common project management standards.
The different uncertainty categories are discussed in detail in the following section.
Table 3: Identified Sources of Uncertainties
| Uncertainty Categories | Uncertainty Sources | Frequencies |
| Stakeholder uncertainty | Inexperience, change, contracts | 17 |
| Organizational uncertainty | Mergers and acquisitions, politics, unknown legacy system | 10 |
| Technological uncertainty | Technical issues, tight specifications | 8 |
| Contextual turbulences | Legal, market | 6 |
| Project characteristics | Unknown complexity | 2 |
| Malmanagement | Self-induced uncertainty, false assumptions | 4 |
Stakeholders as a source of project uncertainties
Stakeholders represent a main source of project uncertainty. In 17 out of the 41 cases, stakeholders induced uncertainties into a project's implementation (see Table 4). They elicit uncertainties in many ways. The most frequent sources for uncertainties are related to the capabilities of different stakeholder groups, behaviors of stakeholders, or unexpected changes of key stakeholders.
The many different stakeholder-related reasons for project uncertainties also demonstrate the complex nature of this category and pose significant challenges for project management during project implementation. The following cases describe in more detail the stakeholder issues identified in the study.
Specific behaviors of key stakeholders, such as opposition and requirement changes, led to project uncertainties in our cases. The following three cases demonstrate how the behaviors of stakeholders cause project uncertainties. In particular, change requests are frequent causes for project uncertainties. In one case we could even identify opposition by a key stakeholder group that led to significant delays and major project uncertainties.
Table 4: Stakeholder-Related Sources of Uncertainties
| Uncertainty Sources | Cases |
| Customer-induced changes/Contracts/Diverse needs | Case 06, Case 23, Case 37 |
| Rejection from clients | Case 31 |
| Requirements changed by project owner | Case 39 |
| Opposition from external stakeholders | Case 40 |
| Inability of contractor or vendor | Case 07, Case 10, Case 30 |
| Inexperienced project manager | Case 17, Case 26 |
| Inexperienced subcontractor | Case 18 |
| Contractor-client relations | Case 15, Case 21 |
| Change of key stakeholders | Case 27, Case 33 |
| Unknown project ownership | Case 01 |
Case 06 is a representation of the classical situation of customer or client-induced changes, while Case 39 is interesting because the changes were requested by the project's owner. The owner was not in place when the project started, but when they got involved they changed the initial requirements in order to simplify the original six features down to one.
Capabilities of stakeholders play a major role in project uncertainties. In more than 20% of the cases, uncertainties were caused by the misjudgment or lack of capabilities of key stakeholders. Inability or inexperience of contractors or subcontractors leads to uncertain project situations. It seems that contractors are often selected on criteria other than their capabilities and capacities. The following two cases are good examples of this kind of situation.
Inexperienced project managers are also a source for uncertainty, as demonstrated by the following two cases.
Over the lifecycle of a project, it is not unusual for key stakeholders to change, as demonstrated in the following three cases.
In one extreme case (Case 01, above) the main owner of a project was unknown to the project team when the pre-study phase was finished. When the sponsoring U.S. Senator retired, it was unclear which organization would assume ownership after the initial project was completed, and whether or not funding would be identified for the project's next phase. This might be an extreme case of stakeholder changes, but it demonstrates how disruptive changes in stakeholders are for the implementation of a project. The whole situation led to a redefinition of the project and resulted in a consortium of owners from different public functions. This interesting case might seem to be an exception, but it is an example of a situation which leads to uncertainties during the implementation of a project.
In Case 27, a technology project for funds transfers between syndicate members was initially headed by an external project manager placed by a consulting firm. Eventually, an internal project manager replaced the initial project manager, causing uncertainty for the project. Case 33 describes a common situation for internal projects with shared resources. Multitasking is disruptive to the accomplishment of the goals of an individual project, but this practice is often supported by senior management to allow for simultaneous execution of multiple projects.
Table 5: Uncertainties Related to Organizational Dynamics
| Uncertainty Sources | Cases |
| Mergers and acquisitions | Case 03, Case 28, Case 32, Case 18 |
| Corporate leadership change | Case 10, Case 22, Case 41 |
| Unknown legacy system | Case 30, Case 33, Case 37 |
Organizational dynamics as a source of project uncertainties
Projects are often implemented within a dynamic and complex organizational context. In particular, organizational changes or political dynamics could lead to project uncertainties. Another source of uncertainty can be the lack of knowledge of the legacy system which is specific to IT-related projects. This might also be true for several projects impacted by mergers and acquisitions. Merger and acquisition situations might be attributable to the relatively high percentage of financial services organizations represented in the case sample (see Table 5).
Mergers and acquisitions caused uncertainties for projects that were in the implementation process. In the three cases below, redundancies of ongoing projects were caused by mergers and acquisitions, which created uncertainty in the roles and responsibilities of those involved in the projects.
In all three Cases above, the merger and acquisition situations led to uncertainty at the organizational level. These situations were not known to the project teams prior to project start and therefore could not be planned for.
The three cases below demonstrate how organizational leadership changes can lead to situations of uncertainty at the project level. For example, in Case 41 below, frequent leadership changes in the marketing organization that sponsored and owned the project led to changes in the scope and requirements of the project.
IT projects involving legacy systems are prone to many different uncertain situations because important technical details may not be fully known at the start of a project. The following three cases demonstrate how complexity and lack of documentation can lead to project uncertainty—particularly in those situations requiring modifications or enhancements.
The documented cases in this section show that, because projects are embedded within organizations, they are influenced by their host organizations in one way or another. In particular, dynamics or significant changes on the organizational level often lead to situations of uncertainty on the project level.
Technology as a source of project uncertainties
Even well-developed technical specifications can fall victim to unknown-unknowns. The innovative nature of projects is inevitably related to technical uncertainties that could not be anticipated during the planning stage. Another category we can identify is related to uncertainties caused by technical specifications that were too tight (see Table 6).
Table 6: Uncertainties Related to Technology
| Uncertainty Sources | Cases |
| Technical issues | Case 16, Case 19, Case 20, Case 34, Case 41 |
| Tight technical specifications | Case 12, Case 13, Case 18 |
Case 19 is a typical example of uncertainties related to technical issues occurring during the implementation of a project.
Case 12 is a good example of how technical specifications that are too tight could cause uncertainty. In that case, the strict specifications led to unsolvable technical problems. This category seems to be underrepresented in our sample of 41 cases. But considering that the sample covers many different project types, it occurs relatively frequently. Not surprisingly, technical causes for uncertainties are more often related to high-tech or technically complex projects.
Uncertainties related to technical issues and tight specifications are associated with complex and/or innovative technical projects.
Table 7: Uncertainties Related to Contextual Turbulence
| Uncertainty Sources | Cases |
| External legal context | Case 04, Case 06, Case 13 |
| External market context (dynamic) | Case 04, Case 15, Case 24, Case 41 |
Contextual turbulence as a source of project uncertainties
Projects are often undertaken within a complex and dynamic context, leading to uncertainties and making it necessary to change initial plans. We identified contextual turbulence as a source of uncertainty in six cases and classified them as belonging in either the external legal context or the external market context (see Table 7).
In the following case (Case 06) regulatory changes directly affected the technical requirements of the project. It is a good example of how regulatory and legal changes could significantly influence the implementation of a project.
This case mainly represents longer-term projects that are closely tied to legal regulations. The unexpected change of specific legal regulations could lead to situations of uncertainty on the project level. Projects within other highly regulated industries, such as banking or pharmaceuticals, are prone to these situations as well.
Another external source for uncertainties is market dynamics, as represented by Case 41.
In this case, the dynamics of a highly competitive market had a direct impact on the product and its market positioning, with significant financial consequences for the project. Since the competition was delivering these premium services for free, the company could not charge for their premium fee-based service any more. It was necessary for the project team to lower the expense of developing the product, in order to remain competitive. For example, they replaced the external vendor with an internal one for some components of the project after the first year.
Project task characteristics as a source of project uncertainties
Project task characteristics are often cited in the project management literature as a major source of uncertainty, and they could create an ambiguous environment for project teams. The projects under investigation provided only two examples of uncertainties related to task characteristics. In both cases the task complexity was unknown or significantly underestimated at the beginning of the projects.
Malmanagement as a source of project uncertainties
One of the most surprising outcomes of this study was an unexpected level of malmanagement. We define malmanagement as bad practice, or the lack of project management standards. Many projects, particularly large projects within large organizations, are still managed without following the fundamental standards of project management. We identified instances where the absence of project management standards or lack of adherence to them created an environment of uncertainty (see Table 8); these situations were categorized as malmanagement.
Table 8: Identified Categories of Malmanagement
| Categories of Malmanagement | Cases |
| Self-induced uncertainty | Case 08, Case 12 |
| False assumptions about project complexity | Case 18 |
| False assumptions about users' needs | Case 35 |
For example, in Case 08 the lack of data surrounding the company's instrument problems was the result of the absence of a continuous tracking mechanism to document technical problems. In this case it was poor management on the organizational level that failed to track and provide necessary data. This created a lengthy and more costly root cause analysis process. Field data about the technical defects had to be gathered first in order to solve the technical defects of the medical instruments with a new device design.
Case 18 and Case 35 are two other examples of malmanagement in projects. In Case 18, the CEO of the subcontractor company viewed the project as strategically significant and the contract was signed from a business, and not a technical, perspective. The management team with overly optimistic assumptions signed for “tight specifications,” which could not be achieved later and caused nine months of delay. In Case 35, the wrong assumptions about users' needs brought uncertainty to the scope of the project. The project team did not conduct a gap analysis to define the users' needs. As a result, scope was extended later, in the midst of project implementation. The project originally was scoped to develop a certification exam, but industry standard was advised later and training was found to be necessary.
The Nature of Exploited Project Value Opportunities
The study of opportunities and whether they are identified during the implementation of projects revealed a surprising plethora of recognized and exploited opportunities. Not all projects were related to opportunities. The results show that opportunities were identified and exploited in 21 projects. The problems are related to a lack of misclassified opportunities. Some interviewees reported opportunities that were more or less marginal improvements for the project outcomes and not really opportunities.
Opportunities have many different characteristics, but all represent a potential for significant increase in value to a project. Basically, when exploited, they can lead to a redefinition of a project's initial baseline. They represent various means for adding value to a project, such as implementing new technologies or processes, or identifying new projects for the future. In our case sample we could identify four distinct opportunity categories (see Table 9).
Table 9: Nature of Identified Opportunities
| Opportunity Category | Opportunities | Frequencies |
| Project & organizational business | Multiplier, identified new opportunities of original solution | 9 |
| Implementation process | Monitoring, process improvement, outsourcing, versioning | 8 |
| Future business | Project life cycle opportunity, beyond project | 5 |
| Technical invention | Remote access capability, testing solution | 3 |
The majority of identified and exploited opportunities are related to the business purpose of the project outputs. Either they lead directly to business results, or they are the basis for future business. There are also process-related opportunities leading to further improvements of management procedures like outsourcing under specific conditions. Technical invention was the category identified least often.
Project and organizational business opportunity
This category of opportunities is related to changes in a project's business perspective and to a new business opportunity that was recognized during project implementation, leading to significant project changes to enable their exploitation (see Table 10).
Case 01 is a representation of an opportunity that changed the focus of the initial project. The new solution defined a more general solution for a wider group of stakeholders. The business perspective led to a change in the original project scope in Case 11. The systems integration was essential for the organization and it could be seen as a project-related opportunity that was identified by considering a systems perspective across the organization. The project opportunity in Case 28 occurred during a merger of two banks. One bank was developing a backup site, and the other bank had a non-activated backup site. The merger created uncertainty that led to the opportunity to unite the two independently planned projects, thus eliminating the need for reconciliation between the two originally planned systems. This allowed for a decrease in the project budget and ongoing maintenance costs.
Implementation process opportunity
This category of opportunities is related to innovative management processes developed during the implementation of a project. These processes were recognized and exploited as opportunities by developing explicit standards for future projects. These processes cover a variety of applications (see Table 11).
The following cases are examples of opportunities to improve the standards and processes for implementing projects.
Future business opportunity
In several cases business opportunities were identified and exploited that created value for the organization beyond the implementation phase of a project, or further beyond the implemented project itself (see Table 12).
The following case (06) represents a project lifecycle opportunity and the two other cases (08, 16) are interesting representatives for opportunities that were identified and exploited beyond the project.
Technical invention opportunity
Opportunities in this category are related to technical inventions that were originally planned at the start of the project (see Table 13). Surprisingly, we could not identify many opportunities that are technology based. This could be related to the fact that projects of technological nature require many decisions before implementation.
In Case 06, a new testing procedure was invented that saved significant portions of the project's budget.
This opportunity demonstrates a technological invention with significant impact on the project's budget.
The Discovery and Exploitation of Opportunities
In our conceptual discussion, we relied on economic theory and proposed that situations of uncertainty are related to opportunities. In this section we analyze the relationship between situations of uncertainty and opportunities. Not every situation of uncertainty leads automatically to an opportunity. The identification of opportunities is not self-evident. It is a highly creative process that takes place in the midst of an uncertain situation and is accompanied by deadline and time pressure. However, the process does not end with the creation and identification of opportunities; it ultimately ends instead with their exploitation. This is not self-evident either, since the exploitation of opportunities requires significant project changes. The main question is whether or not identified opportunities are exploited.
In our interviews we asked the project managers to describe two situations of uncertainty and two identified opportunities. Through reviewing the perceived uncertainties and opportunities, we summarized the number of identified opportunities in Table 14. A single opportunity was identified in 14 projects (34%). We also found that multiple opportunities were identified in only 7 (17%) projects. The more surprising result of our case analysis is that for 19 projects (46%) we could identify at least one misperceived opportunity, and in 4 projects one opportunity was identified and one was misperceived. In 4 projects (10%) no opportunity was identified at all, indicating that the recognition of opportunities is a more common process than we expected.
Table 14: Frequencies of Identified Opportunities
| Number of Opportunities per Project | Frequencies | Percentage |
| One opportunity identified and exploited | 14 | 34% |
| Two opportunities identified and exploited | 7 | 17% |
| Opportunities identified but not exploited | 2 | 5% |
| No opportunity identified | 4 | 10% |
| Misperceived opportunities | 19 | 46% |
In addition, in 4 cases (Case 01, Case 06, Case 21, and Case 41), the project managers said they identified opportunities but did not exploit them. The reasons for unexploited opportunities are various. For example, in Case 01 the team saw an opportunity to develop a mobile detection system that was truck-based and boat-based, as well as linked to a centralized database. Although this system would have addressed a need to identify hazardous materials, the opportunity could not be handed off to the owner because they were not charted to have mobile capability. In Case 06, upgrading the multiplexor unit of the locomotive from a DVD format to a more advanced format was requested by the customers. But the manufacturing company persuaded the customers to forego that option, since it was more expensive and would have caused schedule delays.
The frequencies in Table 14 demonstrate that opportunities are often identified during the implementation of a project. The cases also indicate that once an opportunity is identified the possibility is high that it will be exploited. The results of our cross-case analysis show that identifying opportunities is neither easy nor natural. We asked the project managers if more opportunities were identified, but none reported situations of more than two exploited opportunities for a single project. It is also interesting to note that only very few identified opportunities are rejected.
Table 15: Stakeholders Discovering Value Opportunities
| Stakeholders | Frequencies |
| Project manager | 14 |
| Board of directors | 3 |
| Project sponsor | 3 |
| Project steering committee | 1 |
The Nature of Stakeholders Discovering Value Opportunities
In this section we analyze the question of who is involved in the discovery and recognition of value opportunities. We identified several different stakeholder groups who discovered them (see Table 15).
Project managers are the stakeholders who most frequently discover value opportunities during project implementation. Among the 41 cases, we identified 14 cases in which project managers identified and exploited value opportunities (see Table 16). The following cases are representative examples:
Table 16: Project Managers Discovering Value Opportunities
| Stakeholders | Case Numbers |
| Project manager | Case 01, Case 08, Case 10, Case 11, Case 12, Case 15, Case 16, Case 20, Case 24, Case 27, Case 28, Case 30, Case 31, Case 32 |
The following three cases (01, 10, 28) are good examples of value opportunities that were identified by project managers.
Other stakeholder groups are occasionally involved in the identification of value opportunities (see Table 17). All groups are directly or indirectly representing the interests and perspectives of the project owners or sponsors. These groups have a business perspective on projects, in contrast with the mainly technical view on the project level.
The following cases demonstrate the role of the board of directors (Case 06, 35) and the project sponsors (Case 13, 23, 39) in identifying opportunities. Both represent more or less the strategic business perspective of an organization, and it is not surprising that value opportunities are discovered by these two groups.
Table 17: Other Stakeholder Groups Discovering Value Opportunities
| Stakeholders | Case Numbers |
| Board of directors | Case 06, Case 09, Case 35 |
| Project sponsor | Case 13, Case 23, Case 39 |
| Project steering committee | Case 19 |
Only in one instance, Case 19, was a project steering committee involved in identifying the value opportunity in the project.
Most opportunities were discovered by project managers. We did not directly ask for information about the role of the project teams or the clients/customers in the opportunity discovery process. This would have required additional interviews with the team members and clients, which was beyond the scope of this study.
Value Effects of Opportunities
The cases described so far have demonstrated that opportunities exist during the implementation of projects. Those opportunities are created or discovered by project managers and other stakeholders of the project, and most of them are exploited. The remaining question is: Why is it important to seek opportunities and go through the stress to exploit them? In the interviews for the study, we asked the project managers which project value aspects were affected by the exploited opportunities (see Table 18).
Table 18: Value Effects of Opportunities
| Value Aspects | Frequencies | Percentage |
| Stakeholder satisfaction | 17 | 81% |
| Owner satisfaction | 15 | 71% |
| Financial returns | 13 | 62% |
| Schedule | 13 | 62% |
| Quality (performance) | 12 | 57% |
| Budget | 11 | 52% |
| Outcome (specs) | 10 | 48% |
| Quality (grade) | 8 | 38% |
| Non-financial benefits | 6 | 29% |
| Others | 4 | 19% |
The frequencies in Table 18 are related to the 21 cases of identified opportunities. The results clearly demonstrate that the exploitation of opportunities generally pays off. The impact of opportunities on the realized value of a project is wide and deep. All exploited opportunities had an impact on multiple aspects of project value. Schedule, budget, quality, financial returns, non-financial returns, stakeholder satisfaction, and shareholder satisfaction are all potential benefactors of exploited opportunities in situations of uncertainty. The value embedded in these opportunities is particularly critical in business environments. Looking across all value areas, we can see that the main management attention is focused on improving the level of stakeholder and shareholder satisfaction. Stakeholders are mainly represented by clients or customers, and the shareholders are represented by the project owners. Including improvements of financial returns, the three goals represent the business perspective of a project. But opportunities are also related to improving the classical triple constraint objectives like budget, schedule, and scope (outcomes or specs). In some cases, the quality of the output was significantly improved. Non-financial benefits were related to improved reputation.
The category “Others” in Table 18 reflects those value aspects which go beyond the specified values. For example, in Case 12 (Project Mission: Design and develop electronic components for an aerospace system application) the exploited opportunity was to outsource the engineering design work to consultants resulting in reduced multitasking of the internal engineers leading to an increased throughput within the organization. In Case 19 (Project Mission: A new climate control residential product development project), the newly identified unique component fully meets the end-user's requirement and can be delivered faster. The company could gain market share and deliver fully compliant product because of the new component, which its competitors could not easily match.
Table 19: Types of Misperceptions
| Types of Misperceptions | Frequencies | Percentage |
| Project complexity | 13 | 32% |
| Project uncertainty | 14 | 34% |
| Misperceived opportunity | 19 | 46% |
Misperceptions
The most surprising outcomes of this study were the project managers' perceptions of uncertainty, opportunity, and project characteristics (see Table 19). The misperceptions demonstrate that, in particular, the concept of risk and uncertainty is not well defined or understood. Project managers often identified situations of risk as uncertainty.
Misperceptions of project complexity
One of the questions raised in the project management literature is whether uncertainty is a synonym of complexity. In our research project, project managers were asked to evaluate their projects and describe them on a continuum as either very complex or relatively simple. While misperception occurs in both directions, the instances of the overestimation of complexity are far more frequent than cases where complex projects are considered to be less so (see Table 20).
Table 20: Misperceived Project Complexities
| Complexity Misperceptions | Case Number | Percentage |
| Perceived higher than actual complexity | Case 04, Case 06, Case 08, Case 09, Case 10, Case 20, Case 22, Case 24, Case 25, Case 27, Case 32 | 27% (11) |
| Case 12, Case 30 | 5% (2) |
For this study, we considered a project to be highly complex when it involved multiple interacting technologies and/or multiple internal and external stakeholders. For example, a project may have technical uncertainty because of a high number of work packages that require a large number of resources, because it is being executed in different countries, or because it involves numerous internal and external stakeholders. However, many times we found that although the project managers claimed the complexity of their projects was high, their projects turned out to be repetitive or complicated, but not complex in the way defined above. The following cases (04, 22) are good examples of this type of misperception.
Project complexities are only occasionally underestimated. We identified only two project managers (Cases 12, 30) who underestimated the complexity of their projects.
Complexity is often seen as a source of project uncertainties. The cases demonstrate that the concept of complexity is far from clear and leads to misunderstandings.
Table 21: Misperceived Project Uncertainties
| Misperceptions | Case Number | Percentage |
| Risk perceived as uncertainty | Case 05, Case 07, Case 11, Case 12, Case 14, Case 15, Case 21, Case 24, Case 25, Case 29, Case 36, Case 38, Case 42 | 32% (13) |
| Uncertainty perceived as risk | Case 23 | 2% (1) |
Misperceptions of project uncertainties
Using our definitions, unknown-unknowns are uncertainties, but known-unknowns are risks. In 14 of the cases in our study project managers confused these two different concepts and typically mistook risks as uncertainties. This is an important issue, since we proposed that opportunities are linked to uncertainties. Project managers who misperceived a situation of risk as uncertainty might also likely misperceive the concept of opportunity (see Table 21).
The following three cases (11, 25, 28) are typical examples of risks that were classified as uncertainties. The opposite case, where a situation of uncertainty was classified as risk, is rare but, as Case 23 demonstrates, could also occur.
Misperceptions of opportunities
Several opportunities reported by the interviewees were determined in our case analyses to be misperceptions (see Table 22). The high frequency of misperceptions demonstrates that the concept of opportunity is not well understood.
Table 22: Misperceived Project Opportunities
| Misperceptions | Case Number | Percentage of All Projects |
| Project as an opportunity | Case 18, Case 42 | 5% (2) |
| Self-evident opportunity | Case 03 | 2% (1) |
| No opportunity | Case 04, Case 05, Case 07, Case 17, Case 20, Case 21, Case 22, Case 24, Case 25, Case 26, Case 30, Case 33, Case 34, Case 36, Case 37, Case 40 | 39% (16) |
We identified three categories of misperceived opportunities, which are discussed below.
1. Project as an opportunity: For this category, interviewees viewed the project itself as the opportunity. However, this is a decision that is made before the project is initiated. In general it could be assumed that organizations only engage in those projects that promise a certain return on investment. Therefore, every funded project represents an opportunity, and the decision takes place before the implementation phase of a project, at the senior level of an organization. The following cases (18, 42) are good representatives of this source of misperceptions.
2. Self-evident opportunity: The second category of misperceived opportunities is related to obvious improvements over existing or planned solutions. We call this category of misperceptions self-evident opportunity, as represented by Case 03. There is no search process involved and significant project changes are not necessary. These improvements could be handled within the predefined constraints.
The case of self-evident opportunities seems to be very rare. In this case, improvements were offered by externalities. The alternatives to the original solutions were obviously better than the original solutions. In this case there was no need for the project team to search for opportunities, and there was no other choice or alternative. Changes were made within the given constraints.
3. No opportunity: The third category describes situations that actually were not opportunities because they did not lead to significant value improvements‘ of a project. The misperception is related to misunderstood stakeholder needs. Adding more to a project does not necessarily lead to a higher level of stakeholder satisfaction, as demonstrated in Case 07. Additional performance features in this case do not lead to an improved value proposition for the stakeholders, and only cause delays and increased project budgets.
Relationships between misperceived uncertainties and opportunities
In this section we analyze whether relationships between misperceived uncertainties and opportunities could be identified by comparing them on a case-by-case basis (see Table 23).
Table 23: Misperceived Uncertainties or Misperceived Opportunities
| Case Number | Misperceived Uncertainty | Misperceived Opportunity |
| Case 03 | Self-evident opportunity: Hiring external consultants | |
| Case 04 | Updating their existing old and outdated applications to newer technology | |
| Case 05 | Outcome | Routine opportunities |
| Case 07 | Boating Access Grant: no uncertainty | Increasing the number of features: Adding a playground |
| Case 11 | Insufficient resources from the vendor | |
| Case 12 | Inability of external consultants | |
| Case 14 | Market volatility | |
| Case 15 | Data migration | |
| Case 17 | Moving enhancement requests of the project forward via the program release process | |
| Case 18 | Project as a strategic opportunity | |
| Case 20 | Increasing the memory and cleaning up periodically to avoid shutdowns | |
| Case 21 | Resistance and hostility from the chemists | The company focus changing from cheap labor to improve workforce conditions |
| Case 22 | Accounting entry coming from the global level | |
| Case 24 | Lots of turnover | Changing management process |
| Case 25 | Scope of rules applied to each business unit | Diminishing the risk (value of the project) |
| Case 26 | Getting more education from vendors | |
| Case 29 | Unknown parameters for the software to meet the business needs | |
| Case 30 | Hardware upgrades | |
| Case 33 | A new coding practice to support the migration | |
| Case 34 | Getting the application to work | |
| Case 36 | A medication assumed to treat an existing therapeutic indicator | Gaining approval of a new therapeutic indicator |
| Case 37 | Gaining secure transactions | |
| Case 38 | Not receiving funding approval for vendor work | |
| Case 40 | Negotiation to define an agreement acceptable to the parties in conflict | |
| Case 42 | Economic crisis | Project as a feasibility study |
The comparisons do not indicate a strong relationship between misperceptions of uncertainties and opportunities. The evaluation of both is independent and one misperception does not necessarily lead to the other. We identified only eight cases where both uncertainty and opportunity were misperceived. In six cases a misperceived situation of uncertainty is not linked to a misperceived opportunity. In 12 cases opportunities were misperceived even though situations of uncertainties either did not exist or were correctly classified. This result also indicates that the concept of opportunity during the implementation of a project is even more difficult to grasp.