Unified Workflow Example

The following example demonstrates how CEM integrates processes across the entire project life cycle.

For the example I am going to track a single work result, concrete on an interior renovation project.  When the opportunity is first identified in sales forecast the only thing we may know is it is an Interior Renovation type of constructed entity.  As more detail is added during conceptual estimating, a work result of concrete is scoped.  It represents floor patching required where new bathrooms will be installed on two different floors. 

A bid package constraint would be added and linked to the two work items for the patching, one for floor one and a second for floor two.  The bid package would include a scope document that details the bidder’s responsibilities that is contextually appropriate for the small scope of work.  The details of the document would come from the scope catalog and would include a description of all procedures, expected materials provided and other installation specific requirements the bidder must include in his bid. The bid package would then be sent to potential bidders.

When the three subcontractors submit their bids each would complete the bid package document providing units, duration and cost for the two scheduled items.  For more complex work, there may be more than one bid package with multiple schedule items that represent the entire concrete scope of work, but the process would remain the same as our simple example.  The submitted bid would become a new constraint automatically linked to the two work items by virtue of the scheduled items derived from the bid package.  The new constraint now has the general contractor and the specific sub-contractor identified as an attribute of the constraint.  Bid comparisons are now much easier since there is a basis of comparison that has units.  If a sub has a dramatically different value for the units of concrete compared to other bids or the general contractors estimates, that would indicate he missed some scope of the work.

As the bidding process progresses, a preliminary construction schedule would be developed.  The schedule would include the two concrete work items and the bid package constraint.  At this point a commitment constraint may be roughed out and linked to the work items based on the bid package constraint.  This is a place holder for the future commitment, its duration representing the entire sequence of procurement to the point when the work could be installed.  This allows for the critical path and overall construction schedule to be calculated.

When the actual work is awarded, a new commitment constraint or completion of the existing commitment constraint would be done and the agreement workflow started.  The agreement would be based on the contract documents linked to the work items, the scope document that was part of the bid package and the subs bid with its schedule of values.  The important part is the agreement is a separate constraint, and may contain a subset of items from the subcontractors bid or may be a combination of multiple items from two or more bids submitted by that sub.  The common link to work items provides the framework to understand the commitment status of the entire work at any given moment in time.

Project management would also identify submittal requirements and add a product data constraint scoped to the Work Result::Concrete dimension.  The critical path calculation now constrains both work item starts by the single submittal constraint workflow without having to explicitly link the submittal to the work items.

As the final construction sequence schedule is worked out, it was identified that the concrete work on each floor needs to be separated in area between the women’s and men’s bath.  The two concrete work items would be divided and the units apportioned.  The cost would be also divided between the two new work items proportionately or upon mutual agreement with the sub.  The critical path is calculated with the submittal constraint now implicitly linked to the two new work items, constraining their start.

When the work progresses to the point where the first floor patching is nearing its scheduled start, a three week look ahead schedule would start to include the work item.  Any start constraints not completed would have been driving the schedule at this point and any delay resolved.  The subcontractor responsible would be notified of the status of the work and would start to participate in weekly planning meetings.  He would also complete any remaining start constraints such as a pre-installation meeting or sign-off constraint.  Once the subcontractor begins the work the start date is identified in a field report and progress notes included until completion of the work item.

There is a reinforcing inspection and a concrete material test required by the specification, both added as completion constraints to the WorkResult::Concrete dimension.  This would add four items to a inspection list and four items to a third party inspection list that would include a data range of when each inspection and test may be called for. The logs would look something like this:

City Inspections

Reinforcing Inspection / 1st. Floor Mens Bath3/1/16 - 3/5/16

Reinforcing Inspection / 2nd. Floor Mens Bath 3/28/16 - 4/3/16

Reinforcing Inspection / 1st. Floor Womens Bath 4/15/16 - 4/18/16

Reinforcing Inspection / 2nd. Floor Womens Bath 5/2/16 - 5/5/16

Third Party Testing

Concrete Strength Test / 1st. Floor Mens Bath 3/1/16 - 3/5/16

Concrete Strength Test / 2nd. Floor Mens Bath 3/28/16 - 4/3/16

Concrete Strength Test / 1st. Floor Womens Bath 4/15/16 - 4/18/16

Concrete Strength Test / 2nd. Floor Womens Bath 5/2/16 - 5/5/16

There are two important concepts demonstrated here.  First lists are constraints created by the virtue of linking the two requirements to the concrete work result dimension.  If the concrete work were to be divided again, additional constraints would automatically be added and will show up on the lists with schedule dates.

Second, the dates are ranges and reflect the schedule or actual start date of the work item and the scheduled completion date of the work item.  They do not represent the scheduled date of the inspection or test itself.  This would be a date identified as part of the weekly work plan meetings and would be managed by the inspection or test workflow for each constraint.  If the date range is too large then the work item would need to be divided into smaller more granular work items.  In this example, the concrete work item could be sub-divided into three sequential work items, formwork installation, reinforcing installation and concrete placement.  The inspection would then be linked to the reinforcing work item and the test to the concrete placement work item.  This would narrow the scheduled window for both items.  The schedule inspection and test date, the actual date and any resulting documents could be managed as part of the daily field reporting workflow or by a separate dedicated process to manage all inspections and test.

As part of the monthly billing workflow all work items that have all completion constraints done would be eligible for payment.  A bill type constraint would be created with all completed work items.  The March bill in this example would include the concrete patching work for the first floor men's bath.  After the architect inspects the work to confirm completeness the certificate of payment constraint is executed and the owner pays the bill.  In this example you may be able to eliminate the request for payment from the subcontractor since there is already an agreement as to the scope and value of the work being billed and an understanding of all completion constraints that must be satisfied before the work can be billed.  If there is a contractual requirement for a subcontract request for payment, then this would be a constraint linked to the completed work items of the subcontract.

During construction on the first floor it was identified by the owner that the second floor men's bathroom will be removed from the scope of work and the third floor bathroom remodeled instead.  A request for proposal constraint would be created and linked to WorkResult::Concrete and Space::2nd Floor Mens Bath dimensions.  And a new work item created with the WorkResult::Concrete and Space::3rd Floor Mens Bath dimension.  The change order request prepared by the general contractor would be linked to these two work items as well and would represent the change in cost.  The change workflow is preliminary at this point so the current construction schedule would still represent the original work items and schedule dates.  But you could have a view of the schedule that would take the potential change into account and would ignore the 2nd floor men's bath and include the 3rd. Floor men's bath in the calculated schedule.  This would show the net effect of the potential change and if extension of the schedule results additional general conditions could be included in the proposed cost.  When the change is executed and the status of each work item updated accordingly, the current schedule now represents the new scope and sequence of the work.  The inspection and test constraints linked to the 2nd. Floor men's bath would be cancelled and new one's created for the 3rd. Floor men's bath.  All date ranges reflecting the new current schedule.

The work would progress until all work items are complete.  In this example the owner needs to take occupancy of the first floor prior to the remainder of the project completing.  A separate substantial completion certificate could be issued by the architect for the area dimension.  The architect then completes his punch list inspection.  Punch item constraints would be added for any non-compliant work items and correction workflows started.  Once complete a final certificate of payment would be linked to the first floor work items and final retainage payments made.  The work is complete for that portion of the project.

Corporate Experience | Implementation | Scoping | Use Cases