Project schedule duration probability distributions difference for the ideal and project schedule with both scenarios 

Context in source publication

Context 1

... the following we provide the details of the proxel-based simulation of the sample project schedule that involves a floating task. This should serve as description of our approach through an example. Each task in the model has a name, a priority level (vital or non-vital), a duration probability distributions with respect to possible team association, and a set of pre-requisite tasks. The proxel format of the state of the project schedule encompasses the following parameters:  task vector { T i }, where T i is the task that team i is working on, or I for idle,  age intensity vector {  i }, for tracking the duration of tasks,  probability value. Thus the format of the proxel is as follows: The initial proxel, i.e. the proxel that marks the initial state of the system would be ((T1, T2), (0, 0), 1.0). It describes the situation in which team A is working on task T1, and team B on task T2 with a probability of 1.0. In the next time step the model can do each of the following developments: a) Task T1 is completed, b) Task T2 is completed, or c) None of the tasks are completed Resulting into the following three proxels: a) ((T3, T2), (0, D t), p 1 ) b) ((T1, T3), ( D t, 0), p 2 ) c) ((T1, T2), ( D t, D t), 1 - p 1 - p 2 ) In case (a), team A starts working on task T3, and also the corresponding age intensity is now reset to track the duration of T3. In case (b) team B takes over task T3, instead of sitting idle and waiting on team A to finish task T3. Case (c) shows the situation of both teams continuing what they have been doing before. Because of the on-the-fly decision scenarios, both (T3, T2) and (T1, T3) can transit to (T4, T4). If T1 is completed shortly after team B has started working on T3, then the model transits to (T4, T4) with the completion of T1. Else, it waits for team B to complete T3 before transiting to (T4, T4). For generating each new proxel, the durations of tasks in progress need to be investigated for the decision modeling. The state-transition diagram of the sample project schedule is shown in Figure 3. As depicted with the extra wide arrow , when team A is working on T1 and team B on T3, the transition associated with the completion of T1 depends on the time that team B has already spent on working on task T3. If it was “too long” then team A will stay idle and wait for its completion. One the other hand, if team B has just started working on task T3, then it is interrupted and both teams start working on task T4 which leads to completing the project. The algorithm that we have developed represents an extension of the original proxel-based method [12, 13]. In particular, the differences can be summarized as: The experiments were run on a standard workstation with an Intel Core2Duo Processor at 2.0 GHz and 1 GB RAM. The choice for D t was 0.1 and the simulation was run up to time t = 20. This implies that the number of simulation steps was 200. The computation time for this experiment was ca. 4 seconds. In the following we present the results, i.e. the statistics that were calculated during this simulation experiment. The input data is provided in Table 1. The goal of the experiments is to show the importance of modeling the effects of on-the-fly human decision behaviors on project schedules. For that purpose we first simulated the project schedule in an ideal scenario, i.e. excluding any intrusions during project running. Next, we simulated the project duration exposed to the hypothetical scenarios (both (a) and (b)) for on-the-fly project flow decisions. To study the effect of neglecting them, we compare both solutions and present the results with a chart. In Figure 4, we can see the probability distribution of project duration for all combination of on-the-fly decision scenarios. In order to represent closely the effect of their modeling and simulation, Figure 5 shows the difference of the two probability distributions, with and without on-the-fly decision scenarios. The results show that in our sample model, it goes up to ca. 0.28, which is far from negligible. The approach that we presented allows a higher degree of uncertainty in project schedules to be modeled and simulated. The uncertainty that we observe is in terms of duration of tasks, task allocation, as well as arbitrary on-the-fly decisions that influence the workflow. We all witness that these things happen almost every time and in every project. Thus, simulation models need to consider them in order to obtain accurate measures for the duration of project schedules. Very often, these factors are neglected, and by our example we showed what difference they can make. In our example model, the probability difference for the completion of the project reached ca. 0.27, and this is still just a toy model. In real project schedules it can be more extreme and thus it has to be taken into account. The question that arises is how to obtain the numbers that represent and model these behaviors. We believe that they can be modeled by historical data and tracking from previous projects of similar types. In addition, expert knowledge and common sense can help to a great extent. This paper presents a more realistic project schedule simulation and modeling approach that allows for a high level of uncertainty. The purpose of this simulation model is: (a) to model the uncertainty of human resources allocation to the different project tasks and (b) to take advantage of this uncertainty to simulate various on-the-fly human decisions and their impact on the project duration. To extend our work we plan to address the effect of these uncertainty factors on the productivity and budget, by adding value, effort and cost parameters. I n addition, we intend to extend our simulation model to handle the effects of requirements volatility in software ...