4.09.2012

BIM and XPM: A Made Marriage - Part 1

Prelude...
Since writing this article back in April, It is ranked #2 for the number of all-time hits on this blog. I'd like to encourage you to read all four parts. The hook is I reveal how all this works in the later parts. These lightweight management theories will radically transform your business and professional practice. If you want to see more $$ at the end of the year and create a better working environment, then I strongly advise reading all of the series. aa June '12
 
Introduction
BIM and XPM were made for each other. BIM authoring tools of just about all forms are characterized by elements or families which have some kind of data construct attached to the graphic elements. The graphic elements can be driven by parametric data or not. Not surprisingly, the elements are organized in large categories which roughly approximate the organization of the construction material sets needed to erect a building such as foundations, floors, walls, ceilings, furniture, casework, equipment and the like. Views are organized in a way that traditional document sets have been assembled for decades such as plans, elevations, sections and tabular schedules. Since the model is 3d there is also a new view for 3d perspectives, isometrics and other similar views. A very modular and structured way of thinking.

Most importantly from a work management point of view all these elements and views are very atomic and largely independent of each other. They can be created with or without any data or graphic content in them, or at the very least only the barest of information or graphics as place holders waiting for more specific information. The other important
attribute of this construct is that there is no particular linear order that exhibits cause and effect for any of these elements to exist. They can be truly random in their creation and assembly with little or no effect to the end product. It's almost like Object Oriented Programming complete with class, type, instance and inheritance along with data driven object behavior. If Agile-like management works in the software world with it's iterative design loops and battles with change management, it would surely work in the architectural world, especially when BIM is used as the modeling component analogous  to a Uniform Model structure in the software world.

The Journey Begins
So began a journey over 10 years ago to migrate the world of light-weight management theory to architectural practice. The more I worked with it, the more I found it worked and worked very well. It also delivered some long desired results of cutting down the time to document designs, better utilization of labor resources, delivery of value when it is needed and a consistent work planning structure which is flexible enough to respond to the variety of work demands and schedule changes. I found we could more easily see where risk was present in different design alternatives and then decide how to manage that risk. We found we could manage workload and labor distribution very quickly without having to use very detailed briefings for new team members since their work is very atomic and more standardized they understood much more quickly what was valuable and set to work immediately without a lot of direction.

All those advantages came over time and with effort and a lot of communication and experimentation. I won't tell you we took an agile handbook and transliterated it into architectural-speak and just went to work. No we found that planning fast, working just as fast, prototyping processes and looking for failure points took quite a while and a lot of effort and commitment on the part of everyone from ownership right across to the administrative support staff. But we did find a core set of repeatable methods and tracking devices along with some common project organization techniques that work well together . If you were an experience agile  software team member and you came into this environment, you would certainly see many similarities, but you would also see quite a bit of change and implementation of agile theory into practice. But isn't that what agile management theory is all about? Being flexible, adaptable and keeping communication open are the underpinnings of agile work organization and that's what we did.

Overview
An overview is in order. Much of the organizational structure of Agile is still there. There is still a release plan, but it is focused around the traditional phases of work for our profession and then subdivided only one further level if there are major review deliverables defined in our services contract. Then there are the stories. Here is where some deviation begins. Stories are not strict equivalents to use cases in software, rather they are a way to manage larger elements of work, such as exterior envelope, plan, equipment, environmental systems, vertical circulation and finishes. These stories are carried across a constant time-scale division for iterative work sessions, still called iterations. Often these are only one week in scale but never more than two weeks. The iteration planning, daily standup meetings and measures for velocity and burn rate are all about as you would expect but on the points scale we found a dual scale for stories and tasks needed to be created. One component was difficulty/risk and the other effort. When multiplied together you get a point score for tasks and consequently the composite total for a story during an iteration as well as over the longer time scale. One advantage of this method is when you are in early planning of the project you can designate some rule-of-thumb estimates for those larger scale stories which have the greatest amount of impact on the design outcome and related work effort. Also it makes it easy to track these values over time and for the project as larger subsets of burn rate and velocity in their own right as well as those same components for the ongoing iteration sets.

Finally we did allow for administrative stories which included the planning, tracking and management as well as documentation and organization tasks which does contribute value and are as much a part of the overall fee structure as the design and document production portions which agile usually focuses on.

We also instituted a new construct we called a prototype. Those are groups of tasks which are associated under stories which are highly repeatable and often vary very little from one period or project to another. Reporting tasks and some management task sets were set up that way. Even the view assembly tasks for sheets were created as prototypes. Specific family types and family creations tasks were created as prototypes since we developed highly defined structures and methods for the creation of those elements. You can see how those prototypes reduced a lot of decision-making and eased the planning effort greatly when they could be used.

Other Enhancements
A further development was a wiki construct which held the directives and planning strategies for general project organization. Over time it became our in-house development handbook. We also created another wiki construct which held project-specific information such as design requirements, contracts, contact lists, specific product research and links to project tracking tools for that project. It was easy to create a link from the elements in the model back to the source documentation which drove the creation, use and application of the elements.

So it was easy to plan for upcoming work, track what had been done against some benchmarks using the longer duration stories as well as track the work in progress as to completion of iterations, stories and release points. One final tracking mechanism we employed and I'm not sure where it came from, but we called it Design Capital and Design Debt. Each week if the iteration was completed and more work was completed than originally planned for, the team created Design Capital (value) as expressed in Story Points. Conversely, if they didn't complete the story tasks, what was left over was counted as Design Debt (value). Sometimes some of the tasks in an iteration never got created so if they were dropped from the scope they also were dropped from the Design Debt. Design Capital/Debt was shown as a weekly accumulation in a line chart so the team could see if they were moving along as planned or were falling behind and by how much.

We did all this using open source code application running in browsers on a shared hosting account. Pretty vanilla stuff, but by doing a bit of experimenting, working together and being committed to success we found a serious amount of value in our practice by eliminating waste. We reduced the time we spent on completing projects while increasing the quality of our end products which received very high praise from Owners, Builders, Reviewing Jurisdictions even material suppliers. In doing this we turned our backs on just about all the traditional management measurements, methods and tactics while empowering employees, raising the skill sets of everyone and creating profit in a very tight economy.

I don't know about you, but those were pretty significant accomplishments and we found greater value in using BIM correctly and efficiently. I'll write more on some of the tactical decisions we made along the way and the specifics on how we used the open source software tools.

Enjoy and remember "Collaboration is the glue for success."
On to Part Two

No comments:

Post a Comment