Time
The very nature of CEM is a CPM schedule. The only significant difference between CEM and traditional CPM implementations is in perspective. Most current CPM systems fix time to a given data date. The schedule is current as of that point in time until it is revised with new actual dates and remaining durations. In CEM time is assumed to continue, there is no data date. Thus actual and remaining duration increment / decrement respectively as time passes. The basic assumption is work is progressing on schedule until an actual start date, actual completion date or adjustment of remaining duration occurs. In this way, CEM always represents the state of construction at the current moment in time. The model is continuously updated through the normal course of managing constraints and recording progress. So when the last work item is accepted, the model represents a very detailed and accurate account of the construction process. It demonstrates how each constraint impacted the sequence and duration of the work, which work items were delayed and why.
By utilizing the stage of each work item you can derive many different views of the construction schedule. You could have a view that represents only the work items that are committed by the owner. This would be a current contract schedule. You could also include pending work items to analyze impacts to the critical path for changes in the work. Filtering, grouping and sorting of work items would be accomplished by specifying dimensions and constraints. For example, you could filter the model by a single subcontract agreement and from that get a very accurate start and finish date for the commitment as a whole. You would know when any given subcontractor is or will be working on the project. Want to know when the building will be water tight, filter by the assembly dimension: Shell – the last work item complete represents the water tight date.
Milestones would no longer be activities in the schedule but pre-defined queries of the model. Summary schedules, detail three week look-ahead schedules, material status schedules would all be derived from the model.
Periodic snapshots of the model would allow for point in time comparisons. Given no constraint on storage it would be practical to save a copy of the model every day, so you could analyze trends and identify work items that are deviating from plan.
Updating the schedule is just a normal part of scoping, setting and managing constraint workflows and indicating start dates and remaining durations of work items.
A working calendar is a concept that defines periods of time when the execution of the work can take place. The calendar would have a unit of measure and explicit periods when work may be performed or explicit periods when the work may not be performed. Units could be months, weeks, days, hours or minutes, but days is normally the default. There can be one of more calendars used in a model and would would typically be applied at high level dimension. All child elements in the dimension hierarchy would inherit the calendar of its parent or could have its own. In this way the available work periods for all work items can be constrained and the critical path calculated. When two or more working calendar attributes apply to a work item the more explicit inclusive or exclusive one is used. Working calendars can be global, dimensional or project specific.
Summary | Introduction | Work Item | Constraint | Dependency