Introduction
Planning Software users, and sometimes professional schedulers, have expressed a lot of concern about the results they get, the tools, and methods they use to schedule their project. On one side no-one would dare going back (or would not they?) to the ‘pen and paper’ method of the 50's. On the other side, many give up for various reasons and return to a basic ‘the way forward’ (Uytterwaal, 2000) scheduling: let's show to management that we find every day a way to the end of the project.
Indeed a schedule is a rather complex system made of subassemblies (tasks), components (activities), with various interfaces between them (relationships, links and …stakeholders) as “Exhibit 1: Schedule as a complex system” shows. We are, thus, entitled to apply the basics of System Engineering to both the product and the process of our scheduling effort. Let us begin with what we most often forget: the functions of our time schedule (Functional Analysis), then to the causes of the schedule defaulting (Failure Mode Effect and Criticality Analysis).
Exhibit 1: Schedule as a complex system
The way to a good schedule
Some wrong reasons to stay with a poor schedule
Various authors (Courtot, 1996) analyzed why so many stakeholders of the scheduling process are disappointed. Exhibit 2 summarizes common views. Based on my experience and a survey promoted by Project Management Institute (PMI®) Chapters in France early this year, it looks like companies, especially the ones that ask Project Managers to build and maintain the project schedule by themselves, do not care validating the services the schedule is supposed to perform: informing about milestones, computing progress of work, simulating likely courses of events, helping manage resources, consolidating various projects to get a company-wide view, baselining efforts or authorizing works do not request the same levels of dedication or sophistication. First of all clarify what you expect from the schedule, while taking into account the project cultural maturity of your interfaces, buying all or parts of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) § 6.5.3 Schedule Development Outputs. Doing so, you are less likely to meet:
- ❖ Lip service from top management to scheduling effort
- ❖ Too much time and effort to build the baseline and to keep the information up-to-date
- ❖ Internal or external resistance to candidly share information, especially in a contractual context
We propose the following requirements for a ‘decent’ schedule:
- ❖ Describe duration, level of effort and sequencing of relevant activities so to provide operational guidance to actors
- ❖ Measure progress of work packages and Control Account Plans; facilitate related reporting
- ❖ Ease risk analysis and accounting for uncertainties
Exhibit 2: dissatisfactions with scheduling
Schedule: system and model
Although communication features look more important than technical complexity, schedule consistency and robustness are key to build credibility with stakeholders and users. As a system, our schedule must be:
- ❖ Reliable. In its everyday sense, the word usually means “dependable” or “trustworthy”. It means also – e.g. in testing- the “consistency” or “repeatability” of measurements. The later is a more scientific definition and maps the lay understanding if we assign 1 to a successful ‘start-up’ and 0 to any unsuccessful attempt. Engineers use to link product reliability to MTBF/MTTF, with:
- MTBF = MTTF + MTTR
- MTTF is Mean Time To Failure; MTTR is Mean Time To Repair; Mean Time Between Failures
- ❖ Maintainable. It should be possible to repair your car engine (if not repairable, MTTR = ∞). For your schedule, MTTR is related to the time you need to update, upload information, add activities, change links and possibly re-baseline.
Renault, the French automotive manufacturer, applied these concepts (Benssoussan, 1991) to their scheduling efforts (the process) and results (the product), developing three sets of metrics. Logistic criteria deal with the process of building/ updating the schedule; Propagation criteria relate to how far a problem can jeopardize the project flow: the schedule should be ‘surprise-proof’ in some extent. It relates to preventive actions one can take to protect the schedule. Exhibit 3 helps stakeholders (most of them technical people) to revisit and challenge what they get, without feeling pin-pointed at. It also helps project managers to sell to management their scheduling effort: a schedule is as much a product as a new software, an engine or a power plant.
Exhibit 3: Mapping Schedule and Reliability Criteria
So far we have not completely addressed the functions our schedule is supposed to fulfil; according to the French standardization body AFNOR, a function is ‘any action a product (or process or service) performs expressed in terms of goal’; it relates to the product ability to answer to all or part of a user's needs. We firmly believe that the changes of project environment since the quoted works by Benssoussan and Courtot advocate for a dynamic schedule, a holistic modeling of the current (list of activities, actual knowledge, progress of work) and future (uncertainties, opportunities and threats, time at completion, new knowledge) realities. The conventional view relates more to a Cartesian approach, where DECOMPOSITION is the favorite tool to ‘solve’ a complex problem. The PMBOK® Guide Guide refers almost exclusively to it in the two basic processes ‘create WBS’ and ‘Activity Definition’. Conventional FMECA applied to schedule does the same with some undesirable side effects, as reported by H. Courtot.
Failure Mode and Effects Analysis in practice
FME(C)A in engineering and manufacturing
FME(C)A where C stands for criticality has been standardized in most countries (SAE J1739 -Society of Automotive Engineers-; QS 9000; MIL-STD-1629A; CEI 812 par UTE;NFX60-510;BS 4778 17.7) although it was mostly used in the automotive industry. It is a structured Delphi Method, top-down in the sense that it tries to find all the possible effects of a failure cause, that starts from the knowledge of a product (its functional analysis), uses creativity techniques to identify several failure modes for each function.
You can conduct an FMECA analysis at product, process or means of manufacturing levels. There are slight differences but the rationale and the basics remain the same.
Exhibit 5 shows a simple example of a valve connected to an oil/gas pressurized tank where Frequency (occurrence), Severity (impact to the objective of the function as perceived by the Customer) and inefficiency of Detection are rated on a 1 to 9 scale. Maximum criticality, measured by the maximum Risk Priority Number (RPN) is 729. You could define other prioritization heuristics. We can make some remarks to the method:
- ❖ SEVERITY does not change as it represents the customer or end-user's view point, unaffected by prevention or correction actions on upstream elements.
- ❖ It requests some strategy, analogous to the rolling wave concept of scheduling as explained in Exhibit 4:
- ○ When you are at level n, assume FMEA study at level n-1 is OK
- ○ Do not re-design the product when you are (FMEA) studying the manufacturing process; do not change the manufacturing process when you are studying the availability of Mfg means.
Exhibit 4: Mode, effect, consequences and system components
- ❖ When you deal with a more complex system as you could have done with the valve internals, the logic of effect-mode-cause chain is the same. Item 5 of Exhibit 5 is self explanatory in that respect: loss of metal inside the tube pipe (erosion or corrosion) may block the gate or disk of the valve causing a leakage at system level
FME(C)A for your schedule
The guidelines are:
- ❖ Build your ‘schedule as usual’ taking into account the ‘following requirements page 1’
- ❖ Clarify where you are within your scheduling strategy under the rolling wave concept
- ❖ Define accordingly a group of knowledgeable decision makers so to identify the riskiest/ fuzziest Control Account Plans
- ❖ Revisit the CAPs according to Exhibit 3 so to identify weak areas for your schedule
- ❖ Quantify the risks on summary activities, activities or tasks using a similar table to Exhibit 3. Remember that wave n +1 does not jeopardize wave n FMECA
This method is very logical, rather ‘mechanical’, completely in accordance with PMBOK® Guide Chapter 11, Risk Management. It forces people to look for risk symptoms through the ‘(un)detection factor. But it assumes that decomposition is key to the good understanding of a system behavior. H. Courtot summarizes other interests and limitations as follows:
- ❖ It avoids oversimplifying possible paths towards the end of a successful project because it identifies other ways, feed back loops, time buffers
- ❖ It defines the ‘space of possibles’ thus giving place to a good definition of various scenarios
- ❖ It helps team-built schedule, thus buying-in
- ❖ As most FMECA efforts it can be cumbersome, time consuming, as it relies on an operational database of past failure: without formalized knowledge management the effort might frustrate people
- ❖ It relies on a rather thin decomposition of the work
- ❖ It assumes that the future can be deducted from past experiences…It may create anchor bias, lack of innovation in risk response strategies or people behavior
- ❖ There is no statistical analysis of data
Exhibit 5: FMECA in engineering (simple)
Monte-Carlo Analysis for schedules
Progress of planning software
We will not consider as a progress the feature that allows a scheduling software to produce three or more deterministic types of critical path, based on the 3 envelopes of ‘all pessimistic’, ‘all most likely’, ‘all pessimistic’ durations. This is ‘back to the future’ compared to the good old PERT calculation or to basic Monte Carlo simulation (Desrumaux, 2005).
Nowadays most planning pieces of software allow statistical treatment of durations, whether as part of the original work or as an add-on. As a basic feature, they allow the scheduler to:
- ❖ Replace deterministic durations with density probability functions
- ❖ Determine some level of dependence between two activities
- ❖ Calculate critical duration and path or any other milestone timeline with a sensitivity analysis (usually activities ID)
To do so, schedulers will enter 3 times more data than usually for each activity of the network! By comparison, a PERT calculation on an Excel file limits the extra burden of inputs to the (assumed unchanged) deterministic critical path. In practice, they tend to ‘paste and copy’ basic distributions everywhere without challenging their shape or breadth. Additionally, they tend not to question dependencies, nor have the time to really model what can happen: ‘garbage in, garbage out’. Because (Courtot, 1993):
- ❖ Results are highly dependent upon the shape of statistical distributions
- ❖ Basic add-ons for qualitative analysis by-pass the cause-effect analysis that FMECA helps us to do
- ❖ Unchallenged assumption is that details of project decomposition and development/execution remain fairly stable
It is a pity that causal analysis can be forbidden in the process even though sensitivity analysis helps revisiting inputs. It impedes a good use of newly designed features such as: Probabilistic branching; If/then conditions; Probabilistic calendars
Dealing with high levels of uncertainty…at the beginning of the project
Project Managers know this decision dilemma where:
- ❖ The level of uncertainty is very high, making decomposition of a, say 5 months, long activity into 5 sequentially arranged activities of one month duration very subjective if not very wrong/ questionable
- ❖ The planning software logic asks such a decomposition in order to perform valid simulation
A common error in Monte Carlo simulation cases, as per D. Vose (1996), is exemplified: A departmental manager tells the team that a purchasing activity has 3; 4.25; 10 months duration (minimum, most likely, maximum) respectively, which makes an average of 5 months with a common Pert distribution. The shape is given in Exhibit 6
Exhibit 6: rough assessment
Because of the length and spread of the assessment, the team performs causal analysis and interviews. It appears that the usual duration with this supplier is 3 +/- 0.5 months; there is a 10% chance that the supplier experiences difficulties with a new molding machine. The additional impact would be Pert(1; 1.5; 5) months; there is a 40% chance that they will need to build two prototypes i/o one. The additional impact, if any would be Pert (1; 4; 5.5) months. Without causal analysis, the activity profile is shown in Exhibit 6 as well.
A common modeling mistake is to compute the resulting activity as if you were dealing with deterministic numbers: Total Duration = Normal (3;0.5) + 10% . Betapert (1;1.5;5) + 40% Betapert (1;4;5.5). The result is shown in Exhibit 6 as well.
which clearly does not consider the cases where the risks do not appear
Exhibit 7: wrong simulation of cause
The real Monte Carlo with proper modeling is shown in ‘Exhibit 8: All scenarios taken into account’.
Although the three methods leads to the same average durations, some conclusions could be misleading:
- ❖ When no causal analysis is performed (as per direct MC on planning software), there is an over confidence towards the mean which will propagate along the various paths. The assumed shape of the distribution is wrong
- ❖ When causal analysis is performed but approach derived from Expected Monetary Value is made to consolidate effects, various scenarios are discarded, leading to wrong shape, wrong standard deviation, wrong sensitivity analysis
- ❖ When a complete MC analysis is modeled via Excel-like software, there is a better chance to grasp the problems. Individual distributions are multi-modal, possibly leading to a strange shape of the critical path duration distribution. In case of our example, it would be better to split the main task into 2 parts, corresponding to the two modes.
Exhibit 8: All scenarios taken into account
Conclusions
This paper does not ask you to ‘schedule with Excel’, don't misread me please! It claims that a robust and consistent schedule must take into account uncertainties and get rid of deterministic (often politically correct) numbers. To do so, it advocates to perform cause and effect analysis, taking advantage of the good old industrial FMECA method. To trade-off between time consuming analysis and mathematical robustness, we encourage PMs to map the first wave of scheduling with MC simulation on an Excel software, so to keep control of the scenarios generated. Once a detailed decomposition makes sense, and based on the new knowledge they gained on the previous scheduling waves, they may:
- ❖ Performed a more detailed FMECA analysis, focusing on the fuzziest areas of the schedule
- ❖ Go to the conventional and hidden heuristics of MC for schedule software, entering directly the distributions they obtained from MC for Excel