Design and management of software development projects under rework uncertainty: a study using system dynamics

ABSTRACT

Despite proper planning and scheduling, project execution is challenging, and one critical factor is uncertainty duringthe project implementation process. This study presents a system dynamics (SD) model as a decision-support system for model-based decision-making that considers the uncertainty of rework generation by predicting dynamic and complex project behaviour. The SD model was developedalong with a rework cycle that principally contributes to rework generation. The uncertainty ofrework generation and project performance werevisualized and integrated into decision-making components.Six different scenarios involving hiring and overtime usage were explored to ensure project performance whendesigning a feasible project plan.The novelty of this study lies inthe decision-making process for obtaining the best planning alternatives under uncertainty and project conditions. Actions should be implemented thatpredict and analyse improvised project planningprocesses and control model-based decision-making under uncertainty.

KEYWORDS:

• Project management
• uncertainty
• rework
• system dynamics (SD)
• decision-support
• simulation

1. Introduction

The goal of this study isto enhance our understanding of rework generation uncertainty in model-based decision-making. Rework is an uncertain and vicious factor in software development. It generates delays, cost overruns, and eventually hasa negative impact on performance and quality because it requires additional effort(Hossain, 2018).To maintain project performance in an uncertain environment, we developed a decision-support modelthat can help project managers choose a feasible project plan and present that model in this study. The contribution of this research work lies in selecting an ideal approach for decision-makers to execute a project under uncertaintyusing two managerial control functions. The decision-support system was developed using system dynamics (SD), and focuses on rework uncertainty rather than other uncertaintiesbecause the rework issue is a significant challenge in the software industry (Hossain, 2018). In this study, we considered two essential project manager functions – hiring and overtime work (Jia et al., 2007, July 29-August 2) – as part ofa decision-making process that allows intentional nonlinear productivity behaviour to promote project performance. During this study, we intended to maintain a fixed deadline. Therefore, we explored the use of hiring and overtime separately and collectively, to show how these factors sustain project performance. Six different scenarios were designed, and for each scenario, several performance choices were obtained to verify the model validation.Of course, there are various factors that affect rework generation, such as vague requirement definitions and project complexity. However, this study focused on the decision rule regarding hiring and overtime work. Therefore, this paper leaves other factors aside.

1.1 Crisis with software development project management

Despite its significant evolution, the software industry often suffers from a ‘software crisis’ of cost and scheduling overruns. Scheduling overruns are the most common problem. Almost every software development team has some level of experience with this issue. There are two principal factors in this situation: (1) the increasing complexity of software creates difficulties for project managers ininitial project evaluations when there is limited information on project scope, and (2) ineffective decision-making by project managers when faced with such issues. When problems are complex, it is difficult to find a solution (Abramek & Sołtysik-Piorunkiewicz, 2020). The main focus of this study is the second factor. The software production phase primarily involves development, testing, and rework (Abdel-Hamid, 1984; Browning, 2019; Jia et al., 2007, July 29-August 2). In software development, rework is theextra effort required to revise a process that was incorrectly implemented initially. Incorrect implementation usually results from errors, changes, and poor coordination. Rework is an unexpected event thatcauses uncertainty andcreates challenges in achieving project goals, because it is difficult to estimate accurately (Browning, 2019; Li et al., 2021). Therefore, reworkis a challenging topic in ongoing research (Taipalus et al., 2020).

1.2 Project dynamism and rework

The importance of studying rework is highlighted in modelling projects where the rework cycle is the model’s focus. The rework cyclethat generatesrework is a significant application area, especially in SD simulation modelling, which aids software process improvement by enhancing feedback responses (Madachy, 2007, p. 540).In thedynamic setting of software project development,projects must be aligned with the implementation context, and resources must be continuously deployed throughout the project lifecycle to manage uncertainty in rework generation (Wang et al., 2017). Therefore, the project implementation process involves control actions thatrespond to dynamic behaviour, andmanagement flexibility in the face of rework uncertainty that affects performance (Dikmen et al., 2020) and access time, creatingdeviations from established cost targets(Assaad et al., 2020). To meet the project’s original deadline, hiring and working overtime are common and widely used control actions to respond to dynamic behaviour and difficulties in software projects caused by uncertainty. Abdel-Hamid (1984), Ge et al. (2016), and Chiang and Lin (2020) explored the use of hiring and overtime in managing performance under uncertainty. In these studies, performance was analysed using a single combination of these two control actions. In contrast, we explored several scenarios to validate and utilise the model.

Simulation is an effective and powerful tool for analyzingdynamic behaviour and feedback responses. Two popular methods are used for dynamic simulation: SD and agent-based modelling (ABM; Alshammri & Qin, 2017, December 3-8). SD is an aggregated top-down approach that identifies dynamic effects under different conditions that affectsystem behaviour. ABM is a disaggregated bottom-up approach that defines the emergent behaviour of agents and systems (Alshammri & Qin, 2017, December 3-8).On the other hand,the agile software development process is a bottom-up approach that uses an iteration process and a short development cycle to identify different feedback conditions and reduce the risk of project failure(Cao et al., 2010). However, when considering rework in software development, a rework cycle built with SD can eradicate all rework compared to agile processes.

Thus,we chose SD modelling because our focus is on analysing the project’s dynamic behaviour with rework.SD uses feedback control to reflect the interconnections among elements in a system. This feedback system can capture the interconnection between agile practices in a closed cause-and-effect sequence, and provides an environment in which the process of agile practice is often fully represented (Cao et al., 2010).For these reasons, we developed an SD model with a rework cycle considering hiring and overtime inmodeling uncertainty in rework generation and used it as a decision-support system.

The rest of the paper is organised as follows: Section 2 considers uncertainty, its impact on project management, and reviews the relevant literature. This section implies a desirable scope of project uncertainty that emphasizesproject management. Section 3 presents the proposed research method and procedure for decision support in project management. Project implementation ofmodel-based decision-making is discussed in Section 4,and a detailed exploration is presented in Section 5. Finally, Section 6 concludes the paper and addresses limitations.

2. Literature review

2.1. The effect of uncertainty on project management

Several unexpected events occur inthe project development phasethat significantly affect performancebut cannot beanalyzed before the project’s initiation. These events represent uncertainty, which provides a context for risks that affect project outcomes (Browning, 2019; Qazi et al., 2021). A risk that originatesfrom uncertainty often negatively impacts and creates new opportunities in projects (Adam & Dempsey, 2020). Hence, uncertainty is understood to imply risks. The uncertainty involved makes it difficult to maintain the original goalsthroughout the project (Browning, 2019). Cleden (2012) defined project risk and uncertainty as unfathomable, confounding uncertainty regarding likelihood and impact. Apaolaza et al. (2020) described uncertainty as one of the main characteristics of the project context. Ahern et al. (2014) claimed that a project’s value is not widely known initially, butis identified and updated based on prevailing uncertainty, and involves uncertainty in project implementation due tolittle planning and interactive problem resolution.Several techniques have been developed to focus on uncertainty.Marchwicka (2020) developed a decision-support system for global software project monitoring and rescheduling, with the ability to control the overall uncertainty. Qazi et al. (2020) developed a decision-support method to determinethe loss and gain of projects in the presence of uncertainty. Oger et al. (2020) defined a decision-support approach for assessing the expected effects of potential disruptions due to uncertainty and anticipate new alternatives. Wang et al. (2017) proposed an SD model for project monitoring and controlthat considers strategic and tactical uncertainties in various project execution subsystems and evaluated the value realisation of ongoing projects. However, very few studies have considered rework uncertainty.

2.2. Uncertainty of rework generation

In project management, rework is the extra effort to repeat a process or activity incorrectly performed in the first place (Ma et al., 2019; Palaneeswaran et al., 2014). Rework adversely affects performance, becauseit requires additional time and resources (Al-Janabi et al., 2020). In dynamic modelling, the rework cycle is a way to identifyuncertain rework and is referred to as the SD project model’s canonical structure (Lyneis & Ford, 2007; Rahmandad & Hu, 2010). The rework cycle’srecursive behaviour creates rework in an uncertain way that often extends the project completion time and becomes the source of several challenges. The beginning of rework could be a normal process, namely immediate rework or delayed rework (Nobil et al., 2020). Figure 1 shows the basic structure of the rework cycle(Cooper, 1993). Here, part of the work being donemay contain errors at any time, resulting in undiscovered rework.Errors are not identified automatically, but are found upon work completion or subsequent tests. When errors are detected, they are classified as known rework and require additional effort. The rework quantity is uncertain, because reworking may result in more rework due to the rework cycle’s recursive behaviour (Narayanan et al., 2019; Rahmandad & Hu, 2010; Wen et al., 2021).Pargar et al. (2019) proposed an SD model that considers rework, and mainly focuses on the dynamics of the value creation process in the project alliance context. In contrast, we investigated detailed rework behaviour(Section 3.4.2) with dynamism under uncertainty to explain the effectiveness of the rework process for decision-making based on the basic rework cycle concept.

Figure 1. Basic rework cycle (adopted from Cooper, 1993).

2.3. Problem regarding dynamic and complex project behaviour

Complex relationshipsarethe most crucial characteristics of the project implementation process and key sources of dynamism within the project lifecycle (Butler et al., 2020; Wang et al., 2017). Complexity in project behaviour is increased by distorted information and dynamism, becauseit involves task difficulty, variability, and interdependence (Dikmen et al., 2020; Haq et al., 2019; Phillips-Wren & Adya, 2020) and causes rework (Ma et al., 2019). Complexity makes planning and management difficult, and necessitatesan examination of the relationship between the complexity and dynamism of project behaviour and outcomes (Butler et al., 2020). Project management is a complex process that includes the project scope and its requirements, scheduling, and proper use of the budget and workforce (Mahbubeh & Ameneh, 2019; Lyneis & Ford, 2007; Abdel-Hamid, 1984, p. 21). Therefore, problems occurring during project development due to resource scarcity and uncertain rework are apparent (Qazi et al., 2021). To regulate these problems, project managers primarily focus on overtime and hiring. However, these actions may lead to dynamic feedback that may affect project progress. Therefore, understanding dynamic and complex behaviours are vital for decision-making and goal attainment.

2.4. Implication of hiring and overtime

Proper analysis of resources and requirements is critical in guiding projects to a successful outcome (Haq et al., 2019). When resources are scarce, project managers take several control actions. Generally, four control actions – hiring, overtime, extending deadlines, and reducing requirements – are considered under certain circumstances (Jia et al., 2007, July 29-August 2). Worldwide, working overtime is a common situation. In Japan, workweeks that exceed 60 hours are not uncommon(Beckers et al., 2004). Overtime is defined as the number of weekly working hours that exceed the usual 40-hour workweek without perceived work overload (Allen et al., 2007; Shepard & Clifton, 2000). Several experiments have been conducted on the application of hiring and overtime to software development project management. Abdel-Hamid (1984) explored software project performance using interval-based overtime and dynamic hiring through SD modelling. Abdel-Hamid (1989) and Ge et al. (2016)proposed SD methods in the dynamic setting of adding project staff to software development lifecycles. Chiang and Lin (2020) developed a decision model for resource allocation in software development projects that considered hiring and skill efficiency, and proposed team building in terms of time and cost. Somarathna (2020) developed an agent-based approach for modelling resource allocation that considered new hiring and skill hiring, and analysed project performance for decision-making.The above literature focused on dynamic staffing behaviour, whereas in real-world project development, the focus is on static staffing behaviour to add new staff as needed.

Considering the limitations mentioned above and focusing on rework uncertainty, we have proposed an SD model with a rework cycle based on Wang et al. (2017), where we considered an execution scenario rather than subsystems. We used a static staffing policy and two different overtime options, and then explored six different scenarios for decision-making aimed at efficient project management.

3. Research method

3.1. Research design

The goal of this research was to develop a method to support decisions insoftware development project management concerninguncertain rework.The key questions addressed in this study are as follows:

1. How can wecompute the impact of rework uncertainty on project performance using simulation?

2. How can control actions, such as hiring and overtime, be explored to deal with uncertainty, reduce project duration, and obtain better project performance?

To address these issues, we developed an SD simulation model. This modelis designed tosupport prediction and evaluation inproject planning andprocess improvement, usingcontrolled decision-making to manage performance. In addition, this model will enhance our understanding ofmodel-based decision-making. We first developed anSD simulation model with a rework cycle as a decision-support system.Then we designed six different scenarios that included hiring and overtime, and performed a simulated project run for each scenario to obtain performance in terms of time and cost. We usedsoftware development project data fromLi (2008),which the authors used in anSD model for their research.Because our study is also focused on project development with SD modelling, we found this data relevant tovalidate our decision-making model. This dataset contains project information such asthe number of tasks in the project, the deadline, workforce, and nominal productivity. In experimenting with the model, we used this project information to obtain performance results.Based on the performance, a decision can be made for a feasible project plan. The overall research design is shown in the IDEF diagram in Figure 2.

Figure 2. IDEF diagram of the research design.

3.2. Overview of the Proposed Method

In this study, the proposed SD model is an extended version of the well-known and approved SD models created by Lyneis and Ford (2007) and Ford and Sterman (1998). The general function of project performance management is illustrated. This model is structured with a rework cycle for uncertain rework generation and additional functions of using static hiring processes and two types of overtime. Figure 3 shows an overview of the proposed methodology using the input, output, and essential functions to obtain the desired objective. The model wastested in various situations that includedhiring and overtime, and different scenarios were extracted to evaluate project performance. The SD simulator was developed based on a generalised software development project’s causal loop diagram (CLD). A detailed explanation of the CLD is given in Section 3.4.1.The simulator results showproject performance in a graph. Subsequently, project managers make decisions based on the graphs obtained from the simulator.

Figure 3. Proposed methodology.

A detailed explanationis given in the following sections.

3.3. Options for project managers

Project manager options refer to the alternatives available to accomplish a project in time. In this study, two options – hiring new staffand working overtime – were considered.

i. Hiring

Uncertain rework generation increases the number of unaccomplished tasks that affect project schedules. Therefore, to avoid deadline slippage, the first option that is considered is hiring. Becausehiring is time-consuming, 60 days was used as the delay period during model development. The required workforce would be hired after 60 days, based on the project’s requirements.

ii. Working overtime

Another option to meet the deadline is to work overtime. When workers are scarce, project managers are often torn by competing demands (Marovi´ et al., 2021). In this situation, working overtime canbe another way to manage performance. Therefore, we categorised overtimeinto interval-based overtime and continuous overtime.

3.4. Simulator

As mentioned earlier, we developed a simulator using SD. The primary elements of an SD model arethe CLD and stock-flow diagram. The CLD qualitatively shows the interconnection of the components of a system as a feedback loop. This diagram represents a simplified model structure. Stock-flow diagrams provide a detailed description of the model structure and the basis of the numerical definitions. A stock in a stock-flow diagram accumulates over time, and the flow is the rate of change in the stock.

3.4.1. Assumption of projects’ dynamic behaviour

When developing a software project, several interrelated aspects must be considered: human resources, control, and planning. Human resource management includes hiring; controland planning define scheduled maintenance, overtime,andvarying completion dates. Considering these aspects, a CLD was designed for the process of modelling project features (Figure 4) because this process enhances the ability to simulate realistic project dynamics. The CLD variables are connected by arrows that show the causal effects and interrelationships between the variables, and are excellent for designing hypotheses related to the causes of dynamics.

Figure 4. CLD for hiring and overtime management.

In the CLD, the (+)and (-) signs indicate the change direction relationship between a cause element and a result element. When both elements are affected likewise, the (+) sign is used; otherwise,the (-) sign is used. The feedback loops in a CLD are represented as either a reinforcing loop or a balancing loop. The reinforcing loop is denoted asR, and the balancing loop is indicated with B. In the diagram, feedback loop B1 represents the basic hiring model. More tasks require more time to accomplish, thereby pushing the expected completion date further into the future. An increase in the expected completion time extends the deadline. To meet the deadline, hiring occurs, which increases the number of workers in the workforce. Other feedback loops, B2 and R1, usethe overtime policy and current full-time workforceto meetthe expected completion date.

Figure 5 shows the causal relationship between rework and project factors. The impact of rework on completion time and unaccomplished tasks isshownthrough loops B3 and B4. Loop R2 defines the effect of schedule pressure on the progress caused by overtime. Loop R3 shows the causal relations among project completion time with the required workforce and overtime. Finally, loop R4 represents the causal relationship between the project tasks and progress throughproject control actions.

Figure 5. Causal relationships among project factors and rework.

3.4.2. Uncertainty ofrework

The dynamic behaviour of rework used in the system operation as uncertainty is linked to the rework cycle. The rework cycle describes reworking in the system design that occurs and is discovered unexpectedly. In this study, amodified rework cycle configuration (Figure 6) was employed that links adjustments inrework generation and discovery during system design to the basic rework cycle structure (Figure 1).

Figure 6. Modified rework cycle.

The rework cycle contains four stock variables: original work to do, undiscovered rework, rework to do, and work done. Each project to be modelled includes a series of tasks with a predefined goal,whichis called the original work to do. While being developed, the tasks are either fully completed or may contain errors. An error fraction in the range of 0–1 denotes more or less work being performed in the rework cycle. The error-free task development flow generates correctly developed tasks and transfersthem to the stock work done. Error-based tasks move to another stock, undiscovered rework, whichis caused by rework generation flow until it is discovered. After discovery through therework discovery flow, these tasks becomerework to do, which must be redeveloped and done through the rework completion correctly and rework error rateflows. The parameters original work to do, workforce, productivity, and error fraction influence the rates at which work is completed correctly or incorrectly. The auxiliary variables, productivity and error fraction, are affected by several other variables, such as schedule pressure, hiring, and exhaustion due to overtime. The fundamental behaviour of rework, adopted from Cooper (1993), is shownin Figure 7.

Figure 7. Typical behaviour of rework.

3.4.3. Hiring model

A request is made for help to compensate foralabor resource deficit byhiring new workers. As mentioned earlier, hiring is a time-consuming processand creates ahiring delay. In this study, the hiring delay was set at 60 days; however, this is often flexibleand depends on the management process. Therefore, the following reasoning is used to execute the hiring process..

• The labour resource deficit was determined based on the deadline (fixed), expected completion date, and current full-time equivalent workforce. Consistent with this determination, new workerswere hired.

Based on the project status, there are two hiring alternatives: no hiring or hiring. Hiring is ignored if the labour resource deficit is low or the project manager wants to apply other control actions, such as longer working hours. Otherwise, hiring occurs.

3.4.4. Nonlinear learning behaviour

Hiring increases the number of developers in a team, but at the same time, adversely affects productivity. According to Abdel-Hamid (1984, p. 159), the productivity of new workers is half that of expert workers. Hence, the hiring process reduces overall productivity. In this case, to obtain the same productivity for all members, the newly hired workforce needs to be trained, and the duration of training is called the learning curve. Figure 8 shows the typical learning curve for new workersbased on time-series data (Haylock, 2014, July 23). Software development projectsexhibit the same behaviour (Abdel-Hamid, 1984, p. 161).

Figure 8. The learning curve for the new workforce.

The learning curve for a new workforce is calculated as follows.

$learningrate=hiringrate\times time\times (ovarallprodcutivity-prodcutivityofnewworkforces)/\left(assimilationdelay\right)$

3.4.5. Overtime planning

When modelling overtime, several parameters need to be considered. In this study, the process of overtime planning was examined as follows.

• The shortage in man-days was calculated based on the deadline (fixed), expected completion time, and current full-time equivalent workforce. Based on the man-day requirement and the shortage that can be handled daily, the work rate was boosted, and the overtime schedule was increased.

Figure 9 gives an overview of overtime planning, wherethe actual fraction of man-days in a project (AFMDP) defines the nominal working time in a day.The deadline is fixed, set by the client, and the expected completion date is obtained based on the project scope and available resources. This figureindicates a causal relationship in the style of a cause diagram in SD (Sterman, 2000, p. 137). An arrow indicates the cause or information source as the origin and the result or calculation as an arrowhead. The polarity of the arrow indicates how the cause variable affects the result variable. Given that the cause is X and the result is Y, the ‘+’ sign means, ‘IfX increases, Y increases above what it would have been’ (Richardson, 1997). Likewise, the ‘-’ sign means, ‘If X increases, Y decreases below what it would have been’.

Figure 9. Overview of overtime planning.

i. Interval-based overtime

Interval-based overtime involvesworking overtime for a certain period. After that period, the workforce will work only according to nominal working hours and return to working overtime when workers are no longer ina fatigued state. The necessity of project completion was also considered. The nominal AFMDP is 1.0, and for interval-based overtime, its value was chosen as 1.35 on average. However, this value represents the average and is subject to change.

ii. Continuous overtime

Continuous overtime involvesthe workforce working continuous overtime as needed until project completion. Therefore, for this overtime plan, the AFMDP was chosen to be 1.2 on average.

3.4.6. Nonlinear behaviour of productivity

Productivity is a function of three factors: fatigue resulting from overtime, the ratio of new to experienced workers, and workforce communication congestion. As described in the hiring model, productivity is affected when new workersjoin a team. The exact circumstances occurdue to worker exhaustionwhen overtime is used. As a result, actual productivity differs from nominal productivity and affects project performance. Figure 10 shows the assumed relationship between overtime and productivity (Chang & Woo, 2017; Jia et al., 2007, July 29-August 2). As overtime increases, productivity decreases. We used the following equation to obtain the impact of overtime on productivity.

$productivity=nominalproductivity\times productivitylossduetofatigue\left(impactofovertime\right)$

Figure 10. Impact of overtime on productivity.

where

$productivitylossduetofatigue=overtime\times effectoffatigueonproductivitylookup$

3.5. Project performance

Project performance is analysed based on the following parameters: schedule, cost, quality, scope, and development effort (Lin et al., 2008; Lyneis & Ford, 2007). In this study, the following were evaluated as performance parameters: the schedule: expected completion time; development effort:error-free task development, rework generation rework to do;and cost. Once the analysis was completed, a set of actions were considered for the project. The benefit of this analysis is that a quantitative methodology drives the decision-making process.

3.6. Applying decisionsupport of project management

To use the model as a decision-support system, the following steps were employed.

Step 1. Collect project data and background

Project performance is obtained once the project data have been appropriately collected, as mentioned in Section 3.1. The primary project data include the number of tasks, completion time, workforce, and nominal productivity. The type of data depends on the project type.

Step 2. Decision item definitions

The decision items are defined by the project managers’ options. The decisions made concerningthese options were considered in this study (Table 1). Thisis a morphological matrix representing system concepts, where each row defines a decision item, and each column describes the choices of a concept fragment for each internal process.

Table 1. Decisions concerninghiring and overtime.

No.	Decision items for project managers	Option 1 (O1)	Option 2 (O2)	Option 3 (O3)
D1	Hiring	Yes	No
D2	Overtime	Interval-based	Continuous	no
D3	Changing deadline	Yes	No
D4	Changing scope	Yes	No

Step 3. Configure to SD model and run the simulation

After collecting the data and defining the scenarios based on the decision items, the scenarios were configured in the SD model. Each scenario’sperformance wasdeterminedby exploring different parameters, as defined in Section 3.5.

Step 4. Tradespace analysis to gaininsights

In this study, performance was visualised usingproject completion time and cost, which principally illustrated project planning. Visualisation is helpful in arranging the relationships among the performance parameters (Osuszek & Ledzianowski, 2020). The completion time was set along the x-axis, and the cost was placed along the y-axis. The principal objective of the visualisation is to obtain a clear idea of model-based decision-making to define a feasible project plan in terms of time and cost and the presence of rework uncertainty.

4. Project implementation

The primary purpose of the proposed model is to assist project managers in decision-making regarding project control and monitoring, and to determine the best planning alternatives. In addition, the obtained results provide the best opportunity to forecast each alternative’s effect on project execution concerningcompletion time and cost.

Step 1. Collect project data and background

During the simulation, hiring and overtime were explored to avoid schedule slippage and the negative influence on project performance induced by the uncertainty of rework generation. The simulation was conducted under the following initial conditions obtained from the literature,as mentioned in Section 3.1(Table 2).

Table 2. Input parameters (Li, 2008).

Parameters	Input values
Project size (fixed)	1200 tasks
Full-time equivalent workforces (initial)	15 persons
Deadline (fixed)	1800 days
Nominal productivity	task/man-day

Step 2 Decision item definitions

Six different scenarios were designed to determine the dynamic behaviour of rework generation. Table 3 lists the scenarios obtained based on systemconcepts (Table 1). During the simulation, performance was measured by applying hiring and overtime; hence, six combinations were created for these two factors. The scenarios were simulated by setting the spontaneous probability of uncertainty. The consequences of each scenario were observed after the simulation.

Table 3. Scenario list based on hiring and overtime optiondecisions.

Scenario list	Scenario formulation
Scenario#1[D1O1-D2O1]	Hiring with interval-based overtime
Scenario#2[D1O2-D202]	No hiring but continuous overtime
Scenario#3[D1O1-D2O3]	Hiring and no overtime
Scenario#4[D1O2-D2O1]	No hiring but interval-based overtime
Scenario#5[D1O1-D2O2]	Hiringwith continuous overtime
Scenario#6[D1O2-D2O3]	No hiring nor overtime

The deadline and project scope remained fixed; that is, D3O2 and D4O2 were considered.

Step 3. SD model configuration for visualisation

After generating the scenarios, the project data were configured to the SD model, and the performance variables were explored. Finally, the performance was assessed in terms of time and cost.

First, each scenario’s expected completion time was determinedwith the given resources and considering uncertain rework generation (Figure 11). For Scenario 6, the expected completion time exceeds the fixed deadline without hiring and overtime.

Figure 11. Expected project completion time for each scenario.

For other scenarios, the project is completed bythe deadline due to hiring and overtime. Although hiring and overtime assist in meeting the deadline, they lead to nonlinear productivity behaviour. Figure 12 shows the decrease in productivity due to hiring, which generates nonlinear behaviour, and the application of overtime results in specificconsequences. As for interval-based overtime, productivity is affected when overtime occurs; otherwise, it remains constant, leading to productivity saturation several times. However, whencontinuous application of overtime is required, productivity is significantly affected. This productivity behaviour is obtained using the following equation:

$\begin{array}{rl}& productivity=IFTHENELSE(AFMDP\le 1,grossproductivity,grossproductivity\ast \\ & productivitylossduetofatigue\left(impactofovertime\right)\end{array}$

.

Figure 12. Impact of hiring and overtime on productivity.

Here, the productivity changes based on the AFMDP. As mentioned previously, the nominal value of the AFMDP is 1. When working overtime, the AFMDP’s value increases and affects productivity when the employee becomes fatigued.

The gross productivity is obtained using the following equation:

$grossproductivity=nominalproductivity\ast impactofhiringonproductivity$

This nonlinear productivity behaviour affects the error-free task development rate and rework generation. As shown in the rework cycle (Figure 6), a set of developed tasks is defined as error-free, and another group produces rework, both of which are affected by productivity. The following equations were used to obtain the developed tasks as error-free and with rework:

$error-freetasksdevelopment=productivity\ast workforces\ast \left(1-errorfraction\right))$

$reworkgeneration=productivity\ast effectiveworkforces\ast errorfraction$

.

Here, the error fraction is measured as

$\begin{array}{rl}& errorfraction=nominalerrorfraction\ast impactofovertime\\ & \ast impactofmixworkforces\ast impactofschedulepressure\\ & \ast impactoferrordensity\end{array}$

In Figure 13, rework generation defines the rate of generating rework and occurs uncertainly because of other impacted parameters affecting the performance. The value is initially high for this variable and decreases gradually when tasks are discovered as rework and developed as error-free.

Figure 13. Error-free task development (solid line) with rework generation (dashed line).

After rework generation, taskswere initially defined as undiscovered rework. By discovering the rework in time, tasksare flawed and represent rework to do. The discovery time may vary depending on the developmental environment. Rework to do increases the number of unaccomplished tasks uncertainly because rework cannot be estimated fully, and its recursive behaviour generates more rework. However, if the rework amount can be estimated, then the expected completion time can be predicted. Our analysis reflects this intent. Figure 14 shows the impact of rework on project performance, where the purple colour represents the project state without rework, and the green colour represents the project state with rework. The solid line represents the number of tasks that need to be accomplished, and the dashed line shows the process of accomplishing these tasks for project completion. It is seen that uncertain rework generation increases unaccomplished tasks and affects performance by increasing the completion time. Rework is obtained in a nonlinear manner that produces similar behaviour (Figure 7). Figure 14 shows the impact of rework inScenario 1. For all other scenarios, rework affects the performance in a similar manner.

Figure 14. Effect of rework on the accomplishment of tasks (for Scenario #1).

Step 4. Tradespace analysis

Considering the nonlinear productivity caused by hiring and overtime, uncertain rework, and error-free task development, when all the tasks wereaccomplished, project performance wasobtained in terms of completion time and cost (Figure 15), with error bars of standard deviation for each choice. Thus, this Tradespace represents different possible performance choices for each scenario.

Figure 15. Several choices of project completion time with man-days for each scenario (for decision-making).

As mentioned earlier, rework generation is uncertain, and the amount of rework varies and is not entirely predictable. Hence, several choices were made for each scenario to measure performance and definethe rework generation dynamism. The variations in the choices represent the sensitivity analysis for each scenario. Becauseseveral assumptions weremade in the simulation model, sensitivity analysis helps develop intuition about the model structure, identify variations in assumed information, and study the model’s behaviour to interpret its output depending on input parameters. The choices illustratedinthe Tradespace represent the effects of productivityvariation, error fraction, use of overtime on project completion time, and cost. The corresponding criticality of uncertainty was obtained based on performance variations. Again, the use of the rework cycle in this studysignificantly impactedthe exploration of the rework in detail. The recursive behaviour of the rework cycle repetitively generates and discovers rework, which helps identify the depth of uncertain rework and its impact on project performance. This analysis can be helpful indecision-making by verifying several alternatives. The average results for each scenario are shownin Table 4.

Table 4. Summary results for each scenario by identifying feasible performance.

	Average overtime impact on AFMDP [nominalAFMDP: 1]	Workforce (persons)	Overall productivity (hiring and overtime impact) (task/man-day)	Average project completion time (days)	Std. Dev. Of completion time(±)	Average cost (Man-days)	Std. Dev. Of cost (±)
Scenario #1	1.28	15 (initial) + 1 (hiring)	.046	1730	21.53	31,894.6	799
Scenario #2	1.2	15	.046	1710	41.31	34,014.2	301.45
Scenario #3	1	15 (initial) + 2 (hiring)	.047	1743	27.13	32,589	1291.41
Scenario #4	1.35	15	.046	1745	20.35	33,212.8	595.89
Scenario #5	1.12	15 (initial) + 1 (hiring)	.046	1729	23.94	33,644.6	342.69
Scenario #6	1	15	.047	1978 (exceed deadline)	8.45	29,890.4	285.08

The analysis shows that Scenario 6 exceeds the deadline without hiring and overtime, but requires fewer man-days than other scenarios. Scenario 2, with no hiring and continuous overtime, requires less time but is expensive.Sometimesinterval-based overtime costs less than the continuous overtime scenario, because overtime occurs on an interval basis. For scenarios 1 and 3,the project completion time and cost are bettercompared with the other scenarios. These analyses provide a way to use hiring and overtime and theirimpact on performance, which improves model-based decision-making.

5. Discussion

In keeping with the worksof Browning (2019), Qazi et al. (2020), and Li et al. (2021) concerning the management of uncertainty and the use of simulation models as decisionsupport in project management, this study contributes to the improvement of decision-making approaches for managing software development projects andimproving performance under uncertainty. An essential aspect of the proposed method lies in its usefulness for decision-makers at various managerial levels, because it providesdifferent decisions considering hiring and overtime. The dynamics in which an idea evolves are affected by how project managers deal with the decision-making approach they use. Thus, anidea is selected as a feasible option and is used for project development. These findings contribute a new way of understanding the problems of rework uncertainty in project implementation, broaden the focus of the decision-making process, and hence,assist project managers in dealing with rework issues.

5.1. Designing a feasible plan involving rework uncertainty

The project plan indicates the success or failure of a project. A project that is overestimated or underestimated may cost more in the end. Thus, proper planning before starting a project is essential. To better predict project performance under uncertainty through modelling, and considering thedynamic structure of tasks, we developed ourmodel as a decision-support system. We analysed different scenarios to set up decision-making policies forrework uncertainty andcreate a realistic plan for improving performance. The principal contribution of this study involves determining how uncertain rework affects performance, and how hiring and overtime can be applied in this situation to define a feasible project plan. TheTradespace analysis of the results reflects our contribution. Decision-makers may be motivatedby the impact of uncertain rework on project performance and are familiar with the action of uncertain rework generation. For example, in Scenario 6, rework uncertainty means that the project cannot achieve the expected target without applying control actions. Therefore, scenario analyses based on hiring and overtime in an uncertain environment provide a solution toimprove project performance. In project execution, avoiding the extra effort needed to deal with the changes generated by uncertainties is essential. The accuracy of estimating uncertain rework generation must be emphasised for decision-makers to manage project performance, and the availability of reliable options contributes to the reduction of uncertainty.

5.2. Predicting model-based decision-making in an uncertain environment

The novelty of this study is its contribution to robust and resilient decision-making changes to obtain the best planning alternatives under rework uncertainty usingtwo control actions.Using anunderstanding of model-based decision-making in project management, project managers can make decisionsbased on the simulator’s results. Our investigation of detailed dynamic rework behaviour, using the rework cycle and its impact on project performance, provides a clear decision-making approach. We explained the simulation results in detail using time series so that project managerscanexplore their options and the outcomes of those options. The proposed approach allows decisions to be traced and is expected to improve the quality of decisions in the presence of uncertainty.

Moreover, theability toestimate and plan projects helps reduce uncertainty. With SD and feedback loops, decision-makers can improve decision-making accuracy regarding uncertain rework generation and enhanceproject performance estimation. Thus, this framework could effectively manage projects in real-time and promote behavioural awareness, prediction, and assessment of process change and project planning through various processes.

The pressure of project execution can motivate decision-makers to focus on the project’s goal. Because the source of uncertainties is challenging to pinpoint, using sensitivity analysis to model the impact of uncertainty on project implementations may be valuable for classifying and handling circumstances.

6. Conclusion

In the project management context, rework is uncertain and characteristically affects performance. Therefore, dynamic simulation is used as a flexible method to model complexity and uncertainty. In this study, an SD model was developed as a decision-support system to analyse project performance behaviour with uncertain rework attained from the rework cycle. The proposed model captures the fundamental dynamism of project execution and explores the effect of uncertain rework.

We performed an analysis of project performance in terms of cost and time using various scenarios and options within those scenarios. This analysis isan approach for decision-making in software development projects. Two main control actions, hiring and overtime, can be explored among projects, which can help design a feasible project plan with uncertainties. The developed method integrates the componentsof software development projects, such as productivity, planning, and controlling. It identifies feedback mechanisms and usesthem in project management to establishrelationships. Exploring various scenarios helps us understand decision-making regarding feasible plans by usingcontrol actions in anuncertain environment.

This study focused on a single project’s performance behaviour when faced with uncertainty and nonlinearity, but the involvement of multiple projects was not considered. Another limitation of this study is that while considering the rework cycle, the staffing distributionwasnot considered separately for task development and the rework cycle.In addition, during our model analysis, the project scope remained fixed, so the consequences of changes in scope during project development were not defined. Further studies should focus on these limitations.

Acknowledgment

This research work was supported by collaborative research work with Fujitsu Limited, Japan, of the fiscal year 2020. Our cordial thanks to Editage (www.editage.com) for English language editing.

Disclosure statement

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