<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Seth Gordon</title>
    <link>http://www.boxesandarrows.com/person/1235</link>
    <pubDate>Mon, 02 Jul 2007 12:03:21 GMT</pubDate>
    <description>Comments by Seth Gordon</description>
    <item>
      <description>&lt;p&gt;Many good points, especially the wrap-up about promotion after the success is achieved.&lt;/p&gt;

	&lt;p&gt;I&amp;#8217;ve gone through the evangelism and department building process more than once, with mixed results, but have learned each time.  The one thing that really helps moves things forward is establishing yourself as a credible resource that can deliver on the plan.  Once your organization believes that you are truly a subject matter expert on the topic, they become more inclined to support you.  Some things that I&amp;#8217;ve found help on the credibility front include:&lt;/p&gt;

	&lt;p&gt;having implemented a similar process elsewhere&lt;br /&gt;reading/writing articles and books &amp;lt;!&amp;#8212;which you just did!&lt;br /&gt;being well connected to your experienced peers.&lt;br /&gt;etc.&lt;/p&gt;

	&lt;p&gt;I remember 10 years ago I wanted to start a usability practice at the consultancy where I worked.  So, I talked to the bossman and told him my idea.  His general reply is &amp;#8216;what makes you such an expert in this field that I should support you in building out the practice&amp;#8217;.  Good question, and one that naively, I hadn&amp;#8217;t really given much thought outisde of reading Jakob Nielsen&amp;#8217;s book.&lt;/p&gt;

	&lt;p&gt;In the following months, I wrote a few articles, connected with peers in my local community, spoke at a CNet conference, and viola, I had some legitimate traction and street cred, which made people more willing to trust in my expertise.&lt;/p&gt;

	&lt;p&gt;Often times, it&amp;#8217;s more about the person than the process.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/pioneering-a-user#content_9214</link>
      <guid>http://www.boxesandarrows.com/view/pioneering-a-user#content_9214</guid>
      <pubDate>Mon, 02 Jul 2007 12:03:21 GMT</pubDate>
      <author>Seth Gordon</author>
    </item>
    <item>
      <description>&lt;p&gt;As an agency-type consultant, I like to take the value scoring a step further and assign a point value representing &amp;#8216;level of effort&amp;#8217; (LOE) to implement.  I use that label to measure whatever resources are required to roll out a given feature.  All projects I work on have some limitations in either time, money, resources, so it&amp;#8217;s necessary to capture key requirements early on.   With that information, a total project point value is established, say 1000 points.  The team then prioritizes features (value vs. effort) and has an allowance of points which they can use to purchase functionality / services.  Obviously, it&amp;#8217;s necessary to provide sufficient detail around each item purchased so that the team knows exactly what it is and how it works.  Being too vague in that definition step potentially causes more mayhem than it resolves.&lt;/p&gt;

	&lt;p&gt;A portion of the points need to be spent on foundational requirements / platforms, with the remainder being available for a la carte feature purchase.  The scoring and point assignment model can be as granular or relaxed as is needed.&lt;/p&gt;

	&lt;p&gt;here&amp;#8217;s an oversimplified example:&lt;/p&gt;

	&lt;p&gt;Corporate Blog = 50 points&lt;br /&gt;Faceted Navigation through product catalog = 200 points&lt;br /&gt;enhanced product imagery = 150 points&lt;br /&gt;order and account history = 100 points&lt;br /&gt;Product Rating System = 100 points&lt;br /&gt;spinning 3d corporate wireframe logo = 800 points&lt;br /&gt;photo of bosses wife on site = 20,000 points&lt;/p&gt;

	&lt;p&gt;As soon a team tries to spend more points than the project is alloted, they either need to expand project resources (essentially buy more points) or scale back features in the initial release.  This type of structure is the perfect response to the &amp;#8216;we want everything, now, for this low price&amp;#8217;.  I&amp;#8217;ve been in a lot of situations where the client wants to swap one piece of functionality for another, mid-stream.  by assigning &lt;span class="caps"&gt;LOE&lt;/span&gt; estimates from the start, it makes it easier to figure out which pieces are comparable.&lt;/p&gt;

	&lt;p&gt;While the above description may just sound like &amp;#8216;money&amp;#8217;, it&amp;#8217;s often easier to talk about resources in terms of a generic fixed unit.  I hate sitting in meetings saying &amp;#8216;sure, we can do that, but it costs more money&amp;#8217;.  For most of the agency projects i&amp;#8217;ve worked on, the &amp;#8216;checkbook&amp;#8217; isn&amp;#8217;t sitting in on the day to day meetings, so there&amp;#8217;s not much point in belaboring the point.&lt;/p&gt;

	&lt;p&gt;i certainly didn&amp;#8217;t invent this system, but can&amp;#8217;t recall the originating source.  Maybe I read about it at joelonsoftware.com.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/faceted-feature#content_10236</link>
      <guid>http://www.boxesandarrows.com/view/faceted-feature#content_10236</guid>
      <pubDate>Mon, 18 Feb 2008 23:08:27 GMT</pubDate>
      <author>Seth Gordon</author>
    </item>
    <item>
      <description>&lt;p&gt;it&amp;#8217;s also nice to be able to extract the IA from the dollars and cents discussions, since they generally aren&amp;#8217;t in meetings to play the role of account director.  But, many a wily client has tried to get the IA to commit to extra work without going through the appropriate change request project.&lt;/p&gt;

	&lt;p&gt;In the consulting business, conducting these scoping, prioritization, and negotiation activities/workshops during discovery  is valuable and billable work.  Or, include those discussions during the biz dev effort and recapture the costs in more efficient project delivery works&lt;/p&gt;

	&lt;p&gt;Terry &amp;#8211; how do I determine points?  It can sometimes be done by phase, I like to separate upfront exploration from build. Here&amp;#8217;s a rough and arbitrary value I use to determine what the resource/point burn rate is per week.  This is optimized for T&amp;#38;M projects.  I use a different approach for fixed bid / value pricing.&lt;/p&gt;

	&lt;p&gt;200 points per billable week (80% billable) for a practitioner level (developer, ia, business analyst, etc)&lt;br /&gt;300 points per billable week for a senior level&lt;br /&gt;350 points per billable week for a Lead (mostly oversight rather than production)&lt;br /&gt;then I throw in a 20% overhead for project management / reporting and ~25% for QA&lt;/p&gt;

	&lt;p&gt;Great book called Managing The Professional Service Firm by David H. Maister that talks about proportions of Jr/Sr practitioners.&lt;br /&gt;&lt;a href="http://www.amazon.com/Managing-Professional-Service-David-Maister/dp/0684834316" rel="nofollow"&gt;http://www.amazon.com/Managing-Professional-Service-David&amp;hellip;&lt;/a&gt;&lt;/p&gt;

	&lt;p&gt;Total points available just tend to be a product of time x money.&lt;/p&gt;

	&lt;p&gt;make it as crazy or as simple as you&amp;#8217;d like.  for level of effort, I tend to use 3 categories Easy (1x), Medium (3x), and Hard (5x).&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/faceted-feature#content_10254</link>
      <guid>http://www.boxesandarrows.com/view/faceted-feature#content_10254</guid>
      <pubDate>Thu, 19 Jul 2007 05:44:05 GMT</pubDate>
      <author>Seth Gordon</author>
    </item>
    <item>
      <description>&lt;p&gt;Terry &amp;#8211; planning on doing a written article that is mostly driven by the direct answers from our respondents.  If we&amp;#8217;re formally selected, I&amp;#8217;ll put up another poster asking people to recommend mangers they&amp;#8217;d like to hear from.   We&amp;#8217;ll be sure to include a few open ended questions where managers can ask ones like you&amp;#8217;ve proposed.  Maybe we&amp;#8217;ll just ask &amp;#8216;what makes you special&amp;#8217;.  :-)&lt;/p&gt;

	&lt;p&gt;-Seth&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/9951#content_10339</link>
      <guid>http://www.boxesandarrows.com/idea/view/9951#content_10339</guid>
      <pubDate>Fri, 20 Jul 2007 00:22:44 GMT</pubDate>
      <author>Seth Gordon</author>
    </item>
    <item>
      <description>&lt;p&gt;I have a lot of books in my &amp;#8216;to read&amp;#8217; pile, but Glut went straight to the top.  I knew it was going to be well researched and insightful, but I was surprised at how much fun I had reading it.  I&amp;#8217;m a big fan of arcane knowledge and quotable tidbits, and this book was full of both.  Thanks to Alex for unearthing this knowledge that I now dispense liberally.  i&lt;/p&gt;

	&lt;p&gt;Hard to think of a page-turner in the field of information management, but one exists, and Alex Wright wrote it.&lt;/p&gt;

	&lt;p&gt;I&amp;#8217;m not a big one for building a personal library.  i usually read a book, then gift to a friend with the condition that they then pass it on.  In this case, you may borrow my copy of Glut, but it needs to be returned to me.  It&amp;#8217;s a keeper!&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-hidden-history#content_12873</link>
      <guid>http://www.boxesandarrows.com/view/the-hidden-history#content_12873</guid>
      <pubDate>Mon, 08 Oct 2007 20:34:32 GMT</pubDate>
      <author>Seth Gordon</author>
    </item>
  </channel>
</rss>
