A structured process for the fuzzy front-end of complex projects

Abstract

The front-end stage of projects, which covers the period from inception through to project approval, is not well understood in the literature and is considered ‘fuzzy’. Therefore, the objective of this paper is to develop a structured process for the project front-end stage of complex projects. In this study, the rigorous and protracted front-end process followed by Australian Defence acquisition and development projects is analysed. Findings propose a front-end process that consists of the following four steps: (1) project trigger identification, (2) project idea generation, (3) business case development, and (4) business case appraisal. We further detail the activities included in each step and propose practical implications for operations managers and the organisation. By structuring the front-end process, our research contributes to the operations management literature by clarifying roles, responsibilities, and activities in the management of the front-end of complex projects and their alignment with the operations’ environment.

Keywords:

• Project
• front-end
• operations performance
• project initiation

1. Introduction

Organisations increasingly invest in projects to enhance operations performance (Zwikael and Meredith 2018). Examples of such projects include the introduction of a new manufacturing line and re-engineering the supply chain network. However, these projects are becoming more complex, as they: increasingly rely on distributed and networked teams (Ojiako et al. 2023); need to coordinate under time pressure (Ju and Ning 2023); are often conducted by multiple organisations (Klakegg, Williams, and Shiferaw 2016; Liedtka and Locatelli 2023); commonly have more diverse team members, higher technology risks, ambiguous scope, an unreliable supply chain, and more external stakeholders (Haaskjold, Andersen, and Langlo 2023).

The front-end stage of these complex projects is considered most important (Klakegg, Williams, and Shiferaw 2016; McDonald 2017). During this stage, managers select the best potential project from various proposals, define the project goals and scope, and ensure the project’s alignment and effective coordination with the operations environment (Zwikael and Smyrk 2019). The front-end is concluded when the project is funded and focus shifts to delivering the expected outputs (Williams et al. 2019).

The front-end shapes the project and, if done well, reduces its risk level and enhances its likelihood of success (Chenger and Woiceshyn 2021; Edkins et al. 2013; Kolltveit, Karlsen, and Grønhaug 2004; Morris 2013; Pinto and Winch 2016; Testorelli, Ferreira de Araújo Lima, and Verbano 2022). Conversely, an ineffective front-end process may end with unclear goals and scope and contribute to a poor project selection decision. As a result, Samset and Volden (2016, 301) argue project failure can often be ‘traced back to decisions in the earliest stages, when the initial idea was conceived and developed’.

Yet, following a systematic literature review on the front-end of projects, Williams et al. (2019, 1137) concludes that despite the front-end being critical for project success, it is still ‘not well understand’. More specifically, there is no agreement in the literature as to what constitutes an effective front-end process (Edkins et al. 2013). This may be a result of the literature focusing for many years on the planning and execution stages of projects, while overlooking the front-end stage. For example, there has been much emphasis on project contracting and planning, but less on the process of making a quality decision regarding which projects to fund (Mitchell 2018; Xiong et al. 2022).

This lack of clarity regarding the project front-end stage creates a significant research gap. This research gap is important because it raises ambiguity in processes, roles, accountabilities, and decision-making that have the potential to hinder project and operations performance. It is important that operations managers better utilise their role in steering the front-end of projects before the responsibility temporarily transfers to a project manager for delivering its outputs. In particular, a clear front-end process can help managers in the operations environment to generate effective project ideas to resolve critical operations problems, set effective project goals, and develop a high-quality business case to enhance project investment decision making. Following this research gap and the growing importance of effective management of the project front-end stage in operations management research and practice, we raise the following research question: How can the front-end stage in complex projects be improved?

Our research aims to reduce the ‘fuzziness’ of the front-end stage by identifying delineated and structured steps to support existing processes (Alimadadi 2022; Chenger and Woiceshyn 2021). This aim is supported by the fact that the literature has found multiple advantages for a structured process. For example, a structured front-end process of complex projects can assist managers to overcome ‘bounded rationality’ whereby their capacity to operate within and make sense out of the environment is limited (March and Simon 1958). Further, a structured process can help in better navigating the organisational environment as the repetitive, administrative components of the decision are completed for them, leaving them free to use their cognitive capacity to focus on the unknown elements of the decision. The purpose of organisational formal processes ‘is not to micromanage and control’ but to foster learning and innovation, and ‘provide the conditions and resources to enable project effectiveness’ (Kenny 2003, 53). Finally, in the context of the project front-end stage, a longitudinal study found formal organisational processes have a positive impact on the setting of project goals (Zwikael and Meredith 2019). However, there are also disadvantages of a structured organisational process, such as it impedes innovations and increases duration and cost (Christensen 2013; Reilly and Tushman 2004).

As knowledge on the project front-end is led by practice, where literature is lagging behind, we study the front-end process of complex Defence acquisition and development projects. These Defence processes are rigorous, protracted and outperform similar-size private sector processes (Cook and Unewisse 2020). Through an in-depth document analysis and an illustrative case, we develop a structured process for the fuzzy front-end stage of complex projects. We contribute to the Operations Management literature by extending our knowledge of the front-end process from best practice. We next review the literature on the front-end of complex projects, before discussing our methodology. We then present our findings and conclude with a discussion of their theoretical and practical implications for operations managers.

2. Literature review

This section analyzes the project front-end literature. For this purpose, we used the Scopus database to analyse the literature, using the keywords ‘front-end’ or ‘initiation’ (as these are the two terms most commonly used interchangeably), and ‘project management’. The search for our keywords was constrained to the articles’ title, abstract or keywords only for articles published from 2009. We did not limit the search to journals from a particular discipline, to allow us to capture diverse views from different literatures, e.g. operations management, strategy management, project management, innovation, and Defence. The articles returned through the search were then carefully examined to identify the most relevant ones to be included in the literature review based on their focus on effective front-end processes in complex projects. Using this approach, we reduced the number of articles from 183 to 32 key references.

2.1. The front-end of complex projects

Projects have become a major part of organisational activity to enhance operations performance (Hall, Kutsch, and Partington 2012; Zwikael et al. 2022). However, projects have also become increasingly complex to manage, as they are long in duration and are often conducted by multiple organisations (Klakegg, Williams, and Shiferaw 2016). Further, Patanakul et al. (2016) analysed the main reasons for the high complexity of government projects and found: (1) they pursue non-financial target goals, (2) they have a long product service life, (3) they deal with multiple stakeholders, (4) they are large in size, (5) they are susceptible to the political environment and dynamics, and (6) they follow a mandated project management process.

The front-end stage of complex projects aims to support an informed investment decision made by the organisation, where a project business case is developed and evaluated before funding for a new project is either granted or rejected. Therefore, the costs associated with the front-end stage are mainly transaction costs, as they are the result of planning the project, rather than the activities related to producing the deliverables from the project (Haaskjold, Andersen, and Langlo 2023).

As quality decision-making regarding the selection of a project for funding is a strategic outcome of the front-end process, we follow the well-known decision-making process developed by Mintzberg, Raisinghani, and Theoret (1976) that consists of three steps: (1) Opportunity/problem identification, (2) Solution development, and (3) Selection. In Table 1 we tailor these three decision-making steps to the context of the project front-end stage (e.g. Williams et al. 2019; Zwikael and Smyrk 2019).

Table 1. Project front-end steps.

Decision-making steps	Project front-end steps	Description	Key activities
1. Opportunity/problem identification	1. Project trigger identification	The identification of a problem or opportunity.	Trigger identification Trigger confirmation
	2. Project idea generation	The generation of an idea to respond to a project trigger.	Idea definition Idea assessment Idea prioritisation Project idea conceptual approval
2. Solution development	3. Business case development	The development of a project business case.	Definition Analysis Packaging
3. Selection	4. Business case appraisal	Decision-making regarding the proposed business case.	Business case presentation and assessment Project funding approval Next steps decided

Our analysis in Table 1 shows that these three decision-making steps can be tailored into the project front-end decision steps proposed in the project management literature. We conclude that as the main objective of the project front-end stage is to make a quality investment decision, this stage could consist of the following four high-level steps: (1) Project trigger identification, where the problem or opportunity that triggers the project is identified, (2) Project idea generation, where the idea to respond to the project trigger is generated, (3) Business case development, where a project business case is developed and packaged for submission and/or presentation to secure approval and funding, and (4) Business case appraisal, where the project is approved and the responsibility for its execution is moved from the operations manager to the project manager. These steps will be discussed in detail next.

2.2. The structure of the front-end of complex projects

Below, we provide a detailed literature analysis of each of the four project front-end steps identified in Table 1: (1) Project trigger identification; (2) Project idea generation; (3) Business case development, and (4) Business case appraisal.

2.2.1. Step 1 – Project trigger identification

New projects are triggered by either a problem, such as low customer satisfaction, or an opportunity, such as a new technology (Williams et al. 2019). We have named this first step ‘project trigger identification’. According to Williams and Samset (2010), the project trigger should align with the organisation’s strategy. This supports Kock, Heising, and Gemünden (2015) who noted poor alignment between a project and an organisation’s strategy is associated with poor project outcomes. Although Zwikael and Smyrk (2019) note that it is important for a project to be in alignment with organisational strategy, not every project that an organisation chooses to fund will arise from their strategic vision, e.g. a project initiated only to comply with a new industry regulation.

When the trigger for a project and the desired effects are known, it is easier to produce and rank a selection of project ideas, assess alignment between project goals and the organisation’s objectives, and determine the project’s expected value, defined as the ‘net worth of a project to its funding organization and its key stakeholders’ (Zwikael and Huemann 2023, 2). Although Hill, Schilling, and Jones (2019) discuss internal and external strategic analysis of the organisation’s operating environment, the literature does not detail how an organisation can effectively identify project triggers. According to Chenger and Woiceshyn (2021) this may be because to identify high-risk and high-reward opportunities, the unknown and highly uncertain needs should be explored. Another reason for this gap in the literature may be the lack of understanding of the implications of an imposed project that is not in alignment with the organisation’s strategy.

2.2.2. Step 2 – Project idea generation

The concept of ‘ideation’ (Kock, Heising, and Gemünden 2015) refers to the managerial practices that support the generation of valuable and relevant projects. Triggering excellent project ideas is especially critical in a complex environment as such ideas can enhance the quality of business cases, their evaluation, likelihood of being accepted, and impact on the organisation (Zwikael and Huemann 2023). A project idea can emerge ‘from many different quarters such as a prospective funder, a business unit manager, a services department, an employee, an external consultant or even a supplier’ (Zwikael and Smyrk 2019, p.194). Knowledge of this important front-end step is lacking in the project management and new product development literatures (Joachim and Spieth 2020; Kock, Heising, and Gemünden 2015; Pinto and Winch 2016). It is necessary to understand the project idea generation process because it has been linked to project failure and initial project ideas have a tendency to persist through the front-end stage irrespective of how poorly conceived they may be (Edkins et al. 2013; Kock, Heising, and Gemünden 2015; Samset and Volden 2016). Finally, this knowledge can help situate the project in its wider context through an understanding of how the project came to be (Pinto and Winch 2016).

Another reason that an effective project idea generation step is valuable is the tendency for poor project ideas to receive funding. Sleesman et al. (2012) found escalation of commitment to a losing course of action (such as continued investment in a poor project idea) may occur for several reasons including: project-related reasons, such as opportunity cost; psychological reasons, such as ego threats; social reasons, such as resistance to other’s decisions; and, structural reasons, such as agency problems. As a result, this step raises new ideas for totally different projects. For example, to achieve the outcome of reduced number of car accidents, different projects ideas such as a tunnel, bridge, a traffic light system, and a safety education campaign can be raised.

2.2.3. Step 3 – Business case development

The third step is where the business case (aka a project proposal) is being developed. Project funders use the business case to assess whether a project is worth the investment and the risk (Zwikael and Meredith 2019). The business case should align to the organisation’s strategy and objectives (Einhorn, Meredith, and Marnewick 2022, 38). It contains information about the expected project deliverables, duration, cost, risks, governance, and benefits. According to Zwikael and Meredith (2018) when setting project benefits in the business case they should have three characteristics: Specificity, e.g. a specific target value; Attainability, e.g. the organisation has the capacity to realise them; and, Comprehensiveness, e.g. they reflect the views of key stakeholders.

2.2.4. Step 4 – Business case appraisal

‘Business case appraisal’ is the last step in the project front-end. When the business case is complete it is given to the potential project funder who considers it and either (1) accepts it and funds the project, (2) returns the business case for further work and resubmission, or (3) rejects the business case. When reviewing a business case, the project funder considers whether the trade-off between risk and return is acceptable, and how the project compares with other project proposals also seeking funding (Zwikael and Smyrk 2019). Williams et al. (2019) suggest that while trying to avoid ‘analysis paralysis’, there is a set of analyses and quality assurance activities project funders can engage in before making a final decision regarding the business case. These activities include: (1) Scenario analysis and planning, (2) Real option analysis, (3) Feasibility study, and (4) Concept analysis. Finally, an analysis of the organisation’s internal and external operating environment (Hill, Schilling, and Jones 2019) can also be used to evaluate the businesses case.

3. Methods

3.1. Research design

We study the project front-end using qualitative methods. Qualitative methods are particularly appropriate when investigating a research topic, which is relatively new and/or not well understood. We adopt a critical realism ontological perspective whereby an entity can be studied indirectly through the impact it has on other variables rather than being observed directly (Danermark et al. 2002; Fleetwood 2005). Other researchers have investigated the front-end stage using various qualitative approaches, such as interviews, literature reviews and cases studies (Edkins et al. 2013; Samset and Volden 2016; Williams et al. 2019). This paper uses a different qualitative approach, where we study the front-end process using document and content analysis (Bowen 2009). This research design triangulates previous studies and provides rich empirical and reliable data.

3.2. Data collection and analysis

To develop a comprehensive understanding of this complex phenomena, we collected data on the detailed front-end process of complex acquisition and development projects in the Australian government’s Department of Defence (Defence thereafter). We selected Defence acquisition and development projects because they are particularly large and complex, and delivered in a sophisticated project environment. We studied the Defence front-end stage by analysing documents published on the Defence website and suggested to us by Defence members who specialise in this area. Specifically, we examined the following documentation: The First Principles Review (Department of Defence 2015), Annual Report 16-17 (Department of Defence 2017), Risk Management Framework (Department of Defence 2019), Capability Lifecycle Manual (Department of Defence (Australia)), 2020a), Defence Strategic Update (Department of Defence (Australia)) 2020b), ID Risk Glossary (Department of Defence 2021a), Australian Contingency Context Scenarios (Department of Defence 2021b), and the Capability Life Cycle Management Course documents (Ryan and Soutberg 2020).

We applied content analysis to each of the documents to gather information about the steps in the front-end stage of a Defence project (Bowen 2009). Specifically, we focused on information related to the early stages of Defence capability development as it is most relevant to the project front-end stage. Each of the documents was read and, where required, the Defence language was interpreted using Defence glossaries, which were included in a number of the documents. The information contained in the documents was then organised into categories relating to each of the distinct steps in the lifecycle of a Defence capability. The categories and the linkages between them then formed the basis for this research. We then used a hypothetical illustrative Defence case to present the front-end process in context. Last, the Defence front-end process was compared and contrasted with the four steps retrieved from the literature analysis.

4. Findings

In this section, we analyse each of the steps Defence follows during a project front-end stage. Each of the steps in the Defence front-end process is then linked to the four front-end steps we developed in Table 1.

4.1. The front-end stage a Defence project

The Defence front-end stage supports Defence’s strategic objectives, which are to ‘shape Australia’s strategic environment; to deter actions against Australia’s interests; and to respond with credible military force, when required’ (Department of Defence (Australia)) 2020b, p.1). The Capability Life Cycle (CLC) is the process used by Defence as the overall framework to link ‘strategic direction, developing concepts, defining requirements, acquisition, introduction into service, sustainment, upgrade and disposal of major capital assets (equipment, facilities and ICT)’ (Department of Defence (Australia)) 2020a, 3). There are four stages in the CLC: (1) Strategy and concepts, (2) Risk mitigation and requirements setting, (3) Acquisition, and (4) In-service and disposal. The first two stages form the Defence front-end while the third stage involves project execution, and the fourth stage involves operations. Our analysis of stages 1 and 2 indicates that the Defence front-end commences with a strategy and concepts discussion and concludes once government approval to begin the project has been received. A Defence project is defined as ‘a unique, transient endeavor, undertaken to achieve planned objectives’ (Department of Defence (Australia)) 2020a, A-7).

A large Defence project must be approved in three different gates (two gates for smaller project): Gate 0 occurs at the end of the first ‘Strategy and concepts’ stage for Defence Investment Committee approval; Gate 1 occurs in the middle of the second ‘Risk mitigation and requirements setting’ stage for government consideration and guidance (not required for smaller projects); and Gate 2 occurs at the end of the second CLC stage for government approval. If a project exceeds $20 million, it must receive approval from the government to proceed.

The first two stages of the CLC (the front-end of a Defence project) consist of 11 interdependent steps: (1) Identify change, (2) Qualify risk, (3) Prioritise risk, (4) Develop options, (5) Test options, (6) Identify offsets, (7) Test portfolio options, (8) SMART buyer framework, (9) Contestability framework, (10) Risk mitigation and requirements setting, and (11) Additional risk mitigation and requirements setting. The project management literature refers to the Defence term ‘options’ as ‘ideas’ or ‘alternatives’. The first nine steps make up the ‘Strategy and Concepts’ stage of the CLC (stage 1) while steps 10 and 11 constitute the ‘Risk mitigation and requirements setting’ stage of the CLC (stage 2).

Next, we present a summary of the 11 steps included in the Defence front-end process (see Zwikael and Gilchrist 2022 for a full description of the Defence front-end process). A hypothetical case labelled the ‘Fighter Aircraft Project’ is also used in Table 2 to illustrate each step. We have reduced Defence terminology as much as possible and generalised our analysis to ensure our findings and conclusions are applicable to complex projects in the operations environment.

Table 2. The 11 front-end steps of a Defence project.

Step and label	Step description	Fighter aircraft project illustration
Step 1: Identify Change	Assess the environment to identify changes in the environment. The environment is all of the internal and external input to Government such as new technology, changes to strategic direction and threats.	An intelligence report has identified a significant threat involving the construction of a military aircraft in another country. This aircraft will be able to exceed speeds of any aircraft owned by Defence.
Step 2: Qualify Risk	Conduct an impact assessment of the changes to evaluate the risk to Defence’s strategic objectives.	The risk posed by the foreign country’s faster fighter aircraft was assessed and categorised as ‘extremely high’.
Step 3: Prioritise Risk	Run workshops to prioritise the risks and opportunities generated in Step 2.	The risk to Defence associated with the foreign country’s fighter aircraft was prioritised as being greater than any other risk identified. A decision was made to generate new project ideas that can help mitigate this extreme risk.
Step 4: Develop Options	Perform a gap analysis to compare the current force and the future force. Obtain options from each of the Services and other groups. Select the options that best support the Joint Force. Consider costs and implications for industry.	To address the risk posed by the faster fighter aircraft, three options were proposed: Option 1 is for a new fighter aircraft that is faster than the other country’s fighter aircraft. Option 2 is for upgraded Defence missile systems, and Option 3 is for a new technology to combat the threat posed by the faster fighter aircraft.
Step 5: Test Options	Test each of the options to assess their value using war gaming and experimentation.	Option 1 was selected as it performed best during testing.
Step 6: Identify Offsets	Identify offsets within the budget that can be used to accommodate the new investment. Consider the risk to government posed by rephrasing, rescoping or divesting an existing project.	A new Defence project was identified as a candidate for restructuring and rephrasing, making funds available for the fighter aircraft project.
Step 7. Test Portfolio Options	Identify the net effect of proposed new investments offset in terms of the remaining risk resulting from the revised portfolios.	The portfolio options that included Option 1 were assessed against the remaining risk resulting from the revised portfolios.
Step 8: SMART Buyer	The Independent Assurance Review Team uses the ‘SMART buyer framework’ to identify the triggers and circumstances that led to the project. Run SMART buyer workshops with stakeholders to develop understanding of a project’s risk profile.	The SMART Buyer team provided a greater understanding of the risks and drivers involved in the fighter aircraft project and developed tailored strategies.
Step 9: Contestability	Assess whether the proposed project can be implemented as stated in the proposal and check if the risk assessments and treatment strategies are suitable, if there is evidence to support key decisions, and if costing and scheduling estimates are appropriate.	The fighter aircraft project proposal was reviewed by the Contestability Division against set criteria.
Gate 0: The various options are presented to the Defence Investment Committee. If successful, the selected portfolio receives pre-Gate 1 funding.
Step 10: Risk Mitigation and Requirements Setting	Conduct risk reduction steps which include modelling and simulation, risk reduction studies, commercial risk assessments and trade-off studies. Articulate exactly what will be acquired to provide a basis for public expense, contract requirements and confirming that what has been delivered is acceptable.	Risks include a lack of trained pilots and space for storing the fighter aircrafts. Requirements include the number of aircrafts and pilots needed to fly them, and storage and maintenance requirements. Using the risk reduction steps, the risk level was reduced.
Gate 1: The project is presented to Government. If successful, the project will receive pre-Gate 2 funding.
Step 11: Additional Risk Mitigation and Requirements Setting	Subject the proposal to additional risk mitigation and requirement setting, such as trade-off studies and commercial risk assessments.	The fighter aircraft project underwent additional requirements setting, commercial risk assessments and trade-off studies.
Gate 2: Government considers project approval. If the project receives approval, funding is provided for acquisition. Responsibility for the project is then passed to the Capability Acquisition and Sustainment Group to deliver the approved project.

4.2 A Comparison of the Defence process with the literature

This section compares the front-end process used in Defence with the literature. For this reason, in Table 3 we map the 11 Defence steps (detailed above) into the four front-end steps we identified in the literature (see Table 1). We further add a description of each step that ‘translates’ the Defence terminology into a language that is more common in the Operations Management discipline.

Table 3. The proposed front-end process for complex projects.

Literature front-end steps (See Table 1)	Defence front-end steps	Operations management front-end steps
Step 1 - Project trigger identification	1. Identify change	Identify changes in the environment. Identify changes in the operations environment and determine the impact of these changes.
	2. Qualify risk	Assess risks to the organisation. Conduct risk assessments. Develop risk and issues statements for each of the relevant identified changes.
	3. Prioritise risk	Prioritise threats and opportunities. Confirm and prioritise risks (and gains) to the operations environment.
Step 2 - Project idea generation	4. Develop options	Generate project ideas. Build options sets by adding new projects, substituting existing projects, or amending projects.
	5. Test options	Test project ideas and select a project. Confirm how project options can address risk and identify best value for money.
Step 3 - Business case development	6. Identify offsets	Identify offsets (existing projects). Identify counterbalanced strategies for new investments.
	7. Test portfolio options	Test portfolio options. Test project options in the organisational portfolio to enhance net positive impact.
	8. SMART buyer	Develop a risk mitigation plan. Conduct an independent, formal assessment of the proposed investments with key capability stakeholders and subject matter experts within an analysis and risk based decision-making framework. Identify and cost risk mitigation and requirements definition activities that are required to be conducted.
	9. Contestability	Develop the initial business case. Independently confirm the proposal aligns with strategic and resource guidance. Confirm the project will provide value for money and analyse the spend spread to make sure it is achievable and realistic.
	Defence Investment Committee Decision (Gate 0)	An assessment (e.g. internal, independent, quality assurance or an audit) before the business case is submitted for approval
	10. Risk mitigation and requirements setting	Refine the initial business case. Risk mitigation and requirements refinement are conducted to ensure the investment is fit-for-purpose and will deliver the endorsed benefits. This will ensure investments are defensible and pricing estimates are contract ready.
	Government Decision (Gate 1)	Gate 0 - Board Initial Consideration for Conceptual Approval of the Project
	11. Additional risk mitigation and requirements setting	Develop the detailed business case. Additional risk mitigation and requirement refinement steps.
Step 4 - Business case appraisal	Government Decision (Gate 2)	Gate 1 - Board Consideration for Final Approval of the Project

Our analysis in Table 3 shows that the detailed Defence process is well aligned with the front-end process identified in the literature, though it is more mature and detailed. As a result, the Defence process provides an expansion (e.g. 11 versus four steps) and enrichment of each step in the project front-end literature. For example, Step 1 in the literature calls to identify triggers for a project, whereas the Defence process clarifies how this can be better achieved through a proactive search of the external environment for changes and risks. Further, Defence suggests the project management step of business case development is managed in a portfolio approach where exiting projects are also analysed to see if their cancellation can make room for more attractive projects. The preferred projects then go through a stage-gate approach where their business case is evaluated continuously throughout the front-end process.

5. Discussion

Similar to the strategy formulation process, the front-end of a complex project also ‘commences with the identification of a stimulus for action and ends with the specific commitment to action’ (Mintzberg, Raisinghani, and Theoret 1976, 246). However, the literature on the front-end is relatively immature and the process is still considered fuzzy and poorly understood (Chenger and Woiceshyn 2021; Williams et al. 2019). Research has identified a lack of a structured framework, unclear definition of roles, responsibilities, and steps, and ineffective communication channels as major challenges facing the front-end process (Oh et al. 2016). This paper contributes to the operations management literature by mapping the front-end process of complex projects and providing guidance as to which steps could occur and when to ensure the front-end is efficient and effective.

To construct a more structured process for the complex project front-end, this research complemented the literature with lessons learned from the rigorous process of initiating Defence projects. We employed a qualitative investigation to show the front-end stage of complex projects and used an illustrative case to present our findings. Finally, we compared knowledge of the front-end project stage from the operations and project management literatures with the Defence front-end project stage.

5.1. Theoretical contribution

This research enhances the Operations Management literature by developing a comprehensive front-end process for complex projects. The proposed process (see the right-hand column in Table 3) expands each of the four front-end steps identified in the literature: (1) Project trigger identification; (2) Project idea generation, (3) Business case development, and (4) Business case appraisal. To complement these four high-level steps, based on the results of our study. This table identifies specific project activities and quality assurance gates during the front-end stage.

The proposed front-end process for complex projects contributes to the Operations Management literature as it: (1) includes two businesses cases – an initial business case and a detailed business case – rather than one as is discussed in the literature. This allows the operations manager to first test the level of interest with the project idea before resources are devoted for the major and expensive task of developing a detailed business case, (2) includes two approval gates – a conceptual approval gate (following the initial business case) and a funding approval gate (following the detailed business case). This enhanced consideration may improve decision making of approving complex projects and reduce the chance of unnecessary projects being executed, (3) provides a clear process for two front-end steps that are relatively vague in the literature - the project trigger identification process and the project idea generation process. The proposed process also enhances decision-making during the project front-end as it helps to ensure several alternative options are generated and tested, each option is linked to the project trigger, motivated by a qualitative and quantitative understanding of the risk to the operations environment, have been prioritised and their fit within an organisation’s wider project portfolio has been considered, and (4) analyzes the project front-end holistically with relation to the entire organisational portfolio. This contributes to the literature, which often analyzes the project front-end in isolation.

Further, this paper advances the Operations Management literature by identifying triggers for projects and generating effective ideas to enhance the performance of the operations environment. The existing literature states that the front-end of a project is triggered when the project funder identifies a problem or an opportunity (e.g. Zwikael and Smyrk 2019). However, how to identify the trigger is unclear in the Operations Management literature. We propose that managers first identify project triggers through an assessment of change in the operations environment. This environment consists of all internal and external inputs, such as changes in strategic direction, technology, industry, and budget, as well as threats and opportunities (Hill, Schilling, and Jones 2019). The anticipated effect can then guide the new project idea rather than the present undesired situation (Williams and Samset 2010).

The proposed process may also reduce the likelihood of cognitive factors impacting project idea generation, such as bias and political pressure (Flyvbjerg 2021) by ensuring the project trigger is well aligned with the operation’s strategic objectives and provides clear evidence of the project’s value. This could support project investment decision quality and therefore, project success and operations performance. In other words, the proposed process views the project-operations interface through the lenses of systems theory, which views an organisation like a mechanical system, where feedback loops seek to optimise performance to a desired equilibrium (Alexander, Walker, and Delabre 2022).

Finally, we propose quality assurance checks (Samset and Volden 2016), to be conducted by an independent group so linkages between the project trigger, strategic objectives and proposed project solution are clearly defined and evidence based. This may occur before the initial and detailed business cases are submitted for consideration (at Gates 0 and 1 respectively). Whereas the project owner (or champion, if the owner has not yet been appointed) is responsible to lead all the front-end steps, the project funder is the final decision-maker who then approves the business case and thus, the project funding (Zwikael and Meredith 2018). As a result, it is crucial these key senior roles possess relevant project management knowledge.

5.2. Practical implications

Not all complex projects can afford a front-end process that is as detailed, lengthy, and expensive as the one conducted by Defence projects. To allow some generalisation of the process we propose in Table 3, this section discusses how it can be further simplified and effectively implemented. Therefore, Table 4 presents several implications on how operations managers can implement the proposed model effectively in other contexts of complex projects executed in an operations environment. This table provides the front-end steps, limitations in operations practice associated with each step, and implications of the proposed front-end process for operations managers.

Table 4. Practical implications for operations managers.

Project front-end step	Limitation in practice	Implication operations managers could consider…
1. Project trigger identification	A formal framework is not commonly used to assess the impact posed by changes in the wider environment.	…developing a framework to assess the potential impact to operations of each project trigger found in the operation’s ecosystem.
	When identifying project triggers, the focus of threats and problems often outweighs the focus on opportunities.	…giving greater consideration to opportunities in the environment as potential project triggers.
	There is limited understanding of the implications posed by a project that is misaligned with the operations strategy.	…placing projects in the operation’s ecosystem so that its implications can be better understood.
2. Project idea generation	Focusing heavily on new projects during project idea generation.	…all of the project options.
	An effective project idea generation process has not been made clear.	…following the proposed process outlined in this paper when generating and testing project ideas.
	Limited project idea testing prior to business case development.	…testing the project idea and waiting for conceptual approval from the funder of the project before proceeding with the development of the business case.
3. Business case development	Evaluating a proposed project without taking the full portfolio into consideration.	…testing the effect that the proposed project may have on the current portfolio.
	Internally evaluating a proposed project without any independent assessment.	…having the proposed project independently assessed.
	Developing a business case without considering all of the necessary project inputs required for the project to run.	…the resources and inputs required for operations once the project has been completed. For example, implementing a Life Cycle Cost approach.
4. Business case appraisal	Including only one business case in the front-end stage.	…submitting multiple initial (short) business cases that can address the same problem. A conceptual approval will be given only for the best idea that will proceed to develop a more detailed business case.
	Limited quality assurance assessment of the project proposal before it is appraised.	…an independent review of the project proposal before it is submitted so the quality of the proposal can be assessed.

The proposed front-end process can also advance practice by reducing cases where the most obvious solution (which is not necessarily the best solution) is hastily selected for a project. For example, if usage is exceeding capacity, the most obvious solution is to initiate a project to increase the capacity (e.g. build a new manufacturing line). The proposed front-end process supports linkages between the trigger for the project, strategic objectives, and the approved project. Specifically, these linkages are supported by following a defined process that ensures each step of a project’s development is logically connected to the preceding ones. This ensures the solution can be directly linked to the problem and operations objectives, which will support regular assessment of its suitability as the project matures and evolves. In addition, the process also includes a step for the development of alternative project ideas. Options can then be explored by a group of experts with project management knowledge, and a firm understanding of the organisation’s project portfolio and its operations objectives, as well as the broader political and financial landscape.

6. Conclusion

Literature agrees that an effective front-end stage leads to better project selection, improved project success and enhanced operations performance (e.g. Kolltveit, Karlsen, and Grønhaug 2004; Morris 2013; Pinto and Winch 2016; Testorelli, Ferreira de Araújo Lima, and Verbano 2022; Williams et al. 2019; Zwikael and Smyrk 2019). However, the front-end stage in complex projects is still viewed as unclear or ‘fuzzy’. Therefore, little is known in the literature about the process operations managers can follow when proposing complex projects to achieve their objectives.

To address this research gap, we conducted a qualitative study into the front-end of Defence projects in the Australian government. We used an illustrative case to present our findings and compared the Defence project front-end with the literature to enhance research knowledge in this area. We presented a front-end process, as well as implications for practice when initiating complex projects.

This research contributes to operations management knowledge by detailing how an effective front-end stage can be constructed by considering the context that the complex project has been ‘idealized, validated, and shaped’ within (Pinto and Winch 2016, 238). In particular, the paper integrates the concept of ‘ideation’ - the managerial practices that support the generation of valuable and relevant ideas (Kock, Heising, and Gemünden 2015) - into the front-end stage of complex projects. Triggering excellent project ideas can then enhance the quality of business cases, their evaluation, likelihood of being accepted and contribution to the organisation. Pending validation, our research can assist with the reduction of the following: (1) uncertainty and complexity that are typically associated with the front-end stage of projects (Kolltveit, Karlsen, and Grønhaug 2004); (2) unnecessary investment of time and resources; and (3) the risk of overlooking the front-end completely and instead locking in early to a project that may not be the best project (Kolltveit, Karlsen, and Grønhaug 2004; Morgan 1987). This contribution is valuable as an effective front-end process typically enhances project success and hence operations performance (Zwikael and Meredith 2018).

Finally, limitations of this research include the generalisation of learnings from Defence projects to other types of complex projects that may not have the same amount of resources to invest in a lengthy and expensive front-end process. Whereas we acknowledge that the proposed structured process may be more attractive for large-scale projects where the front-end stage can take months, the proposed process can be tailored and simplified as required. Future research can further develop a simplified front-end process for small-scale complex projects that do not require such a comprehensive process, for example they may have only one business case and quality assurance gate rather than the two proposed in our proposed process. Our research design is limited by a reliance on document analysis as a single method of data collection. We recommend future researchers involving the front-end process also draw on additional methods of data collection to triangulate and strengthen their findings. Last, this research provides opportunities for further research integrating the front-end of projects with operations management, as well as the ‘back-end’ of projects. For example, research on project handover to operations can also enhance project implementation and the positive impact operations management can make on the operations environment.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Notes on contributors

Ofer Zwikael

Ofer Zwikael is a Professor of Project Management at the Australian National University. His five books and more than 250 scholarly peer-reviewed papers have been recognised through research awards from the Academy of Management, British Academy of Management, Project Management Institute, International Project Management Association, Emerald, and the Australian Institute of Project Management. Professor Zwikael was named by Stanford University and Elsevier to be among the top 2% of international scientists in Business and Management. His research on project benefits management has been funded by major organisations, including the Australian Department of Defence and the Project Management Institute (US). He has held leadership roles including Head of School and Associate Dean and is currently an Associate Editor for the International Journal of Project Management.

Alicia Gilchrist

Alicia Gilchrist is a Lecturer of Project Management at the Australian National University. Her research areas include social alignment, stakeholder relationships and the project front-end. Dr Gilchrist has published in leading journals, including the International Journal of Project Management and Communications of the ACM. Alicia has also held registration as a psychologist.