Current Trends for Program and Project Management Approaches

#### **Chapter 3**

## Balancing Hedging and Flexing for Inclusive Project Management

*Wim Leendertse, Bert de Groot and Tim Busscher*

#### **Abstract**

Current project management often emphasizes hedging through a strictly phased and funneled development of the project scope. However, an increasingly engaged project environment and rise in the complexity of societal challenges cause an emerging demand for more open and interactive ways of managing projects. This requires projects to adopt an integrated management approach that focuses on flexing, which emphasizes the ability of a project to adapt to and co-create with the environment. Overemphasizing flexing, however, may undermine the controlled nature of project management. Therefore, it is necessary to find a form of project management that is both open and interactive without losing control. On the basis of specific project contexts and characteristics, this chapter presents criteria and tools for balancing hedging and flexing for inclusive project management.

**Keywords:** project management, hedging, flexing, stakeholder participation, project flexibility

#### **1. Introduction**

Our society is presented with grand challenges. We have to deal with many issues at the same time, such as climate change, the energy transition, the transition to a circular economy, empowered citizens, the increasing role of digitization, increasing attention to the living environment and nature, etc. This means that projects, which can be seen as interventions in our society, can no longer be separated from their environment. Current project management, however, still follows a hedging approach that is strongly based on the classical step-wise development of a predefined output, where the environment is seen as a threat that must be mitigated. In order to be able to respond to the increasing complexity of the project environment, there is an emerging demand for a more open and interactive approach to project management. We refer to this approach as a flexing approach. While a flexing approach may emphasize the ability of projects to move along with and shape their environment, this also increases the interdependencies between the project and its environment, thereby increasing complexity, leading to less control of the project and potentially causing projects to drift. Therefore, it is necessary to find a form of project management that is open and interactive without losing control. The theory and practice of process management offer valuable insights for this. On the basis of insights from recent project and process management literature, this chapter describes how strategies

and instruments of process management can be combined with project management tools and techniques to come to a more open form of management without losing manageability.

#### **2. From hedging to flexing in project management**

#### **2.1 What is meant by "project" and "project management"?**

Literature has numerous definitions of the term "project." One of the most used definitions was developed by Turner and Müller [1], who define a project as a temporary endeavor in which human, material, and financial resources are organized in a novel way, to undertake a unique scope of work, of given specification, within constraints of cost and time, so as to achieve beneficial change defined by quantitative and qualitative objectives. Following this definition, project management can be seen as the organizational activities, to be carried out by a plurality of specialized persons or groups, in a temporary joint venture that aims to deliver a clearly specified result within a limited period of time, within certain conditions and with finite resources. In short, project management concerns the application of knowledge, skills, tools, and techniques to ensure that project activities meet project requirements [2].

#### **2.2 Limitations of classic project management**

Classic project management is strongly focused on manageability and control. It is based on a causal rational paradigm [3, 4], where the process of managing a project is translated in a sequential and linear phasing of activities that should lead to a predefined result. This is further expressed in scope, cost, and time management using dedicated project management tools and techniques, suggesting that the appropriate use of these instruments leads to the intended result. In this paradigm, the project is regarded as a closed system with a clear boundary to its environment. This system is not isolated—there is interaction between the system and its environment—but changes in that environment may have a negative effect on project progress and are considered a potential threat that must be mitigated. Projects are therefore supposed to conduct risk analyses and develop contingency plans to cope with risk. In general, classic project management is based on advanced predictions that must be achieved via a strictly defined path through the correct and effective use of project management tools and techniques. These tools and techniques take the form of methods, rules, step-by-step procedures, frameworks, and models. A search on Google quickly reveals the multitude of project management tools and techniques and a multitude of handbooks that describe these [2, 5, 6]. Organizations such as the International Project Management Association (IPMA) and the Project Management Institute (PMI) even offer dedicated courses to learn these tools and techniques and to certify project managers.

However, due to this closed system perspective, potential opportunities may be missed and the defensive attitude may lead to problems in delivering projects. This limits the contribution that projects can (and should) make to the major societal challenges we are facing today and the potential use of opportunities as tool for adaptation. In addition, society is becoming increasingly engaged, and a sectoral projectoriented process without the engagement of its environment is no longer accepted. Or as Van Buuren et al. [7] argued, the main characteristic and focus of (classic) project

management is its main disadvantage: it tends to focus primarily on the realization of one single project ambition, suffers from a singular logic, and is limited in terms of scope, budget, and time. An answer may be a more open system approach in which the boundary of the system becomes permeable and stakeholders are included as co-actors, especially in more dynamic environments with a relatively high degree of uncertainty. A shift in focus of project management from purely instrumental to more process-oriented.

#### **2.3 From hedging to flexing**

Classic project management, based on a hedging strategy, offers hardly any room for adjustments to the project scope, planning, or budget, to respond to changes in the environment. In general, hedging is less satisfactory in dynamic environments when complexity in and around the project is relatively high. In these cases, a process-oriented approach, or flexing, is more appropriate. Flexing is often characterized by a broader scope (integration of challenges), a flexible planning on various timescales (short, medium, and long term), interim monitoring, a partly flexible budget to which several parties contribute (co-financing), and involvement of stakeholders through open dialog and a co-creative approach. Determining the right mix, i.e., a balance between hedging and flexing (which may even change over time), is the key challenge in modern project management. This mix is determined by both the context of the project and the capabilities of the project organization. By "context" we mean the unique conditions in which the project is being managed [8], including the organization's internal context (e.g., other projects, departments, and organizational strategy), and external context (e.g., stakeholders, adjacent environment). **Table 1** shows main characteristics of classic project management and a process-oriented approach [9].

In the next sections, we will first look at the context of a project from a complexity perspective. Higher degrees of complexity of a project and/or its environment require the project to deal with higher levels of uncertainty, which requires more flexibility


#### **Table 1.**

*Main characteristics of (classic) project management and process management (derived from [9]).*

of the project. Then we will discuss strategies to open project boundaries and to increase the ability of a project to reach out to its environment through stakeholder engagement, active opportunity seeking, and inclusive planning. Subsequently, we will discuss the ability of the project organization itself to proactively deal with uncertainty. In the final section, we will bring it all together as related building blocks for next-generation project management.

#### **3. Projects and complexity**

Complexity is an often-used concept in project development and management. In our daily use, it often refers to the perspective of the project participants on the difficulty of a project. From a more fundamental perspective, complexity revolves around actors or elements in or close to a project that interact with each other in a reciprocal way. For example, nowadays, the project environment in both project development and implementation requires intensive interaction, which may lead to a multitude of interdependent relationships of the project with its environment.

Not all projects are necessarily complex. Some projects can be classified as simple or complicated. The degree of complexity—i.e., a simple, complicated, or complex project—has implications for project management; or at least, it should have. Higher degrees of complexity often imply more uncertainty, more vulnerability for change, and need a management style that can deal with this. In general, simple or complicated projects can be managed on the basis of a hedging project management approach, whereas complex projects need more flexibility and a more flexing project management approach.

On the basis of a recent literature review of international peer-reviewed journals on project complexity, four forms of complexity can be distilled: technical or structural complexity, organizational complexity, contextual complexity, and institutional complexity [10]. Projects may have to deal with any form of complexity. Technical or structural complexity relates to the tasks and substantive aspects of a project. This not only includes the diversity and number of tasks or aspects within a project, but also the interdependencies between tasks or technologies. Organizational complexity relates to the organizational structure of the project or its parent organization. A complex organizational structure is one that consists of several interdependent parts. Institutional complexity is the result of different institutional logics of the actors involved in a project. Institutional logics influence personal definitions and working methods, which are partly shaped by the cultural and political background of the actors. For this chapter, especially the fourth identified type of complexity, the concept of contextual complexity, is relevant. *Contextual complexity* is described in literature as the complexity resulting from environmental influences. The literature review of Busscher et al. [10] revealed several indicators of contextual complexity, which can be used to assess the degree of complexity of a project in a specific context. The following indicators were found in the studied literature: the amount of project stakeholders, the level of sociopolitical interests or influence in project, the degree of support (from stakeholders) for the project, the internal (intra organizational) support for the project, the degree of competition in the market, geographical differences in regulations, the level of influence of contextual developments on the project, and the amount and intensity of social discussions.

As mentioned above, a higher degree of contextual complexity needs more flexibility of the project—or a more flexing style of project management. However,

#### *Balancing Hedging and Flexing for Inclusive Project Management DOI: http://dx.doi.org/10.5772/intechopen.102972*

the need for flexibility does not (always) match the possibilities to be flexible in every phase of the project life cycle [11]. For instance, the need for flexibility may be high in the planning phase and the beginning of the execution phase when the design is elaborated and stakeholders are confronted with the concrete effects of the intervention. As the design evolves, the possibilities for flexibility will decrease and will be lower in the end of the planning phase and low in the execution phase and termination phase. Typically, in project management, a change of phase comes with an intermediate decision, which fixes the boundary conditions for the next phase and by doing so reduces the opportunities for flexibility.

#### **4. Strategies, tools, and techniques to deal with contextual complexity**

#### **4.1 Stakeholder management and opportunity management**

Already in the 1980s of the last century, Cleland (1986) introduced stakeholder thinking into project management. Since then, the importance of *stakeholder management* in project management has increased, i.e., the process of adapting the specifications, plans, and approaches to the different concerns and expectations of the various stakeholders [2]. A stakeholder can be defined as a group or individual that has an interest in the success or failure of a project [12]. Stakeholder management is the process of managing the expectations of anyone who has an interest in a project or will be affected by its deliverables or outputs. Stakeholder management typically has been used as an iterative process of identifying and analyzing stakeholders from a project perspective, defining strategies and accompanying measures, implementing the measures, and evaluating the effectiveness (plan-do-check-act). In this approach, the stakeholders are considered manageable to meet project goals [13]. Together with the development of stakeholder management also *opportunity management* gained increasing attention. Opportunity management can be seen as the inverse of risk management, in the sense that risk management seeks to proactively minimize the probability and/or negative effect of a potential event on a project and opportunity management, in turn, seeks to maximize opportunities that can bring value to a project by connecting project challenges to stakeholder challenges [14]. From a project management perspective, an opportunity is an uncertainty that potentially adds more value to the project than the potential loss of value it may bring along [15]. This interpretation of opportunity management is based on the Mutual Gains Approach as developed at Harvard University in the beginning of this century [16, 17]. Being able to seize opportunities increases the flexibility of the project, since the extra value of an opportunity may be used to, for example, extend the scope of the project or compensate for potential time or cost overruns.

#### **4.2 Co-development**

This leaves the question: can one really manage stakeholders and the project environment? As mentioned above, society becomes more emancipated. People take responsibility to design their own environment, and citizens' initiatives are becoming more and more common [18]. The power of interest groups, NGOs, and individual stakeholders is increasing. These developments imply that projects can no longer act autonomously and instead have to work together with stakeholders. Stakeholder and opportunity management thus have to shift to an orientation

focused on co-development. In contrast to "management of stakeholders," a "*management for stakeholders"* approach embraces all the stakeholders and tries to reach win-win situations [19]. In line with this approach, participation through co-development is broadly discussed in planning and management literature in the last decades [20–25].

*Co-development* can be defined as the joint development and improvement of policies and services at an equal level through constructive dialog [26]. Dialog means interactivity, engagement, and a propensity to act on both sides. It is about empathic understanding of both sides and a communication of equals. The intensity of joint activities can differ (see, for example, the classic ladder of participation by Arnstein, 1966), but communication and information exchange are always the basis for any stakeholder involvement. Attuning and adjusting mutual activities can be added on top of communication and information exchange so as to achieve results more efficiently, i.e., mutual coordination. When, in addition to the abovementioned activities, also resources are exchanged, one may speak of cooperation. Collaboration is considered the ultimate form of cooperation, where information, activities, resources, and responsibilities are jointly planned, implemented, and evaluated to achieve a common goal [27]. In all these definitions, joint development in equity, interaction, and dialog influence on agenda setting, high involvement and common goals are main characteristics of co-development.

#### **4.3 Engaging stakeholders and issue management**

Co-development in a project environment means that the project engages the stakeholders in a collaborative problem-solving process [28]. The project organization respects and uses the expertise of the stakeholders and is open and willing to share all information necessary for a joint project design. The design is based on problem-specific interaction involving the interests of all relevant stakeholders. The decision-making is based on the weighing of interests in what Aaltonen & Sivonen [29] describe as an adaptation strategy. **Figure 1** shows different corresponding strategies as mentioned in literature the axis from (classic) project management to process management.

*Strategic stakeholder Involvement* (SSI) is a practical tool to engage stakeholders in co-development [30]. This approach combines traditional stakeholder management, designed to minimize risks caused by parties with different interests, with seizing opportunities through issue management. *Issue management* entails a process of continuously scanning the environment for new issues, which are developments or events that might happen and force stakeholders to take position. Issues come and go and change over time. Central to issue management is the identification of issues that may influence the project or may be influenced by the project and address these in interaction with the stakeholders from a win-win perspective.

#### **4.4 Co-creation and social design**

The descriptions above are based on a so-called inside-out perspective, which looks at the environment from within the project. At the same time, the project can also be seen as an instrument that may contribute to solving broader social issues. This perspective works from the outside-in and assumes the project goal and task to be only one of the goals and tasks that have to be tackled in interaction with and between stakeholders, thus opening the box [13].

#### **Figure 1.**

*Strategies for project and process management.*

*Social design* is a design methodology to tackle complex issues, placing the combined social issues as the priority. The basic idea is to break down the walls between disciplines and enable truly interdisciplinary work to take place. The classic approach of project management starts with a (project) problem and organizes the most efficient path to come to a predefined output or outcome, which solves that problem. Social design is based on the process and principles of design thinking developed by the British Design Counsel (www.designcounsil.org.uk), the "Double Diamond" or "4D" model. In this approach, the design process starts with a joint problem definition involving all relevant problems of the project and its context and their stakeholders. The idea is that actors collectively scan a relevant context around the project searching for problems and issues. Based on a joint problem definition, information is gathered and possible combinations are developed in a co-creative process. In contrast to

**Figure 2.** *Process steps of social design (source: British Design Counsel).* the traditional project management life cycle, this process is not linear from problem to solution, but interactively dynamic via diverging and converging stages [20, 31]. **Figure 2** shows the typical steps of a social design process.

Social design may lead to more integrated solutions and a higher degree of acceptance. However, to keep the process manageable, it is necessary to add some hedging elements to the process, for example, by setting milestones, by setting clear and smart boundaries, and by transparently communicating about the boundaries of the decision-making process.

#### **5. Building project flexibility**

The project context is essential for the successful management of a project [32]. As mentioned above, project organizations need to be responsive and open up to their context and engage stakeholders to enable project success. This requires considerable flexibility of the project organization, as it includes giving room for co-development and co-creation and at the same time keeping the project manageable [8]. Olsson [33] defines project flexibility as the capability to adjust the project to prospective consequences of uncertain circumstances within the context of the project. Adopting a flexible approach improves not only the project results, but also the evaluation of the project management itself.

The extended Pentagon model of Rolstadås et al. [34] offers a model to connect the project management process to the external context through so-called formal qualities, such as structure and technologies, and informal qualities, such as culture, social relations and networks, and interaction (see **Figure 3**).

The distinction between formal and informal qualities may be viewed as hedging versus flexing, controlling versus emerging, or prescriptive versus adaptive. In this

**Figure 3.** *The extended pentagon model (source: [34]).*

#### *Balancing Hedging and Flexing for Inclusive Project Management DOI: http://dx.doi.org/10.5772/intechopen.102972*

model, flexibility is created through the interaction between formal and informal qualities of project organizations. For example, rules may formally be more loosely defined to allow informal qualities to be revealed. Building on this, Sohi et al. [35] delivered a list of flexibility enablers regarding both formal and informal qualities of project organizations as shown in **Table 2**.


**Table 2.**

*Overview of the extended pentagon model in relation to flexibility enablers and collective learning.*

The model is dynamic and involves continuous iterative processes within the project organization and interaction with external stakeholders and contexts. The project team members receive feedback from stakeholders or the context. This feedback is interpreted both individually and collectively. Positive feedback reinforces successful practices, whereas negative feedback will lead to an attempt to alter existing practices. This multilevel process of collective learning is a process of adaptation consisting of changes in common understanding, mutual agreement, and collective action. The ability to build new knowledge, relationships, and practices in response to complex environmental challenges links (collective) learning to flexibility. In fact, collective learning may even be considered a proxy for flexibility. De Groot et al. [36] describe in their article typical identifiers of collective learning in project-oriented organizations as summarized in **Table 2**.

The enablers and indicators shown in **Table 2** resemble the aforementioned characteristics of process management (see **Table 1**). In general, adaptive project management or flexibility requires a more open approach both within the system of a project organization and through interaction with the project context.

While this might be seen to decrease the control of the project, an open approach does not necessarily lead to a loss of control, but to a different form of control. Project organizations still need a solid *structure* with clear roles and responsibilities. However, to enable flexibility, project management may lower barriers between disciplines and promote horizontal and vertical integration through cross-discipline meeting structures and decision-making processes. Project organizations still need *technologies*, such as skills, tools, and techniques to manage the project. However, the corresponding tools and infrastructure may allow for more explicit anticipation of contingencies through, for example, scenario analyses or systems that enable easy access to information throughout the project organization. Finally, there needs to be a *culture* that enables flexibility. Team members may have to get used to a (partially) new way of working. They may be encouraged to look for creative and integral solutions and to view changes as opportunities. In this, important is the organization of *interaction* through *social relations and networks* based on open information exchange leading to trust and effective collaboration within the project organization and with the project's stakeholders.

#### **6. Balancing hedging and flexing for inclusive project management**

Classic project management is based on a closed system approach, where the context is typically seen as a threat for the efficient delivering of the project output or outcome, which has to be mitigated through risk management. We referred to this as a hedging approach. However, the increasingly dynamic and engaged society requires an open (inclusive) approach, where challenges are integrated and stakeholders are involved in the development of the project. In general, opening project boundaries may lead to higher contextual complexity. A higher degree of contextual complexity needs more flexibility of the project or a more flexing style of project management. This leads to an important paradox in current project management. To efficiently manage their projects, project managers need (or are forced) to organize interaction with the project context or their community of interest, while involving more stakeholders or integrating more challenges in the project will lead to more (contextual) complexity and more uncertainty. Consequently, an important task for the project manager is to find a balanced mix between hedging and flexing tools and techniques.

**Figure 4.**

*Building blocks for inclusive project management.*

Adding to the challenge is the fact that this mix may change during the project phases, because the need for flexing and the possibilities to implement flexing tools and techniques differ per project stage. In practice, in the planning phase, the need for flexibility is relatively high because the elaboration of the project design confronts stakeholders with the concrete effects of interventions, whereas the possibilities to flex are relatively high in this phase because there are still relatively few agreements, little expenses made, and hardly any concrete results realized. As a project progresses, it becomes increasingly difficult to alter the desired project output due to, for example, ongoing agreements between stakeholders and realized project parts limiting the possibilities for other solutions. However, implementing flexing tools and techniques to engage stakeholders remains also in the latter phases important as (most) projects are realized in a continuously changing environment.

**Figure 4** gives an overview of the building blocks that become increasingly important in modern, inclusive project management; arranged in such a way that from the left to the right, tools and techniques offer more flexibility.

#### **7. Conclusion**

This chapter has provided an array of tools and techniques that can be used to compose a balanced mix of hedging and flexing for inclusive project management. As such, it provides the building blocks that help to shift the orientation of project managers from a project-problem centrality to a focus on multiple contextual problems and challenges. We argue that project organizations should always strive for project flexibility. Projects, being simple, complicated, or complex, are always potentially confronted with unexpected events. Being flexible may then be the answer to deal with these uncertainties. As discussed above, being able to create diversity and learning are key to increase project flexibility.

Projects are temporary endeavors, which means that they have a beginning and an end. As discussed, in dynamic and engaged contexts, a more open approach of project management may be necessary, which potentially leads to more diversity. However, to come to an end, this diversity has to be converged and funneled by intermediate decision-making or hedging. The real art of modern, inclusive project management is defining a balanced mix of hedging and flexing in every phase of the project.

*Project Management – New Trends and Applications*

#### **Author details**

Wim Leendertse1,2\*, Bert de Groot1,2 and Tim Busscher1

1 Faculty of Spatial Sciences, University of Groningen, Groningen, The Netherlands

2 Ministry of Infrastructure and Water Management, The Netherlands

\*Address all correspondence to: w.l.leendertse@rug.nl; wim.leendertse@rws.nl

© 2022 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

### **References**

[1] Turner R, Müller R. On the nature of the project as a temporary organisation. International Journal of Project Management. 2003;**21**(7):1-8

[2] PMI. A Guide to the Project Management Body of Knowledge and the Standard for Project Management. 7th ed. Project Management Institute: Pennsylvania, USA; 2021

[3] Stacey R. Tools and Techniques of Leadership and Management. Meeting the Challenge of Complexity. Routledge: New York; 2012

[4] Stacey R. Strategic Management and Organisational Dynamics. 7th ed. Prentice Hall: London; 2015

[5] Turner R. Gower Handbook of Project Management. 5th ed. Routledge: London, UK; 2014

[6] Morris P, Pinto J, Söderlund J. The Oxford Handbook of Project Management. Oxford, UK: Oxford University Press; 2012

[7] Van Buuren A, Buijs J-M, Teisman G. Program management and the creative art of coopetition: Dealing with potential tensions and synergies between spatial development projects. International Journal of Project Management. 2010;**28**(7):672-682

[8] Martinsuo I, Korhonen T, Laine T. Identifying, framing and managing uncertainties in project portfolios. International Journal of Project Management. 2014;**32**(5):732-746

[9] Edelenbos J, Klijn H-E, Kort M, van Twist M. Project versus process management in PPP projects. Bestuurskunde. 2007;**2007**(1):66-79 [10] Busscher T, Verweij S, Joustra G, Wesselo G. Management of Complexity in Projects of Rijkswaterstaat. Groningen: University of Groningen; 2022

[11] Pinto J. Project Management. Achieving Competitive Advantage. 4th ed. Pearson Education: Harlow, UK; 2016

[12] Freeman R, Harrison J, Wicks A, Parmar B, De Colle S. Stake-holder theory. In: The State of the Art. Cambridge, UK: Cambridge University Press; 2010

[13] Lehtinen J, Aaltonen K. Organizing external stakeholder engagement in inter-organizational projects: Opening the black box. International Journal of Project Management. 2020;**2020**(38):85-98

[14] Hillson. Effective Opportunity Management for Projects: Exploiting Positive Risk. New York: Routledge; 2004

[15] Johansson A, Bjerke Y, Landmark A. Why is it difficult to exploit opportunities in projects? In: Euram Conference 2015 proceedings. 2015

[16] Fischer R, Ury W, Patton B. Getting to Yes. Negotiation an Agreement without Giving in. Random House Group: Croydon UK; 2012

[17] Susskind L. Good for you, Great for me. Finding the trading zone and winning at win-win negotiation. New York: Public Affairs; 2014

[18] Hajer M. The need to zoom out: Understanding planning processes in a post-corporatist society. In: In the Governance of Place: Space and Planning Processes. Taylor and Francis Inc.; 2017

[19] Huemann M, Eskerod P, Ringhofer C. Rethink! Project Stakeholder Management. Newtown Square, USA: Project Management Institute Library; 2015

[20] Ansell C, Torfing J. Public Governance as co-Creation. A Strategy for Revitalizing the Public Sector and Rejuvenating Democracy. Cambridge, UK: Cambridge University Press; 2021

[21] Forester J. Challenges of deliberation and participation. Les Ateliers de l'Ethique. 2008;**2008**(2):20-25

[22] Healey P. Collaborative Planning. Shaping Places in Fragmented Societies. Palgrave MacMillan: New York; 2006

[23] Healey P. Contemporary movements in planning. In: Hillier J, Healey P, editors. Critical Essays in Planning Theory. Vol. 3. London, UK: Routledge; 2017

[24] Osborne S, Strokosch K. It takes two to tango? Understanding the co-production of public services by integrating the services management and public administration perspectives. British Journal of Management. 2013;**24**(1):31-47

[25] Voorberg W, Bekkers V, Tummers L. A systematic review of co-creation and co-production: Embarking on the social innovation journey. Public Management Review. 2014;**17**(9):1333-1357

[26] Leendertse W, Langbroek M, Arts J, Nijhuis A. Generating spatial quality through co-creation. Experiences from the Blankenburgverbinding (The Netherlands). In: Transportation Research Procedia. Elsevier; 2016

[27] Kitzi J. Cooperative strategy: Building networks, partnerships and alliances. In: Dees J, editor. Strategic

Tools for Social Entrepreneurs. Wiley & Sons, New York; 2002

[28] Edelenbos J. Proces in Vorm: Procesbegeleiding Van Interactieve Beleidsvorming over Lokale Ruimtelijke Projecten (Process Support of Interactive Policy Making in Local Area Development). Utrecht: Lemma; 2000

[29] Aaltonen K, Sivonen R. Response strategies to stakeholder pressures in global projects. International Journal of Project Management. 2009;**2009**(27):131-141

[30] Wesselink M. Handboek Strategisch Omgevingsmanagement (Handbook Strategic Stakeholder Management). Deventer: Kluwer; 2010

[31] Radulescu M, Leendertse W, Arts J. Living labs: A creative and collaborative planning approach. In: Co-creativity and Engaged Scholarship. Cham, Switserland: A. Franklin, Palgrave MacMillan; 2021

[32] Martinsuo I, Geraldi J. Management of project portfolios: Relationships of project portfolios with their contexts. International Journal of Project Management. 2020;**2020**(38):441-453

[33] Olsson NOE. Management of flexibility in projects. International Journal of Project Management. 2006;**24**(1):66-74

[34] Rolstadås A, Tommelein I, Morten Schiefloe P, Ballard G. Understanding project success through analysis of project management approach. International Journal of Managing Projects in Business. 2014;**7**(4):638-660

[35] Sohi AJ, Bosch-Rekveldt M, Hertogh M. Four stages of making project management flexible: Insight, importance, implementation and

*Balancing Hedging and Flexing for Inclusive Project Management DOI: http://dx.doi.org/10.5772/intechopen.102972*

improvement. Organization, Technology and Management in Construction. 2020;**12**(1):2117-2136

[36] De Groot B, Leendertse W, Arts J. Building adaptive capacity through learning in project-oriented organisations in infrastructure planning. Urban Planning. 2020;**5**(1):33-45

#### **Chapter 4**

## Application of Fuzzy Expert Systems in IT Project Management

*Oleksii Dudnyk and Zoia Sokolovska*

#### **Abstract**

The available statistics show the growing influence of the IT market on the world economy over the last decade. According to expert information, this situation will continue, despite the IT sector's economic crises, uneven development, and periodic fluctuations. The need to involve fuzzy expert systems (ES) in the IT field is stated, based on the high uncertainty level due to specifics of IT project management. The hypothesis of embedding ES in an IT company's business process management to increase the efficiency of operational and strategic decisions is tested. The structure of ES is offered, built on the basis of fuzzy logic using a combined model of the semantic network and implication rules. The operation of the system is demonstrated in the example of managing an IT company's current business processes to maximize its profits. Comparing the conclusions of the ES with the historical decisions of a real company demonstrates the feasibility of implementing the ES. The operation of the developed ES, using the knowledge base formed on the basis of 30 Ukrainian IT companies, confirmed the effectiveness of its use as a tool to support management decisions and increase the IT sector's financial performance.

**Keywords:** IT market, IT company, expert system, fuzzy logic, IT business processes, management decisions, project management

#### **1. Introduction**

One of the distinguishing features of recent years has been the exponential growth of digital data aggregation. This is accompanied by the expansion of big data analytics, artificial intelligence, cloud computing, and digital platforms. As more devices access the Internet and the number of people using digital services grows, the role of digital data and technology is becoming more widespread, and the digital economy is evolving at a breakneck pace [1]. The information and communication technology (ICT) industry is at the heart of much of this activity, supporting the digital economy and serving as a reliable measure of its effectiveness.

ICT plays a crucial role in the economy not only as a source of potential income but also as a vector of cross-growth, making profound changes in various sectors of the economy. Technologies such as the Internet of Things, robotics, artificial intelligence, cloud computing, big data analysis, 3D printing, and many others are already changing the way businesses design, produce and provide services.

Despite how important IT projects are to all aspects of the modern world, their management is not an ideal process. A recent survey conducted by Standish Group showed that 19% of over 50,000 software projects are failed and never completed [2]. At the same time, over the previous 10 years, the percentage of failures varied from 17–22%, which indicates the regularity of this problem in software engineering [3]. In the context of numerous crisis phenomena of the world economy, against the background of these trends, the importance of the main subjects in the IT industry (product and outsourcing IT firms) and tools to improve the efficiency of their operational business processes is growing. One of the innovative directions is the use of technologies like ES in the management processes to better plan and execute project development. Although the use of expert systems in economics and management is not entirely new, the dynamics of research and application of this artificial intelligence apparatus over the past 20–40 years have undergone significant changes and fluctuations—from discovery and active development to a significant decline, and again to the current trend of scientific recovery and the practical interest of specialists in various fields.

Accordingly, the tasks of the analysis of the history of development and use of expert systems in IT project management are set. The expediency and prospects of using the ES in the management of business processes in IT companies as innovative management methods that take into account the vagueness and uncertainty of the information environment of the facilities are proven. The positive impact of the introduction of intelligent technologies, including fuzzy ones, on the management processes of IT companies is demonstrated, which is reflected in the main financial indicators of their operation.

The article is organized as follows. Section 2 confirms the relevance of embedding expert systems in the overall business process management of IT companies. A retrospective of ES research and examples of applications of specific applications in various fields of economics and management are presented. Section 3 discusses the working hypotheses of the study; the ES architecture developed on the basis of fuzzy logic is offered. Section 4 provides a statement of the simulated situation, which is used for expert consultations using the appropriate knowledge base; an example of forming a knowledge base is described based on information provided by 30 IT companies of Ukraine, as well as using the expertise of agile specialists; the conclusions of the fuzzy expert system obtained as a result of its implementation (expert consultations) and historical decisions made by a functioning IT company are presented. Section 5 provides a comparative analysis of the results of the expert system inference conclusions and the real conclusions of a functioning IT company. Section 6 is devoted to outlining potential ways of further research to determine the useful consequences of the implementation of the proposed mathematical apparatus.

#### **2. Historical analysis and overview**

#### **2.1 IT project management research analysis**

The characteristic features of a software project are a large amount of research and development work, high uncertainty in the type, timing and cost of work, significant risks, and high costs. On top of that software development is associated with a high degree of complexity in a constantly changing environment. Thus, software projects demand effective management using innovative approaches.

#### *Application of Fuzzy Expert Systems in IT Project Management DOI: http://dx.doi.org/10.5772/intechopen.102439*

Problems of IT project management are researched in many literature sources. Tam et al. in Ref. [4] conducted a survey of 216 agile professionals and identified the main human factors for the success of agile software development projects. In Ref. [5] Fink and Pinchovski presented an empirical study of the bias of the decision to save time in a software development project by increasing the speed of development and proposed methods to combat this bias. In Ref. [6] Hoffmann et al. presented the principles of designing strategically consistent and effective, but flexible portfolios of IT projects. Einhorn et al. in Ref. [7] consider the importance of taking into account the business case throughout the project life cycle and also provides valuable information on ways to avoid common mistakes and achieve the planned strategic benefits of the project. Lin et al. explore in Ref. [8] how to improve the integration of knowledge by actively addressing the problem of project uncertainty and proposes different management regimes, taking into account the types of uncertainty. In Ref. [9] Bjorvatn and Wald conducted an empirical study of the relationship between project complexity and management efficiency and determined the crucial importance of absorption capacity at the team level. Keil et al. in Ref. [10] research the impact of project management constraints on the possible escalation of software projects. In their work, Tavares et al. [11] analyzed different risk management strategies carried out in Scrum software projects and developed a novel risk management framework.

One of the key issues faced by both software developers and customers is to consider the degree of risk inherent in the various stages of IT project deployment. In [12–17] the classification of risks, their sources—related to incorrect determination of project volumes [13], excess of project costs [14], errors in budget planning [15, 16], deviations from deadlines performance [17].

Several works are devoted to automating some parts of IT project management activities. Alba and Chicano in Ref. [18] applied genetic algorithms to optimally allocate resources for IT projects. Uzzafer in Ref. [19] presented a simulation model for strategic IT project management. The results of the simulation determine the budget and schedule required for a project.

In the process of preparing and implementing a software project, the manager is forced to make decisions in conditions of uncertainty, based on incomplete or inaccurate information about the current state and prospects of the project's development. It is possible to improve the quality of the decisions made by integrating an intelligent component—an expert system—into the decision-making process. However, the use of expert systems in the process of IT project management is almost beyond the attention of researchers.

#### **2.2 Expert system research and usage in IT project management**

An expert system is a computer program that, based on the rules laid down in its knowledge base, can give reasonable advice and suggest a solution to a problem. The use of the expert system as a decision support tool is justified for solving problems that cannot be solved based on analytical calculations.

Work on the creation of expert systems began in the early 1950s by Newell et al. [20], who developed a common problem solver for solving problems of elementary logic, proving theorems, and playing chess. This approach underestimated the role of specific knowledge in reasoning. Aware of the possibilities, research has been conducted in more specific areas of knowledge, such as medicine and chemistry. The first expert system was developed in 1965 by Feigenbaum et al. [21] and was intended for the analysis of chemical compounds. Since then, the range of applications of expert systems to industrial and commercial problems has become so widespread that they have become one of the most successful commercial areas of artificial intelligence. Some examples of the ES use in various areas of business are discussed below.

One example of the ES application in management is the software application Business Insight [22]—an expert system to support decision-making and strategic planning. Insight business presents the user with opportunities for strategic analysis, business monitoring; identification of key factors influencing business success; strengths and weaknesses of the business; obtaining the results of forecasts for the implementation of various business strategies. Starting with the user's answer to the questions asked by the system during the introduction, it can conduct a number of analyzes, providing the user with practical understanding and advice on his business and marketing strategies. The system also shows the progress of its logic for each comment or recommendation it makes.

In Ref. [23] Rao et al. present an expert system called PAT (productivity assessment technology), which provides a comprehensive analysis of project effectiveness. PAT uses the same logical process as a specialist in this field would identify the causes of good or bad performance. The proposed system also recommends corrective action and provides the user with explanations or justifications for the results.

When discussing the pros and cons of expert systems, most researchers focus on the list of advantages of expert systems and pay less attention to the disadvantages. In Ref. [24] Zarandi et al. focus on the weaknesses of expert systems, namely:


One of the methods of combating these shortcomings is a combination of expert systems with methods and techniques of machine learning and artificial intelligence. For example, fuzzy logic can be used to manage uncertainty in expert systems and solve problems that cannot be effectively solved by conventional methods [25]. The main purpose of fuzzy expert systems is to use human knowledge to process uncertain and ambiguous data. Fuzzy expert systems have a history of use in various fields, in particular in economics and IT.

One of the potential areas of ES and fuzzy ES applications is IT projects management and their inherent business processes. Information technology projects are particularly prone to failures due to their specific characteristics, such as the lack of clear constraints, the complexity and abstractness of tasks, and the extremely rapid pace of technological progress. These factors increase the uncertainty, inaccuracy, and subjectivity in information technology projects and require the search for new management methods. Here are some examples of the ES application in the field of information technology.

The work of Dufner et al. [26] discusses the PMA expert system (Project Management Advisor), which can improve control over the IT project by evaluating the proposed project plan, identifying anomalies, and providing guidance for correction.

The PMA was developed as part of the CyberCollaboratory [27], built to facilitate collaborative design work. The PMA was approved by industry experts involved in the knowledge acquisition process and evaluated on 11 realistic project plans. The results showed a clear ability to detect anomalies in the project plan. The PMA also provided explanations and suggested corrective action.

Truicǎ and Barnoschi present in Ref. [28] an expert system for recruiting IT specialists, which helps the human resources department to perform the recruitment of qualified specialists, assessing their skills, and offering advice on appointments. The system is designed to work in the field of information technology. Checking the accuracy of the system showed that the system selected the same three best job candidates as the expert person.

The work of Rodríguez et al. in Ref. [29] proposes a new method of risk assessment for the analysis of projects in the field of IT. The proposed method is based on a combination of a fuzzy process of analytical hierarchy and a system of fuzzy inference, benefiting from their advantages and minimizing their disadvantages. The proposed model takes into account different levels of uncertainty, the relationship between groups of risk factors, and the possibility of adding or suppressing variations without losing consistency with previous estimates. A case study of three actual IT projects showed the suitability and consistency of the proposed method results.

However, despite the fact that the field of information technology is very promising for the use of fuzzy expert systems, a review of the literature shows extremely little use of this apparatus in this area.

#### **3. Fuzzy expert system application design**

Historical review of the development and use of expert systems show both the prospects of the direction and the lack of attention to it. Next, we will focus on the architecture, methodological platform, and usage of the developed application—a fuzzy expert system. We will prove the possibilities and efficiency of its use in the business process management of a typical IT company.

Further considerations are based on the following hypotheses:


Classical ES architecture based on inference: Database with initial information necessary to get an output; base of facts for the preservation of intermediate results; knowledge base with information on inference process through the knowledge base and fact base, and the core of inference (see **Figure 1**). The most important components that make sense to explore are the knowledge base and the core inference.

One of the disadvantages of the classical inference architecture is the constant need to access the database to obtain the necessary information to calculate and maintain the database of facts in the current state. The second disadvantage creates unnecessary questions about the structure and ways to maintain a database of facts, which can be physically part of the knowledge base, which is illogical, or part of the database, which increases the load on the database.

It is possible to get rid of both shortcomings by reviewing how to work with the knowledge base and ways to maintain it. Instead of using crisp inference rules, there is a possibility to use a combination of fuzzy inference rules and simplified linguistic variables, which will be described below. This structure of the knowledge base allows getting rid of the intermediate facts database, which was closely related to the need to store intermediate information in order to have permanent access to the database.

#### **3.1 Knowledge base structure**

Before moving on to the use of semantic networks for fuzzy inference core, consider the second important component—the knowledge base. In the terminology of fuzzy expert systems, the knowledge base is a set of inference rules and linguistic variables, on the basis of which the mechanisms of direct and inverse inference work. A production rule can be defined as an IF-THEN structure that links information or facts in an IF part to certain actions or information in a THEN part. Thus, the base of production rules can be composed of an unlimited number of rules of the form:

$$IF\left(X = A\right) \text{ THEN } (Y = C),\tag{1}$$

*X*, *Y* are linguistic variables;*A*, *C* are fuzzy linguistic equivalents of some crisp value associated with the corresponding linguistic variable.

The second part of the knowledge base is a set of linguistic variables that consists of an unlimited number of variables of the form:

*X* : *Initial* : ½ � *A* : *Trapezoidal* : ð*A1*, *A2*, *A3*, *A4*Þj*B* : *Trapezoidal* : ð Þ *B1*, *B2*, *B3*, *B4* , (2)

*X* is a linguistic variable;*Initial/Derivative* indicates that linguistic variable value will be taken, for example, from a database or the value of which will be derived in the process of working with the knowledge base;*A: Trapezoidal:(A1,A2,A3,A4) and B: Trapezoidal:(B1,B2,B3,B4)* are the fuzzy membership functions;*A, B* are sets of values for a linguistic variable *X*;Trapezoidal indicates a trapezoidal type of membership function used to describe the values of a linguistic variable;*(A1,A2,A3,A4), (B1,B2,B3, B4)* are crisp values behind the fuzzy values of *A* and *B*, respectively.

This structure of the knowledge base has several very important features. First, it is possible to expand and reuse. The knowledge base can be expanded with new knowledge in the transition from specialist to specialist. Second, it is a potential opportunity to combine a knowledge base and a database to simplify the creation of a knowledge base based on production rule templates and linguistic variables. In this case, it will be possible to use rule templates instead of the structures of inference rules and linguistic variables described earlier, which will significantly speed up the process of creating a typical content of the knowledge base.

#### **3.2 Inference core: SNePS**

Next, we consider the process of fuzzy inference, namely the use of semantic networks for fuzzy inference. Semantic networks have been developed to present knowledge of an intelligent system that uses natural language. For the fuzzy inference problem, it was decided to use the SNePS semantic network processing system from the study of Shapiro and Rapaport [30], which is a denoted directional graph in which nodes represent concepts and arcs represent binary relationships between concepts. A feature of the SNePS semantic network is access to the database once to obtain the initial data. The inference rule can be represented in a graph through the nodes of the rule itself, the formulas of the input and output arguments, as well as the arcs that pass from the nodes of the rule to the nodes of the arguments. We should not forget about the connection between the rules due to the inclusion of linguistic variables from the right or left part of one rule in the right or left part of another rule. If the left part of one rule occurs in the right part of the second, the second rule is called the predecessor. Otherwise—a follower. Consider the following example and semantic network for this set of rules (see **Figure 2**):

*R1: IF (A1) THEN (B1) R2: IF (A2 AND A3) THEN (B2) R3: IF (B1 AND B2) THEN (C1)*

Rule *R1* is an equivalence rule, which means the following—if the predecessor is *TRUE*, then the successor also becomes *TRUE*. Rules *R2* and *R3* are general inference rules, which means that each predecessor must be *TRUE* for the followers to be *TRUE*.

Inference graphs were proposed and developed by Schlegel and Shapiro in Ref. [31] as extensions of propositional graphs. An inference graph is a graph of reasoning that is capable of inverse, direct, and bidirectional inference. It can support parallel processing for reasoning using inference logic. Inference graphs modify propositional graphs by adding channels between nodes along possible inference paths. Channels carry priority messages to transmit new information from one node to another. Message priorities affect the order in which tasks are performed so that messages are executed closer to the inference output and the inappropriate output tasks are canceled. A rule node is capable of performing inference operations using a set of rules known as Rule Usage

**Figure 2.** *Semantic network for a set of rules.*

Information (RUI) [32]. RUIs contain information about which predecessors are true *TRUE* or *FALSE*, as well as information that explains how these values were derived. When a new RUI is created, it is combined with a set of existing ones. The resulting combination is used to determine whether the inference rule node can be used again.

For fuzzy inference in the developed system, only the direct inference process is used. Therefore, the structure of the inference graphs can be simplified:


**Figure 3** represents a graph from **Figure 2** with the corresponding channels. Channels allow predecessors to report rule nodes when it was calculated and also allow rule nodes to report that they have been calculated. With this use of the semantic network, the dependence on the initial data in the database is reversed so that the core of the inference mechanism, that is, the semantic network, does not need to

**Figure 3.** *Semantic network for a set of rules with channels.*

*Application of Fuzzy Expert Systems in IT Project Management DOI: http://dx.doi.org/10.5772/intechopen.102439*

**Figure 4.** *Modified inference mechanism.*

constantly query the data, but only rely on existing initial data and the potential for external expansion during the inference process. Thus, the general architecture of the developed fuzzy ES<sup>1</sup> is shown in **Figure 4**.

More information on the proposed architecture can be found in the authors' work on a detailed review of the methodology for creating a fuzzy expert system application suitable for work in the IT field combined with the Stage-Gate framework [33].

#### **4. Application of fuzzy expert systems in IT project management**

On the example of one of the expert consultations, we will demonstrate the work of an expert system based on fuzzy logic using a combined model of the semantic network SNePS (Semantic Network Processing System) and fuzzy inference rules.

Consider the following problem statement for an IT company. The model situation for projects is the availability of five teams (CycleDuo, Templater, Avion, Howl, and Converge) to develop existing and potential projects. A new team (Emerald) was also hired during the year, increasing the total number of available teams to six. The current market situation is to select five projects (Genesis, Crowding, Firantis, Exploration, and Hymera) from two customers (Mazzle, Global State). Also, additional information is provided on costs not directly related to current projects, namely the costs inherent in the maintenance of the office, administrative staff, and the cost of various advertising campaigns. Given the available data, the IT company faces the task of finding the best way to maximize annual profits.

According to the above problem statement, we will demonstrate the results of using a fuzzy expert system based on modeled data and compare those results with

<sup>1</sup> Source code of developed fuzzy expert system could be found at https://github.com/frightempire/ FuzzyExpert.


#### **Table 1.**

*Net revenue calculation indicators.*

real historical data. To prove the success of the proposed method, it is necessary to find a way to measure its performance. In this example, it is advisable to consider the criterion of net profit as a measure of the effectiveness of the task of maximizing the company's profits [34]. Next, consider in more detail the process of calculating net revenue.

First, consider the main indicators involved in the calculation of net revenue. **Table 1** provides a general description of these indicators [35].

Let us start with the calculation of gross revenue:

$$\text{Gross revenue} = \text{total revenue} - \text{COGS},\tag{3}$$

where the value of total revenue can be obtained by summing the planned annual profit from projects in development, and the cost of goods sold in our case is the cost of services, that is, the total cost of compensation for teams working on projects in development.

Given the value of gross revenue, it is possible to calculate the value of net revenue:

$$\text{Net revenue} = \text{gross revenue} - \text{operating expenses},\tag{4}$$

where operating expenses in our case are the costs of advertising campaigns and assets in the form of office space and administrative staff.

Thus, based on the indicators for which data are available, we can formulate the following method of calculating net revenue:

$$\text{Net revenue} = \text{total revenue} - \text{COGS} - \text{operating expenses}.\tag{5}$$

#### **4.1 Knowledge base creation process**

To fill the knowledge base we used a combination of project managers' expertise and leading research results in the field of software project management (described in Section 2). Combining research data with information provided by management specialists from approximately 30 Ukraine IT companies, which describes the general structure of business processes during the management of the project portfolio within the IT company, a knowledge base was formed. Knowledge base corresponds to the IF-THEN structure and is aimed at solving a specific task of maximizing the profits of a typical IT company.

Templates for creating a knowledge base are as follows:


#### **4.2 Fuzzy expert system implementation results**

As a usage result of a fuzzy expert system, the following recommendations were received from the system:


#### **4.3 Modeled historical data**

The available historical data were provided by the HYS Enterprise B.V.<sup>2</sup> IT company and is based on an annual breakdown of data close to real data, namely:


Approximate available data on planned annual revenues from projects can be found in **Table 2**. Monthly compensation of teams, annual expenses of supporting assets in the form of office and administrative staff, as well as monthly expenses of active advertising campaigns are provided in **Table 3**.

The value of the annual net revenue was provided already calculated, but for visualization, we will perform this calculation again. This will help to make a similar calculation in the case of expert system usage. Before the calculation, we briefly describe the historically made decisions based on the data described in **Tables 1** and **2**:

<sup>2</sup> All data are not real, but close to real. Any similarity to real data is a coincidence. HYS Enterprise B.V. is not responsible for the correctness or sharing of the methods proposed in this work, as well as for the quality of the results obtained on their basis. If any questions about described methods, test data, or results occur, it is recommend to contact the authors.


#### **Table 2.**

*Planned annual revenues from potential projects.*


#### **Table 3.**

*Expenses by different categories.*


First, we calculate the planned total revenue based on the planned annual revenues from the projects. Already existing projects are also taken into account in the calculations regardless of their completion date. Another interesting point is the failure of the Crowding project by the Avion team due to the combination of high risk of interaction with the customer Mazzle and the Avion team. Thus, the Crowding project is not taken into account in the calculations:

$$\begin{aligned} \text{Total revenue} &= \mathbf{12} \times \mathbf{1000} \times (\mathbf{150} + \mathbf{90} + \mathbf{50} + \mathbf{45} + \mathbf{35}) + \mathbf{12} \times \mathbf{1000} \times (\mathbf{350} + \mathbf{285} + \mathbf{320}) \\ &= \mathbf{1,640,000} \text{s} \end{aligned}$$

Now we calculate the annual cost of goods sold, which in this example is the sum of the compensation of the teams involved in the development. Teams involved in the development of current projects that have not yet been completed are also taken into account in this calculation:

$$\text{COGS} = 12 \times 1000 \times (7 + 4 + 12 + 8 + 3 + 5) = 468,000 \text{s}.\tag{7}$$

(6)

It remains to calculate the operating expenses, which consist of advertising campaigns, office support, and administrative staff expenses:

$$\begin{array}{l} \text{Operating expenses} = 12 \times 1000 \times (18 + 15) + 1000 \times (12 + 50 + 90 + 15) \\ = 563,000 \text{s} \end{array} \tag{8}$$

All indicators necessary for calculation of net revenue are prepared:

$$\text{Net revenue} = 1,640,000\\$ - 4\text{€},000\\$ - \text{\$5\%},000\\$ = \text{609},000\\$.\tag{9}$$

#### **5. Results**

Here we will consider in what aspects the historical solutions coincide and differ with solutions proposed by the expert system and will demonstrate the effects of those differences. Let us briefly summarize the differences in decision making:


Other expert system decisions are similar to decisions from historical data. The first major difference is in finding a team for the Crowding project. The expert system analyzed the risk of cooperation with the customer and existing teams and concluded that due to a combination of high risks it is less risky to hire a new team to implement the project than to appoint one of the existing ones. Thus, the probability of successfully completing the project and avoiding the situation demonstrated in the historical data on the failure of the Crowding project due to incompatibility with the Avion team increases. Given this information, the Avion team was tasked with working on the Firantis project.

The next difference is a proposal to abandon the active office. This decision was made after analyzing the risks of working with current teams and obtaining a low overall risk. The usefulness of current advertising campaigns is analyzed. The budget for the social media campaign has been expanded, which on the one hand increases expenses, but due to high utility and small investments creates the most favorable environment for finding new teams and customers. This in the long run leads to a more rapid expansion of the company and increases the likelihood of finding a customer, which will increase the value of total revenue. Due to the average level of utility and costs, it was decided to leave the budget of university advertising campaigns unchanged. After analyzing the low level of utility and high costs of the campaign through conferences, the expert system made an unequivocal decision to abandon this type of campaign.

Next let us make similar calculations of net revenue, taking into account the implementation of the expert system recommendations. But it should be borne in mind that since the data are historical, the implementation of the expert system is modeled. Based on these calculations, we can observe the impact of these decisions on the value of total profit and operating expenses.

We calculate total revenue based on planned annual revenues from existing and potential projects. In contrast to real historical data, the Crowding project corresponds to a team with a lower risk of cooperation, which suggests a higher probability of successful completion of the project. Thus, in this calculation, the Crowding project is taken into account:

$$\begin{aligned} \text{Total revenue} &= 12 \times 1000 \times (150 + 90 + 50 + 45 + 35) + 12 \times 1000 \times (350 + 250 + 285 + 320) \\ &= 1,890,000 \text{s} \end{aligned}$$

(10)

The calculation of the compensation amount of the teams involved in the development does not differ from the calculation of historical data. After all, the same teams are involved in the development. The amount of compensation is:

$$\text{COGS} = 468,000 \text{\\$}.\tag{11}$$

Thus, we immediately proceed to the calculation of operating expenses. The difference from historical data is the proposal to abandon the active office, as well as the advertising campaign through conferences. At the same time, do not change the

budget for university advertising campaigns. We are reducing the budget for university advertising campaigns compared to historical data from \$50,000 to \$30,000, which is the size of this budget before expansion. We are expanding the budget for an advertising campaign on social networks in approximately the same proportions from \$12,000 to \$20,000. Refusing an advertising campaign through conferences and office support, we generally have:

Operating expenses ¼ 12 � 1000 � 15 þ 1000 � ð Þ¼ 20 þ 30 230, 000\$*:* (12)

All indicators necessary for calculation of net revenue are prepared:

Net revenue ¼ 1, 890, 000\$ � 468, 000\$ � 230, 000\$ ¼ 1, 192, 000\$*:* (13)

Comparing historical data and implementation results, we can see that the total profit increased by \$250,000. In turn, operating expenses decreased by \$333,000. Thus the total increase in annual net revenue is \$583,000.

#### **6. Conclusions**

The role of the main subjects in the industry—IT companies—and the level of management of their business processes are growing. Effective management will help to achieve the strategic goals of companies and strengthen their financial stability. The analysis of the instrumental base for support of management decision-making in the conditions of uncertainty and risk brings to the fore the use of expert systems. At the same time, fuzzy expert systems built using methods and models of fuzzy logic seem to be the most effective.

Historical review of research and applications of this mathematical apparatus has shown only some examples of its use in the field of IT—a "bottleneck" that must be overcome because the feasibility of implementing intelligent technologies is confirmed by many factors. Among the main ones—the ability to present available information in linguistic form, smoothing insufficient or missing information, the institutional memory of the ES with tools to supplement and modify it, the presence of built-in mechanisms (for various architectures and algorithms) decision-making, metacomponent to explain expert advice, a library of precedents for adjusting the adoption of previous management decisions with the involvement of expert data, etc.

Given the need and feasibility of implementing the apparatus of fuzzy ES in IT project management, a fuzzy ES application was developed. The main difference between the developed application and the existing one is the proposal of the architectural model of the ES with a modified mechanism of fuzzy inference. This significantly speeds up the process of fuzzy inference and reduces the duration of expert consultations. The effectiveness of the proposed fuzzy ES application is demonstrated by the example of a modeled situation of maximizing the revenue of an IT company in specific circumstances—the business process environment associated with the implementation of current projects.

Currently, the experimental operation of the developed expert system application is carried out on the basis of a number of IT companies. Topics of expert advice on IT business process management include a wide range of tasks, such as search and monitoring of projects (selection of customers, teams, and other resources), forming a balanced portfolio of the company, assessing the status of projects, ensuring strategic goals and improving (in particular, financial) indicators of its activity, etc.

The experience gained based on the sector of outsourced IT companies allowed us to propose a methodology for embedding the ES application in the overall management loop within the Stage-Gate framework, which increases the efficiency of the system.

Further improvement of the application is carried out in the following areas:

	- Combining fuzzy and crisp calculations;
	- Integration with the metacomponent of historical analysis;
	- Increasing the flexibility of the fuzzy model for knowledge base creation.

In essence, expert systems belong to the reusable apparatus. Their effectiveness as a management tool increases with the enrichment of knowledge and databases through the introduction of new experiences. The rapid development of the IT industry, specification, and standardization of software development processes at the global level provides a fundamental basis for the exchange, reproduction, and implementation of intelligent technologies with elements of fuzzy logic.

### **Acknowledgements**

We would like to show gratitude to HYS Enterprise B.V.™ for providing modeled historical data for the purposes of this research and validation of the proposed fuzzy ES and its practical relevance.

### **Author details**

Oleksii Dudnyk\* and Zoia Sokolovska Department of Economic Cybernetics and Information Technologies, Odessa National Polytechnic University, Odessa, Ukraine

\*Address all correspondence to: dudnyk.o.o@op.edu.ua

© 2022 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

### **References**

[1] Digital Economy Report 2019 [Internet]. UNCTAD; 2019. Available from: https://unctad.org/system/files/ official-document/der2019\_en.pdf [Accessed: December 04, 2021]

[2] Portman H. Review Standish Group— CHAOS 2020: Beyond Infinity [Internet]. 2021. Available from: https:// hennyportman.wordpress.com/2021/01/ 06/review-standish-group-chaos-2020 beyond-infinity/ [Accessed: December 04, 2021]

[3] The Standish Group. CHAOS Report 2015 [Internet]. 2015. Available from: https://www.standishgroup.com/sample\_ research\_files/CHAOSReport2015-Final. pdf [Accessed: December 04, 2021]

[4] Tam C, Moura EJ da C, Oliveira T, Varajão J. The factors influencing the success of on-going agile software development projects. International Journal of Project Management. 2020; **38**(3):165-176. DOI: 10.1016/j.ijproman. 2020.02.001

[5] Fink L, Pinchovski B. It is about time: Bias and its mitigation in time-saving decisions in software development projects. International Journal of Project Management. 2020;**38**(2):99-111. DOI: 10.1016/j.ijproman.2020.01.001

[6] Hoffmann D, Ahlemann F, Reining S. Reconciling alignment, efficiency, and agility in IT project portfolio management: Recommendations based on a revelatory case study. International Journal of Project Management. 2020;**38**(2):124-136. DOI: 10.1016/j.ijproman.2020.01.004

[7] Einhorn F, Marnewick C, Meredith J. Achieving strategic benefits from business IT projects: The critical importance of using the business case across the entire project lifetime.

International Journal of Project Management. 2019;**37**(8):989-1002. DOI: 10.1016/j.ijproman.2019.09.001

[8] Lin L, Müller R, Zhu F, Liu H. Choosing suitable project control modes to improve the knowledge integration under different uncertainties. International Journal of Project Management. 2019;**37**(7):896-911. DOI: 10.1016/j.ijproman.2019.07.002

[9] Bjorvatn T,Wald A. Project complexity and team-level absorptive capacity as drivers of project management performance. International Journal of Project Management. 2018;**36**(6):876-888. DOI: 10.1016/j.ijproman.2018.05.003

[10] Keil M, Rai A, Cheney Mann JE, Zhang GP. Why software projects escalate: The importance of project management constructs. IEEE Transactions on Engineering Management. 2003;**50**(3):251. DOI: 10.1109/TEM.2003.817312

[11] Tavares BG, da Silva CES, de Souza AD. Risk management analysis in Scrum software projects. International Transactions in Operational Research. 2019;**26**(5):1. DOI: 10.1111/itor.12401

[12] Rosenau MD, Githens GD. Successful Project Management: A Step-By-Step Approach with Practical Examples. 4th ed. United States: Wiley; 2005

[13] Mirza MN, Pourzolfaghar Z, Shahnazari M. Significance of scope in project success. Procedia Technology. 2013;**9**:722-729. DOI: 10.1016/j.protcy. 2013.12.080

[14] Bloch M, Blumberg S, Laartz J. Delivering large-scale IT projects on time, on budget, and on value. McKinsey Quarterly. 2012;**27**:2-7

[15] Charette RN. Software Engineering Risk Analysis and Management. USA: McGraw-Hill, Inc.; 1989

[16] Pfleeger SL, Atlee JM. Software Engineering: Theory and Practice. 4th ed. USA: Pearson; 2010

[17] Arnuphaptrairong T. Top ten lists of software project risks: Evidence from the literature survey. In: Proceedings of the International MultiConference of Engineers and Computer Scientists. Hong Kong: IAENG (International Association of Engineers); 2011. pp. 1-6

[18] Alba E, Francisco Chicano J. Software project management with GAs. Information Sciences. 2007;**177**(11): 2380. DOI: 10.1016/j.ins.2006.12.020

[19] Uzzafer M. A simulation model for strategic management process of software projects. Journal of Systems and Software. 2013;**86**(1):21. DOI: 10.1016/j. jss.2012.06.042

[20] Newell A, Shaw JC, Simon HA. Report on a general problem solving program. In: Proceedings of the International Conference on Information Processing. Santa Monica, California, U.S.: RAND Corporation; 1959. pp. 256-264

[21] Feigenbaum E, Buchanan B, Lederberg J. On generality and problem solving: A case study using the DENDRAL program. Machine Intelligence. 1970;**6**:1

[22] McNeilly M, Gessner S. Business Insights™: An expert system for strategic analysis. Planning Review. 1993;**21**(2):32-33. DOI: 10.1108/ eb054410

[23] Rao MP, Miller DM, Lin B. PET: An expert system for productivity analysis. Expert Systems with Applications. 2005; **29**(2):300-309. DOI: 10.1016/j.eswa. 2005.04.003

[24] Zarandi MHF, Asl AAS, Sotudian S, Castillo O. A state of the art review of intelligent scheduling. Artificial Intelligence Review. 2020;**53**(1):501-593. DOI: 10.1007/s10462-018-9667-6

[25] Zadeh LA. The role of fuzzy logic in the management of uncertainty in expert systems. Fuzzy Sets and Systems. 1983; **11**(1-3):199-227. DOI: 10.1016/S0165- 0114(83)80081-5

[26] Dufner D, Kwon O, Doty A. Improving software development project team performance: A Web-based expert support system for project control. In: Proceedings of the Hawaii International Conference on System Sciences. Manhattan, New York, U.S.: IEEE Comp Soc; 1999. p. 6. DOI: 10.1109/ HICSS.1999.772622

[27] Dufner D, Kwon O, Hadidi R. Development and implementation of a WEB-enabled CyberCollaboratory for asynchronous teams (Web-CCAT). In: Proceedings of the Thirty-First Hawaii International Conference on System Sciences. Kohala Coast, HI, USA: IEEE; 1998. pp. 330-339. DOI: 10.1109/HICSS. 1998.653116

[28] Truicǎ CO, Barnoschi A. Innovating HR using an expert system for recruiting IT specialists—ESRIT. Journal of Software & Systems Development. 2015; **2015**:1-11. DOI: 10.5171/2015.762987

[29] Rodríguez A, Ortega F, Concepción R. A method for the evaluation of risk in IT projects. Expert Systems with Applications. 2016;**45**: 273-285. DOI: 10.1016/j.eswa.2015. 09.056

[30] Shapiro SC, Rapaport WJ. The SNePS family. Computers and

*Application of Fuzzy Expert Systems in IT Project Management DOI: http://dx.doi.org/10.5772/intechopen.102439*

Mathematics with Applications. 1992;**23** (2-5):243-275. DOI: 10.1016/0898-1221 (92)90143-6

[31] Schlegel DR, Shapiro SC. Concurrent reasoning with inference graphs. In: Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). New York, U.S.: Springer Verlag; 2014. pp. 138-164. DOI: 10.1007/978-3-319-04534-4\_10

[32] Choi J, Shapiro SC. Efficient implementation of non-standard connectives and quantifiers in deductive reasoning systems. In: Proceedings of the Twenty-Fifth Hawaii International Conference on System Sciences. Vol. 1. Manhattan, New York, U.S.: Institute of Electrical and Electronics Engineers (IEEE); 1992. pp. 381-390. DOI: 10.1109/ HICSS.1992.183186

[33] Sokolovska Z, Dudnyk O. Devising a technology for managing outsourcing IT-projects with the application of fuzzy logic. Eastern-European Journal of Enterprise Technologies. 2021;**2** (3(110)):52. DOI: 10.15587/ 1729-4061.2021.224529

[34] Net revenue [Internet]. Farlex Financial Dictionary. Available from: https://financial-dictionary. thefreedictionary.com/Net+revenue [Accessed: November 07, 2021]

[35] Farlex Financial Dictionary [Internet]. Available from https:// financial-dictionary.thefreedictionary. com [Accessed: November 07, 2021]

#### **Chapter 5**

### Program Management Integrated with Data and Decision Sciences

*Tien M. Nguyen, John D.T. Nguyen, My T.N. Nguyen, Charles H. Lee and Tam Nguyen*

#### **Abstract**

Program management (PM) complexity depends on the budget size and program types. In general, the program types can be classified into three categories, namely, defense, commercial, and civilian types. This chapter presents and discusses an approach for integrating the PM discipline areas with emerging data science and decision science1 (DDS) for any program type. Additionally, we describe the key PM areas and present a corresponding generalized model consists of a list of multiple PM discipline areas that can be tailored for any program types. To demonstrate the PM-DDS integration approach, we focus on three key PM areas and corresponding PM discipline areas related to schedule, cost, and risk management. These three discipline areas are analyzed to identify appropriate program elements that can be enhanced using existing DDS technology enablers (TEs). We also propose a flexible PM-DSS integration framework by leveraging existing machine learning operations (MLOps) framework. The proposed integration framework is expected to allow for enhancing the program planning and execution by reducing the program risk using a wide range of DDS TEs, including big data analytics, artificial intelligence, machine learning, deep learning, neural networks, and artificial intelligent.

**Keywords:** program management, defense, civilian, commercial, program management model, program risk management, program schedule management, data science, decision (support) science, big data analytics, artificial intelligent, deep learning, neural networks, machine learning operations (ML ops)

#### **1. Introduction**

Traditionally, program management (PM) usually addresses a group of several related projects that are meant to achieve an organization's goals and business objectives when integrated them together. A project management is usually deals with a single short-term period of performance (PoP) focused on specific objective(s) and related delivery schedules, quality, and cost controls. In contrast, PM deals with a much longer-term PoP with an emphasis on the integration of all the short-term projects

<sup>1</sup> a. k. a. data and decision sciences and abbreviated as DDS throughout the chapter.

to achieve an overall benefit to the organization. In another word, PM addresses the outcomes of all deliverables obtained from a group of short-term projects.

PM for a sizable budget program (i.e., above 50 Mil USD) regardless of the program type (i.e., defense vs. commercial vs. civilian) is a complex task. As an example, it is usually involved with the nine basic PM areas [1], including (i) managing enterprise, organizational, and program goals, (ii) managing program financial goals, (iii) managing program risk (a.k.a. risk management), (iv) managing program schedule (a.k.a. Schedule Management), (v) managing technical/product performance, (vi) developing and managing program team, (vii) managing performance and quality assurance (QA), (viii) managing internal and external communications, and (ix) managing program integration. These PM areas can be tailored to any specific acquisition system such as DoD acquisition system [2, 3], NASA acquisition system [4], acquisition of commercial products and commercial services for US government agencies [5–7], and commercial procurement process for commercial systems acquisition for private companies [8]. Section 3 provides detailed description of the key PM areas. For defense and civilian acquisition systems, such as US Department of Defense (DoD) and NASA, a program manager can decompose these nine PM areas into at least 13 PM discipline areas [1–7], consisting of (i) system engineering related to the system being acquired; (ii) contracts and legal dealing with contractors, suppliers, and stakeholders; (iii) financial and cost management; (iv) schedule management; (v) system test and evaluation, (vi) logistics and supply chain management, (vii) production, quality, and manufacturing (PQM) management, (viii) program risk management, (ix) intelligence and security management, (x) software management, (xi) business and marketing practices, (xii) configuration management, and (xiii) information technology management. The program manager must have a good understanding of these discipline areas and integrate them to manage them and successfully execute the overall program. In the DoD and NASA, the program manager has the authority to accomplish program objectives for the development, production, and sustainment of systems to meet the user's operational needs and is accountable to the acquisition decision authorities. Section 3 provides a generic model with a comprehensive list of 19 PM discipline areas that can tailored to fit any program types.

The main objective of this chapter is to present an innovative approach for integrating PM with emerging DDS technology enablers2 (TEs) for improving the program execution and management of any program types. This approach is referred to as the PM-DDS integration throughout this chapter. The approach identifies the five key PM areas that are important to any program managers and a generalized approach to decompose these areas into multiple discipline areas and conducts an analysis of these (discipline) areas for PM-DDS integration. The goal of the analysis is to identify the discipline areas that a program manager can leverage DDS TEs to enhance the overall program planning, execution, and risk reduction. For each area, we will discuss potential ways in which DDS TEs can be used to support the program manager and his team in managing and executing the project more effectively. In addition, the chapter also discusses a simplified, flexible, and adaptable MLOps framework that can help any program managers to identify the desired program discipline areas and related DDS tools to support his program from

<sup>2</sup> In the context of this chapter, the DSS technology enabler (TE) is defined as data science and/or decision science framework, processes, and/or software tools that can enable the data science and decision support (DDS) technologies. An example of DDS technology enable is big data analytics (BDA). An example of a BDA TE is the Data Acquisition processes and software tools or the Data Curation processes and tools.

*Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

the start to the end of the program. To limit the scope of work, the chapter only focuses on (i) the program management for acquiring a system, or a product, or a service, and (ii) five key PM areas, namely, program goals, schedule, cost, risk, and technical performance management.

The chapter is organized as follows: (i) Section 2 presents our innovative approach for PM-DDS integration; (ii) Section 3 provides a description of the nine key PM areas; (iii) Section 4 discusses a generalized approach on the decomposition of the multiple discipline areas and provides the decomposed discipline areas associated with the PM areas discussed in Section 3; (iv) Section 5 analyzes and selects a set of discipline areas for applying DDS; (v) Section 6 aligns the selected discipline areas with an appropriate DDS TE and provides some examples to demonstrate how the selected DDS TE can improve the program planning and/or reduce program risk; (vi) Section 7 describes our proposed simple, flexible, and adaptable MLOps framework for use by any program managers; and (vii) the chapter concludes with a summary and proposed way forward.

#### **2. Proposed innovative approach for PM-DDS integration**

Our proposed innovative PM-DDS integration approach includes a six-step approach as shown in **Figure 1**. These steps describe how any program manager, regardless of program types, can identify which PM discipline areas can leverage the emerging DDS TEs to improve the execution and management of their programs. A description of these steps is provided below.

**Figure 1.**

*Proposed PM-DDS integration approach.*

**Step I:** This step leverages existing PMBOK® Guide, NASA PM Guide and Processes, and DOD Guide for Program Managers to identify a set of generic PM areas that are the most important to any program managers. This set of PM areas is also referred to as the key PM areas that can be used for any program types. The detailed description of these key PM areas is provided in Section 3.

**Step II:** This step discusses a generalized approach to decompose PM areas into multiple discipline areas that any program manager is required to manage throughout the various phases of their program. The generalized decomposition approach can be tailored to any program types. Section 4 provides a detailed description of generalized approach and corresponding PM areas decomposition results.

**Step III:** To gain a deep understanding of existing DDS technologies, we have conducted a survey on the emerging DDS TEs and their applications on program management. Step III leverages the survey results and our own experience to perform the analysis of the decomposed discipline areas obtained from Step II above. The analysis helps us to select a set of discipline areas that can benefit from the integration of existing DDS TEs for improving the program planning and reduce overall program risk. As indicated in Section 1, the scope of work for this chapter is limited to the five key PM areas, including program goals, schedule, cost, risk, and technical performance management. We will focus our analysis on these five PM areas and related PM discipline areas decomposed from these five areas. Section 5 describes the analysis results on the selected set of discipline areas that can be beneficial from the PM-DDS integration.

**Step IV:** For each selected discipline area and/or a group of selected discipline areas, Step IV identifies corresponding DDS TE and/or a group of integrated TEs, respectively. The goal of this step is to align each selected discipline areas and/or a group of selected discipline areas with a specific DDS TE or a group of DDS TEs, respectively. The alignment will help us to identify which selected discipline area and/ or a group of selected discipline areas can be beneficial by integrating DDS TEs for improved program planning and/or program risk reduction. In practice, this step is the most important step because it helps the program managers to address the question on the integration of DDS technology for enhancing the program execution and effectively reducing the overall program risk. Section 6 provides a summary of the survey results on existing DDS TEs, consisting of big data analytics (BDA), artificial intelligence (AI), machine learning (ML), deep learning, and neural networks. Additionally, Section 6 describes the alignment of the selected discipline areas with specific DDS TEs and/or a group of DDS TEs. Some examples are also provided in Section 6 to demonstrate the use of DDS TEs for improving PM execution and planning.

**Step V:** Leverages the above four steps and existing MLOps framework and processes to develop a simplified, flexible, and adaptable MLOps framework that can help any program managers to identify the desired program discipline areas and related DDS tools to support his program planning and execution from the start of his program. Section 7 describes the proposed MLOps framework.

#### **3. Key PM areas identification**

From our experience and review [1–12], as pointed out in Section 1, the PM areas for any program types that are the most important to any managers can be classified into nine key areas. These nine key areas can be generalized and organized as nine

#### *Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

PM areas. Followings are a brief description of these nine key PM areas. Based on the description, this section provides a set of recommendations for the PM areas that should be beneficial from PM-DDS integration.


addressed in the WBS, IMP, and IMS. Program risk management requires the program managers to identify potential risks across the program and quantify these risks to assess and track the potential risk variation in the planned approach and its expected outcome [1–7]. It should be mentioned that the program risk can be classified into two categories, namely, (i) the technical risk associated with the technical requirements associated with a system or a product or a service, and (ii) non-technical risk associated with human resources, supplier, safety, etc.


and calibration laboratories [12]. This PM area is not the focus on this study and will not be addressed in the remaining sections.

	- ix.Program Integration Management: To achieve the overall program goals, the program managers are responsible for program integration that is required to integrate all the projects under their programs. The integration is required to be performed at the individual project integration level. At this level, the project manager coordinates tasks, resources, stakeholders, and any other project elements, in addition to managing conflicts between different aspects of a project, making trade-offs between competing requests, and evaluating resources. Integrated program management ensures related individual projects are not managed in isolation. This PM area is also not in the interest of this chapter, and it will not be addressed in the subsequent sections.

As mentioned in Section 1, due to page constraint and our focus on the application of DDS technology to program management, this chapter focuses on the four key PM areas that can receive the most benefits from DDS, including (i) program goals, (ii) schedule, (iii) cost, and (iv) risk management. These four PM areas are defined in the bullets above as i, ii, iii, and iv, which correspond to: (i) Enterprise, Organizational, and Program Goals Management using commonly used program KPIs, (ii) Overall Program cost estimate and cost management, (iii) Overall Program risk management, and (iv) Overall Schedule planning and management. Subsequent sections focus on the decomposition of these four PM areas into multiple discipline PM areas for PM-DDS integration.

#### **4. PM area decomposition to multiple discipline areas**

In practice, a program manager is the title that is assigned to an individual who is responsible for managing the nine PM areas described in Section 3. The program manager must have the knowledge and a good understanding of the required multiple discipline areas associated with the nine PM areas to successfully execute the overall program. The program manager has the full authority to achieve specific program objectives from the development phase to the sustainment phase. For the US DOD defense programs, the program manager is accountable to the Milestone Decision Authority (MDA). Based on our experience working on NASA, US DOD, commercial programs, and our review of the multiple PM discipline areas associated with the nine key PM areas [1–9], we propose a generalized model for the decomposition of the above nine PM areas into a set of multiple discipline areas. The program manager must fully understand these multiple PM discipline areas to effectively execute the program from the start to the end of the program. Below is a proposed generalized model consisting of 19 PM discipline areas, including:

	- ix.Program schedule planning and management,
	- x.Program cost planning and management,
	- xi.System/product/service3 risk planning and management,

<sup>3</sup> From here and on, we will use the term "a system" to indicate a system/product/service, which depends on the application. As example, a system can be a satellite system or a commercial building; a product can be a phase array antenna with digital beam forming capability or a complete air condition system for a commercial shopping center; and a service can be a private Wide Area Network (WAN) service to support a military base or a private WAN service supporting a commercial enterprise.

*Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

xiv.Logistics and supply chain management,

xv.Production, Quality, and Manufacturing (PQM),

xvi.Program and system intelligence and security management,

xvii.Program and system software management,

xviii. Program and system configuration management,

xix.Program and system information technology, and

xx.Other Specialty Program Planning and Management.

The above 20 PM discipline areas that can be tailored to fit with any program areas and types. Below is a list of four key PM areas and associated PM discipline areas:


The following subsections provide detailed description of the above three key PM discipline areas related to program cost, risk, and schedule.

#### **4.1 Program cost planning and management discipline area**

Cost planning and management for a product being acquired by a program is critical for the success of the program, especially during the pre-acquisition phase, i.e., planning phase. The cost of a system and its risk depend on the technical requirements. The more uncertainty associated with the technical requirements, the more cost risk. This is especially true for acquiring an advanced state of the art system or when the program management team is not sure about the technical requirements on a specific system they are planning to acquire. In the following section, we discuss this challenge and identify existing DDS TE that can address it.

#### **4.2 Program schedule planning and management discipline area**

In Section 3, the program schedule planning provides a program schedule plan captures the program start and end dates for all activities defined in the WBS. The program activities include program milestones, individual projects with associated tasks, timeline for completing individual tasks, related durations, resources for each task, identified predecessors, and dependencies for each task. Based on our review of the existing schedule plan, development and management discipline area includes five steps, namely program activity definition (described in the WBS), activity sequencing, activity duration estimate, schedule development, and schedule control [1–8]. **Figure 2** captures these five steps of the schedule plan development and management, and their detailed descriptions are provided below.

**Step 1—Program Activity definition**: This step identifies required activities specified in the WBS. This definition step also defines all WBS activities that must be accomplished to achieve the objectives of the overall program. The output of this step includes (i) a list of activities with a complete description of each of the activities

**Figure 2.**

*Five steps for schedule planning and management.*

and they are linked to the WBS. The list contains supporting details for each activity, including assumptions and constraints.

**Step 2—Activity Sequencing**: This step identifies the constraints and relationships among activities. It also defines the priority of the activities and the order of the tasks without causing bottleneck from one activity to the other. To determine the order, this step requires several inputs, including (i) activity list developed in Step 1, (ii) required constraints and related dependencies, discretionary constraints and related dependencies developed by the program management team based on "best practices" or specific sequences desired by management, (iii) external dependencies, and (iv) other constraints and assumptions. For instance, the required constraints and related dependencies can be a prototype must be fabricated before it can be tested, and external dependencies can be the availability of test sites.

**Step 3—Activity Time Duration Estimate**: It provides an estimate of the time duration required to complete the activities that make up the program. This is an important task that required SMEs who are most familiar with the activity to provide the estimates. At a minimum, there are two key required inputs to this step, namely, (i) the resources required and assigned for the activity, and (ii) the capabilities of the resources assigned. For improving the estimate, this step leverages historical information and lessons earned from past and similar programs and from commercial databases. In practice, the output of this step provides an estimate of the likely time duration to complete each activity. The estimates should include the mean values of the time duration estimate and 1-sigma value around the mean value, for instance, 1 month ±1 week, and corresponding assumptions made in the estimated time durations.

**Step 4—Schedule Development**: From the estimated time duration obtained in Step 3, this step develops realistic start and finish dates for each activity based on the specified program PoP. The schedule development process is an iterative process considering Step 2—activity sequencing, and Step 3—activity time duration estimates along with resource requirements and availability to display when the activities can be executed, constraints, assumptions, and associated risk. This step provides a set of schedules and associated information for the program, including (i) the IMS and the supporting detailed schedules, and (ii) the best balance possible between competing demands of time and resources. The schedules also consider the risk associated with time, cost, and performance tradeoffs and the impact on the overall program.

**Step 5—Schedule Control**: This step identifies potential schedule variations and manages actual changes to the developed schedules. The schedule change control system provides a well-defined procedure by which changes can be made and automatically be integrated into the program. The schedule change control system also provides mechanisms for (i) schedule performance tracking, and (ii) the approving and authorizing the required changes. Note that schedule changes come from various factors, including failure to achieve planned dates for specific activities, delayed tests, late delivery of required prototypes, internal program management assessment and replanning, and external direction, such as reallocation of funding.

#### **4.3 Program risk management discipline area**

As discussed above, program risk discipline required the program managers to define an approach to measure the future uncertainties in achieving overall program performance goals, requirements, and objectives within defined program cost, schedule, and performance constraints. More specifically, program managers need

to address risk associated with cyber security threats, human safety, program safety, system risk and safety, technology maturity level (TRL), supplier capability, supply chain management, system design maturation, manufacturing maturity level (MRL), and performance against plan. These program and system risks are usually associated with the program tasks described in the WBS, IMS, and IMP. The program and system risks address the potential variations in the program planned approach and its expected outcomes [1–7]. The US DOD risk management framework is described in Ref. [10]. In general, the risk management process is shown in **Figure 3** below.

As shown in **Figure 3**, the risk management process consists of five key steps, namely, risk identification, risk analysis, risk mitigation planning, risk mitigation plan implementation, and risk tracking. The followings describe these five key risk management activities in detail.

**Step 1—Risk Identification:** This activity identifies program risks throughout the program life. The risk identification process includes the nine following steps:


**Step 2—Risk Analysis**: This activity analyzes each identified risk to ensure the risk description is accurate, isolate the root cause, determine the effects, set risk and associated mitigation priorities. The analysis refines each risk item in terms of its likelihood, its consequence, and its relationship to other risk areas or processes.

**Step 3—Risk Mitigation Planning**: The objective of the risk mitigation is to reduce or eliminate the impact of risks on a program. The risk mitigation plan (RMP) activity identifies, evaluates, selects, and implements mitigation options to bring the identified risk from unacceptable levels to acceptable levels given program constraints and objectives. The RMP activity also provides detailed description of what mitigation technique should be used, when the risk mitigation should be accomplished, who is responsible for bringing the risk to acceptable levels, and associated cost and schedule. In general, the RMP strategy can be chosen from the four mitigation options, namely, risk avoidance (RAV), risk controlling (RCO), risk transfer and sharing (RTaS), and risk assumptions (RAS) [1, 10].

RAV approach is used when there is alternative activity that can be used for achieving the same outcome of the task without carrying the identified risk. This technique requires the risk team to reconfigure the project such that the identified risk in question disappears or is reduced to an acceptable level. RA approach is recommended when the risk team can control the identified risk by managing the root cause and/or related consequence. RCO approach can leverage the risk database along with a warning system that can provide required warning signs to assess more accurately the impact, likelihood, or timing of a risk. RTaS approach is preferred when the risk team can share the identified risk with a third party like a supplier or subcontractor or an insurance company. RAS approach is recommended as a mitigation strategy by the risk team when the identified risks are small risks. The small risk is defined as the risk that when it occurs the cost of insuring against the risk would be greater over time than the total losses sustained. The RAS strategy accepts the loss, or benefit of gain, from the identified risk when it occurs.

**Step 4—Risk Mitigation Plan Implementation:** The risk team is responsible for developing and implementing the RMP. The plan ensures successful risk mitigation occurs and the timing for the burnt down risks is based upon the RMP. In practice, the implementation plan (i) determines what planning and associated budget and requirements along with contractual changes are required to burn down the risks, (ii) provides a plan for coordination between program management team and all stakeholders, (iii) directs the program teams to execute the defined and approved RMP, (iv) provides a summary of the registered risk reporting requirements for on-going monitoring, and (v) documents the change history.

One of the key activities in the implementation step is the risk assessment activity. The risk assessment activity is performed by the risk team to identify and analyze the risk by its category. In practice, the key risk categories include performance, schedule, and cost risks. Thus, it is essential that the RMP implementation approach should also be accomplished by risk category, and it is important for this process to be worked through the risk IPT structure and and/or projects' risk structure.

**Step 5—Risk tracking:** The risk tracking is also known as risk monitoring. It is defined as an activity that can track and evaluate the performance of risk mitigation actions against established metrics throughout the pre- and post-acquisition process. This objective of this activity is to (i) evaluate the performance of RMP actions against a pre-defined metrics, and (ii) execute the RMP or develop further risk mitigation choices, as appropriate. The results obtained from this activity provide required information on how the risks are burnt down ensuring the success of the RMP. The objective of the risk tracking activity is to ensure that the program team to (i) communicate risks status to all affected Stakeholders, (ii) monitor RMP, (iii) review RMP status updates, (iv) display RMP dynamics, (v) track RMP status within the risk reporting matrix, and (vi) alert management as to when RMP should be implemented or adjusted.

#### **5. PM discipline areas analysis for DDS integration**

This section provides a summary of our survey results and our experience on the analytical and simulation tools to support the three PM discipline areas discussed in subsections 4.1 (program cost management), 4.2 (program schedule management), and 4.3 (program risk management) above. The objective of this section is to (i) analyze these three PM discipline areas and the identified supporting tools, and (ii) select a set of the activities within each of the PM discipline areas that can benefit from the integration of existing DDS TEs. The objective of the PM-DDS integration is to improve the efficiency of the program planning and reduce the overall program risk for achieving the cost, schedule, and technical performance. The following subsections focus on the analysis of PM-DDS integration for program cost, schedule, and risk management discipline areas.

#### **5.1 DDS integration with program cost management**

Based on our survey of existing cost tools, the available cost tools implemented the four commonly used cost-estimating techniques [2, 5, 7, 14], including (i) Analogy technique that based on historical data for an analogous product or system or subsystem; (ii) Engineering Build-up technique, where a system or a product is broken into lower-level components (e.g., individual parts or assemblies), each of which is costed separately for direct labor, direct material, and other costs; (iii) Parametric technique that uses regression or other statistical methods to estimate the cost and its relationship between historical cost of a system and a product; and (iv) Actual cost estimation technique that leverages actual cost experience or trends from prototypes, engineering development models, and/or early production items used

#### *Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

to project estimates of future costs for the same system. These cost tools can provide cost estimate with associated confidence level. The confidence level specification helps the program managers to understand the likelihood that actual costs would fall below estimated costs. This means that the greater the confidence level, the higher the estimated cost. Note that in the US DOD, it is mandatory for the program managers to conduct an independent cost estimate that is performed by different organization that is not part of the program organization. Some of the cost tools available are as follows:


For acquiring advanced systems with high uncertainty associated with the technical requirements, the cost and schedule estimates of the proposed system during the pre-acquisition phase become a challenge for the system design team, cost team, and risk management team. These three teams need to develop an optimal system solution based on multiple design criteria, including market uncertainty, technological uncertainty, technical risk, performance risk, cost risk, and schedule risk. The program manager needs to come up with a payoff-and-cost function that can balance out the performance, cost, and schedule risks with the market uncertainty and technological uncertainty. This is a multi-criteria decision problem that requires the designer to come up with a satisfactory and safe decision. Recently, a war-gaming concept using game theory was proposed to analyze alternative system solutions by playing out the Government's acquisition objectives against the Contractor's bidding motivations [20, 21]. As pointed out in Ref. [22], the game scenarios simulating various system solutions sometimes lead to conflicting and non-converging solutions. An advanced multiple-criteria decision mathematical model also proposed in Ref. [22]. This model employed the ELECTRE II model to resolve the non-convergence game scenarios encountered in the war-gaming model. Thus, the ELECTRE II model described in [22] when combined with proposed Advanced Game-based Mathematical Framework (AGMF), Unified Game-based Acquisition Framework (UGAF), and a set of War-Gaming Engines (WGEs) described [20] can address the cost estimate for an advanced system with low level of TRL (i.e., high technical requirements uncertainty). The recommended PM-DDS integration approach for cost planning includes big data analytics (BDA) approach with BDA data acquisition and data curation TEs, and artificial intelligent and machine learning (AI-ML) TEs. AI-ML TEs include (i) data mining techniques and tools (DMTT), (ii) data exploitation using multi-objective reinforce learning and adaptive neural network (MORL-ANN) tool, and (iii) predictive analytics techniques using MORL-ANN tool. For cost management, the

recommended PM-DDS integration approach for performing the cost management includes three key components, BDA approach with BDA TEs listed above, AI-ML TEs listed above, and the Earn Value Management System (EVMS) to track and manage the cost [23, 24].

#### **5.2 DDS integration with program schedule management**

This section analyzes and discusses the five program schedule activity steps defined in Section 4.2.

**Step 1—Program Activity Analysis:** The techniques commonly used in activity definition are as follows: (i) decomposition process involved the successive breakdown of program elements into smaller, more manageable components, which eventually described the activities to be scheduled. This technique is essentially the same as the one used in the WBS development; and (ii) a template process that is an activity list or WBS element from another similar program that can serve as a model for the current program and provide a starting point for defining specific activities. Based on our current analysis of the existing techniques used for this Step 1 activity, it is difficult to integrate existing technique and tools with the current DDS technology and associated TEs.

**Step 2—Activity Sequencing Analysis:** Step 2 activity has been using several techniques and tools to develop the logic diagrams reflected the desired activity sequencing. Existing network scheduling techniques and tools include (i) Critical Chain Method (CCM), (ii) Critical Path Method (CPM), (iii) Precedence Diagram Method (PDM), and (iv) Program Evaluation and Review Technique (PERT) [1–7, 25–27]. The recommended PM-DDS integration approach for conducting the activity sequencing estimate includes three key components consisting of BDA TEs, AI-ML TEs, and existing activity sequencing tools (i.e., CCM, CPM, PDM, and PERT). The recommended integration approach is expected to improve the program planning efficiency.

**Step 3—Activity Duration Estimate Analysis**: The following techniques are commonly used in estimating activity durations: (i) Expert judgment guided by historical information, (ii) Analogous estimating based on the experience of similar programs, (iii) Parametric estimating based on formulas describing relationships among program parameters and time, and (iv) Use of simulation to develop distributions of the probable duration of each activity. Like the above Step 2 analysis, the recommended PM-DDS integration approach for conducting the activity time duration estimate also includes three key components consisting of BDA TEs, AI-ML TEs, and existing four activity duration estimate techniques described above. This recommended integration approach is also expected to enhance the program planning efficiency.

**Step 4—Schedule Development Analysis**: Several techniques and related tools are useful to developing schedules. These tools contain the capability to perform mathematical analyses calculating theoretical start and finish dates for each activity based on the overall sequencing of the program activities. Two of the more commonly known analysis techniques and related tools are: (i) CPM and (ii) PERT. Other scheduling development techniques and related tools that are also available to generate schedule plan using resource constraints, such as time, human resource, budget, and material. These tools provide another avenue to manage the effect of these constraints. A few of these techniques and related tools are schedule compression, and resource leveling. Like the above Steps 2 and 3 analyses, the recommended PM-DDS integration approach for generating a schedule plan also includes three key *Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

components consisting of BDA TEs, AI-ML TEs, and existing schedule development techniques and tools described above. This recommended integration approach when combined with the above integration approaches is also expected to increase the overall program planning efficiency.

**Step 5—Schedule Control Analysis**: The analysis of Step 5 on schedule control and management showed that the Line of Balance (LOB) process and related tools are currently used by program managers to manage the overall program control process [28, 29]. The LOB process and tools are used to collect program data, measure, and display the actual program status related to timing, phasing of the project activities, cost, related background, and accomplishments measured against a specific program management plan. The displayed results provide program management team desired program information that helps the team to (i) compare actual progress with a formal objective program plan, (ii) examine the deviations from the established plans and evaluate their degree of severity with respect to the remainder of the project, (iii) receive timely program information concerning potential trouble areas and indicate the areas that required immediate corrective action, and (iv) forecast future program performance. The recommended PM-DDS integration approach for schedule control and management also includes three key components consisting of BDA TEs, AI-ML TEs, and existing LOB tool. This recommended integration approach is expected to reduce the overall schedule risk and enhance the program execution by identifying and correcting potential trouble areas before they occur.

**Figure 4** illustrates the proposed PM-DDS integration approach. This figure shows that the program schedule management can be integrated with existing DDS technology enablers for enhancing program planning and execution for risk reduction.

#### **5.3 DDS integration with program risk management**

This section analyzes and discusses five program schedule activity steps defined in Section 4.2.

**Step 1—Risk Identification Analysis**: Our analysis shows that the commonly used techniques and tools for risk identification include (i) objectives-based risk identification (OBR-ID), (ii) scenario-based risk identification (SBR-ID), (iii) taxonomy-based risk identification (TBR-ID), and (iv) common-risk checking

#### **Figure 4.**

*PM-DDS integration approach for schedule planning and management.*

(CRC). The OBR-ID technique and related tools identify the risk associated with the objectives defined by organizations and project teams [1–7]. Any event that may endanger achieving an objective partly or fully is identified as risk. SBR-ID technique and related tool perform scenario analysis using different pre-defined scenarios. The scenarios may be the alternative ways to achieve a pre-defined objective, or an investigation of the interaction of external forces in, for example, a market or battle. An undesired scenario that may occur in the future is identified as a risk, and any event that may trigger it is considered a risk trigger.

The TBR-ID technique and related tools are used to breakdown possible risk sources. Leveraging the taxonomy and knowledge of best practices, a set of questionnaires is compiled for review by SMEs. The answers to the questions reveal potential risks and are compiled in the program risk registry. CRC tools can leverage industry databases to provide lists of known risks associated with known activities, products, program elements. Each risk in the program risk registry can be checked for application to a specific situation.

The recommended PM-DDS integration approach for conducting the risk identification activity includes three key components consisting of risk databases with data acquisition and data curation TEs, AI-ML TEs, and existing risk identification techniques and related tools. The recommended AI-ML TEs include (i) DMTT, (ii) data exploitation using MORL-ANN tool, and (iii) predictive analytics techniques using MORL-ANN tool. This recommended integration approach is expected to improve the program management planning by reducing the uncertainty associated with the risk identification process.

**Step 2—Analysis of Risk Analysis Activity:** Based on our analysis of Step 2 on the risk analysis activity, the current risk analysis processes and related tools are focused on (i) system performance risk analysis, (ii) schedule risk analysis, and (iii) cost risk analysis [30]. The output of these processes and related tools consists of (i) assigned likelihood (probability of occurrence) and related consequence (the environmental impact if a risk event occurs) results to each risk using the criteria in the risk reporting matrix, (ii) consequence results in terms of performance, schedule, and/or cost impact using defined criteria, (iii) the risk matrix reporting the risk results, and (iv) documented risk results in the program risk register.

The system performance risk analysis tools typically focus on analyzing the technical requirements related to operational environment, TRL and/or MRL associated with systems/products being acquired, standards, material readiness, etc. Section 5.1 discusses available tools for addressing technical requirements with low TRL (i.e., high technological uncertainty level) and/or low MRL (i.e., market availability is low). For technical requirements with low TRL and/or MRL, the recommended tools include ELECTRE II, AGMF, and WGEs.

Existing schedule risk analysis tools are focused on the analysis of the (i) baseline schedule inputs, including durations and network logic; (ii) technical and schedule uncertainty inputs to the program schedule model; (iii) risk impacts to program schedule based on the program technical SMEs' inputs; (iv) IMS incorporating the potential impact from all contract and supplier schedules and associated stakeholders' activities; and (iv) schedule excursions reflecting the effects of cost risks, including human resource, budget, and schedule constraints. Note that when the identified risk impacts the critical path, then this risk affects both schedule and cost, and this risk should be registered as a schedule risk. Section 5.2, Step 5, discussed required analysis tools using PM-DDS integration approach for efficient schedule control and

#### *Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

management. The integrated tools can effectively identify potential trouble areas in the IMS and indicate the areas that required immediate corrective action.

Currently, the cost risk analysis tools available focused on the cost analysis of the life-cycle-cost (LCC) by (i) building on technical and schedule assessment results, (ii) translating performance and schedule risks into LLC, and (iii) deriving LCC estimates by integrating technical assessment and schedule risk impacts on resources. The cost analysis tools are also capable of creating budgetary requirements consistent with fiscal year planning and determining the adequacy and phasing of funding supports the technical and acquisition approaches. The tools can document the cost basis and risk impacts and provide program LCC excursions from near-term budget execution impacts and external budget changes and related constraints. The recommended PM-DDS integration approach for performing the cost risk analysis is identical to Section 5.1 above, i.e., also includes the cost analysis tools described above, BDA data acquisition and data curation TEs, and AI-ML TEs. AI-ML TEs include (i) DMTT, (ii) data exploitation using MORL-ANN tool; and (iii) predictive analytics techniques using MORL-ANN tool.

**Step 3—Risk Mitigation Planning Analysis:** Current risk mitigation planning (RMP) tools focused on the four mitigation techniques, namely, (i) risk avoidance (RAV), (ii) risk controlling (RCO), (iii) risk transfer and sharing (RTaS), and (iv) risk assumptions (RAS). Existing RMP tools are mostly customized to specific programs. Most of the existing RMP tools are stovepiped and do not leverage analytical tools that have recently been developed using BDA and AI-ML technologies and associated TEs. To effectively conducting the RMP activity, we recommend integrating existing BDA and AI-ML tools into existing mitigation techniques. BDA tools include data acquisition and data curation processes and tools. The AI-ML tools include (i) DMTT, (ii) data exploitation using MORL-ANN tool, and (iii) predictive analytics techniques using MORL-ANN tool. This recommended PM-DSS integration approach is expected to improve the program management planning and execution.

**Step 4—Risk Mitigation Plan Implementation analysis:** Our survey of the risk mitigation plan (MRP) implementation tools shows no tools available and the MRP implementation is usually conducted by the risk team with support from SMEs across the program related organizations. As discussed in Sub-Section 4.4, RMP captured the key risk categories including performance, schedule, and cost risks, and the risk team is responsible for implementing the plan with the support of the program.

**Step 5—Risk Tracking Analysis:** Our survey of the risk tracking tools showed that the tools are focused on the tracking of the performance of RMP actions against a pre-defined metrics. The tools are also capable of executing the RMP to generate alternative risk mitigation choices, as appropriate. The tools track the burnt down activity to ensure the success of the RMP. To effectively generate alternatives risk mitigation choices, we recommend integrating existing BDA and AI-ML tools into existing risk tracking tools. BDA tools include data acquisition and data curation processes and tools. The AI-ML tools include (i) DMTT, (ii) data exploitation using MORL-ANN tool, and (iii) predictive analytics techniques using MORL-ANN tool.

The recommended PM-DSS integration approach for conducting the risk tracking is expected to improve the program management planning and execution by providing alternative mitigation choices to burn down the risk before it occurs. **Figure 5** depicts our proposed PM-DDS integration approach for conducting program risk management more effectively. For improving the program planning, we recommend incorporating BDA and AI-ML process and tools to support risk identification, risk analysis, and risk mitigation planning. To reduce the program risk, we recommend incorporating BDA and AI-ML process and tools to support risk tracking.

**Figure 5.** *PM-DDS integration approach for program risk management.*

#### **6. Selected DDS TEs alignment with PM discipline areas**

This section provides the alignment between the selected sets of DDS TEs and the PM discipline areas identified in our analyses presented in Section 5 above. From the nine key PM areas discussed in Section 3, Section 4 decomposed them into a generalized model of 19 PM discipline areas and selected only three PM discipline areas that were aligned with the selected five PM areas (i.e., program goals, schedule, cost, risk, and technical performance management). **Table 1** provides a summary of the proposed PM-DSS integration approach for the program cost management (PCM) discipline. The table aligns existing PCM framework/process/model with DDS framework/process/model for the recommended PCM integration.

The use of artificial neural network tools to predict the actual cost of a project to enhance EVMS is discussed in Refs. [35, 36] and easily extended to the program cost prediction. **Table 2** summarizes our recommended PM-DSS integration approach for the program schedule management (PSM) discipline. The table aligns existing PSM framework/process/tools with DDS framework/process/model for the recommended PSM integration.

Like **Table 2**, **Table 3** provides a summary our recommendation for the PM-DSS integration approach for the program risk management (PRM) discipline. This table aligns existing PRM framework/process/tools with DDS framework/process/model for the recommended PRM integration.

As discussed in Refs. [24, 31–33], EVMS is a systematic process that uses earned value as the primary tool for integrating program cost, schedule, technical performance, and risk to manage a program. Program managers can leverage EVMS tools to determine and track the actual program status at any given point during program PoP. This activity can be done very effectively if the tools have successfully implemented required program constraints, program rules and process, and organizational rules. The implementation of EVMS requires a disciplined approach. Recently, BDA and AI-ML processes and tools have been successfully integrated into EVMS. Current

*Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*


#### **Table 1.**

*DDS process and tool for PCM integration.*


#### **Table 2.**

*DDS process and tool for PSM integration.*

analysis results show that when these BDA and AI-ML tools are properly integrated with EVMS, the tools can certainly assist the program managers to execute their programs more effectively by anticipating the cost, schedule, program, and technical risks and mitigating these risks before they occur.


#### **Table 3.**

*DDS process and tool for PRM integration.*

#### **7. Proposed flexible and adaptable PM-DSS integration life cycle framework leveraging MLOps**

Successful PM-DSS integration requires planning, structure process, and proper selection of DSS models and tools. This section focuses on how to leverage the concept of MLOps, and its existing framework described in [42–46] for the development a PM-DSS integration framework. The proposed framework should be easy to use and tailored to any program types.

As pointed out in Refs. [42–46], the objective of MLOps is to reduce the technical friction associated with the development of AI-ML models and tools from an idea into production in the shortest possible time to market with as little risk as possible. But the objective for the PM-DSS integration framework is to reduce the integration risk between a set of BDA, and AI-ML tools with the selected PM discipline areas. The framework focuses on the start of the program to the deployment of the integrated tools with the lowest possible risk. In addition, the framework should also address the operational phase where the program team can leverage the integrated PM-DSS products to execute the program effectively. More specifically, using the program data displayed by the integrated tools, the program team can use proactive risk management method to improve the program planning and execution by reducing overall program risk. **Figure 6** depicts a proposed PM-DSS integration framework leveraging existing MLOps life cycle framework. This proposed integration framework is easy to tailor to any program types and can be adaptable to any PM discipline areas and any set of BDA and AI-ML models and tools.

As shown in **Figure 6**, the proposed framework has a life cycle that consists of seven key stages, including (i) PM-DSS integration specification, (ii) related *Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

#### **Figure 6.**

*PM-DDS integration life cycle framework.*

program data acquisition, (iii) related program data curation, (iv) BDA and AI-ML models selection and integration, (v) PM-DSS integrated models testing, (vi) integrated model deployment, and (vii) display, monitor, and control program data. A high-level description of these key stages is provided in **Figure 6**. The feed-forward and feedback arrows are shown to describe the transition of each stage and the dependent of each stage.

#### **8. Conclusion**

This chapter describes an approach for integrating existing DDS models and tools with any PM processes, models, and tools for improving program planning and more efficient program execution by reducing overall program risk. A detailed description of the nine key PM areas along with the decomposed generalized 20 PM discipline areas were provided. This chapter proposed a PM-DSS integration approach for three PM discipline areas that were aligned with the selected four key PM areas, including program goals, schedule, cost, and risk. For the integration of each PM discipline area, a list of BDA and AI-ML models and tools were identified and suggested for the integration. In addition, the chapter proposes a flexible and adaptable PM-DSS integration life cycle that can be used to deploy BDA and AI-ML models and tools for improving program planning and execution.

Finally, when writing this chapter, the authors were intentionally focused on the high-level PM discipline areas and DDS technology enablers without technical depth. Only common DDS technology enablers that are known to the authors were selected

for the integration. In practice, each PM discipline area deserves a whole book to address it in technical detail. There are many open PM-DSS integration problems and technical relevance associated with each activity step described in this chapter. The authors hope that the program management experts, data scientists, decision scientists, and mathematicians would benefit from this paper and its applications to these open problems.

### **Acknowledgements**

The authors would like to thank their CSUF colleagues for their support of this work, particularly Professor Sam Behseta.

### **Conflict of interest**

The authors declare no conflict of interest. The proposed approach and opinions expressed in this chapter are those of the authors and they are not endorsed by CCAM and Mihaylo College of Business & Economics, CSUF.

### **Notes/thanks/other declarations**

The first author would like to thank his wife, Thu-Hang Nguyen, for tremendous patience and support during the preparation and writing of this chapter.

*Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

### **Author details**

Tien M. Nguyen1 \* † , John D.T. Nguyen<sup>2</sup> , My T.N. Nguyen2 , Charles H. Lee3 and Tam Nguyen3

1 California State University, Fullerton, California, USA

2 JDTN Consulting Services, California, USA

3 CSUF, Mathematics Department, Mihaylo College of Business and Economics, USA

\*Address all correspondence to: tmnguyen57@fullerton.edu

† Adjunct Research Professor, CSUF, Center for Computational and Applied Mathematics. Also with the Aerospace Corporation, California. A retired Engineering Fellow at Raytheon. He was a Raytheon Certified Level-5/-6 Program Manager, EVMS Level-2, and Six-Sigma.

© 2023 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

### **References**

[1] Program management overview. Available from: https://acqnotes. com/acqnote/careerfields/ program-management-overview

[2] A guide for DOD program managers, defense acquisition authority. 2014. Available from: https://acqnotes.com/ wp-content/uploads/2014/09/A-Guidefor-DoD-Program-Managers.pdf

[3] DOD acquisition system. 2020; Available from: https://www.esd. whs.mil/Portals/54/Documents/DD/ issuances/dodd/500001p.pdf

[4] Policy for NASA acquisition. 2020. Available from: https://nodis3.gsfc. nasa.gov/displayDir.cfm?t=NPD& c=1000&s=5C#:~:text=NASA's%20 strategic%20acquisition%20process%20 supports,advance%20the%20 Agency's%20statutory%20objectives

[5] Project Management Handbook. Available from: https://www. researchgate.net/publication/320101542\_ project\_management\_handbook

[6] A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 2000 Edition; Available from: http:// www.cs.bilkent.edu.tr/~cagatay/cs413/ PMBOK.pdf

[7] Basic Guidelines for Program Planning and Management. 18 January 2022; Available from: https://managementhelp. org/programmanagement/businessprograms.htm#anchor4294894489

[8] Acquisition of Commercial Products and Commercial Services. 2022. Available from: https://www.acquisition. gov/far/part-12

[9] Top 12 Performance Management Goals & Objectives. Available from:

https://www.clearpointstrategy.com/ top-performance-management-goalsand-objectives/

[10] Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs. January 2017. Available from: https://acqnotes. com/wp-content/uploads/2017/07/ DoD-Risk-Issue-and-Opportunity-Management-Guide-Jan-2017.pdf

[11] Cost Control in Building Design and Construction. July 2022. Available from: https://www.designingbuildings.co.uk/ wiki/Cost\_control\_in\_building\_design\_ and\_construction

[12] ISO/IEC 17025, Wikipedia. Available from: https://en.wikipedia.org/wiki/ISO/ IEC\_17025

[13] Program team: The program team: what they do and why it matters; Available from: https://medium.com/ loud-updates/the-program-teamwhat-they-do-and-why-it-matters-64cdda6782ef

[14] DOD Cost Estimating Guide. Available from: https://www. cape.osd.mil/files/Reports/DoD\_ CostEstimatingGuidev1.0\_Dec2020.pdf

[15] SEER Cost Tool. Available from: https://galorath.com/products/ seer-for-software/

[16] aPriori Cost Estimating Software. Available from: https:// www.apriori.com/should-cost-ana lysis/?gclid=EAIaIQobChMI97H qw4bZ-gIVFR6tBh3AJA0eEAAY ASAAEgIT2\_D\_BwE

[17] Paul TB. COCOMO software cost estimating model. 2008. Available from: *Program Management Integrated with Data and Decision Sciences DOI: http://dx.doi.org/10.5772/intechopen.109964*

https://www.unf.edu/~broggio/cis6516/ CocomoPresentation.ppt

[18] COCOMO II - Model definition manual, center for software engineering, USC. 2000. Available from: https://www. rose-hulman.edu/class/cs/csse372/201310/ Homework/CII\_modelman2000.pdf

[19] Lane JA, Boehm B. Modern tools to support DoD software intensive system of systems cost estimation. Available from: https://citeseerx.ist.psu.edu/ viewdoc/download?doi=10.1.1.365.8978 &rep=rep1&type=pdf

[20] Tien M. Nguyen, Andy Guillen, Sumner Matsunaga, Hien T. Tran, Tung X. Bui, War-gaming applications for achieving optimum acquisition of future space systems. In: Simulation and Gaming. London, UKINTECH-Open Science-Open Minds: London ISBN: 978-953-51-3800-6. DOI: 10.5772/ intechopen.69391. 2018

[21] Nguyen TM, Tran HT, Guillen AT, Bui TX, Matsunaga SS. Acquisition war-gaming technique for acquiring future complex systems: Modeling and simulation results for cost plus incentive fee contract. Journal of Mathematics. 2018;**6**:1-29. DOI: 10.3390/math6030043. Available from: www.mdpi.com/journal/ mathematics

[22] Nguyen TM, Freeze T, Bui TX, Guillen A. Multi-criteria decision theory for enterprise architecture risk assessment: Theory, modeling and results. Proceedings, Sensors and Systems for Space Applications XIII. 2020;**11422**:114220. DOI: 10.1117/12.2559317

[23] Earned Value Management Handbook. Princes Risborough, Buckinghamshire: Association for Project Management; March 2013. Available from: https:// apmv1livestorage.blob.core.windows.

net/legacyimages/earned%20value%20 management%20handbook\_secure.pdf

[24] NASA Earned Value Management Handbook. Washington D.C.: National Aeronautics and Space Administration, NASA Headquarters; November 2019. Available from: https://www.nasa.gov/content/ earned-value-management-handbook

[25] Procurement 101: Process, types and optimization guide 2022. 2022. Available from: https://kissflow.com/procurement/ procurement-process/

[26] A critical look at critical change project management. Available from: https://www.researchgate.net/ publication/3228307\_A\_Critical\_Look\_ at\_Critical\_Chain\_Project\_Management

[27] Critical Change Project Management. Available from: https:// ensembleconsulting group.com/ wp-content/uploads/2018/07/CCPM-Executive-Guide.pdf

[28] Line of Balance (LOB). Available from: https://acqnotes.com/acqnote/ tasks/line-of-balance

[29] Vargas RV, Moreira FF. Scheduling optimization with line of balance and start-finish relations. In: PMI® Global Congress 2015—EMEA. London, England. Newtown Square, PA: Project Management Institute; May 2015. Available from: https:// www.pmi.org/learning/library/ scheduling-optimization-balance-10614

[30] Risk and Safety Management. Available from: https://acqnotes.com/ acqnote/tasks/risk-analysis

[31] Earned Value Management: The Basic. Available from: https:// www.ecosys.net/knowledge/ earned-value-management-basics/ [32] Simplilearn, Understanding Earned Value Management and Formulas, August 2022; Available from: https:// www.simplilearn.com/earned-valuemanagement-and-its-formulas-article

[33] Office of Under Secretary of Defense, Joint Space Cost Council Better Earned Value Management System Implementation. October 2017; Available from: https://www.acq.osd.mil/asda/ ae/ada/ipm/docs/JSCC\_Better\_EVMS\_ Implementation\_Study.PDF

[34] MATLAB Deep Deterministic Policy Gradient (DDPG) Agents. Available from: https: //www.mathworks.com/ help/reinforcement-learning/ug/ddpgagents.html

[35] Iranmanesh SH, Zarezadeh M. Application of artificial neural network to forecast actual cost of a project to improve earned value management system. International Journal of Social, Behavioral, Educational, Economic, Business and Industrial Engineering. 2008

[36] Garling R. Artificial intelligence and earned value in project management, a [Master thesis], American Military University. 2020. Available from: https:// richgarling.com/#\_Toc36301150

[37] Wauters M, Vanhoucke M. A comparative study of artificial intelligence methods for project duration forecasting. Expert Systems with Applications. 2016;**46**:249-261. DOI: 10.1016/j.eswa.2015.10.008

[38] Lee S, H, Kim K-Y, Shin Y. Effective feature selection method for deep learning-based automatic modulation classification scheme using higher-order statistics. MDPI Applied Science. 2020. DOI: 10.3390/app10020588

[39] AI vs. Machine learning vs. deep learning vs. neural networks: What's the difference?. 22 May 2020. Available from: https://www.ibm.com/cloud/blog/ai-vsmachine-learning-vs-deep-learning-vsneural-networks

[40] Raz T, Michael E. Use and benefits of tools for project risk management. International Journal of Project Management. 2001;**19**:9-17. Available from: https://www.diva-portal.org/ smash/get/diva2:708652/fulltext01.pdf

[41] Hayford F, Ahmed S. Tools and techniques for project risk management: Perspective of micro to small scale construction firms in Ghana, [Master thesis], Stockholm, Sweden. 2013, Available from: https://www.divaportal.org/smash/get/diva2:708652/ FULLTEXT01.pdf

[42] Valohai, MLOps Basics. Available from: https://valohai.com/mlops/

[43] Kirenz J, Gröger C, Lutsch A. Data Platform Architectures & Machine Learning Operations (MLOps). Hochschule Der Medien. HdM Stuttgart; 2021. Available from: https://www.kirenz. com/slides/data-platform-mlops.pdf

[44] Kreuzberger D, Kühl N. Machine learning operations (MLOps): Overview, definition, and architecture. Available from: https://arxiv.org/ftp/arxiv/ papers/2205/2205.02302.pdf

[45] Liu Y, Ling Z, Huo B, Wang B, Chen T, Mouine E. Building a platform for machine learning operations from open source frameworks. In: 3rd IFAC Workshop on Cyber-Physical & Human Systems CPHS 2020. Beijing, China: ScienceDirect, Elsevier; 3-5 December 2020. DOI: 10.1016/j.ifacol.2021.04.161

[46] Munir M. How artificial intelligence can help project managers. Global Journal of Management and Business Research: Administration and Management. 2019;**19**(4):29-35. Online ISSN: 2249-4588 & Print ISSN: 0975-5853

#### **Chapter 6**

## Perspective Chapter: Program Planning and Management for Defense Advanced Concept Technology Programs

*Tien M. Nguyen*

#### **Abstract**

The complexity of program planning and management (PPM) for defense programs and related projects depends on the program types and associated budget size. In general, the defense program types can be classified into three categories, namely, normal program of record (POR), new program with traditional and/or well-defined acquisition strategy, and advanced concept technology (ACT) program. This chapter offers a new perspective on the development of an effective PPM plan for ACT programs. For the ACT program type, the traditional PPM is usually not applicable and required to be handled differently according to the uncertainty associated with the technical requirements and associated technology and corresponding cost risks. The chapter provides an overview of typical ACT PPM and associated planning, execution, and management activities from both government and contractor's perspectives. In addition, the chapter attempts to (i) quantify the risks associated with ACT programs in terms of innovation indicators using simplified Cooper chart, and (ii) develop a set of recommended PPM activities that can be used as a basic framework for conducting the planning and execution of PPM of ACT programs.

**Keywords:** advanced concept technology, program planning and management, defense, acquisition, requirement, technology risk, cost risk, innovation, Cooper chart

#### **1. Introduction**

In practice, the complexity of planning, managing, and executing a defense program depends on the budget size and program type. In the US, for a new traditional or a POR with large budget, usually above 100M USD, the government PM plans the program using the DOD acquisition system [1, 2] and DOD Instruction (DODI) 5000.02 [3]. The PM follows the planning and execution of the program according to the DOD guide for PMs [4]. In addition to the DOD guide for PMs, the government PM also uses additional DOD guidebooks to (i) identify the potential technical, management, and related program issues and risks [5], and (ii) investigate the use of modular open system approach to reduce the interfaces technical risk and the

associated cost [6]. When the new traditional program with large budget involved with the acquisition of commercial products and/or commercial services, the government PMs seek guidance from the federal acquisition regulation (FAR) Part 12 [7] for the development of a PPM plan. This type of large programs is usually required to go through the normal acquisition process, which leverages mature technology and related technology enablers (TEs). In practice, the level of mature technology is defined using the Technology Readiness Level (TRL) scale ranging from TRL-1 to TRL-9 [8]. TRL-1 is defined as the basic principles have been observed and reported, and TRL-9 is for an actual system is proven through successful mission operations. Practically, TRL-8 is usually considered to be matured, because at this TRL the actual system is completed and qualified through test and demonstration.

Unlike the traditional program and/or POR, for advanced concept technology (ACT) programs with small budgets (less than 100M USD) are usually not acquisition programs. This type of advanced defense programs includes DOD ACT Demonstration Program (ACTD) [9, 10], advanced contract research and development (CRAD) programs from DOD Laboratories (Labs) (e.g., Air Force Research Lab (AFRL), Naval Research Lab (ARL), Army Research Lab (ARL), etc) [11], and Defense Advanced Research Projects Agency (DARPA) programs [12, 13]. In addition to these ACT programs, US government also manages ACT programs with emphasis on the development of advanced TEs in critical technology areas by domestic small businesses [14]. These ACT programs are referred to as Small Business Innovation Research and Small Business Technology Transfer (SBIR/STTR) programs. For these ACT programs, the government PMs are required to use different DOD acquisition process that is different from the normal acquisition process for traditional programs and/or POR. The development of a PPM plan for ACT programs is quite different from traditional/POR programs with large budgets. In practice, when selected as the prime contractor (a.k.a. developer) for executing an ACT program, the contractor program manager (PM) is also required to develop a PPM plan, and execute and manage the plan, according to the government PPM requirements.

The primary objective of this chapter is to provide an overview on the development of an effective PPM plan and executing the plan from both government and contractor perspectives. The chapter also provides a set of recommendations that can be used as a basic framework for the development and executing a PPM plan. The chapter has eight main sections, and it is organized as follows:


*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*


#### **2. Characteristics of ACT programs/projects**

**Figure 1** captures typical DOD ACT program types discussed in Section 1. For US DOD, the defense ACT program types can be classified into four categories, namely, ACTD, DARPA, CRAD, and SBIR/STTR programs. The ACTD programs usually range from a few millions USD to 10+ mils USD [10], which are initiated by DOD to determine a proposed mature technology enabler (TE) that will be used to improve specific defense capabilities before entering the normal DOD acquisition process. The period of performance (PoP) for the assessment of the proposed TE is typically between 2 to 4 years, and the TE under ACTD program implementation is usually at TRL-7 (or even at TRL-8) with a goal to achieve higher TRL before entering formal acquisition process. Note that TRL-8 and TRL-9 indicate low and the lowest possible technology risk level, respectively. From the government PM perspective, ACTD program requires to identify (i) a mature TE that aligns with a priority military need for achieving specific defense capabilities, and (ii) a corresponding government sponsor in urgent needs of these capabilities. From the developer (contractor) PM perspective, ACTD program requires the execution team to be ready and prepare a detailed plan to conduct the demonstrations and/or exercises with required key performance parameters for the military utility assessment. The plan must also address all related risks for the demo/exercises.


*A general description of ACT program types.*

The CRAD programs are usually more advance than the ACTD programs, since they are more focus on the advancement of scientific and technical knowledge and apply that knowledge to achieve specific goals set by the sponsored agency and national goals [11]. Practically, most of CRAD programs usually start at TRL-1. Like ACTD programs, CRAD program funding has similar budget ranging from a few millions USD to 10+ mils USD. PoP for CRAD programs also range from 2 years to 4 years. From the government PM perspective, CRAD program requires to (i) find a critical technology area and related TEs that are aligned with the agency needs and national goals, and (ii) supply a clear, concise, and complete statement of work (SOW) or a request for proposal (RFP) describing the area for basic research and the end objectives for development and applied research. The technical and contracting personnel must individually tailor the SOW/RFP to allow for contractor to exercise innovation and creativity while achieving objectives of the R&D [11]. From the contractor PM perspective, the CRAD program requires the contractor execution team to be ready and prepare a detailed PPM plan to address the SOW/RFP requirements and associated challenges. The contractor PPM plan must also provide supporting evidence to demonstrate the contractor's technical capabilities to achieve the end objectives.

The DARPA program type is quite different than ACTD and CRAD programs because they are focused the development of breakthrough technology [12]. As stated in the DARPA website, the objective of DARPA programs is to transform revolutionary concepts and even seeming impossibilities into practical defense capabilities. Typical DARPA program ranges from a few millions USD funding and up to 100M<sup>1</sup> USD [13]. Practically, DARPA program PoP ranges from 1 to 3 years for proof of revolutionary concepts. From DARPA perspective, DARPA program requires to (i) identify a revolutionary and breakthrough technology that aligns with DARPA needs (or national needs), and (ii) provide a clear, concise, and complete Broad Agency Announcement (BAA) or an RFP describing the area for research and development pushing the leading-edge technology and the end objectives. The BAA/RFP should address how DARPA rewards risk by clearly define criteria for evaluating the proposed DARPA programs using a set of questions known as the "Heilmeier Catechism" [15]. From the contractor PM perspective, DARPA program requires the contractor execution team to be ready and prepare an innovative PPM plan to address the BAA/ RFP requirements with emphasis on the answers to Heilmeier's questions. The plan must clearly describe the innovative features of the proposed solution and provide supporting evidence to demonstrate the contractor's technical capabilities to achieve the program objective.

Last but not least, the SBIR/STTR programs are usually focused on the critical technology areas that are aligned with the government agencies' objectives and national goals. Typical SBIR/STTR programs are usually emphasis on the basic and applied research for advancing the state-of-art, increasing knowledge, or understanding of specified technology and related TEs rather than focusing on a specific system or hardware solution. Typically, these programs have three phases, namely, Phase 1, Phase 2, and Phase 3. Phase 1 funding ranges from 150K to 175K USD, Phase 2 funding from 750K to 1M USD, and Phase 3 funding ranges from 2M or higher depending on

<sup>1</sup> In practice, for defense ACT programs, the program manager is required to (i) go through official program management and EVMS training programs, and (ii) be certified at specific certification level corresponding to the ACT program budget.

*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

the commercialization matching funds. Typical PoP for Phase 1 is usually from 6 months to 1 year, Phase 2 is 2 years, and Phase 3 is 2 to 4 years depending on the funding and industry partner's plan for the integration with existing partner's products or planned systems.

#### **3. ACT program life cycle: government vs. contractor perspectives**

Practically, a detailed ACT program life cycle varies depending on the ACT program types, agency objectives and national goals. Thus, the development of a PPM plan also varies accordingly depending on government and contractor perspectives. This section provides an overview of typical ACT program life cycle and discusses the roles of the PMs and desired PPM activities from both government and contractor perspectives. In general, the ACT program life cycle can be expressed in four phases, namely, concept, pre-acquisition, post-acquisition, and transition phases as shown in **Figure 2**. The figure is derived from the traditional DoD program acquisition life cycle [1–3]. It also captures the roles of government and contractor PMs for each phase.

As shown in **Figure 2**, the government PM role with required PPM activities covers the entire ACT program life cycle from the concept phase to the transition phase. While the contractor PM role with PPM activities begins after the pre-acquisition from the post-acquisition to the transition phases. Theoretically, the contractor PM role starts at the post-acquisition phase after the ACT contract is awarded. But in practice, the contractor PM role starts at the release of the BAA/RFP/SOW. For large ACT programs (i.e., 10<sup>+</sup> M USD), at the release of the BAA/RFP/SOW, the contractor PM is usually working with the contractor capture team (CCT) under the leadership of a business capture manager to prepare and generate proposal and cost volume for the bids. The contractor capture and program managers with support from their program chief engineer will work with the government PM to gain a deep understand of the agency objectives, national goals, and corresponding program requirements to properly address them during the preparation of the proposal and cost volume.

**Figure 2.** *ACT program life cycle derived from traditional DoD program life cycle [1–3].*

As mentioned earlier, the PPM activities begin at the concept phase and preacquisition phase for the government team and contractor team, respectively. In practice, for the contractor team, the PPM activity begins at end of the pre-acquisition phase after the lease of the BAA/RFP/SOW and the execution of the PPM plan starts at the beginning of the post-acquisition phase after the contract award and continues throughout the transition phase. As shown in **Figure 2**, the role of the contractor PM changes slightly during the transition phase. When the technology and associated TE developed by the program is selected for transition to existing POR and/or planned acquisition program, the contractor PM and his technical team will continue to work with the new government PM to integrate the newly developed TEs into the new program execution plan. When the newly developed TE is selected for commercialization, the contractor PM will continue to work with the government PM and the industry partner to commercialize the products. For SBIR/STTR programs, the funding for the commercialization of the ACT products is usually through a matching fund with support from an industry partner. Note that for ACTD program, if the selected technology and associated TE are successfully demonstrated, the contractor PM will continue to work with the new government PM.

During the concept phase, the government PM works with the government team to develop a PPM plan. The team includes potential stakeholders, technical personnel, contract personnel, and operational users. The government team ensures that the PPM plan will (i) provide required operational capabilities to meet the user needs, and (ii) meet the end objectives and national goals. The user's needs must be identified and approved by appropriate government decision makers and associated stakeholders. After the approval, the government PM will conduct industry survey (a.k.a. market survey) to collect necessary technical inputs and related data to identify appropriate technologies and related TEs to address the user's needs. The government PM with support from the team will work with government acquisition authority to make the decision on new ACT programs/ projects based on the collected inputs and data. A positive decision allows to turn on the pre-acquisition process and start the new ACT programs/projects. During this pre-acquisition phase, the government PM with support from government technical and contract personnel will identify and analyze the program risk, including technical performance, cost, and schedule risks and prepare the BAA/RFP/SOW. The government PM generates and releases the BAA/RFP/SOW to public for bids. After the release of BAA/RFP/SOW, the government PM forms the source selection team (SST) consisting of subject matter experts (SMEs) in specific technology areas related to the ACT topics, cost, contract, and schedule. The SST will review and select the best proposal(s) for the contract award. The post-acquisition phase begins after the contract award, and the government PM executes and manages the ACT contract (i.e., executing and managing the PPM plan) to ensure the contractor team meets the contract requirements from technical, cost, and schedule perspectives.

The contractor team begins the PPM activities after the release of BAA/RFP/SOW. The team usually works with the government PM to (i) understand the ACT program requirements, and (ii) prepare the proposal addressing all required requirements and submits the bid. As mentioned earlier, for large ACT programs (10<sup>+</sup> M USD), the contractor PM works with the business capture manager to accurately address all ACT program requirements with high probability of winning the contract award. For this type of program, the contractor capture team (CCT) will develop an effective PPM plan to ensure high probability of win. The CCT team consists of SMEs across contractor's organization, including engineering, contract, cost, and schedule departments. After the contract award, the contractor PM will work with the government

#### *Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

PM to adjust the proposed contractor's PPM plan to ensure alignment with the government's PPM plan. The contractor PM will work with his contractor execution team to execute the adjusted PPM plan. The contractor PM reports the program progress and milestone accomplishments to the government PM. The role of the contractor PM will slightly change during the transition phase depending on the transition path. As shown in **Figure 2**, when the transition path goes to existing and/or planned DOD program that followed normal DOD acquisition process, the contractor PM is required to work with the existing government PM and the new government PM<sup>2</sup> and the new government execution team to develop an integration plan. At this time, the contractor team is required to (i) gain a good understanding of the proposed system being acquired, and (ii) develop an integration plan to integrate the newly developed TEs into the proposed system. The contractor PM and the contractor execution team are usually required to provide technical support over the life cycle of the DOD program being transitioned into. When the transition path goes to the commercialization path, the contractor PM will work with the ACT government program PM and the interested industry partner to develop detailed plan and associated products using the newly developed TEs. For this transition path, the contractor PM is required to understand the industry partner products and the to be developed products.

The remaining of this chapter provides an overview of the ACT program PPM activities for both government and contractor perspectives.

#### **4. ACT program planning: the Zachman framework**

As pointed out in ref. [16], there is a set of twenty multiple PM discipline areas, including (i) Program goals management, (ii) Systems engineering related to the systems/products/services being acquired, (iii) Specialized engineering related to the products and services being acquired, (iv) Contracts and legal dealing with contractors, suppliers, and stakeholders, (v) Program Financial management, (vi) Business and marketing practices for the newly acquired systems/products/services, (vii) System/ product/service technical requirements and associated performance risk management, (viii) System/product/service cost planning and management, (ix) Program schedule planning and management, (x) Program cost planning and management, (xi) System/ product/service3 risk planning and management, (xii) Program risk planning and management, (xiii) System test and evaluation, (xiv) Logistics and supply chain management, (xv) Production, Quality, and Manufacturing (PQM), (xvi) Program and system intelligence and security management, (xvii) Program and system software management, (xviii) Program and system configuration management, (xix) Program and system information technology, and (xx) Other Specialty Program Planning and Management. For ACT programs, depending on the PM's perspective, the PM is required to select a subset of these PM discipline areas for the development of an effective PPM plan. From the government perspective, at the minimum, the PM must develop a PPM plan that addresses the eleven out of the twenty PM discipline areas listed above, including (i), (ii), (iii), (iv), (v), (vii), (viii), (ix), (x), (xi), and (xii).

<sup>2</sup> In practice, the government PM for the existing and/or planned acquisition program is different from the government PM for the ACT program.

<sup>3</sup> The term "a system" in ACT program context means a new system concept that leverages advanced TEs being developed under the ACT program, which depends on the application.

From the contractor perspective, the PM also requires develop a PPM plan that addresses the same PM discipline areas except Bullet (i), namely "program goals management." Note that for the PM discipline area (iv), namely the "contracts and legal dealing with contractors, suppliers, and stakeholders," the contractor PM is required to address the contracts and legal dealing with the government PM and its subcontractors, including the suppliers. Based on our experience working on ACT program planning from both contractor and government perspectives, the Zachman framework can be tailored to effectively develop the PPM plan:


To develop an effective PPM plan, the Zachman framework can be tailored as recommended in **Table 1** to address the PPM activities across the PM discipline areas (i), (ii), (iv), (v), (vii), (viii), (ix), (x), (xi), and (xii) from both government and contractor PM perspectives. Like standard Zachman framework, the recommended tailored-Zachman framework also organizes around the points of view taken by the various players. The players include government PM and contractor PM. From the government perspective, the PM undertakes the planning of an ACT program to ensure alignment with the agency objectives and national goals. Hence, the government PM role is to develop a PPM plan, prepare, generate and release BAA/RFP/SOW that is fully support by the industry. From the contractor perspective, the PM will work with his technical team to identify and apply specific technologies and related TEs to solve the ACT problems described in the government released BAA/RFP/SOW. In summary, each of these players can look at the same PM discipline areas but with different perspectives. The government perspective is to ensure meeting the agency's ACT development objectives and national goals within allocated budget with minimum program risks. The key program risks are defined in terms of technology and market uncertainties that will be discussed in the next section.

Like standard Zackman framework, the roles of the players are represented by rows in a matrix shown in **Table 1**, and the columns represent the issues/topics that will be examined by the players. More specifically, the columns represent [17, 18]:


*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*


**Table 1.**

*Tailored Zachman framework for ACT program planning [17, 18].*

The set of cells shown in **Table 1**, constructed by the roles of the players and the issues/topics to be examined by the players. These ceels describe all the ACT planning topics/issues that are required to be addressed by the government and contractor PMs. The government PM will use this tailored Zachman framework to conduct the PPM activities under government perspective discussed. The contractor PM can also use this tailored framework but with contractor perspective. Unlike the government perspective, the contractor perspective focuses on meeting the government requirements stated in the released BBA/RFP/SOW with minimum cost (i.e., maximum profit) and lowest ACT program risks. The ACT program risks will be addressed in the next section.

The description of the rows in the first column shown in **Table 1** is given below:


#### **5. Quantification of ACT program risks using innovation indicators**

This section emphasizes on the analysis of ACT program risks for the development of an effective PPM plan. From a PM's perspective, regardless of government or contractor, it is important to understand and mitigate the program risks. As discussed in Section 4, the technology and market<sup>4</sup> uncertainties are the key attributes for the

<sup>4</sup> Note that the market uncertainty represents the measure of the uncertainty associated with the availability of the hardware/software (HW/SW) components associated with the selected technology and related TEs. Low market uncertainty means there are related SW/HW components available in the market and these components are required to modify/upgrade to meet the required ACT program requirements. High market uncertainty means no HW/SW components are available in the market.

*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*


**Table 2.**

*Newly proposed ACT program innovation indicators.*

assessment of ACT program risks. Practically, the technology and market uncertainties can be used to translate into the technology and market risks, respectively. To plan and manage these risks, the PMs are required to quantify these risks based on the technology and market uncertainties provided by the manufacturers. Let us classify the uncertainty (i.e., risk) levels as Low (L, blue color), Medium (M, green color), and High (H, red color), and define the innovation indicators associated with these uncertainty levels as follows:


**Table 2** summarizes the technology and market risk levels associated with the five proposed innovation indicator levels. Our next step is to associate these innovation indicator levels with the desired innovative solutions required for various types of ACT programs as described in **Figure 1**.

In practice, private and for-profit enterprises (PaFoPEs) are usually invested into their internal research and development (IRAD) projects<sup>5</sup> to (i) defend and extend their current capabilities to sustain the position in existing market, (ii) prepare for a venture launch by continuously improving existing products, (iii) look-out for a market for their new products (scouting option) by incremental changes of

<sup>5</sup> This is a.k.a. industry IRAD projects, which in internally funded by private and for-profit enterprises to improve their existing products or launch a new products or prepare to capture new programs.


#### **Table 3.**

*Newly proposed mapping of IILs to industry IRAD and ACT projects/programs.*

technology, (iv) position for a newly developed radical technology and related products that can transform industry and potentially creating a new market (position option), and (v) develop disruptive technology that can disrupt existing products and market (stepping-stone option) [19–23]. In fact, these types of PaFoPEs' IRAD projects are usually classified based on the technology and market risks that can be mapped to the IILs presented in **Table 2**. For government ACT programs listed in **Figure 1**, they are classified in terms of TRLs that can be linked to the technology risk shown in **Table 2**. Thus, ACT programs can also be mapped to the IILs presented in **Table 2**. **Table 3** captures the mapping of the IIL levels to industry IRAD projects and government ACT projects/programs.

As shown in **Table 3**, the ACTD type of ACT programs focuses the technology demonstration of mature TEs with high TRLs (i.e., L technology risk). The CRAD type of ACT programs can range from low-to-high TRLs (i.e., H-to-L technology risk). Typically, the SBIR/STTR program type focuses on the development of TEs ranging from medium-to-high TRLs (i.e., M-to-L technology risk). Finally, the DARPA programs/projects focus on the development of disruptive technology with low TRLs (i.e., H technology risks). The mapping shown in **Table 3** reflects these facts. Note that the mapping of SBIR/STTR, CRAD, and DARPA are based on our experience working on these ACT programs/projects.

The mapping presented in **Table 3** can be captured using a simplified Cooper chart approach [19–23] as shown in **Figure 3**. In this figure, the chart has two axes, namely, x-axis represents the market uncertainty indicator, and the y-axis is the technology uncertainty indicator with a scale from low to high corresponding to L-to-H risk. As mentioned earlier, the technology and market uncertainty indicators are translated directly to technology and market risks. The technology risk is indicated by the TRL as discussed above.

Note that the market risk presented in **Table 2** can be translated into the manufacturing readiness level<sup>6</sup> (MRL) [24, 25]. The five IILs presented in **Table 2** are

<sup>6</sup> The MRL concept was developed by the US DOD to assess the maturity of a manufacturing process throughout its conception, development, deployment and support progression phases. As defined in Refs [24, 25], MRLs, the MRL scale ranges from MRL-1 to MRL-10, with MRL-1 being the least mature and MRL-10 being the most mature.

*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

**Figure 3.**

*Newly proposed simplified cooper chart for quantifying the innovation indicators.*

then mapped onto the simplified Cooper chart depending on their assigned risks. The mapping of the industry IRAD projects and government ACT programs/projects shown in **Figure 3** is performed using **Table 3**.

In practice, from the PaFoPE perspective, the industry IRAD projects are usually planned and managed by PaFoPEs to align with the national goals and agencies' objectives. If this alignment is done properly, it will help PaFoPEs to (i) prepare their proposals for biding the BAA/RFPs/ SOWs to be released by DOD agencies, (ii) effectively address the government requirements described in their released BAA/ RFPs/ SOWs, and (ii) increase the probability of winning the bids. From the government perspective, understanding of the technology and market risks will help the program managers to better plan the budget and prepare the BAA/RFPs/SOWs.

#### **6. Program management: balancing cost, technical, and program management risks**

As discussed in Section 4 above, there are only ten or eleven out of twenty program management discipline areas that required the program managers to address during the program planning and execution phases. A good program manager must know to balance cost, technical, program management risks during the planning and execution phases. An effective PPM plan must carefully address the three key program management discipline areas including cost, schedule, and program risk planning and management. To do this the program manager must understand the key ACT program risk types and identify all associated risks for each type. Based on our experience, there are four key ACT program types, including technical/technology risk, non-technical risk, people/staffing risk, and program management risk. Based on our research in public domain concerning the risk type [1–34], a generic list of risks for each of these risk types is provided in **Figure 4**. Understanding of these risks will help the program

#### **Figure 4.**

*Understanding the key ACT program risk types.*

managers to balance the cost, schedule, and program management risks when executing the ACT programs. As an example, if the technical risks associated with technology maturity and system complexity are high, the program manager must (i) identify a subject matter expert and a technical team who are familiar with the identified technology and related TEs, and (ii) allocate appropriate budget to mitigate these risk in the program plan.

Understanding of the ACT program risk types and associated risks will help the program manager to identify the risks and develop an effective program plan to mitigate and balance out the identified risks. Depending on the PM's perspective, the ACT program risk types and associated risks (see **Figure 4**) usually have different impacts on the program planning and execution. Based on our experience, to effectively develop a PPM plan for executing and managing the program during the postacquisition phase, the program manager requires to understand all PPM activities throughout the ACT program life cycle illustrated in **Figure 2**. From the government perspective, **Figure 5** describes these PPM activities from the concept phase through the pre-acquisition phase with related source selection planning-and-execution and to the post-acquisition phase. For the concept phase shown in **Figure 5**, the planning actives must address the following tasks: (i) understand the agency objectives and national goals, (ii) understand the user needs and align the user needs with agency objectives and national goals, (iii) identify the required technology and related TEs to provide desired operational capability that meet the user needs, and (iv) conduct the (industry) market survey to understand the technology and market uncertainties on the identified technology and related TEs. For the pre-acquisition phase, the planning activities must address the following tasks: (i) analyze, assess, and quantify the program risks based on the (industry) market survey results, (ii) identify the technical and programmatic challenges based on the market assessment results, (iii) identify and generate required technical tasks in the form of the work breakdown structure (WBS) to address the identified challenges, and (iv) conduct and perform cost, schedule, and program planning and analysis to fit the allocated budget and scheduled timeframe and generate the government program plan to be described in the BAAs/ RFPs/SOWs. For the source selection planning-and-execution phase, the activities must address the following tasks: (i) generate and release the BAAs/RFPs/SOWs to

*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

#### **Figure 5.**

*A new perspective on the understanding ACT program planning, execution, and management activities from government perspective.*

public domain requesting the bids from industry, (ii) form a source selection team with subject matter experts on both technical and program management areas, (iii) conduct source selection and select the best contractor for executing the government program plan, and (iv) announce the contract award winner(s) and debrief the losers. Finally, for the post-acquisition phase and program execution- and-management, the activities must address the following tasks: (i) plan and conduct program kick-off and work with the selected contractor to finalize the program requirements and request the contractor to present their final execution program plan at the kick-off meeting, (ii) conduct the program quarterly review (should be bi-monthly for short period of performance program), (iii) review contractor quarterly reports and identify new and/or potential technical and programmatic risks and update the cost/schedule/and program plan to add new risks and retire the old ones, and (iv) conduct final review and evaluate final report to make final decision on the way forward.

Similarly, from the contractor perspective, **Figure 6** illustrates the desired PPM activities from the pre-acquisition phase through the source selection planning-andexecution and to the post-acquisition phase. Unlike the government perspective, the contractor perspective does not have the concept phase planning activities. For the pre-acquisition phase illustrated in **Figure 6**, the contractor planning actives must address the following tasks: (i) receive and review<sup>7</sup> the BAAs/RFPs/SOWs from the DOD agency of interest, (ii) form a CCT8 to prepare the proposal and start the bidding process<sup>9</sup> , (iii) conduct the contract requirement flow-down, (iv) identify the key

<sup>7</sup> In practice, the capture or (and) program manager(s) is (are) usually the initial reviewer(s).

<sup>8</sup> For program with budget of 5+ M USD, CCT team includes a capture manager, PM, and a program chief engineer, who will oversee engineers and staff with required experience.

<sup>9</sup> In practice, industry bidding process is a gate process deciding if the BAA/RFP/SOW is aligned with PaFoPE's interest with high probability of win. The chapter assumes that the BAA/RFP/SOW is of PaFoPE's interest. Note that PaFoPE is the acronyms of private and for-profit enterprise.

program requirements and associated technical and programmatic challenges, (v) tailored system engineering process with required program tasks and generate a WBS addressing the overall program requirements and challenges, (vi) analyze program cost, schedule, and program planning to fit the allocated budget and schedule within specified timeframe, (vii) conduct program cost, schedule, and program risk assessment, and (viii) revise and finalize the WBS to address cost, schedule, and all technical and program risks. For the source selection planning-and-execution phase, the PPM activities must address the following tasks: (i) generate the proposal and prepare the cost volume for the bid, (ii) work with the government PM to gain better understanding of ACT program requirements, (iii) refine the proposal and cost volume as needed, (iv) submit the proposal and cost volume, and (v) when requested, respond to government source selection team and wait for the contract award decision. Finally, for the post-acquisition phase and program execution- and-management (assuming the contract is awarded), the PPM activities must address the following tasks: (i) work with the government PM to plan and conduct program kick-off and finalize the program requirements and present the final execution program plan at the kick-off meeting, (ii) work with the government PM to prepare and execute the program quarterly review (should be bi-monthly for short period of performance program), (iii) respond to government PM's requests, and (iv) prepare and execute final program review and address all government PM's requests.

**Figures 5** and **6** describe the recommended PPM activities that can potentially help the program managers to develop an effective PPM plan with a good balance between cost, technical, and program management risks for both government and contractor perspectives, respectively. From the government perspective shown in **Figure 5**, the act to balance the cost, technical, and program management risks occurs between the pre-acquisition planning phase (see blue-star) and the post-acquisition phase (see redstar). In practice, the blue-star captures the government PPM plan, while the red-star captures the progress of the plan during program execution phase. This is the time

#### **Figure 6.**

*A new perspective on the understanding ACT program planning, execution, and management activities from contractor perspective.*

#### *Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

when the government PM can balance the cost, schedule, and program risks based on contractor's performance. The PM will (i) add new risks and retire the old risks, and (ii) adjust the PPM plan to balance the risks. Similarly, from the contractor perspective, the act to balance the risks also occurs between the blue-star and the red-star shown in **Figure 6**. It should be noted that, for a small ACT program, the PPM only requires the WBS, and a schedule plan. For large budget program (typically 20<sup>+</sup> M USD), the PPM plan requires an integrated master plan (IMP) and integrated master schedule (IMS) [26, 27].

#### **7. Earned value management system for tracking and managing risks**

In practice, both government and contractor PMs use the Earned Value Management System (EVMS) to effective track and manage the program risks. As described in [29, 30], the term "EV" is defined as an objective measure of the work done expressed in terms USD or hours that representing the value of the work done. The "earned value management (EVM) process is defined as the process of defining, planning, and controlling the scope of work, program schedule, and program budget. Thus, the EVMS is the integration of EVM processes, EVM procedures, and related EV tools to comply with the ANSI/EIA Standard 748 [28]. He recommended EVMS is a combination of processes, procedure, and related tools [28–31], which can be used to measure and track the "earned value" (EV) against an integrated baseline plan (IBP) captured in the PPM plan. The IBP is the baseline IMP and IMS mentioned earlier. In practice, for defense ACT programs with contract value greater than or equal to 20M USD, the contractor PM is required to submit the integrated program management report (IPMR) to the government PM [29, 32]. The IPMR combines and replaces the Contract Performance Reports per DIMGMT-81466 and the Integrated Master Schedule per DI-MGMT81650 [33]. The IPMR report contains the EV performance data. Per DI-MGMT-81861 [32], the report provides required program status of contract cost and schedule performance according to the government required seven formats. The seven formats include Formats 1, 2, 3, 4, 5, 6, and 7. **Table 4** summarizes the requirements associated with the seven required formats.


**Table 4.**

*Description of required IPMR seven formats to capture EV performance data [32, 33].*


**Table 5.**

*Applicability of EVMS to ACT programs/projects [32, 33].*

As indicated in [29, 30], US government has adopted the standard that defines the EVMS implementation requirements for tracking and managing risks for all defense programs. According to [29], the EVMS implementation is (i) a mandatory requirement for all defense programs with contract value greater than or equal to 20M USD, and (ii) not required for less than 20M USD. Per DI-MGMT81861A, for contract value between 20M and \$50M, a simplified IPMR report may be allowed at the government PM discretion based on program risk. The simplified IPMR requires to report EV data according to Formats 1, 5, and 6 described in **Table 4**. For contract value greater than \$50 M, a full IPMR report is required, including all formats described in **Table 4**. **Table 5** captures a summary of the applicability of EVMS to defense ACT programs/ projects and associated contract values.

To provide a better understanding of EV data and related cost and schedule performance data, the remaining of this section provides an overview of the recommended baseline EVMS model. The model includes five key EV data captured the Budgeted Cost of Work Scheduled (BCWS), Budgeted Cost of Work Performed (BCWP), Actual Cost of Work Performed (ACWP), Budget at Completion (BAC), and Estimate at Completion (EAC) [28, 31]. The BCWS represents the planned EV of the work planned to be accomplished in a period of time. BCWS can be calculated using:

$$\text{BCWS} = \text{\%Complexe}(\text{planned}) \* \text{ProjectBudget} \tag{1}$$

BCWP is defined as the EV of completed work in terms of the work's assigned budget and calculated using the following equation:

$$\text{BCWP} = \% \text{Complete}(\text{Actual}) \ast \text{ProjectBudget} \tag{2}$$

The ACWP is the actual cost incurred and recorded for work completed within a specified time period. The contractor PM usually reports the cumulative ACWP for the WBS work package that have been completed. Finally, the estimate of BAC is established by the PMs during the program planning phase. From the contractor perspective, the contractor PM estimates the BAC during the pre-acquisition phase for every specified level of the WBS. The BAC value represents the total budget from which individual period BCWS values are derived and they are the benchmarks for assessing overruns and underruns at the end of the contract. The budgets for all authorized work must be captured within the BAC. The BAC can also be referred to as *Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

the "Total Planned Value" of a project. As indicated in [34], there is no formula for calculating BAC. The calculation of BAC requires complex cost estimating methods and associated tools [16, 34]. Popular estimating methods include parametric, analogy, engineering estimate, actual costs, and three-point estimate [34]. Popular estimating tools include SEER, aPriori Cost Estimating Software Tools, and DOD COCOMO Software [16].

The cost and schedule performance data are characterized by Schedule Performance Index (SPI) and Cost Performance Index (CPI), and the SPI and CPI data are generated using the following equations:

$$\text{SPI} = \frac{\text{BCWP}}{\text{BCWS}} = \begin{Bmatrix} \text{SPI} \mathbf{1} : \text{Indicatedes an head} - \text{of} - \text{schedule condition} \\ \text{SPI} < \mathbf{1} : \text{Indicated} - \text{schedule condition} \end{Bmatrix} \tag{3}$$

$$\text{CPI} = \frac{\text{BCWP}}{\text{ACWP}} = \left\{ \begin{array}{c} \text{CPI} > \mathbf{1} : \text{Indicated cost efficiency condition} \\ \text{CPI} < \mathbf{1} : \text{Indicated cost efficiency condition} \end{array} \| \text{plain} \right\} \tag{4}$$

The PMs track and monitor the SPI and CPI data manage the execution teams according to the reported SPI and CPI values. As an example, when both SPI and CPI indices are equal to 1, the execution team performs their work according to schedule time and allocated budget. For instance, if the SPI is .8, it means that the team is behind the schedule and that only 80% of the scheduled work has been completed, not the 80% of the total planned work. When the CPI is .8, it means that for every dollar actually spent by the execution team, only 80% worth of work was performed. For this case, the execution team might have spent 20% of the budget on the re-work.

The EAC is also an important EV parameter that required the PMs to track and monitor. The EAC value represents the forecasted total budget that is required to complete at a given time during a project. The EAC value can be computed using BCWP, ACWP, SPI, and CPI using the following equation:

$$\text{EAC} = \text{ACWP} + \frac{\text{BAC-BCWP}}{\text{CPI} \ast \text{SPI}} \tag{5}$$

Other related EV parameters are the percentage of the Cost Variance (CV%), percentage of the Schedule Variance (SV%), and the Variance at Completion (VAR). The CV%, SV%, and VAR can be calculated from the EV data using the following equations:

$$\text{ACV@} = \frac{\text{BCWP} - \text{ACWS}}{\text{BCWP}} \tag{6}$$

$$\text{SV@} = \frac{\text{BCWP} - \text{BCWS}}{\text{BCWS}} \tag{7}$$

$$\text{VAR} = \text{BAC} - \text{EAC} \tag{8}$$

From Eqs. (6) and (7), the Cost Variance (CV) and Schedule Variance (SV) can be written as follow:

$$\text{CV} = \text{BCWP} - \text{ACWS}$$

¼ f g CV > 0 : Indicatesthecostunderrunplanjj j CV < 0 : Indicatesthecostoverrun

(9)

SV ¼ BCWP � BCWS ¼ fSV > 0 : Indicatesthescheduleisaheadplanjj j CV <0 : Indicatesthescheduleisbehind g (10)

In practice, the level of effort (LOE) cannot have a schedule variance because BCWS and BCWP are always the same. The PMs can use the EV data to check and correct for anomalies associated with the program "health." Typical anomalies are: (i) actual budget that is required to complete at a given time during a project should never be greater than EAC at the same given time, and (ii) you cannot earn more than what is budgeted, i.e., BCWP cannot be greater than BAC.

#### **8. Conclusion and recommendations**

The specific nature of ACT program characteristics requires the PMs to have a good understanding of the PPM activities to develop effective PPM plans. As discussed above, the plan will be developed depending on the PM's perspective, i.e., contractor vs. government. In general (regardless of the perspective), a PM, who is responsible for the planning and executing an ACT program, must have a good understanding of the challenges and issues associated with ACT program characteristics, acquisition life cycle, program cost/technical/management risks, desired PPM activities for balancing cost, technical and program management risks, and EVMS methods and tools. The above sections, Sections 2, 3, 4, 5, 6, and 7, have provided an overview with sufficient details on each of the challenges and issues mentioned above. To help improve the preparation and development of an effective PPM plan during the concept and pre-acquisition phases, the chapter recommends (i) a tailored Zachman framework for PPM planning, (ii) an innovative approach to quantify the technology and market risks associated with ACT programs using the innovation indicators and simplified Cooper chart, (iii) a set of PPM activities for balancing cost, technical and program management risks, and (iv) the EVMS applicability for tracking and managing the identified ACT program risks.

Recently, based on [16, 34–45] has proposed an approach to integrate data and decision sciences into PPM. The proposed integration approach for PPM planning and execution leverages big data analytics (BDA) technology with BDA data acquisition and data curation TEs, and ML-AI TEs. The recommended ML-AI TE's include (i) data mining techniques and tools (DMTT), (ii) data exploitation using multi-objective reinforce learning and adaptive neural network (MORL-ANN) tool, and (iii) predictive analytics techniques using MORL-ANN tool [34–45]. These ML-AI techniques and tools leverage related cost historical data bases, BDA framework with data acquisition and data curation models and tools to develop the program cost estimate and execute the EVMS plan to be included in the PPM plan. As pointed out in [35], there are many researchers and start-up companies developing algorithms, analytical models, and tools to apply ML-AI in program management. When this next generation ML-AI tools becomes popular and widely adapted by the decision makers (such as PMs and acquisition authorities), there will be radical changes that will disrupt the development and execution of a PPM plan [35] predicted that ML-AI will disrupt six aspects of PPM, including: (i) better section and prioritization, (ii) support for the project management office, (iii) improved, faster project definition, planning, and reporting, (iv) Virtual project assistants, (v) advanced testing systems and software, and (vi) a new role for the project manager.

*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

In summary, this chapter provides an overview of the ACT program types and related program characteristics along with program risks and describes the acquisition life cycle from both government and contractor perspectives. The chapter also describes (i) the government recommended ANSI/EIA Standard 748 for the implementation of EVMS framework, procedures, processes, and tools, and (ii) the trends for integrating ML-AI TES into the planning and executing of the PPM plan. In addition, the chapter recommends an innovative approach to quantify the technology and market risks, and a tailored Zachman framework that can be used to enhance the efficiency of a PPM plan. A set of desired PPM activities is also recommended for balancing cost, technical and program management risks. Finally, the chapter discusses the applicability of EVMS to ACT Programs and recommends a simplified EVMS report should be provided for contract value between 10M and 20M USD. The simplified report with Format 1 data analysis is required to capture cost and schedule performance data by a specified WBS along with a narrative report to capture the required performance analysis.

#### **Acknowledgements**

The author wants to thank his wife, Thu-Hang Nguyen, for her tremendous patience and support during the preparation and writing of this chapter.

#### **Conflict of interest**

The author declares no conflict of interest. The opinions expressed in this chapter are those of the author and they are not endorsed by CSUF nor Aerospace Corporation.

#### **Author details**

Tien M. Nguyen California State University, Fullerton (CSUF), California, USA

\*Address all correspondence to: tmnguyen57@fullerton.edu

© 2023 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

### **References**

[1] DOD Acquisition Process. Acquisition Process Overview. Available from: https://acqnotes.com/acqnote/ acquisitions/acquisition-process-overview

[2] DOD Directive 5000.01. The Defense Acquisition System. Office of the Under Secretary of Defense for Acquisition and Sustainment. September 2020, 2022. Available from: https://aaf.dau.edu/ storage/2022/07/DoDD-5000-01- Change-1-2022-07-28.pdf

[3] DOD Instruction 5000.02. Operation of the Adaptive Acquisition Framework. Office of the Under Secretary of Defense for Acquisition and Sustainment. 23 January 2020. Available from: https:// www.esd.whs.mil/Portals/54/Docume nts/DD/issuances/dodi/500002p.pdf

[4] William TC, Brian CR. A Guide for DOD Program Managers. Defense Acquisition Authority. Fort Belvoir, Virginia: Defense Acquisition University (DAU); December 2014. Available from: https://acqnotes.com/wp-content/ uploads/2014/09/A-Guide-for-DoD-Program-Managers.pdf

[5] Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs. Washington, D.C.: Office of the Deputy Assistant Secretary of Defense for Systems Engineering; January 2017. Available from: https://acqnotes.com/ wp-content/uploads/2017/07/DoD-Risk-Issue-and-Opportunity-Management-Guide-Jan-2017.pdf

[6] DoD Open System Architecture. Contract Guidebook for Program Managers, v1.1. Prepared by DoD Open Systems Architecture Data Rights Team. June 2013. Available from: https://www. acqnotes.com/Attachments/Open% 20System%20Architecture%20%28OSA %29%20Contract%20Guidebook%20for %20Program%20Managers%20June% 2013.pdf

[7] Tien MN. Program planning and management for defense advanced concept technology programs. In: Marinela M, Tien MN, editors. Project Management – New Trends and Applications. UKINTECH-Open Science; 2023

[8] Technology Readiness Assessment (TRA) Deskbook. Department of Defense. Director, Research Directorate (DRD). Office of the Director, Defense Research and Engineering (DDR&E). July 2009. Available from: https://apps.dtic.mil/sti/ pdfs/ADA524200.pdf

[9] Mark P. Advanced Concept Technology Demonstrations (ACTD). Program Resources & Integration Office of the Secretary of Defense DDR&E/ AS&C (Advanced Systems & Concepts). April 2006. Available from: https://ndiastorage.blob.core.usgovc loudapi.net/ndia/2006/science/ peterson.pdf

[10] General Accounting Office (GAO). Advanced Concept Technology Demonstration Program Can Be Improved. Report No. GAO/NSIAD-99-4 Defense Acquisition. October 1998. Available from: https://www.gao.gov/ assets/nsiad-99-4.pdf

[11] Federal Acquisition Regulation (FAR). Part 35 - Research and Development Contracting. FAC Number: 2023-04. 6 February 2023. Available from: https://www.acquisition. gov/far/part-35

[12] Defense Advanced Research Projects Agency (DARPA). About DARPA. DARPA Overview. Available from:

*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

https://www.darpa.mil/about-us/aboutdarpa

[13] Mariella M. What you need to know about DARPA, the Pentagon's mad science division. 19 July 2019. Available from: https://www.engadget.com/2014- 07-07-darpa-explainer.html?guccounte r=1&guce\_referrer=aHR0cHM6Ly93d3c uZ29vZ2xlLmNvbS8&guce\_referrer\_ sig=AQAAAG7aYv4lhc RVQrluKAES5CkktaRD-IvxeYg YWZ0EswiLZappyWlwR8UoZhJftQc6f jFAUoJI76Ng5-\_OL8R1c 0N1R0tzVyVVCKjSp4CCwiTFDHTVq\_ 0qOV4iQu1ugy0vyP0eOqec5zC5jjb 8WHVF2Q JZa2d-MHGQrjoOJ2HkM-cx

[14] Department of Defense. Small Business Innovation Research and Small Business Technology Transfer (SBIR/STTR) Programs. Available from: https://www.defensesbirsttr.mil/SBIR-STTR/Program/

[15] DARPA. The Heilmeier Catechism. Available from: https:// www.darpa.mil/work-with-us/ heilmeier-catechism

[16] Tien MN, John DTN, My TN, Charles HL, Tam N. Program management integrated with data and decision sciences. In: Marinela M, Tien MN, editors. Project Management – New Trends and Applications. IntechOpen. DOI: 10.5772/intechopen.109964. Available from: https://www.intech open.com/online-first/86949

[17] Zachman JA. A framework for information systems architecture. IBM Systems Journal. 1987;**26**(3):276-292. DOI: 10.1147/sj.263.0276

[18] Hay D. The Zachman Framework: An Introduction. The Data Administration Newsletter. June 1997. Available from: https://tdan.com/thezachman-framework-an-introduction/ 4140

[19] Marisa D, Knut B. Innovation indicators throughout the innovation process: An extensive literature analysis. Technovation (Elsevier). February– March 2019;**80–81**:3-29. Available from: https://www.sciencedirect.com/science/ article/pii/S0166497217301402?via% 3Dihub

[20] Ottinger R. Create Sustainable Success with the 4 Types of Innovation. Fresh Consulting. 2 April 2021. Available from: https://www.freshconsulting.com/ insights/blog/the-4-types-of-innovation/

[21] Miner K. The four levels of innovation: Assess the time, effort, and resources necessary to join the ranks of innovation. Pepperdine. Graziadio Business Review. Entrepreneurship, Innovations. 2010;**13**(4):1-3. Available from: https://gbr.pepperdine.edu/2010/ 10/the-four-levels-of-innovation/

[22] Cooper JR. A multidimensional approach to the adoption of innovation. Management Decision. 1998;**36**(8): 493-502. DOI: 10.1108/002517498 10232565

[23] Sopheonblog. Innovation and New Product Development Q&A with Dr. Bob Cooper. Webinar with Dr. Bob Cooper, the Founder of the Stage-Gate® System. Available from: https://www. sopheon.com/blog/innovation-and-newproduct-development-npd-qawith-bobcooper

[24] Program Management Tool for Aerospace. Production, Quality & Manufacturing, Manufacturing Readiness Level (MRL). AcqNotes. Your Government Contract Vehicle Experts Website. Available from: https://acqnotes.com/acqnote/careerfie

lds/manufacturing-readiness-levelma nufact

[25] Manufacturing Readiness Level (MRL) Deskbook, Version 2.0. Prepared by OSD Manufacturing Technology Program in Collaboration with the Joint Service/Industry MRLWorking Group. May 2011. Available from: https://www.dodmrl.com/MRL\_Deskb ook\_V2.pdf

[26] Program Management Tool for Aerospace. Program Management, Integrated Master Plan AcqNotes. Your Government Contract Vehicle Experts Website. Available from: https://acqnote s.com/acqnote/careerfields/integratedmaster-plan

[27] Program Management Tool for Aerospace. Program Management, Integrated Master Schedule. AcqNotes. Your Government Contract Vehicle Experts Website. Available from: https:// acqnotes.com/acqnote/tasks/integratedmaster-scheduleschedule

[28] Program Management Tool for Aerospace. Earned Value Management, NDIA EIA 748 Earned Value Management. AcqNotes. Your Government Contract Vehicle Experts Website. Available from: https:// acqnotes.com/acqnote/tasks/ ansi-eia-748-earned-value-management

[29] Earned Value Management System (EVMS) Interpretation Guide (EVMSIG). DoD. Earned Value Management Acquisition Analytics and Policy. OUSD A&S (AE/AAP). 2019. Available from: https://www.acq.osd. mil/asda/ae/ada/ipm/docs/DoD\_ EVMSIG\_14MAR2019.pdf

[30] Earned Value Management Implementation Guide (EVMIG). DoD. Earned Value Management Acquisition Analytics and Policy. OUSD A&S

(AE/AAP). 2019. Available from: https:// www.humphreys-assoc.com/evms/e vms-documents/dod/DOD%20EVMIG-01-18-2019.pdf

[31] Program Management Tool for Aerospace. Earned Value Management, EVMS Equations. AcqNotes. Your Government Contract Vehicle Experts Website. Available from: https://acqnotes.com/acqnote/tasks/e vms-equations

[32] Data Item Description. Integrated Program Management Report (IPMR). Number: DI-MGMT-81861A. OUSD (AT&L) PARCA. 2015. Available from: https://www.cms.gov/research-statistic s-data-and-systems/cms-informationtechnology/earnedvaluemanagement/ downloads/ipmr-did.pdf

[33] Integrated Program Management Report. ACQuipedia. 2017. Available from: https://www.dau.edu/acquipedia/ pages/ArticleContent.aspx?itemid=274

[34] Earned Value Management. Budget at Completion (BAC). AcqNotes. Your Government Contract Vehicle Experts Website. Available from: https://acqnotes.com/acqnote/tasks/ budget-at-completion

[35] Nieto-Rodriguez A, Vargas RV. How AI will Transform Project Management. Harvard Business Review. Project Management. 2023. Available from: https://www.dau.edu/acquipedia/pages/ ArticleContent.aspx?itemid=274

[36] Iranmanesh SH, Zarezadeh M. Application of artificial neural network to forecast actual cost of a project to improve earned value management system. International Journal of Social, Behavioral, Educational, Economic, Business and Industrial Engineering. 2008:658-661

*Perspective Chapter: Program Planning and Management for Defense Advanced Concept… DOI: http://dx.doi.org/10.5772/intechopen.112864*

[37] Garling R. Artificial Intelligence and Earned Value in Project Management [Master thesis]. Charles Town, WV: American Military University; 2020. Available from: https://richgarling.com/? p=649

[38] Wauters M, Vanhoucke M. A comparative study of artificial intelligence methods for project duration forecasting. Expert Systems with Applications. 2016;**46**(15):249-261. DOI: 10.1016/j.eswa.2015.10.008

[39] Lee SH, Kim K-Y, Shin Y. Effective feature selection method for deep learning-based automatic modulation classification scheme using higher-order statistics. MDPI Applied Science. 2020: 1-14. DOI: 10.3390/app10020588

[40] AI vs. Machine Learning vs. Deep Learning vs. Neural Networks: What's the Difference? IBM Blog. IBM Data and AI Team; July 2023. Available from: https://www.ibm.com/cloud/blog/ai-vsmachine-learning-vs-deep-learning-vsneural-networks

[41] Valohai. MLOps Basics. Valohai Blog. Available from: https://valohai.com/mlops/

[42] Kirenz J, Gröger C, Lutsch A. Data Platform Architectures & Machine Learning Operations (MLOps). Stuttgart: Hochschule Der Medien. pp. 1-19. Available from: https://www.kirenz.com/ slides/data-platform-mlops.pdf

[43] Kreuzberger D, Kühl N. Machine Learning Operations (MLOps): Overview, Definition, and Architecture. pp. 1-13. Available from: https://arxiv. org/ftp/arxiv/papers/2205/2205. 02302.pdf

[44] Liu Y, Ling Z, Huo B, Wang B, Chen T, Mouine E. Building a platform for machine learning operations from

open source frameworks. In: 3rd IFAC Workshop on Cyber-Physical & Human Systems CPHS 2020. Beijing, China; 2020. DOI: 10.1016/j.ifacol.2021.04.161

[45] Munir M. How artificial intelligence can help project managers. Global Journal of Management and Business Research: Administration and Management. 2019;**19**(4):29-35

Section 4
