<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="https://www.stress-free.co.nz"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>stressfree - industry need</title>
 <link>https://www.stress-free.co.nz/tech/industry_need</link>
 <description></description>
 <language>en</language>
<item>
 <title>The thesis aim: Industry applicability</title>
 <link>https://www.stress-free.co.nz/the_thesis_aim_industry_applicability</link>
 <description>
  &lt;div class=&quot;field-body&quot;&gt;
    &lt;p&gt;The last couple of months have been difficult as I have tried to focus on the problem of satisfactory testing the Project Information Cloud concept. This process has required I nail down my aim and hypothesis so that whatever methodology was decided on would ensure the overall ambitions and specific requirements of the thesis were met. Initially my aim focused on improving the access, timeliness and relevance of the information available to project participants however this posed problems around the semantics and testability of ‘relevance’. Relevance can mean many things to many people and is also dependent on time. Something relevant to me now may not be relevant later but that same thing could be very relevant to you later on but of completely no value at the present. Consequently determining a reasonable and sound methodology for testing relevance was proving to be difficult.&lt;/p&gt;&lt;p&gt;The issue with testing relevance is establishing a viable control sample and locking down the constraints between the control and test samples to the point where the test becomes repeatable. Relevance is like hindsight, it is something you only know after the fact and as a consequence the relevance of data is usually dependent on a number of variables such as the person, situation, time constraints and the interface to the data. As a result I began to feel any test for relevance, be it through case studies, model based testing, prototyping or thought based experiments would end up testing these other factors more than the concept of the Project Information Cloud.&lt;/p&gt;&lt;p&gt;Mike and I talked about this a couple of Fridays ago during one of our weekly meetings. He raised a good point which was that one the seemingly forgotten origins of the research was that whilst the ‘Building Information Model’ approach was completely viable its timeframe for industry-wide adoption was very large. This long-term adoption process did not solve the industry’s short-medium term information management issues and if for some reason BIM failed to take hold as many felt it would AEC professionals would be left using the same basic collaboration and information management tools that they have been struggling with at the present time. Hence the primary underlying objective of the research was to propose and prove a method of improving the access and timeliness of project information that can be applied within todays current industry conditions.&lt;/p&gt;&lt;p&gt;Establishing ‘applicability’ as an aim instead of ‘relevance’ achieves two things. Firstly it grounds the research within the current AEC industry instead of setting it apart as some hypothetical and generalised project/information management thought experiment. This is important because after all this is an architecture thesis and should first and foremost be about an architecture problem not a series of general knowledge management concerns. Secondly by focusing on applicability rather than relevance it opens up a whole field of thought and prototype style experiments related to the Web and getting the concept to work in ‘practice’ (both in the real world and architecture sense). Following the applicability route allows the generation of far more specific and to the point conclusions, for example “this concept would work in contemporary practice given the following criteria are meet and these processes followed”. &lt;/p&gt;&lt;p&gt;Following this line of investigation also brings into focus the importance of not creating another Building Information Model concept in the sense that it should be immediately applicable and also not just a Web-enabled Building Information Model. Using this line of thought there are a number of Web-orientated conceptual and technical tests that can satisfactory test the immediate applicability of a Web-based, distributed Project Information Cloud. If it can be shown that the concept meets the requirements laid out by notable researchers such as Tim Berners Lee&#039;s &lt;a href=&quot;http://www.w3.org/DesignIssues/Principles.html&quot;&gt;Principles of Design&lt;/a&gt; then it can be argued that the concept would have a practical and immediate future within the Industry. Using this testing method it gets around the ever-present user-interface issues that exist when performing prototype or discussion group style experiments. In these scenarios often what ends up being tested is the quality of the human interface rather than the benefits or drawbacks of different practical solutions. &lt;/p&gt;  &lt;/div&gt;

&lt;ul class=&quot;field-taxonomy-vocabulary-1&quot;&gt;

      &lt;li&gt;
      &lt;a href=&quot;/thesis&quot;&gt;thesis&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/methodology&quot;&gt;methodology&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/industry_need&quot;&gt;industry need&lt;/a&gt;    &lt;/li&gt;
  
&lt;/ul&gt;
</description>
 <pubDate>Tue, 29 Aug 2006 00:16:00 +0000</pubDate>
 <dc:creator>David</dc:creator>
 <guid isPermaLink="false">300 at https://www.stress-free.co.nz</guid>
</item>
<item>
 <title>Some Quick Questions</title>
 <link>https://www.stress-free.co.nz/some_quick_questions</link>
 <description>
  &lt;div class=&quot;field-body&quot;&gt;
    &lt;p&gt;In order to test my assumptions regarding the digital habits of New Zealand architecture practices I put together a few questions and informally emailed a number of my friends. Thanks to the power of the forward button I got many more responses than I hoped. Below is the five quick questions I asked with the intention of justifying my own position on the subject matter:    &lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-style: italic&quot;&gt;1. When dealing with design variations (at a conceptual or development level) do you work on the same file or create a new file and keep the other versions for reference?&lt;/span&gt;    &lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-style: italic&quot;&gt;2. Do you ever find yourself searching for information in a current project or an older one?&lt;/span&gt;    &lt;br /&gt;&lt;span style=&quot;font-style: italic&quot;&gt;    If so what do you normally end up doing to find this information? (eg. ask everyone nearby and then give up)&lt;/span&gt;&lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-style: italic&quot;&gt;3. How do you track the hours that you&#039;ve worked on a project (manually, Excel file, Outlook, special program)?&lt;/span&gt;    &lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-style: italic&quot;&gt;4. Does your office share digital files with clients/contractors and if so are these files specially prepared or copies of your working files?&lt;/span&gt;    &lt;/p&gt;&lt;p&gt;&lt;span style=&quot;font-style: italic&quot;&gt;5. When dealing with digital files (CAD/images/documents) what backup method do you employ? (if you don&#039;t know that&#039;s fine)    &lt;br /&gt;&lt;/span&gt;&lt;/p&gt; &lt;h2&gt;Findings    &lt;br /&gt;&lt;/h2&gt; &lt;p&gt;Thanks to the email forwarding tool I received many more replies than I originally envisioned from a range of architecture practices not only in Wellington but around New Zealand. Fortunately the answers I received were satisfyingly similar. They were satisfying in the sense that it proved to myself that my personal assumptions acquired through experience in the industry were correct plus most were very similar which meant drawing generalized conclusions was relatively easy.    &lt;br /&gt;&lt;/p&gt;&lt;h4&gt;1. Design Variations&lt;/h4&gt;Design variations were handled in generally the same manner but applied slightly differently across the different practices. In general a new version of the design (CAD) file is created when a major design change takes place. Whether this new file was archived or worked on as the current project file varied greatly. No respondents used any of the variation options available within the CAD programes (or a third party versioning system). All kept their variation system simple and many smaller variations were proposed within the same file (with the design details dated). Folder structure in this process is very important in most of the practices as it provides the primary means of distinguishing different projects, concept/development and sometimes even design variations.    &lt;br /&gt;&lt;h4&gt;2. Searching for Information&lt;/h4&gt;When it came to searching for information scouring print documentation was identified as being the easiest and most commonly used avenue for researching. In some cases old information was not kept onsite which made locating old design information very difficult. Other people in the office were the most valuable resource, generally if the user could not find an answer within the current working document other people in the office related to the project were questioned before any further searching took place.    &lt;br /&gt;&lt;h4&gt;3. Time Tracking&lt;/h4&gt;The most obvious finding was that Excel is used extensively to track time spent on projects. Excel is arguably one of the biggest scourges in any IT environment. It is widely used by people for a variety of uses but as far as sharing, searching or managing this data the Excel solution is highly problematic.    &lt;br /&gt;&lt;h4&gt;4. Information Sharing&lt;/h4&gt;File sharing between organisations was a common practice. Many exchanged raw CAD files (usally in dwg format) whilst others exported to a neutral, change resistant format such as PDF before sending to a third party. In most situations, especially where a special export file was generated, a copy of the exchanged file was kept locally for future reference.    &lt;br /&gt;&lt;h4&gt;5. Data Backups&lt;/h4&gt;Backups were undertaken at least weekly if not daily. Many Practices backed their data up to CD (which is a highly unreliable backup medium) whilst a few trusted this task to a third party tape/hard drive solution. In these instances if an archived file was required the third party would need to be contacted in order to retrieve the required file from the archive.    &lt;br /&gt;The informal survey confirmed my assumptions regarding several IT practices in Wellington&#039;s architecture community. Comparing these findings to the discussions on the NZIA email discussion list it would be relatively safe to assume these processes are very similar to those in use around New Zealand.    &lt;br /&gt;&lt;br /&gt;&lt;p&gt; &lt;/p&gt;   &lt;/div&gt;

&lt;ul class=&quot;field-taxonomy-vocabulary-1&quot;&gt;

      &lt;li&gt;
      &lt;a href=&quot;/thesis&quot;&gt;thesis&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/questions&quot;&gt;questions&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/industry_need&quot;&gt;industry need&lt;/a&gt;    &lt;/li&gt;
  
&lt;/ul&gt;
</description>
 <pubDate>Tue, 22 Nov 2005 01:38:30 +0000</pubDate>
 <dc:creator>David</dc:creator>
 <guid isPermaLink="false">170 at https://www.stress-free.co.nz</guid>
</item>
<item>
 <title>So what need is this research fulfilling?</title>
 <link>https://www.stress-free.co.nz/so_what_need_is_this_research_fulfilling</link>
 <description>
  &lt;div class=&quot;field-body&quot;&gt;
      &lt;p&gt;I often wonder what the &lt;a href=&quot;http://news.bbc.co.uk/1/hi/business/3666241.stm&quot; title=&quot;Google Founders on BBC&quot;&gt;Google founders&lt;/a&gt; were researching at University and if it had anything at all to do with Google or Internet search. Assuming they did and they decided to tackle the problem of &#039;relevant search&#039; I am then left wondering how do you academically describe &#039;relevant&#039; in a way that is testable.    &lt;br /&gt;&lt;br /&gt;My direction has been set primarily by a bunch of observations gathered from a number of other issues in the modern AEC environment. There are some clearly identified issues with the rigidness of the briefing process that are an ongoing concern within the industry. An issue I have been grappling with is how brief requirements and conceptual issues can be maintained and reevaluated throughout the design and construction process. Following a traditional process a briefing document is prepared and the architect responds to this with a set of working drawings. Other participants (contractors, engineers and consultants) typically only interact with these formal working drawings or the completed work. As a consequence of this reinterpretation the consumers (client/occupants) find it difficult to change their requirements whilst the producers are left with a partial understanding of the overall intentions and evolution of the project.    &lt;br /&gt;&lt;br /&gt;Solving this problem is reliant on clear and consistent communication. A major issue in communicating architectural ideas is the language in which this conversation takes place. An obvious focus for this debate is the richly detailed computer models that constitute a large portion of contemporary project documentation.  Building Information Model (BIM) theory is attempting to establish a unified &#039;model&#039; in which the life-cycle of of building can be tracked and monitored. Unfortunately the structured nature of this model makes capturing and relating informal conversation about a project very difficult and time consuming as fitting these snippets of information into a highly structured model is very difficult (and adapting existing models to suit informal structures impossible).    &lt;br /&gt;&lt;br /&gt;Compounding the BIM advocates is the limited degree of Information Technology uptake throughout the AEC industry. Whilst proposing the use of highly technical BIM&#039;s may suit the management tier of a project (architects, engineers and consultants) it does not &#039;downsize&#039; well into the production arena where technology skills and resources are low or enable those unaccustomed to the concept (clients and occupants) to participate at an even level. What is required is a lowest common denominator means of transferring and storing this informal conversation in a manner that facilitates later reuse in the design process or within a much higher level Building Information Model.    &lt;br /&gt;&lt;br /&gt;These issues all fall under the general umbrella of &#039;knowledge management&#039; which is a formal term for &#039;stuff we should really note down and hopefully don&#039;t forget&#039;. Whilst at the Manchester conference last year I sat through many (rather dull) presentations about the subject and how it fitted into the AEC industry. Given the level of interest at academic and even professional levels there is obviously some demand for knowledge management but I think it should be known more appropriately as information reuse. Knowledge is something that you have learnt over time through the process of doing and parsing different information sources.  &lt;/p&gt;  &lt;p&gt; &lt;/p&gt;   &lt;/div&gt;

&lt;ul class=&quot;field-taxonomy-vocabulary-1&quot;&gt;

      &lt;li&gt;
      &lt;a href=&quot;/thesis&quot;&gt;thesis&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/concept&quot;&gt;concept&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/industry_need&quot;&gt;industry need&lt;/a&gt;    &lt;/li&gt;
  
&lt;/ul&gt;
</description>
 <pubDate>Tue, 25 Oct 2005 02:51:10 +0000</pubDate>
 <dc:creator>David</dc:creator>
 <guid isPermaLink="false">157 at https://www.stress-free.co.nz</guid>
</item>
</channel>
</rss>
