Integration is a Discipline

Posted on January 28, 2011


Several months ago I attended a seminar on behavioral health in the hospital environment. The presentation showed how it takes both a clinical change and a structural change to make the treatment methods work. For instance, a structural attribute would be convenient co-location of key components within the building. A clinical attribute would be shared medical records between a primary physician and psych professional. This combination was emphasized as an integrated model, a model of maximized efficacy.

I find this a fitting description of integration in projects. The way Haskell delivers projects is in an integrated manner, with both “structural” and “clinical” methods of integration at work. It can be argued that without both integration at the structural level, or how a firm is organized and operates internally, and the clinical level, or practice-led integration, integration is a hollow concept.

Perhaps just as educational, the seminar  further explored the challenges of integration. Integration is not easily defined or measured. In organizations, support for integration is high but commitment is weak. No one model of integration is appropriate for all situations. The functional integration model is favored over a structural model. Surprisingly, all of these challenges are shared in the design and construction industry.

All of these are sad but true realities mainly because most designers and builders take the path of least resistance. Companies that do not employ both the structural and clinical only pay lip service to integration. Haskell does both. For Haskell, integration is a discipline.