<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Comments on Tackling Maintenance Projects</title>
    <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects</link>
    <pubDate>Fri, 26 Jan 2007 14:53:05 GMT</pubDate>
    <description>A typical maintenance project goes something like this: someone has a new piece of functionality or content they want to put up on the website. The IA&#8217;s job: find the best place for it. </description>
    <item>
      <description>&lt;p&gt;Hi dan,&lt;br /&gt;there are maintenance projects where issues are not frequent and not complex also. What will help team to keep busy &amp;#38; motivated?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_3348</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_3348</guid>
      <pubDate>Fri, 26 Jan 2007 14:53:05 GMT</pubDate>
      <author>Malashree J D</author>
    </item>
    <item>
      <description>&lt;p&gt;Unfortunately, I don&amp;#8217;t. My experience with dedicated maintenance teams is pretty limited. My maintenance work has always (thankfully) been mixed in with new project work. I imagine there are a lot of burn-out issues that occur with teams who deal strictly with maintenance projects&amp;#8230;&lt;/p&gt;

	&lt;p&gt;Dan&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_950</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_950</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:48 GMT</pubDate>
      <author>Dan Saffer</author>
    </item>
    <item>
      <description>&lt;p&gt;I&amp;#8217;m glad my article spoke to you all!&lt;/p&gt;

	&lt;p&gt;By the way, if you are interested in seeing what some Down N Dirty wire frames look like, I have a set that contains a few posted on my website at &lt;a href="http://www.odannyboy.com/datek/margin_enhancements.pdf" rel="nofollow"&gt;http://www.odannyboy.com/datek/margin_enhancements.pdf&lt;/a&gt;&lt;/p&gt;

	&lt;p&gt;Dan&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_949</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_949</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:48 GMT</pubDate>
      <author>Dan Saffer</author>
    </item>
    <item>
      <description>&lt;p&gt;Kudos to Dan for his down n&amp;#8217; dirty approach to wireframes. You&amp;#8217;ve seemingly helped a group of smart designers realize they&amp;#8217;ve been doing IA work without a net and it works. They simply recognize poor interaction design based on common senses like comfort, necessity and intuition, and demonstrate solutions quickly using whatever means possible. With a bit of business understanding and a proactive spirit these designers will be increasingly more effective and therefore more valuable to the organization but more importantly, the user.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_948</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_948</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:48 GMT</pubDate>
      <author>David Reid</author>
    </item>
    <item>
      <description>&lt;p&gt;I liked reading this because,as a &amp;#8216;large agency IA&amp;#8217;, the most challenging projects that I have worked on have been the &amp;#8220;maintenance&amp;#8221; projects&amp;#8230;they can be extremely difficult! So, if the old adage hold true that &amp;#8216;misery loves company&amp;#8217; it is nice to hear that others have similar struggles.&lt;/p&gt;

	&lt;p&gt;Maintenance is just a fact of life on large sites that are driven by metrics and changing business environments. It is, 9 times out of 10, driven by changing business requirements&amp;#8230;hardly ever by end user requirements!! Just a fact of life and sometimes part of what we have to do.&lt;/p&gt;

	&lt;p&gt;It isn&amp;#8217;t IA in the purest sense, but implementing maintenance changes is pretty heavily IA dependent nonetheless.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_947</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_947</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:48 GMT</pubDate>
      <author>H. Galloway</author>
    </item>
    <item>
      <description>&lt;p&gt;Maybe IAs who work in agencies are in a position to sink their teeth into a big project but I think in-house IAs tend to tackle maintenance projects as their daily bread and butter. One reason is cost &amp;#8211; it takes time and money and co-operation with various other departments within a company to start a new project on such a scale that it has a beginning and an end (a redesign for example or perhaps an offshoot of the main site).&lt;/p&gt;

	&lt;p&gt;Not wanting to start a discussion over which is harder, but I think there are more pitfalls when tackling maintenance projects. Often, an IA has no idea what&amp;#8217;s coming round the corner in two, three or four months (sometimes weeks) time. The business could feed in projects that require a massive increase in the size of the site &amp;#8211; the IA has to fit this into the current architecture while considering the scalability of the site for future, and often unknown, projects. Of course it will be up to the IA to feed recommendations back into the business to tell them that the current architecture will no longer support the business requirements that the site has to meet. Quite often, the business does not care. Sort it out, do what you can but don&amp;#8217;t ask us to fund a complete redesign.&lt;/p&gt;

	&lt;p&gt;I think there are a lot more &amp;#8220;Maintenance Information Architects&amp;#8221; out there than what we think there is. As to whether we need to split IAs like this &amp;#8211; I&amp;#8217;m not sure. There are different skills required for each but IA is already a specialism &amp;#8211; do we want to further specialise within a specialism? No &amp;#8211; especially when it&amp;#8217;s hard enough for IAs to get jobs as &amp;#8220;Vanilla Information Architect&amp;#8221;. I&amp;#8217;d settle for saying there are two types of IA work &amp;#8211; maintenance and life-cycle. I&amp;#8217;d love to do an equal mix of both.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_946</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_946</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:48 GMT</pubDate>
      <author>Paul Nattress</author>
    </item>
    <item>
      <description>&lt;p&gt;I&amp;#8217;d hate to see IAs split up like that. I&amp;#8217;d hope that all IAs get a mix of full projects and a few maintenance projects (although not too many).&lt;/p&gt;

	&lt;p&gt;I will say that maintenance projects might be good  for beginning IAs to cut their teeth on&amp;#8230;for a while. But to really sink your teeth into a big project from beginning to end is really the best situation all around.&lt;/p&gt;

	&lt;p&gt;Glad you liked the article.&lt;/p&gt;

	&lt;p&gt;Dan&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_945</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_945</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:48 GMT</pubDate>
      <author>Dan Saffer</author>
    </item>
    <item>
      <description>&lt;p&gt;Dan,&lt;/p&gt;

	&lt;p&gt;Thanks for the article &amp;#8211; this accurately describes the type of IA/content work that I&amp;#8217;ve been doing since getting into this specialism. For a while I&amp;#8217;ve been thinking to myself &amp;#8220;I&amp;#8217;m not working on controlled vocabularies or thesauri so am I doing *real* IA?&amp;#8221;&lt;/p&gt;

	&lt;p&gt;Perhaps we should split &amp;#8220;Information Architect&amp;#8221; into several sub-titles &amp;#8211; &amp;#8220;Maintenance Information Architect&amp;#8221; for those who do the work described in this article and &amp;#8220;Full Life-Cycle Information Architect&amp;#8221; for those who get to see a project from concept to completion (and perhaps through a redesign too?)&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_944</link>
      <guid>http://www.boxesandarrows.com/view/tackling_maintenance_projects#content_944</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:48 GMT</pubDate>
      <author>Paul Nattress</author>
    </item>
  </channel>
</rss>
