In current construction management practice there are many procedural hand-offs during the pursuit and execution of a project.  Opportunity pursuit, estimating, procurement and construction management are very often performed by different teams and individuals within the general contractor’s office.  Each tend to use information systems geared toward optimizing their particular workflow and information needs.  When responsibility changes hands the new team needs to interpret the current set of project information and transform it into their preferred information management system.

There is an argument to be made that the separation of information systems is optimal and the transformation and re-input of the data is a very important part of the process.  When responsibility changes, the new team must invest time to understanding the project.  They must do their own examinations and detailed analysis of the work to understand the scope and requirements of the project.  While there may be duplication of effort, this hand-off helps enforce the transfer of ownership of the project from one team to the next. 

Our current information systems have evolved in this disconnected environment and reinforce the manual hand-off, interpretation, transformation, and re-entry process.  The transfer of knowledge from one management system to the next is not inherent and relies upon the skill and diligence of the team to understand what is important and to acquire the knowledge needed to control the next stage of the project.

That being said this approach is problematic and not very scalable.  Each control process has basic information requirements that have a specific shape.  Knowledge acquired in a previous process may not be suitable in scope and granularity to inform the next requiring interpretation and transformation of data.  Whenever this happens some of the acquired knowledge is always lost or discarded.  The data while important in a prior process is not immediately relevant to the current so is not re-entered.  The limited time and resources of project management make this problem more acute and results in only the most critical information passing to the next process.  In addition, there are many cases when key facts are entered multiple times in each new control process possible changing its meaning and intent. This creates siloes of information that do not correlate by default.  Project teams re-learn some of the knowledge acquired in the past because that knowledge is no longer readily available.

As the size of project teams and organizations increase, the siloed effect becomes more prominent.  In small teams and organizations, knowledge sharing happens organically due to physical proximity.  The same people work on multiple projects together and have shared experience.  The larger the organization, the more projects executed the less individuals work together and the less knowledge sharing occurs across the organization.  People become specialized and specific knowledge is once again siloed.  Our information systems do not have the capacity to manage the acquisition of corporate experience and make it consumable to a project team in a efficient manner. 

CEM is a new way of managing knowledge acquisition during the life cycle of a project.  As a project progresses each team contributes there acquired knowledge in a structured consistent method.  Instead of the hand-off process, all participates are contributors to a single model of information that evolves and becomes more detailed over time.  Work items described in early stages of the project by one team are further decomposed and detailed by other teams later in the project life cycle.  The framework allows for the expansion of detail that by the end of the project is the most appropriate set of information required to manage that particular project with no redundant effort.  And knowledge is organized in a way that is now comparable and available from one project to the next.

The fundamental process of understanding and documenting the scope of work for any given project is called “Scoping”.

Scoping | Use Cases | Unified Workflow Example | Corporate Experience