Getting a schedule just right is tricky - we’ve been there! This document sets out what the priorities are when building a schedule for creating the best possible forecast, so you can get the most out of nPlan’s insights as quickly as possible.
The 12 points below are similar to the DCMA 14-Point Assessment, and we’ve also described why these preferences are required below.
| No. | Title | Detail | Why is this important? |
| 1 | Preferred level of detail | Minimum accepted level of detail is at L2. The more detailed the schedule, the more insightful and reliable our forecasts get | Our Deep Learning models infer information from the duration of activities, their description, and other details in the schedule. The model performs well with Level 2, 3, and 4 schedules. However, it can be more challenging to design mitigations when schedules are less detailed, which makes taking action more difficult. |
| 2 | Format | *.xer (P6), *.pp (Asta Powerproject), *.xml (MS Project) | |
| 3 | Planning unit | Days, with a minimum duration of 0.5 days. Activity durations should ideally be between 3 days to 30 days. Activities longer than 15% of the total project duration or 60 days are not taken into account in the analysis. | Our dataset shows that activities longer than 60 days are rarely actualised, which suggests they are more likely to be broken down into more specific activities, which we can forecast with greater certainty. We can however model uncertainty on activities longer than 60 days on request. |
| 4 | Task names | The more detail, the better - machine learning works best when it's got data to work with, and activity descriptions are a source of this data. Avoid using acronyms where possible, particularly when the acronym is critical to understanding the activity, e.g. describing the object being built. For example, 'build a Large Hadron Collider' would be more helpful than 'build a LHC'. All non-standard acronyms must be expanded in the schedule file. |
One of the features that the Deep Learning model uses to analyse activities is its description. Therefore, more information in the description means that the ML model has more information to process, and this helps with forecasting accuracy and confidence. Where acronyms (particularly local/bespoke acronyms) are unavoidable, we can translate the acronyms for the model, for example by using a glossary. |
| 5 | Logic | All activities should have a successor and predecessor except the initial start and final finish activities. Use the most appropriate logic link for the relationship. Usually this will mostly be finish-to-start, and start-to-start/finish-to-finish with lags where appropriate. No start-to-finish relationships. No circular/cyclical logic No conflicting additional logic (e.g a finish-to-finish and finish-to-start, for the same activity) |
Logic shows the relationship between activities and consequently, the effect if these activities are completed early or late. Without these logical relationships, the forecast is limited in its ability to show the impact of delay or efficiency in the schedule. The forecast won’t include activities that are not linked to the target milestone for analysis. |
| 6 | Lags | Only use lags where appropriate. No negative lag |
In the forecast, lags are treated differently to float - uncertainty is not applied to them. Excessive use of lags therefore results in the schedule being unable to make sure of float in the schedule - it becomes more rigid and therefore less resilient in delay. |
| 7 | Constraints | Use constraints only where appropriate and try to limit the use of ‘hard’ constraints (e.g. ‘Finish On’). Let us know which constraints you would like us to respect in the analysis. |
Constraints, and particularly ‘hard’ constraints limit a schedule’s ability to realise opportunity. In certain cases, constraints are appropriate as a reflection of activities in the project. However, they should not be used to ‘hold a schedule together’ (i.e. in lieu of activities and logical relationships). Our dataset indicates that, in reality, constraints are not always respected as originally planned in schedules. |
| 8 | Calendars | Calendars with more than 2 consecutive non-working weeks should be carefully considered to allow any activities associated with them to move to an appropriate working window in the event of delays | Calendars define when in a day, week, month or year, activities can take place. They can impact forecasts significantly, and provide unrealistic outputs, especially with calendars containing large periods of non-working time. |
| 9 | Milestones | Any tasks with zero duration should be classified as milestones. | Milestones are an indication of a section of work starting or being completed - they are not representations of activities. |
| 10 | Work Breakdown Structure (WBS) | A WBS should be used and named in a meaningful way for the project. | Some of our analysis (for example identifying risky project areas) considers the WBS, and we use the elements of the WBS to communicate these areas to our clients. Therefore, a meaningful WBS will help us to find more perceptive insights for you. |
| 11 | Scheduling Settings | Please schedule the file before submitting. The recommended scheduling settings are:
|
There are many different schedule settings that can be applied in planning software packages. These settings are what we consider to make most sense when forecasting construction projects. Should you use different settings, that’s fine! Just let us know and we’ll bear that in mind when forecasting. |
| 12 | Contingency / Time Risk Allowance | Remove or zero out the contingency / TRA | We don’t want to forecast on contingency activities. By not including it in the forecast we also can make an informed decision on whether or not the allocated contingency is sufficient for our chosen risk tolerance. |