Google Glass, Augmented Reality and Always-On

I just came across a follow on blog post by Josh Web who is one of those guys looking at what is going on and extending it to what might go on in the future. Some of you know I've been interested in the melding of visual and data driven technologies to provide a richer environment to work and live within. I first started thinking about this back in the late 1990's when I ran across a couple of guys in Dallas who were trying to get some augmented reality off the ground for HVAC field techs. They were really ahead of their time. Cell networks were just getting past the old analog services and Dallas has always been one of those testing markets for new doo-dads and services.

So, I've been wondering when we can get BIM, geocoding and virtual reality to work together and what that might mean to the AEC and Built Environment worlds. Wifi enabled cell phones can get down to pretty small increments for locational accuracy when four transceiver locations can pinpoint the WiFi device inside of 2 feet or less. How about using this kind of technology for mining, roadway construction, bridge construction, pipeline alignment and construction. All these types of projects would benefit from some form or combination of augmented reality merged with design and fabrication virtual models. The folks at Trimble Navigation already are embarked on the remote control of roadway construction machinery and open pit mining, but there is a lot more to be done.

Take a quick look at the slide presentation by Josh below and then let me know what you think about where we might be going with these idea in a couple of years.
Enjoy!

BIM Metrics

The following is an email I wrote to a LinkdIn contact Tim Cole of Causeway Software. Tim had asked me about what I thought about how the Levels of Detail effect the kind of data which can be collected as Key Performance Metrics around BIM models. This is my second reply in the discussion between Tim and I and I thought others might be interested in this particular segment. The issue I'm dealing with is at the the heart of metrics in any form, and that's the data collected and for what purpose that data is intended. My contention that the kind of data some folks want to collect is a direct reflection on the authoring software and purpose of the project's original intention. So here goes. I hope you enjoy the read. And as always remember, "Collaboration is the Glue of Success."

Tim,
I'm not sure how I came up with the five levels, but they are similar to the US AIA level of detail document. I've modified that level to suit what my experience has taught me and what I've seen more advanced Owners such as General Motors, Ford, Motorolla and Intel use as their increasing tiers of service they ask for. For man of us in the US the first level of use is just assumed to be a 3d model. I know you can have a flat drawing that has data attributes on it, but it really is not a virtual building model, it is just a flat drawing with data attributes. Yes I do know you can do 3d Acad with 3d blocks and attributes, and that could be constructed as a BIM model, but it is pretty crude and rudimentary. Acad never was intended to hold a lot of data attributes, it is a drafting program. Using it in the extended form is a bit cumbersome. Then there's Catia. A premiere 3d mechanical modeling tool Frank Gehry has spent millions on to make it into a building modeling tool. And a very good one, but at a tremendous cost to own and operate.

Then we get to the built for purpose software like Revit, Archicad, Tekla and Datacad. These tools were built to handle data and intended to model space and construction from the beginning. Revit's history comes out of a mechanical modeling history but the guys quickly found that a mechanical parametric modeler just didn't work well to construct buildings, so they started all over and used a completely different mathematical base for the definition of parts. There is only one other program I know of designed like Revit since the 1980's and Tekla owns that original source code now. Tekla and Revit share some common ancestry in the algorithms they use to define elements but Revit has taken that definition and internalized the data store to be almost entirely inside the model. That, I think, is the one weakness of Revit, but eventually they will change this and make most of the data external and accessible to 3rd parties as the projects grow in size and complexity.

The takeaway here is that purpose-built software intends to create a virtual building from the outset and not be a drafting or documentation tool. That is the biggest difference in the two camps or classes of software on the market today. Here in the US most of the users don't think of any 2d documents as BIM. Maybe intelligent drawings, but certainly not a virtual building. So for us starting at Level 1 as a 3d virtual building, although it may be just a very general idea of the design and construction, or maybe no construction technology has been thought of at all. It really just conveys a design intent and not much more. You know that these models are quick and dirty and there are a lot of 3d modeling tools that can be used to get this kind of result, but it's not a BIM model if there isn't any Information component in it to help w/ completing the design. This stage is where Onuma really works well. Their space and utilization tools are really nice for building models at this level. They allow you to use something like Sketchup and then marry that spatial model to data by importing the 3d into Onuma and apply lots of data attributes to the spatial construction. There is a lot of value there to FM and Capital planning folks that don't really care about the construction detail.

The work I've been doing for the last 10 years has been focused on how to leverage the incredible resources of a virtual building process into the overall delivery methods we use. I've found that no matter what level of detail you use in a model there is a much more important story going on along side it which we leave completely out of the picture and that gap creates a lot of confusion and cost. Marrying those conversations with the model in a central storage repository so anyone connected to the project can understand why decisions were made would be a tremendous leap forward. There are so many levels where this 'conversation dialog map' could answer all kinds of questions about what is going on. Paired with a knowledge store of allied information keyed as a semantic network of relationships is what I think is needed to help BIM deliver the meta information which is really where the real value is during the building's lifetime. This goes way beyond the concept of levels of design and gets back more closely to the original questions about BIM metrics.

With a data store as described above you would know about how decisions were made, what the design assumptions and goals were, how they were intended to me met and how they were actually met in the end product. These are the metrics which are most important to Owners, not what level of detail we used in a model. The results of thoughts which turned into action, this is what building owners and investors are interested in. What was the return on investment for a design implemented over time? Did the extra money spent, really result in better service and a longer material service life?  Right now we aren't measuring this kind of performance. In fact, we aren't even actively determining if USGBC certified and rated buildings really perform over time as they were intended. There are some pilot projects going on, but a limited response for now. So do Owners really get any benefit out of a 'green' building? That to me is an important metric which few people are doing any significant work on now.

In the end, all metrics are driven by data. Data that can be reliably gathered and analyzed in a standard format (read an extension of accounting rules). Until the profession matures enough to settle on some data-driven processes, this question of metrics will be one of many words, conferences and papers and a few people who bravely go out and try something, anything to see what works. Those brave few will be the ones that set the pace for the rest of the professions years afterwards.

Andrew Abernathy

 This post is a continuing String of  articles as on the effects of Building Information Modeling and Virtual Design Construction on the Built Environment. As such there are Connections between the worlds of  design, software, economics, finance and Facilities Management.

BIM and XPM: A Made Marriage - Part 4

So far in the previous parts One, Two and Three of this series I've introduced you to an alternative work management method using eXtreme Project Management theory (XPM). XPM is a variant of the Agile light-weight management movement. The roots of this management theory caught hold in the software world and has moved into other business domains. If you want to change your management to fit more closely with collaborative efforts and use BIM in your practice, then you need to give XPM a very close look. It has a lot of advantages to offer and gives a lot more control to the people actually doing the

Google sells SketchUp to Trimble

Yesterday, 4/26/12 John Bacus, Product Manager for SketchUp announced the sale of SketchUp to Trimble and Trimble also announced the acquisition. What will this mean to the AEC and others who are avid or even passive user of SketchUp? As usual only time will tell.

BIM and XPM: A Made Marriage - Part 3

Part 1 and Part 2 of this series introduced you to a new light-weight management method based on Agile and XPM planning methods. In Parts 1 & 2 I told you I would tell you how we used this theory so in this installment I'll make good on the promise.

We started out trying a piece of web-based tracking software which is open source. We abandoned it for a couple of reasons, the biggest reasons being a serious bug in the software and a lot of terminology specific to software development. As a second attempt we backed off and started over with a stack of 3 x 5 cards to represent the elements of the plan from Releases right through to the Tasks / Tests. Later on the team wanted to use an online solution and we agreed on a simple online forum as a platform. It meant a little more manual work than the previous online software, but we found it worked just as well and was simple to use and it didn't have all that foreign lingo of software development. We were free to make up our own language. I'll also say at this point we also tried spread sheets as an alternate to the web forum, but that was just too unwieldy and didn't have good multiuser support. Spreadsheets really are built for single authors. We did find the spreadsheet was OK as an alternative to the 3x5 cards for planning.

We created several different structures in our forums but the following became our standard of practice.

A list of categories called Active Projects, Completed Projects, General Discussions, and Food for Thought. We used General Discussions for topics that weren't germane to the production of any single job, but something someone wanted to pass along as a supporting thought or reference for the general practice. Food for Thought was used only for discussions that directly related to the management practices and how they might be improved or extended.

Next under each forum category we had the projects themselves. Under these we had children forums for Planned Work, Current Work and Completed Work That looked something like this.

So you can see a very simple mechanism implemented in a simple to use software tool like a forum, gave us the majority of the functionality needed to organize our work. It was easy to move the elements of the discussions as well as the discussions around as their information matured.

It only took us a very short amount of time to teach anyone in the office how to set up and maintain this organization method so we used the junior team members to do this task. That way they got used to the tool and how it was used every day.

The Language of the Forum
Next we had to create a lexicon and grammar to organize the information at each level. We tried a lot of different solutions with varying results. We finally gave each project team some latitude on their choices due to the preferences of team leadership and the complexity of the project. We had a range of organization that had little if any sorting string thought to some that could organize the views by selecting string or substring values along with numbering schemes that produced views with only a very selective result. For instance some teams chose to use a title string that looked like the following organization
[completion] | release | Iteration | story | task | [Responsible] | title and looked like....

[y/n]2.3.15.100[] Model interior sound partitions

If someone only wanted to see incomplete release 2 tasks they would look for a string like "[n]2.*". Or all the incomplete story 15 tasks with "[n]*15.*" If someone wanted to see all the work they had taken charge of they could look for "*[aa]" if their initials were "aa". So you can see there is a lot of flexibility in an open string and search tool to quickly create searches to display results. Our forum also had a listing view to show all the past activity as new or changed information in the forum, which made it easy to watch the work being completed without having to do a lot of searching.

We also included information in the body of the task / test entry like when it was due as a calendar date [11/15/11] and any reference documents back to the Project Notebook or other web resources before the task description. Work completed was created as a reply to the forum entry and signed / dated along with the hours used to complete the task and test. Both the Task and Test portions had to be completed before the work was marked completed. 

The wiki project notebook
The companion to our forums was a wiki organization which we implemented using Mediawiki. The wiki held both the higher order project information like clients, contacts, project budget and schedule information as well as specific information regarding selections for materials, assemblies and all the other design requirements information. In addition we used template pages that organized much of this higher level information so all a manager or other assigned team member had to do was select one of the template documents, duplicate it in their project and then fill in the blanks as needed. This normalized both the information and the organization pattern for this kind of information and gave each element a url page location which could be used in the forum to point back to when needed. So the wiki became the project notebook and it was uniformly accessible by anyone at anytime from anywhere they could get a web connection.

We also had sections in the wiki to assist project work planning teams to easily create stories, and task collections by creating lists of common stories and tasks / test combinations. They could cut / paste the needed information out to make it easier to create the forum entries. 

So there you have the core of our tracking and documentation methods. Nothing fancy, but it works and it is free. There is enough flexibility in the methods to accommodate a lot of differing need so if you need a simple implementation, pare off what you don't need and use the rest. If you have more people and work to manage, you can step up the organizational framework to meet your needs.

Advantages
This level of project documentation made it easy to add new members to the team. They only needed to read the information necessary around the work they were assigned to. If they needed some background on how the model was organized the BIM Execution plan gave them that info housed in the wiki and referred to in the tasks / tests they would work on. Instead of having to brief someone for 20 minutes or more, it took about 5 minutes for a new person to join in and get productive, and that was without a senior team member giving them a briefing. Yes this did take some time, but it kept people focused on their work. Work that was needed was completed in timely manner. Work that was not needed yet didn't get worked on. And tracking the completion of work or where there were issues were easily identified and solved quickly by the team or an outside source when needed. After setting the expectations and training this system was very effective in keeping our projects on track and eliminating waste.

I hope this helps you understand how we organized our work. In Part 4 I'll share the measurement indicators we used to track progress. Until then remember "Collaboration is the glue of success."

Now on to Part 4, the last one

 

This article continues a String of Connections between practice management, BIM and Agile management practices. 

"Right" BIM Thinking

Does our thinking need to change in order to do BIM well? How?

What is "right thinking" when it comes to BIM, anyway? How is it different than "right thinking" was 5 or ten years ago? How do you train for it? Can the playing field to accommodate "right BIM thinking" better?

Question by Brian Lighthart in LinkedIn Group BIM Experts

It's Saturday AM and I'm catching up on reading I didn't have time for earlier in the week, so I thought I would pass along this gem I found. I would suggest you read the discussion since, in my humble opinion, this is one of the more insightful questions asked around the general topic of BIM. Those of you who are part of the new rush to use BIM will find this discussion either enlightening or obtuse or even dark. The truth of the matter is Building Information Modeling / Management is a technology still in it's early development. An adolescent at best. All the stakeholders who could benefit haven't weighed in yet. All the potential benefits haven't even been defined, discovered or delivered. And definitely not all the right questions have been asked.

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

Design Age: Six Characteristics of Modern Design

Design Age; Six Characteristics of Modern Design

I've been trying to describe the means and methods of failures in the larger design profession for a few years now. Every time I think I might have some of it defined, I find more to work on and less confident of a succinct set of reasons. The old "the more you know the more you don't know" paradox. If we look at software design is a veritable Eden of failure and and looks like a Gobi desert of success. The expectations of success for software design, delivery and maintenance are so low right now that anything that even looks or smells like it might be a partial success is hailed as a breakthrough. But compare metrics of completed, tested and proven work over time against any other domain and you see how horribly we fail as software designers. But I don't want to waste all my rocks on the lowly IT folks, there's plenty to go around in the physical product design professions as well, and don't forget the built environment folks who haven't had a serious  breakthrough in productivity since the Department of Commerce began tracking such stuff over 45 years ago. By the way software is in the non-farm sector, so that line would be better if it were taken out.

While I'm still looking for more definition around the failure of more and more design projects I have found six characteristics which I and others seem to find present more often than not. If you read my lead-off post about wicked problems I confess some of these characteristics define wicked problems, but more on that later.

Here are the Six.
1. Solutions are needed to further understand the problem.
2. There is no point defined before we begin that says we have solved the problem. Rittel called this the "no stopping rule."
3. Every problem is unique unto itself.
4. Hence, every solution is "one-off" not to be repeated again.
5. Solutions are not right or wrong.
6. There is no commonly understood alternative solution

So, for all you Type A control freaks out there (I'm one as well.) this is not good news. Just when you think you have an answer to a really difficult problem, there is someone out there ready and willing to punch really big, and I mean huge honking holes in your precious solution you've been working on for the past year. So what are the quintessential problem solvers to do? Horst Rittel thought it might be irrational to continue trying to solve problems of the more complex nature by individuals, since the iterative definition of solutions lead to more problems in an ever spiraling circle of failure.

Now there has to be some kind of way out of our dilemma and several folks over the past 25 years have suggested that first we quit trying to solve difficult problems as individuals. Get more people together, get more experience together, and then agree to ground rules that let you work together productively. One of the first, and rather off-putting to our democratic sensibilities, is that majority agreement does not always rule. Rather seek a plurality of consensus not agreement. I know it's a fine line we tread here, but it is a central tenant for making any progress with these difficult problems. Consensus is that dirty little secret lying in the closets of politicians. They rule by cajoling, deal-making and moving power around. That can lead to a form of consensus, but there are positive ways to reach the same thing. I'm not talking about forced compromise, but reaching an agreement to move forward, regardless of prior position or thought.

NOUN: consensus

1. An opinion or position reached by a group as a whole: "Among political women . . . there is a clear consensus about the problems women candidates have traditionally faced" (Wendy Kaminer). 
2. General agreement or accord: government by consensus.

You don't see anything about majority of opinion or position, just an agreement to move on. Often a plurality of agreement is as much as we can expect and need from a group of varied stakeholders with a likewise myriad base of experience. And just as important, is consensus can be changed at a later time without serious loss of face or power position, since after all it was just a consent of the group at a point in time, given the information at hand.

But design, isn't that a different thing? Isn't design something that has tangible outcomes and results we can measure success from? Sure it is, but we've been enduring bad design since the dawn of man. It's what trial and error is all about. And this gets back to the first common attribute, "it takes another problem solution to understand the direction toward a possible solution". Now the inferred element is that the earlier effort had some element of failure. Now I'm a proponent of failing fast and often, just to find out what does and does not work. I say better to get it out or the way instead of burying it and having to deal with the failure later, for I've found your sins will surely find you out, eventually. So consensus and being willing to fail are two partners that work well together, if we are all willing to take those mental positions.

Design is becoming more and more complex. Most of you all know that the simpler something looks the more is being done for you and the harder it is to make something that is really difficult look and feel simple. In our world of instant gratification, everyone has the expectation that something will be easy, simple and intuitive. If we can't figure it out without instructions, then it's too hard and we don't want to put in that much effort. We would rather have a tool that is easy to use as long as we can live with the results. Results don't have to be perfect, just acceptable. But on the other hand we really do wish for perfection and would like to have it if we could get it.

Take for instance the clothes washer that is connected to the internet and will call the manufacturer if the spin speed isn't fast enough, or if the fill cycle didn't work just right. Those are two functional elements in the washer that the manufacturer could trigger the washer to run a diagnostic routine to find potential reasons for their existence and potentially have some adjustment in the controls circuits to reestablish the proper set points so the fill cycle works correctly and the spin cycle gets the clothes spun to the correct dryness. If those solutions did not work they could send a warranty repair notice to the local repair company and send you a notice via sms messaging, email or phone call, or all three, that someone was going to come and check out your new washer.

The simple sensors, logic controllers and communication devices are the easy part of this scenario, it's the people part that is difficult, but you can see the problem is far more complex now than even five years ago when we simply bought a washer and used it until it demonstrated some kind of serious problem. We called the repairman on our own. Yet we see the design requirements are far more complex in today's world of possibilities. There is a direct correlation between the greater number of design requirements and the greater possibility of failure, yet we still expect the washer to be simple to operate, convenient to use and efficient in it's consumption of water and energy and the results of consistently clean clothes the results of our efforts.

In the above scenario not only were the mechanical, electrical and industrial designers expected to deliver a great product, but a new element of coordinating a customer service and warranty repair program were also part of the solution. Three very different kinds of organizations, but necessary for the design requirements of this washer. It is a wicked web we weave and one with many sticky points along the way to say the least. Today product manufacturers are expected to deliver not only on the technological side, but the soft side as well. It's not something manufacturers are well known for doing well. But that is the world consumers have been told is possible and that is what they are demanding with their purchasing power and their social media power.

Do pity the poor designer who has to figure out who and how these problems will be solved. Fortunately for some product manufacturers they have awakened to the possibility of an entire continuum of people to solve these problems is much better than a single person or team from a singular viewpoint. More on the other points later...... Continue to part two

Ideate BIMLink for Revit

As an old data hack from ages ago one of the prime gripes I've had with Revit, even from the early pre-Autodesk days was data manipulation without having to use Revit to access the data. Ideate BIMLink for Revit helps to solve part of that problem. First, getting the data out so you can work on it. Second, getting data back into Revit easily and reliably.

While this process is manual, it is easy and with a little planning and coordination you should now be able to extract data from Revit, change it, spell check it, even add new associated values and then reinsert the data. Of course all the editing is taking place in an outside application, MS Excel. Now I want to make this perfectly clear, as I said before this is a manual process and those can be easily messed up because of our human tendency to err. I would much rather see these extractions to a simple data manager that allows automatic updates for data changes in the external data application, that way everything is always up to snuff, so to say.

In the second part of the solution getting the data back into Revit is as simple as selecting the BIMLink addon in the Revit menu bar, select the spreadsheet file you want to load and then presto! the data is added. At least that's what they want you to believe, but you have to know that the data format have to match up with the data elements defined already in the model, but that should go without saying.

So in the end, even our most novice users can learn how to use this software and get some really needed extended value out of B<I>M and make everyone's life easier.