Project Topics
Get Complete Project Material File(s) Now! »
Industry 4.0: Sopra Steria conception
In practice, digitization challenges business or organizational models in many cases. Established organizations frequently fail to embrace opportunities offered by IT; they also struggle to adapt their business models (Westerman et al., 2014) or routines. Many missions of Sopra Steria consultants concern digitization, and one declination in industrial sector, that is Industry 4.0. TPM aim at developing a detailed planning or scheduling, managing project cost, locking in contracts, etc. Nevertheless, TPM can lead to situations where the plan has succeeded, but the customer is not satisfied. By contrast, recent APM coming from IT sector seems sometimes more relevant. The key issue is then to develop with agility Industry 4.0 projects.
For Sopra Steria consultants, project related to Industry 4.0 are based on four pillars: data-driven activities, openness, focus on operational performances, and agility as a key performance driver. Achieving the goals of these pillars supposes to implement APM.
Data-driven activities – TPM tends to bureaucratize project management. For example, each project management domain is always highly documented. Moreover, TPM is based on a hierarchical organization control: the higher the maturity is, the more the project management is excluded from the projects’ life. In contrast, with the Industry 4.0 paradigm, data-driven collective and reactive decisions are replacing hierarchical decisions (McAfee et al., 2012).
Openness – Smart factories are supposed to facilitate the reindustrialization by bringing design, fabrication and distribution closer to the customers. On the contrary, TPM is usually based on introvert tools which only focus on internal practices (see PMMMs presented in chapter 2). The only opening towards organizations’ external environment is reduced since it concerns only benchmarks of best practices. Industry 4.0 is by definition an open concept. It integrates several stakeholders (customers, suppliers, etc.), it is based on cross-functional teams, and it recognizes that everything changes because of continuous flows of opportunities, threats, innovations, etc.
Operational performances – Smart factories are supposed to be extremely reactive and flexible. On the contrary, under TPM, key performance indicators are reliability and efficiency. TPM’s main idea is to make project managers’ practices safer and more cost-efficient by detailing what they have to do. By acting efficiently and safely, project managers reduce the unexpected loops slowing down the planned progress of the project. However, the literature shows that APM improves delivery times and customer satisfaction (Budzier & Flyvbjerg, 2013). In the new context of Industry 4.0, we found new variables to measure projects’ performance, e.g. customer involvement, brand penetration, data acquisition, goodwill, etc. Consequently, a new PMMM should not only evaluate the project manager’s practices, but also other actors’ practices interacting during an agile project. Agility – Nowadays, agility is a key word, and even a buzz word… It can concern the capability to adapt quickly and with astuteness to any new situation. Key leverages of agility are cooperation, IT implementation, feedback, iterations, actors’ involvement, etc. For example, under APM, designers are expected to prototype a solution as quickly as possible in order to iterate with the clients, customers, end user, etc. This modality appears in start-up companies implementing a continuous “build-measure-learn” loop (Blank & Dorf, 2012). This way of conceiving the progress of the project seems to be incompatible with TPM or manufacturing practices based on planned schedules and sequences. The literature on agile processes presents few assessments only to check firms’ digital maturity (Schumacher et al., 2016), which supposes that every use of IT is intrinsically agile.
Few articles highlight the complications of existing PMMMs and TPM compared to Industry 4.0 paradigm. Nevertheless, we have no clear distinction between TPM and APM, and no clear idea of the location of the border between these two project management archetypes. We do not have any guideline or rule explaining when moving from TPM to APM (T. J. Cooke-Davies & Arzymanow, 2003; Jugdev & Thomas, 2002).
Background on project management methodologies
Agile Project Management (APM) is supposed to replace the Traditional Project Management (TPM). However, literature shows that there is a spectrum of project management approaches between these two (Doug, 2004). In this section, we do a brief literature summary and we present several types of project management methodologies. For example, Wysocki (2006) proposes a classification of project management types based on two criteria: (1) the nature of the goal of the project (clear or well-defined vs. not clear or ill-defined) and (2) the nature of the process to achieve this goal (clear or planned vs. not clear or ad hoc). Inspired by this author, we can highlight four potential types of project management (Table 3.1, adapted from (Wysocki, 2006)). A concrete project management practice or a project methodology belong to at least one of Wysocki’s types.
Agile Project Management as a challenger of Traditional Project Management
Traditional Project Management (TPM – also called classic, heavy, linear or bureaucratic project management, etc., depending on the authors) is based on a sequential conception of the project’s dynamics. This temporary organization is then driven by fully defined requirements, deliverables, scheduling (Boehm and Turner, 2003), tools, mandatory roles and processes designed by experts belonging to the “technostructure” (Mintzberg, 1980). Project managers are expected to implement the processes as strictly as possible and auditors check whether their ways of managing projects comply with standards. By contrast, Agile Project Management (APM) (Conforto, Amaral, da Silva, Di Felippo, & Kamikawachi, 2016; Dalcher, 2011) derives from and iterative conception of the project (L. Lee, Reinicke, Sarkar, & Anderson, 2015; Rose, 2010), corresponding to methodologies types 2 and 3 in Wysocki’s typology. Project’s dynamics depend on teams or communities exhibiting daily reactivity, quick communication, creativity and flexibility. Project actors work autonomously by acting iteratively and by using a shared pool of resources or specific IT (Henriksen & Pedersen, 2017). Under APM, project managers play a key role as enablers facilitating the spontaneous team work (Elonen & Artto, 2003b).
APM and TPM seems to be two opposite ways of conceiving and managing projects. Nevertheless, it is possible, for organizations that wish to change their routines, to shift from one methodology (TPM) to another (APM). According to Conforto et al. (Conforto et al., 2016), agility is “the ability to change project plan as a response to customers or stakeholders needs, market or technology demands, in order to achieve better project and product performance”. We define then ‘agilification’ as the process by which organizations make this shift effective. Agilification qualifies thus the ability of an organization to gain agility, thus to behave quickly, with celerity, promptness, astuteness, reactivity, flexibility and dexterity.
Project management specialists may conceive agilification as a disruption. On the contrary, we assume that agilification can be considered as an incremental process. One of the theoretical reasons explaining our conception comes from the work of theorists of “organizational ambidexterity” (Tushman & Nadler, 1978), who explain that organizations combine “exploitation of old certainties” and “exploration of new possibilities” (March, 1991). In the case of project management, ambidexterity has a specific meaning: this type of management balances the implementation of planned processes (exploitation, as TPM highlights it) and the guidance of improvisation (exploration, as APM mentions it). Moreover, empirical works show the complementary between APM and TPM. For instance, whereas APM has a significant impact on projects’ efficiency, stakeholders’ satisfaction, and internal perceptions (Pedro Serrador & Pinto, 2015), it does not concern all areas of the project management (Whyte, Stasis, & Lindkvist, 2016). In large companies designing complex and potentially hazardous products, TPM remains thus dominant in risk or contracts management. Therefore, one issue arises: What TPM parts can be adapted to make agilification effective? We defend that a TPM’s key instrument, which is the Project Management Maturity Model (PMMM) presented in chapter 2, can be sufficiently flexible to be adapted to APM. Nevertheless, existing PMMMs involve substantial improvements and changes that we will present in this chapter.
Identification of Traditional Project Management (TPM) principles
In this section, we give more details about TPM principles (type 1 in Wysocki’s typology). Project management experts aim at rationalizing working activities. That explains why, since the beginning of the 2000s, they have been developing more than thirty instances of PMMMs, as described in chapter 2. Despite their differences in detail, these models share common principles that we point out hereafter.
Principle 1 (P1.T, ‘T’ for ‘Traditional): The achievement of Key Performance Indicators (KPIs) describe the success of projects. These KPIs are supposed to drive projects’ reliability and efficiency.
P2.T: Projects’ successes (vs. fails) are explained by the fact that projects’ managers implement (or not) certain practices (Cook-Davies, 2002).
P3.T: These practices are tasks producing well-defined outputs and working rules. For example, a Work Breakdown Structure (WBS) is a well-defined output and create the WBS once the Product Breakdown Structure (PBS) is defined is a working rule.
P4.T: Project experts can defined a process as a collection of well-defined events, mandatory tasks (or practices, routines, etc.) and working rules.
P5.T: Several process audit missions enable to identify the best practices improving organizations’ capabilities in project management, i.e. their recognized ability to implement routines differentiating them from nearby organizations, e.g. competitors, rivals, followers, etc.
P6.T: There is a scale of perfection dividing the maturity levels from lowest to highest. Process maturity depends on a Confucian vision of learning: without any predefined process, the project managers improvise harmfully, and then they gain maturity by conforming to a detailed pattern created by experts, creating improved ways of performing processes.
P7.T: project management concerns different separated domains (or knowledge areas). Project managers’ work has then a wide scope; they must be aware of different aspects, implement various practices, e.g. technical specifications, team animation, cost reporting, etc., and produce several types of deliverables, e.g. bill of requirements, scheduling charts, scorecards, contracts, meeting reports, etc.
IB2M we have presented in chapter 2 concerns many sectors and types of organizations; does it remain relevant when managers require more agile projects? To answer this question, we need to clarify APM basements.
Steps towards an Agile Project Management Maturity Model
The goal of this chapter is to apply the proposed model in projects of the specific industrial environment. We have found that during on their missions, were consultants worked on making agile the schedule management, they have detected several challenges, e.g. the requirements were continuing to change due to the concurrent design; and the obsolescence of the schedule was accelerating. It was decided to “agilify” the schedule management. Several derived challenges occurred then, e.g. How to reorganize teamwork? How to train personnel in APM, especially in terms of sprints implementation (see P3.A) and resources sharing (see P2.A)? How to align sprints to the PBS, defined before the realization of the project, and then to prioritize the requirements in monthly backlogs (see P3.A)? How to convince and involve top managers in this first APM experience to change theirs organizational routines, i.e. TPM?
Under TPM, project management tasks belong to separated areas (see P7.T). On the contrary, we found that this disaggregation is harmful: tasks, processes, and then areas are interdependent and clustered. We proposed then to break down these silos; auditing one project area (for instance, schedule management) requires to audit other connected areas, e.g. scope management, integration management, quality management, etc. As we proposed in the domains definitions on chapter 2, section 2.3.2.
While TPM differs to APM, we assume that there is a process, we called agilification, to move from one to the other. The first issue is then to analyze if Project Management Maturity Model (PMMM) presented in chapter 2 can describe the universe of APM. Therefore, in this section, we will propose a PMMM integrating some characteristics of TPM and APM defined above. The proposed PMMM will be elaborated in three phases: set a specific conceptual model of the project management domain, which is a first step to have a behavior ontology of this domain, and then build the maturity grid, to conclude with the presentation of the roadmap for agilification.
Build a Project Management Conceptual Model
Our first assumption is that every PMMM should be based on an ontological basis, i.e. an explicit conception of the project’s domain made of specific entities (projects, actors, process, practices, deliverables, resources, etc.), properties (conformity, agility, reactivity, maturity, etc.) and relations (is a, is part of, drives, etc.). We suggest that these ontological fundaments can be based on a generic entity called ‘behavior’; project management ontology is then no more than an instance of behavior ontology. The behavior is an entity with the following characteristics: (1) It is labelled with an action verb describing what is done. (2) It is related to an individual or collective actor with a well-defined role in an organizational structure. (3) It is triggered when a given event occurs (stimulus). (4) It produces an observable output (response). (5) It occurs in a given context made of alters and resources. (6) It drives by internal variables (goal-oriented). (7) It follows some given modalities, maturity included.
We develop Figure 3.1 as a concept map based on our proposed Invariant-Based Management Model (IB2M). The grey T defines TPM’s instances of interest. The first instance we can derive from the behavior ontology is the perfection scale. Made of maturity levels (see P6.T), it refers to modalities of the behavior to check. A level of the perfection scale qualifies how project managers should behave. Do they improvise? Do they conform to an existing pattern? Do they improve the ways of performing processes? We have also instances of the behavior when we mention project domains (see P7.T). Any of them defines the content of the behaviors projects managers realize: operations vs. transactions, e.g. PBS definition vs. procurement. The domains also mention the results of their behaviors, e.g. deliverables, contracts, interpersonal relationships, etc. The behavior has a third instance referring to the types of roles individuals play. They exhibit specific behaviors by managing organizational structures, managing projects, auditing processes, etc. The behavior concepts may be structured according to the levels of decision in projects. The strategic level concerns the development of the organizational structure’s capability; the tactical level refers to the improvement of process maturity; the operational level corresponds to the way projects are led, and the practical level concerns the way tasks are performed in projects.
Finally, the right side in figure 3.1 shows who is concerned by the ability to implement best practices defined by experts (Project Manager, Process Auditor, Team). In addition, this figure is useful to understand the evaluation process as it displays how maturity evaluation is driven by process conformity and Project KPIs.
Theoretical Review of Bayesian Networks
Bayesian Networks (BN) are part of probabilistic models representing a set of variables and their dependencies by a graph, i.e. a pair G = (V, E), where V is a finite set of distinct nodes and E ⊆ V×V is a set of arcs. An ordered pair (u, v) ∈ E denotes a directed arc from node u to node v, and u is said to be a parent of v and v a child of u (Pearl, 1988).
BN are usually direct acyclic graphs (DAG) representing probabilistic causal relationships in which nodes represent variables and arcs express the dependencies between variables. More precisely, nodes are the states of random variables and arcs pointing from a parent node to a child node is the causal condition dependency between two nodes. The causal relationship is represented by the probability of the node’s state provided different probabilities of the parent node’s state. BN use conditional probabilities to describe events. Any belief about uncertainty of an event or hypothesis H is assumed provisional. This is called prior probability or ‘P(H)’. This prior probability is updated by the new experience ‘e’ providing a revised belief about the uncertainty of ‘H’. The new probability is called posterior probability given the evidence or ‘P(H|e)’. Bayes’ theorem (Eq.4.1) describes the relationship of posterior probability and the prior probability. ‘P(e|H)’ is the probability of the evidence been true given that the hypothesis is true, and ‘P(e)’ represents how probable is the new evidence under all possible hypotheses. 𝑃(𝐻|𝑒)=𝑃(𝑒|𝐻)∗𝑃(𝐻)𝑃(𝑒) (Eq.4.1).
Table of contents :
1. General Introduction
1.1. Research context
1.2. Research Questions
1.3. Research goals
1.4. Working Hypothesis
1.5. Research contributions
1.5.1. A generic model to evaluate project management maturity
1.5.2. Applying the proposed PMMM to agile project management methodologies.
1.5.3. Evaluate and select the appropriated AI technique that could explain causal relationships within Project Management.
1.5.4. Propose a methodology to explain how project management maturity can explain project performance for specific projects.
1.6. Structure of the PhD Thesis
2 An Invariant-Based Project Management Maturity Model
2.1 Introduction
2.2 Literature Review on Project Management Maturity Models
2.2.1 Basic concepts and definitions in PMMMs
2.2.2 Traditional PMMMs
2.2.3 Limits of PMMMs
2.3 Building an Invariant-based Maturity Model (IB2M)
2.3.1 Step 1: Identify the most relevant results in PMMMs literature to extract invariants
2.3.2 Step 2: Integrating the best practices of PMMs in our proposed IB2M
2.4 Industrial Assessment
2.4.1 Step 3: Check IB2M’s qualitative value by interviews
2.3.2 Step 4: Check IB2M’s quantitative value by data related to past projects
2.5 Discussion
2.6 Conclusion
3 Applying Invariant-Based Management Model to traditional and agile project management
3.1 Industry 4.0: Sopra Steria conception
3.2 Background on project management methodologies
3.3 Agile Project Management as a challenger of Traditional Project Management
3.3.1 Identification of Traditional Project Management (TPM) principles
3.3.2 Identification of Agile Project Management (APM) principles, the case of Scrum
3.3.3 Terms of comparison
3.4 Steps towards an Agile Project Management Maturity Model
3.4.1 Step 1. Build a Project Management Conceptual Model
3.4.2 Step 2. Build a Maturity Grid
3.4.3 Step 3. Define the Roadmap for Agilification
3.5 New Tools for Enabling Projects’ Agilification
3.5.1 Step 1. Set a Project Management Conceptual Model
3.5.2 Step 2. Build a Maturity Grid
3.5.3 Step 3. Define the Roadmap for Agilification
3.6 Discussion
3.6.1 Theoretical learnings
3.6.2 Practical learnings
3.7 Conclusion
4 Selection and use of the appropriate technique to solve the research problem.
4.1 Introduction
4.2 Review of Artificial Intelligence techniques used in PM literature
4.2.1. ANN Foundations
4.2.2. Reinforcement learning (RL): a brief review
4.2.3 Brief Review on Bayesian networks (BN)
4.3 Selection of the adequate technique
4.3.1. Data assessment framework
4.3.2. Data assessment related to our inquiry
4.4. Theoretical Review of Bayesian Networks
4.4.1 Interest of Synthetic Nodes
4.5. Building causal models based on BN
4.5.1. The hyperparameter setting problem
4.5.2. Eligibility Criteria selection
4.5.3. The influence of the hyperparameters on the eligibility criteria
4.6 Using Bayesian Networks for Project Management Evaluation
4.6.1. First limitation: absence of synthetic nodes and conceptual structure
4.6.2. Second limitation: incorrect number of states.
4.6.3. Third limitation: semantics undefined strictly
4.6.4. Fourth limitation: having too many target nodes
4.6.5. Fifth limitation: causal paths multiplicity and ML impossibility
4.5.6. Synthesis
4.7 Discussion: defining BN Building rules
4.8 Conclusion
5 Projects’ cost overruns prediction methodology based on Bayesian Networks
5.1 Introduction
5.2 A Bayesian Approach
5.2.1. Step 1 – Define a semantic model for Project Management Maturity Evaluation
5.2.2. Step 2 – Define how the input nodes will measure maturity.
5.2.3. Step 3 – Define and classify the synthetic nodes.
5.2.4. Step 4 – Define aggregation rules for synthetic nodes
5.2.5. Step 5 – Select, clean, and structure the database.
5.2.6. Step 6 – Define the target node
5.2.7. Step 7 – Train and test the causal model.
5.3 Case Study: Evaluation of Drift Factors in Oil and Gas Offshore Projects
5.3.1. Step 1: Define a common model for Project Management Maturity Evaluation.
5.3.2. Step 2. Define how the input nodes will measure maturity.
5.3.3. Step 3. Define and classify the synthetic nodes.
5.3.4 Step 4: Define aggregation rules for synthetic nodes
5.3.5 Step 5: Select, clean, and structure the database.
5.3.6 Step 6: Define the target node.
5.3.7 Step 7: Train and test the causal model.
5.4 Improvement Scenarios
5.5 Discussion
5.6. Conclusion
6 General Conclusion & Perspectives
6.1. Thesis Abstract
6.2. Our Contributions in detail
6.3. Research perspectives
6.2.1. Project organization as a system placed in its environment.
6.2.2 Evaluating project management maturity from traces
7 Bibliography
