This post is the first in a series of posts that will explore the immensely powerful impact that STWs properly organized and implemented by the AECO Team, can have immediate and enormous impact on the entire design, construct and operate processes.
STWs were briefly introduced in the BB post “What Comprises the BuildUSA Collaborative Environment”. They are in fact both the heart and muscle of the entire BuildUSA program. Anyone who has a bit of grey hair and worked in the building industry over the past 4 decades, has been involved with countless initiatives to create standards in their office. Starting in the 1980’s standard details, sheet layouts, notes, spreadsheets, proposals, change orders, memos… the list was endless. Every office started to standardize all these items within their office. It was a great learning curve content that varied from project team to project team began to become standardized to an office standard and although not perfect and completely silo’d within a single office, we all became excited about the possibilities. Forty years later the potential is still somewhere in the future. Standards have been placed into increasingly powerful applications that take portions of the building life cycle and provide clear benefits, while creating heartbreaking loose ends and the necessity for manual assistance.
In the 80’s and before it was 100% true that we all thought our office standards clearly represented intellectual property (IP) that provided a competitive advantage. Today, this still represents most offices, but more and more are recognizing that there is something wrong. More money is poured into technology (software/hardware/training) only to see it walk out of the office when a skilled professional moves on after spending the last few years learning their skills on your office dollar. More importantly, every office works hard at controlling the data content and workflow through their silo’d platform, because everyone has different software, and if not different software, different coding, workflows… there is always enough difference that the increase in quality, efficiency & profits, decrease in time and cost is always an elusive ghost flirting just ahead of all of us.
In developing the current STWs, we started by asking a single question. What is the purpose of STWs, or what do we want them to do for us? I think in the beginning (40 years ago) there were so many things to standardize that it was always to just make one task simpler and more consistent. It was not simple to see the big picture and over time clarity was attained bit by bit. Every new standard, every new template or workflow was part of a learning curve that created greater insight into the ultimate goals. In recent years this question has been answered in the following way. STWs create data structures and processes that allow ALL the data developed during a project’s development strategy, design, construction, commissioning and operation, to be readily accessed, analyzed, reported on, allowing metrics and analytics to inform the current project or operation and future projects.
This is no easy task. Data is developed by multiple organizations, each in their own technological eco-system and STWs.