Inter-Organizational Integration, Transition, and Collaboration in the Project Front-End, and Project Initiation Phase

Abstract

Project management is a complex process involving different stakeholders within and outside the firm. These stakeholders involve among others, the client who has the initial need, and establishes the project requirements and boundaries; the sales teams involved in developing the initial solution and sealing the contract with the client; the project management practitioners responsible for executing the solution as per the contractual requirements; different organizational units, such as engineering, finance, supply chain, health, and safety; and other stakeholders, such as sub-suppliers, legal authorities, consultants, and funding agencies. These stakeholders have different perspectives and objectives that make project management a complex process. In this chapter the challenges, benefits, and opportunities of inter-organizational integration, transition, and collaboration within and between firms in large complex projects are explored. The scope of this chapter is on the interface between the sales front-end phase and the project initiation phase because it is in the sales front-end, where the strategic and operational direction for the rest of the project is set and agreed. A better understanding of this interface may provide opportunities for improvement in project management success.

1. Introduction

Project management has received much attention in the last several decades. This attention is largely driven by the state of project management in many firms. Many firms have reported projects that have failed due to numerous reasons, among which include at least the following—scope creep, cost overruns, schedule slippage, poor planning, lack of proper risk management, inferior quality control systems, poor procurement processes, gaps in meeting technical specifications and performance, inadequate resources, poor integration between the different stakeholders involved in the project life cycle (PLC), poor teamwork, poor communication, lack of collaboration, nonadherence to quality standards as well as other project processes, and poor monitoring and control, etc. This list is not exhaustive but gives a good overview of the complex challenges facing project practitioners.

In response to the poor state of project management, there has been much research in the area of project management with the main aim to improve project success. The research is aimed at improving the project management body of knowledge with the end result of improving project management practices and in so doing improving project success rates. While there are numerous academic journals, conferences, and books aimed at contributing to the project management body of knowledge, it is worth mentioning ref. [1], which is an exhaustive text providing a fully comprehensive methodology for managing the PLC. In the private sector, many firms have also responded with initiatives primarily aimed at reducing project failures and improving success. The internet provides many examples of such initiatives, to mention at least PM@Siemens, which is a fully comprehensive project management methodology aimed at improving project management practices within the Siemens group of companies [2].

Project Management Institute [1] sees project management consisting of five steps, namely—initiation, planning, execution, monitoring and control, and closure. Taking a systems engineering view to project management, Blanchard and Fabrycky [3] view project management as consisting of two parts, namely—the acquisition part and the utilization part. The acquisition part includes conceptual/preliminary design, detailed design and development, production, and/or construction. The utilization part consists of product use, phase-out, and disposal. Blanchard and Fabrycky [3] do include conceptual design as part of the project management phases; however, they do not include the project concept phase. Blanchard and Fabrycky [3] include the feasibility study as part of conceptual design; however, this feasibility study is specific to the design and focuses on design-specific issues, such as needs analysis, system and operational requirements, system maintenance concepts, functional requirements, and project planning as well as the project specifications. In this chapter, the project concept phase is seen as part of the project front-end phase and it includes the project scope, requirements, boundaries, the initial solution and alternatives, specifications and performance measures, resource commitments, timelines, costs, business case, the funding requirements, contractual terms, and conditions as well as the formalization thereof, and the go/no-decision, etc. The project concept is much more than the technical design concept; it includes the entire business case, all the various organizations, the various mechanisms and arrangements involved in the inter-organizational relationships [4]. Project Management Institute [1] also does not see the project concept phase as part of the initiation phase. In Ref. [1] the project initiation phase commences once the project is handed over from the sales front-end team to the project team; it excludes the sales front-end. The project concept phase is part of the project front-end phase; this refers to the activities that are performed before the actual start of the project [5]. This project concept phase occurs before the PLC; note that according to Project Management Institute [1], the PLC commences at the project initiation phase and extends until project closure, which is when the project is handed over to the client. Therefore, it is emphasized that by only focusing on the PLC, we are missing the critical front-end part of the project [6].

Notwithstanding that there is an abundance of focus from both academia and a practitioner level on improvement in project success, many researchers and practitioners have identified that much of the failures in project management is because of poor inter-organizational integration, transition, and collaboration between the different stakeholders that are involved from the initial sales stage to the PLC phases. Project Management Institute [1] defines the PLC to commence at the project initiation phase, which is when the project manager takes accountability and responsibility for project delivery. This is where the project manager’s accountability and responsibility commence for the operational delivery of the project in terms of cost, schedule, and performance. However, the project has been committed much earlier in the sales stage where the sales team has already set the direction for the project. It is in the sales front-end stage where the initial project needs, as well as project requirements, are established, where the project budget is established, which is a function of the materials, equipment, resources, and time. It is also where the high-level project solution is conceptualized, which establishes the boundaries for the project specifications, criteria for the project performance, and where project sustainability is established. This is an important and critical phase, which requires sufficient focus and commitment to establish the correct foundation and future direction for the project.

The rest of this chapter is structured as follows—first, an understanding of the interface between the sales front-end and the project initiation phase is provided; this is followed by the relevant definitions and terminology, challenges, project success, and governance requirements. Thereafter the mechanisms to improve integration, transition, and collaboration are provided, which is then followed by the benefits and opportunities of inter-organizational integration, transition, and collaboration, and finally a conclusion highlighting important lessons for project practitioners and managers is provided.

2. Understanding the interface between the sales front-end phase and the project initiation phase

For further clarity in terms of the interface between the sales team and the project team, consider the following generic example. Firm A has a need for some type of infrastructure development project; let us refer to firm A as the client. The client will conduct an initial analysis in terms of project scope, project timelines, project budgets, etc., to ascertain the feasibility of the project. Client A may perform this work internally or appoint external consultants to perform this piece of work. Whichever option client A chooses, the work is multidisciplinary in nature and involves many internal and external stakeholders. This is the initiation phase of the project from a client perspective. From their perspective, most of this work is performed by the client’s project team. Once the client is satisfied with the feasibility study, the client will then proceed with the next phase, which includes the client issuing a request for proposal (RFP) to the market. Other organizations will respond to the RFP: Let us just consider one service provider who supplies a lump-sum turnkey project. Let us refer to this service provider as contractor B. The contracting firm will then respond to the RFP. The contracting firm will have its own initiation phase that includes the project scope, project time, project budgets, feasibility analysis, etc. From a contractor B perspective, this work is also multidisciplinary in nature and most of this work is led by the contractor’s sales team.

The are several steps that include discussions, documentation exchange, and negotiations between client A and contractor B before a contract is awarded. There are also other discussions, documentation exchanges, and negotiations with other contractors, say C, D, E, etc. These contractors are the competitors to contractor B. These contractors were not successful in advancing to the award stage. In this chapter, the focus is not on the engagement between client A and the competitors to contractor B. Let us assume that contractor B is successful in being awarded the work by client A. Note that most of the engagement between client A and contractor B was driven by the project team from client A and the sales team from contractor B. The project team from contractor B was to a substantial extent led by the sales team, where in most cases involvement from the project team is limited.

In preparing the value proposition for client A, the sales team from contractor B is also involved with many sub-suppliers and other stakeholders internal and external to contractor B. These sub-suppliers are an integral part of the value proposition. These engagements typically define the value proposition to client A and it also is prone to potentially high-risk levels if not correctly managed. In these engagements, important decisions are made by the sales front-end team that commits to the future direction of the project. These engagements have long-term consequences for contractor B. Therefore joint involvement between the sales front-end team and the project execution team will be beneficial. Sales teams sometimes place far too much weight on decisions and choices based on costs. They do not always give the right amount of focus on other factors, such as technical capability and performance, and this could be detrimental to the firm as well as the project. Joint involvement between sales and project execution teams offers the advantage of the four-eyed principle. Where the best options are evaluated by both the sales and project execution teams, better-informed decisions are made. This alleviates risks and sets up the project for success. Figure 1 gives a graphical representation of the interface between the sales and project execution teams.

Figure 1.

Interface between sales and project teams.

Once the project is awarded, the sales team from contractor B hands over the project to the project team in contractor B. This is the handover process between the sales front-end team and the project execution team. Once handed over, the project team takes accountability and responsibility for the project. The project team then kicks off the project and several activities are triggered, for example, project kick-off meetings, setting up of the project charter, project organizing, planning, resource allocation, carrying out the work, project closure, etc. The project charter is extremely important as it is a document that reinforces the project costs, scope boundaries, schedules, quality control aspects, project deliverables, resource allocations, escalation mechanisms, etc. The project charter is an agreement between the project team from contractor B and client A. It is an essential part of the project initiation phase because it aligns the commitments made in the sales front-end phase to the commitments that will be adhered to and followed throughout the PLC. The project charter is a key milestone document that sets the direction for the rest of the project. Note that in this example the project deliverables have already been communicated by client A when the RFP was issued. This may have been quantified and/or qualified further during contract negotiations. Any changes must be reflected in the contract when awarded. This implies that the initial concept design, project timelines, costs, schedule, etc., which have already been committed during the negotiated sales phase are now further clarified and agreed. The project charter reinforces these commitments, highlights and records any additional changes that have now come to the fore, such as changes in scope, deliverables, schedules, and costs. An integral part of this phase is revisiting and assessing project risks that were initially identified during the sales phase.

Prior to the official award of the contract by client A to contractor B, there are numerous discussions, documents exchange, etc., before mutual understanding is finally reached that eventually leads to the contract award. During this period (interface and exchange between Client A and contractor B), there is a rapport which is built, and a mutual trust relationship is established. During this phase, the sales team from contractor B was predominant in managing the relationship between client A and contractor B. They were also instrumental in putting together the technical solution, and finalizing the price, which is dependent on inputs from many other firms internal and external to the contracting firm. These inputs include, for example, engineering for the technical solution, procurement for the cost inputs based on engagements with external sub-suppliers, health and safety for legislative requirements, finance, etc., with some and often limited involvement from the project team regarding resource allocations, timelines, project risks, etc. It is, therefore, imperative that for continuity from sales to project execution there is a properly documented handover between the sales team and the project team. Note that during the sales front-end phase there is tacit as well as explicit knowledge. The explicit knowledge is recorded in documents and is easier to transfer, tacit knowledge is not recorded and is difficult to transfer. The handover over process must take cognizance of both tacit and explicit knowledge. Siriram [7] highlighted the importance of a proper handover from the sales team to the project team. He also highlighted that those promises made at the sales stages of the project are not often carried to the project phases and this has the potential to result in project cost overruns. Based on at least this example, it is evident that the transition (and interface) between sales teams and project teams is of utmost importance. Therefore, it is key to contextualize the integration, transition, and collaboration in terms of the PLC.

To better understand the dynamics in terms of these interactions between the sales and project teams, it is important to explore the integration, transition, and collaboration dynamics between the sales and project teams.

3. Definitions and terminology: integration, transition, collaboration, the project front-end, and the project initiation phase

Firstly, before diving into the dynamics of integration, transition, and collaboration, it is important to define and understand these terms.

In terms of integration, there is a requirement for both technical and nontechnical integration. Technical integration deals with the technological interfaces between different disciplines, locations as well as interfaces between different systems and sub-system components [8]. Nontechnical integration deals with the communication, behavioral and social influences among people, organizations, and the external environment of the project [8]. Integration may also be viewed as the coordination of activities across the PLC. However, integration has been approached from a more mechanistic rational approach, in other words, a systematic approach, which is management by objectives approach. This is a short-term view to integration across the PLC, neglecting a more systemic holistic approach. The latter integrates the project from a wider systems context taking a longer-term view. This view takes into consideration the project’s wider organizational and strategic perspective as well as its future sustainability and the co-existence of the project in the wider environment. The longer-term view is a more strategic approach compared to the shorter-term view, which is more operational. It is also worth noting that the strategic longer-term view is established in the project front-end, which is driven by the sales team, while the operational shorter-term view is embedded in the PLC stages, which is driven by the project team and their project goals. There are two separate parts—the sales front-end and the project execution part.

Transitions may be defined as how the project moves from one phase to the next; it specifically addresses the mechanisms for the handover, for example, between the sales front-end phase and the project initiation phase. It is important to understand that there are certain activities that are used to trigger transitions. For example, a signed contract by client A and the sales team of contracting firm B is a key milestone and is a trigger to commence the project initiation phase. Other examples of such triggers include, for example, signing of the project charter that indicates alignment between client A and the project team from contractor B; completion of the project technical design, indicating that project execution may commence, etc. Triggers are mechanisms to initiate transition activities, indicating that the project can advance to the next step and may also trigger payment points. Transition activities or milestones are sometimes celebrated through ceremonial events. When a signed contract is in place, the firm may choose to celebrate this event. It must, however, be pointed out that transitions are temporary events that are used to govern the PLC at certain points in time. It must also be highlighted that while the triggers for transition, such as signing of contracts, project kick-offs, or project milestones, are well known and practiced in the project management environment, there has been little emphasis on the social and symbolic aspects of transition activities (celebrations) [9]. Celebrations may be used to trigger transition activities, but they must be used with caution to celebrate key milestones and should not be overdone. Celebrating transitions through ceremonial events can be an effective way to ensure that the transition has occurred. However, one must caution against false celebrations that are a cover-up for throwing things over the wall from sales to project execution without the face-to-face interface discussions, negotiations, and agreements.

Collaboration may be seen, as a mechanism to cope with uncertainty and ambiguity in the project environment. Collaboration facilitates teamwork, information flow, and knowledge-sharing, and enables communication, resource flexibility, a good working environment, etc. The importance of collaboration within the project organization is well recognized. However, collaboration outside the project organization involving the different stakeholders might be neglected. There are formal means of collaboration as well as informal means of collaboration. Both types of collaboration are a means to enable information and knowledge sharing across the project environment from sales to project execution. Collaboration is also a function of trust where higher levels of trust give rise to better collaboration. Collaboration is a mechanism to ensure integration and transition. Formal means of collaboration include organizational structures, processes, documentation, systems, etc., while informal means of collaboration include meetings, workshops, and other social gatherings.

The project front-end refers to the sales and business development phase of the project. It is one of the most critical phases of the project as it is where the initial analyses of problems, needs, and client and stakeholder requirements are conducted. It is in the front-end where the initial solution alternatives and choices are positioned to the client [6, 10]. It is there where the business cases, target benefits, and their realization are set out both for the client and contractor. It is important to note that there are two sets of business cases—the first being the client’s view in terms of the project scope, feasibility with its benefits, and realization. The second is the business case from the contractor’s perspective for the project scope and feasibility with its benefits and realization. These are two separate initiatives done by two different firms—the client and the contractor, respectively. The project must make business sense for both firms, it must be a win-win situation to make the project a success. The front-end is the most critical phase of the project; it is where critical decisions are made. However, the front-end is not seen as part of the domain of the PLC and is outside the domain of the project manager [1, 3].

The project initiation phase is the start of the project from the execution perspective; it is the first phase of the PLC. Note, however, that the project has commenced much earlier in the sales front-end. The project initiation phase is when the project manager takes over accountability and responsibility from the sales and business development team. The project manager is now accountable and responsible to ensure that the project is delivered according to the project budget, schedule, and specifications that were established in the front-end and mutually agreed upon signing of the project charter. The project initiation phase is when accountability and responsibility have transitioned from the front-end.

4. Challenges associated with integration, transition, and collaboration between the project front-end and the project initiation phase

Challenges associated with integration include how well the project activities are coordinated across the different functional units as well as the coordination among the different stakeholders. Integration is a function of how well activities are coordinated. Integration demands at least the following alignment, documentation, coordination, communication, monitoring and control, and competencies as well as capabilities. Alignment includes strategic alignment in terms of the project’s long-term and short-term perspectives, clear objectives, and in terms of project scope, client expectations, cross-functional team involvement, quality and risk measures, technical specifications and performance, etc. Documentation and coordination include well-documented and coordinated processes that are inclusive of ensuring adherence to processes. Communication includes clear guidelines and instructions on what is required and what is not allowed, how to access information and processes, and where to seek guidance if in doubt. Communication must allow for a two-way process that is not dictatorial but seeks to improve information flow and knowledge transfer and as such, improve processes and improve the adherence thereto. Monitoring and control speak to the adherence in terms of process as well as how to handle deviations to process and their associated nonconformances. Competencies and capabilities are a fundamental requirement of the individuals involved in developing and executing the project and these are inclusive of both the front-end sales team as well as the project execution team. Unclear objectives, lack of coordination among activities, lack of well-documented processes, poor communication, poor adherence to process, lack of trust, lack of formal documentation specifying the interface between functional organizational units as well as system component parts, etc., are some of the challenges facing integration. Other challenges associated with integration include the mechanisms to improve coordination among the different activities in the project network. These are associated with how well activities are coordinated; poor coordination leads to poor integration.

Challenges associated with the transition from the front-end to the project initiation phase include at least the following—the shift in thinking from long term to short term. The front-end team is concerned with the long-term sustainability of the project, which includes factors that have social, environmental, and economic impact, coupled with client relationship management that extends beyond the scope of the current project, and it also includes project decommissioning. The project team, however, is concerned with short-term project benefits that include, cost, schedule, and performance of the project measured against what was sold to the client. The focus from the sales front-end team is geared toward the long-term sustainability of the firm, while the focus from the project team is focused on the successful delivery of the project. Therefore, one may view the front-end view as more strategic and the project view as more operational. This difference in thinking is a major challenge that needs to be overcome during the transition phase. Further to this, the transition process is also faced with other challenges like differences in performance metrics between the sales front-end and project teams, others like refs. [11, 12] also include the personalities, backgrounds, locations and responsibilities, lack of support, and proper organizational structures as additional challenges facing the transition. Others like ref. [13] also include a lack of management attention during the transition phase as a challenge. Specifically, executive management’s attention in the transition process is key to removing obstacles and enabling a better transition process.

Challenges associated with collaboration include the uncertainty and ambiguity that arise because of the project environment, which includes multiple stakeholders, conflicting objectives, trust, the means, frequency, and quality of communication as well as resource constraints. Project resources are revenue generating and as such, they generate money for the firm. Removing them and reallocating them to sales activities that are nonrevenue generating is a challenge, as it hinders the firm’s revenue-generating capability. Project resources are essential for revenue and profit. They are normally utilized to full capacity, especially the project manager, who is in most cases already committed to other projects. Availability of project resources is, therefore, a constraint that is a challenge for collaboration. The sales team, however, is nonrevenue generating; they are also constrained as they often work on multiple sales initiatives, and therefore, coordinating the availability of sales and project teams may also pose a challenge for collaboration. Collaboration is also a function of trust; higher trust leads to better collaboration and lower trust leads to lower levels of collaboration. The better the collaboration the greater the coordination, which leads to better integration of activities.

These challenges need to be overcome to improve project success. It is, therefore, necessary to understand what project success means both from a firm perspective as well as a project perspective. The interface between the project front-end and the project initiation phase is the most critical interface required for project success, and it requires special managerial attention. It is, therefore, important to understand what is required to improve management and governance to ensure project success.

The project execution team is more concerned with hard deliverable realities, while the sales team is more concerned with meeting the client’s expectations and wishes, which sometimes may not be realistic, but to win the order, sales teams may make certain commitments. In preparing the solution for the client, the project team is risk-averse, while the sales teams are risk-taking. Should these two not tie up, there are gaps, which may lead to conflict with the client that will also then hamper integration, transition, and collaboration efforts. This is an undesirable situation. Therefore, proper governance is required at the onset to effectively manage the interface between the sales front-end and the project initiation phase.

5. Project success and governance

From a project management perspective, project success is viewed as meeting the project objectives in terms of the project budget (cost), schedule (time), and performance (specifications). This view of project success is a short-term perspective; it is management by objectives view, and it is a rational mechanistic and systematic view. In this view, the long-term wider more strategic and systemic perspective is neglected. The short-term view needs to expand the current view of project success to include project sustainability, which is the life of the project beyond its completion, the relevance and effectiveness of the project, extending to the longer-term goals of the project that were set in the front-end phase. These two perspectives on project success, namely the short term and long term, need proper management and governance. The project success criteria must include both long-term and short-term metrics.

Project governance mechanisms need to be put in place to manage both the short-term (operational, tactical, and systematic) and long-term (strategic and systemic) objectives of the project. Project governance mechanisms include organizational structures, the incorporation of processes, systems, regulations, as well as formal and informal mechanisms that can improve communication, integration, transition, and collaboration across the life of the project. Such mechanisms must also include the appropriate organizational structures to support cross-functional alignment in project environments, which is inclusive of well-documented processes. In terms of process, emphasis is placed on a proper handover process and documentation from sales to project execution. Other governance mechanisms include cross-functional teams to improve communication, information and knowledge sharing, and collaboration between the front-end and project execution phases. Attention must also be devoted to cultivating a symbiotic relationship between sales and project execution teams. Careful and continuous risk management, and risk mitigation processes early on, commencing at the sales front-end phase with continuity through to the project execution phases, should not be neglected. Project execution teams must be included in the front-end and have significant input in pricing the solution and sales must be involved in project execution as an oversight function, etc.

Such mechanisms improve collaboration, but integration is not well addressed by cross-functional teams. Collaboration may help improve communication, information flow, and knowledge sharing between the different functional units, but it does not enable integration. Integration can only be achieved through the alignment of goals, objectives, and performance metrics. This is mainly because organizational boundaries exist between the different units. These divide the different organizational units into different entities that have different goals and objectives, each having its own responsibilities and tasks that are measured by a separate set of performance metrics. For example, the sales team is measured on order intake targets measured in financial terms (e.g., dollars), while the project execution team is measured in terms of meeting project deliverables, such as cost, schedule, and performance. Procurement is measured on a range of factors, for example, cost of input items, lead-time, and delivery reliability of suppliers. The sales team should not only be measured on order intake targets, but profit margin should also be a criterion that will safeguard against accepting sales orders that have poor margin quality. Project execution should also be not only be measured on criteria, such as cost, schedule, and performance, but also on criteria, such as long-term sustainability of the project and client satisfaction. Procurement should also be measured not only on cost target measures but also on supplier reliability, delivery, flexibility, etc. These types of overlapping metrics enable better integration, transition, and collaboration between sales and project execution teams. Close alignment of performance metrics between the different functional units will improve integration from the sales front-end to project execution.

6. Mechanisms to improve integration, transition, and collaboration

Transition activities go beyond the structural dimensions that are required to ensure how well participants in both sales and project execution teams adhere to defined integration and collaboration mechanisms. It extends beyond adherence to organizational structures, processes, and adoption of systems; it is inclusive of mutual trust and understanding between the different stakeholders. This mutual establishment of trust must be developed early in the project; typically in the sales front-end phase and such trust will aid in developing a symbiotic relationship between the sales and project execution teams.

Integration is a means to facilitate the transition. There are different types of integration, namely vertical and horizontal integration. Vertical integration focuses on integration within a single unit through centralization, standardization, formation, and on systems. Horizontal integration focuses across organizational units, for example, through mechanisms such as cross-functional teams and job rotation [14, 15]. The question arises which types of integration mechanisms are appropriate for successful project completion. When there is the complexity that gives rise to elevated levels of uncertainty, people become inundated with different alternatives, making choices difficult. In such cases, more informal means of integration that facilitate information and knowledge sharing enabling a big picture approach are preferred. Informal means are more interpersonal and tend to bring different stakeholders together in a calmer environment which may facilitate better communication, which is critical in complex environments [16]. However, this does not negate the importance of formal means, such as organizational structures, standardization of processes and systems, which are also crucial factors. In terms of processes, an effective way to ensure adherence is to “hard wire” them; that is, automate processes where possible. In the digital era, it is not uncommon to automate processes and in so doing, deviations can be tracked and escalation paths trigged automatically. However, common business sense must prevail, and automation must be used cautiously; it must be used as a mechanism to improve efficiency and effectiveness while at the same time not hampering business operations and team productivity. Both vertical and horizontal integration mechanisms are required to facilitate integration and transition.

In terms of organizational structures, processes, and systems, it is not sufficient just to have them, but to also have the right ones. Different projects have different complexities, depending on the size, duration, number of resources, complexity, etc. Therefore, some categorization is required and as such, each type of categorization may need different mechanisms, organizational structures, processes, and systems. For example, consider the following:

There are three types of projects namely:

1. Class A: High cost, long duration, many resources, and complex.

2. Class B: Medium cost, medium duration, medium resources, and less complex.

3. Class C: Small cost, short duration, few resources, and little to no complexity.

In class A projects, we have time on our side to fix problems when they occur. The high cost, duration, number of resources, and complexity require more rigid organizational structures, detailed processes, and robust systems.

In class B projects, we have less time than in class A projects. Time is still on our side, so the project has some flexibility in terms of recovery from potential problems. The organizational structures, processes, and systems, however, to a considerable extent are like class A projects but with some allowance for flexibility in the implementation.

In class C projects, we must pull the trigger on day one; there is no time factor on our side and every-day counts, so we must start the day the order is received. The project cannot be hurdled by complex organizational structures, long-drawn-out processes, and complicated systems. Therefore a much reduced but effective level of organizational structures, processes, and systems is required.

Based on this simple example, it is apparent that we need to have different organizational structures, processes, and systems for diverse types of projects—one size does not fit all. We need to have organizational structures, processes, and systems that are fit for purpose. The same applies to governance mechanisms, they should be fit for purpose to control and monitor adherence to the organizational structures, processes, and systems.

Similarly to the categorization of projects, we also need to categorize project managers. For example, consider the following:

There are also three types of project managers namely:

1. A superstar who takes an already good project (e.g., high margin quality, no major schedule/time constraints, and not many risks) and exceeds delivery expectations from a cost, schedule, and performance perspective. Such a project manager is also able to take a bad project (e.g., low margin, major schedule constraints, and with many risks) and always wins no matter what.

2. Average project manager will deliver the project as sold with no radical improvement or innovation in delivery.

3. Mediocre project manager makes no difference if it was a good project or a bad project at the outset, this project manager often will allow the project to suffer, and it may not be recovered.

Therefore, it is important that the right level of project manager is appointed to the right project. It would be significantly beneficial to include the project manager responsible for the project execution during the sales front-end phase. However, this may not always be possible due to project resource constraints already discussed. However, in high-risk projects, every endeavor should be made to involve the project manager early in the sales front-end phase. Superstar project managers should be given the opportunity to excel; they should be coached and exposed to more class A type projects. Average project managers should be coached and mentored with the intention to turn them into superstar project managers. Mediocre project managers should be given the opportunity to develop, failing which, tough decisions should be made regarding their future as project managers.

Another important mechanism is executive management participation and their capital allocation responsibility early in the sales front-end. Capital in this context is everything that is required in terms of resources, such as people, funds, factory, and space. Executive management involvement in the sales front-end can help alleviate challenges and mitigate risks early in that phase. They can also assist with the challenges associated with, for example, collaboration, coordination, resource availability, conflicting objectives, etc. It will also be beneficial to appoint a project sponsor or project “godfather” from the executive team, whose responsibility is to provide high-level leadership and guidance from the sales front-end through to the PLC phases.

It is also important to reinforce the discussion on processes at the handover stage. Processes need to be the right fit for the project category. The project execution team must take accountability and responsibility for the handover processes. The project execution team needs to be the process owners, they must own the handover process. For a proper handover, the sales teams must adhere to requirements set by the project execution team. The project execution team may have “dark fears,” therefore, the handover processes need to be driven by the project execution team and not the sales teams, sales teams are participants. Project execution teams must own the process, they must be accountable and responsible for putting the process in place, as well as monitoring and controlling the process. Consider the handover process as a client-supplier relationship where the project execution team is the client and the sales team is the suppliers. Joint involvement from both sales and project execution teams in costing and estimating, in face-to-face discussions with the client in the front-end will only reinforce integration, transition, and collaboration. Pricing finalization needs to be a joint effort between sales and project execution. Noting that the project manager and project execution teams are risk-averse, they need to be realistic and simply including mechanisms to eliminate or reduce risk unrealistically will over price and over constrain the solution. This would be an undesirable situation resulting in the solution being rejected by the client, leading to order failure.

On formal handover between sales and project execution, the project manager has the final say in terms of signing off, by indicating that a proper handover has taken place from sales to project execution. The project execution team must indicate that they are, or are not, sufficiently satisfied with the handover from sales. However, measures must also be put in place to safeguard against the project execution team being too rigid and unrealistic in rejecting handovers from sales to project execution. At the end of the day, the project must be delivered to the client and internal processes between sales and project execution must align to client deliverables and not hamper the client.

A post-mortem should be done at the end of the sales front-end phase before the commencement of the PLC phases. This is at the project initiation phase so that anything that has been missed can be highlighted and proper risk management can be put in place to mitigate the risks identified, as well as enable lessons learned for future projects. Ideally, one consolidated document needs to be part of the handover process and this document must be signed by both teams as such agreement is reached. The post-mortem ideally will precede the project charter. In this way, there is internal alignment between sales and project execution teams before aligning with the client.

Having the correct integration mechanisms is not sufficient, one also has to have the right governance structures to facilitate the integration. This will lead to a better transition between the front-end and project execution teams. There are many options when it comes to governance structures. A key account management structure is sometimes adopted by large firms. This type of structure enables the front-end and project execution teams to effectively engage with the client. It allows for multiple levels of engagement with the contractor and the client. Figure 2 gives a typical example of such a structure. For example, the sales team from the contractor engages with the project owner and project team in the client firm; the engineering teams from both firms interact with each other; the project teams from both firms interact with each other; the CEOs can also have a one-to-one engagement, etc. This allows multiple levels of engagement that enable better information and knowledge sharing and continuity across the PLC as well as across the entire firm. Key account structures may also offer some flexibility to alleviate the resources constraints from both the sales front-end team as well as the project execution team. Key account management structures only make sense for large firms and large projects. For smaller less complex projects and for smaller types of firms more informal means like appropriate organizational structures, cross functional-teams, meetings, face-to-face communications, etc., are more appropriate. It must, however, be noted that organizational structures, standard processes, and systems are an integral part of the governance mechanisms, key account management structures and other informal means do not negate their importance.

Figure 2.

Key account management structure.

7. Benefits and opportunities of inter-organizational integration, transition, and collaboration

The benefits of a well integrated, transitioned, and collaborated project include at least the following:

Alignment of stakeholder requirements, as well as a unified understanding and acceptance of measurements and milestones. Moreover, it puts both the sales team and project team on the same page. It helps reduce risks and potential conflicts, it also facilities information and knowledge sharing and enables continuity from the front-end to project execution phases. There is also continuity in terms of risk management from the project front-end to the PLC phases, allowing the team to collectively manage project risks and identify opportunities for improvement. Benefits lie in lower risk because both sales and project execution teams are jointly involved in developing the client value proposition. This joint involvement ensures that both sales and project execution teams are aligned in terms of the deliverables, which is required in meeting client expectations. Furthermore, the commitments that are made have a much better chance of being achievable because of the joint involvement. The collaborative efforts result in more accurate budgeting, costing, and planning, which provide greater confidence in bringing the project within budget, schedule, and specifications. The end result is a happy client.

The handover process between sales and project execution is much smoother. This leads to better teamwork and cross-functional collaboration in the later stages of the project. Better alignment leads to the sales front-end and project execution teams working collaboratively to meet client expectations. This improves the chances of project success from a project budget, schedule, and performance perspective. A close working relationship leads to better team satisfaction and a good atmosphere enables the team to work in a more collaborative manner to overcome any hurdles that may occur.

A baseline understanding of the project deliverables has been established between the sales and project execution teams. The transition from the front-end to the project execution formalizes the change in accountability and responsibility from the sales team to the project team. Now that the transition has occurred and accountabilities and responsibilities have changed, and the clock has started ticking from a project schedule perspective, the milestones and measurements now need to be regularly tracked. This is required to ensure adherence to the project budget, schedule, and specifications that were committed during the sales phase. It is also important to note that transition occurs throughout the PLC, potentially at every “go/stop” gate (if a Phase-Gate process is used). Accountability and responsibility change at certain gate points where the project is handed to a new team. This must also be coordinated with the contractual phases of the PLC.

A well integrated, transitioned, and collaborated project results in higher-margin quality as well as lower risk in project execution. This also improves team morale, as general staff works better on a project knowing there is upstream potential to improve on the project deliverables. This is a lot better than trying to recover a project with high risk, which is often the case in projects that are not well integrated, transitioned, and collaborated. There is also a better understanding of the limitations, mutual understanding, and clarity in terms of meeting client expectations and project deliverables.

Integration, transition, and collaboration also imply information and knowledge sharing, which ensures that everybody on the projects knows what is required. This leads to better alignment between all stakeholders. It must also be noted that transition is not a once-off event, it occurs throughout the PLC. Just as the project execution team needs to be involved in the front-end process, so too do the sales team need to be involved in an advisory or oversight capacity in project execution, to ensure that the work is completed to the agreed requirements both from an explicit and tacit perspective. When sales and project execution work together the transition is smooth and seamless. As the project evolves sales team involvement is reduced. However, it is not a hard stop from the sales team, the transition is a process of information and knowledge sharing and continuity with a gradual reduction in sales involvement.

While the benefits are numerous as outlined herein, both sales and project practitioners must be cautioned against at least the following:

Acknowledging that while information and knowledge have been shared between the sales and project execution teams, one must ensure that tacit knowledge, which has not been documented, is also transferred across to the project execution team. This is possible through the gradual reduction of the sales team involvement, which will ensure information and knowledge transfer and continuity.

The project scope and limitations must be understood and adhered to as per the contractual documentation and risk management need to be a continuous process throughout, commencing at the sales front-end through to the PLC phases.

Acknowledging the transition from sales to project execution, the latter needs to ensure that the correct resources at the right capacity and capability are allocated to ensure that the project milestones and deliverables are met.

Resources now need to be committed and the project is now in execution mode. It is important that the scope is correctly managed by the project execution team and any deviations need to follow due process, otherwise, the project can be hampered by scope creep, which could lead to cost, schedule, and specification deviations that will be detrimental to the project.

8. Conclusions

Project management is not a single functional unit operating in isolation. It involves different functional units like sales and marketing, tendering, engineering, procurement, logistics, health, safety, etc. Therefore, successful project management requires proper integration, transition, and collaboration between the different functional units as well as the different activities. Projects are complex structures, mainly because of the complexity that arises from managing different stakeholders with different objectives. These stakeholders are both internal and external to the firm. There are also technical and nontechnical aspects of the project that need to be integrated and managed. Technical integration for example includes different technologies, perhaps from different suppliers, which all need to be integrated to create a complete solution, as well as the integration of possible different project locations. Nontechnical integration refers to the communication, behavioral and social influences between the different people, firms, and the internal and external environment.

In this chapter, the shortcomings in project management have been highlighted. Attention is specifically drawn to the integration, transition, and collaboration between the front-end and project execution phases. The front-end is predominately managed by the sales team, in some cases with limited involvement from the project execution team. The interface between the front-end and project execution phases is not understood well and requires special attention. The front-end is where the scope of the project is established, where the initial solution is defined, and where the rapport with the client is established. It is, therefore, important to ensure continuity between the front-end and project execution teams, failing which will be detrimental to the future success of the project. The front-end does not fall under the scope of project execution, but it is a crucial phase that sets the strategic direction for the future success of the project. It is emphasized that the front-end requires more involvement from the project execution team and it must be a joint effort between the sales and project execution teams. It must, however, be noted that project execution resources are expensive, and they are also limited. Therefore these constraints need to be recognized; however, every endeavor should be made for joint involvement as the benefits outweigh the costs and risks.

To improve understanding of the integration, transition, and collaboration between the sales front-end and project initiation phase, it is important to better understand this interface. Therefore in this chapter attention has been devoted to understanding this interface, by reinforcing the definitions and terminology associated with integration, transition, and collaboration. Thereafter, the challenges, requirements for project success and governance, mechanisms for improvement, and associated benefits are highlighted. This chapter draws attention to this crucial interface and ensures it receives the right amount of management attention. It also highlights that the current scope of project management focuses on the PLC, which does not include the sales front-end phase. Therefore, to improve project success, there needs to be a concerted effort dedicated to integration, transition, and collaboration between these two phases.

Notwithstanding the points already highlighted, it is important to point out that the basis for integration, transition, and collaboration is trust. Trust between all stakeholders needs to be established early on in the front-end. Without trust, the mechanisms will not be successful and the benefits will not be realized. It is also important to highlight that tacit knowledge transfer is an important item in establishing trust, as not transferring tacit knowledge could create the perception of a poor trust relationship, which is detrimental to the project. Integration is a function of the coordination of activities. Higher levels of trust lead to better collaboration, which leads to better coordination, and better integration, which leads to better transition.

Finally, as a reminder, the importance of having the right organizational structures, processes, and systems that are fit for purpose, and the monitoring and control of these organizational structures, processes and systems cannot be over-emphasized. Having organizational structures, well-documented processes, and expensive systems that are not adhered to, is simply a waste of effort and time.

Acknowledgments

The author recognizes the contribution made by Thomas Eichbaum, Bohdan Pylypczak, Jacobus Johannes Smit, and Dave Evans for reading the initial drafts of this chapter and providing valuable comments on editing, as well as further insights, which helped improve the content and quality of this work. The author is grateful for their valuable contribution.

There were no funders involved in this work.