<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
   <channel>
      <title>John Buletza&apos;s Weblog</title>
      <link>http://www.jandrconsult.com/blogs/john/</link>
      <description></description>
      <language>en</language>
      <copyright>Copyright 2006</copyright>
      <lastBuildDate>Thu, 31 Mar 2005 13:41:22 -0500</lastBuildDate>
      <generator>http://www.sixapart.com/movabletype/?v=3.2</generator>
      <docs>http://blogs.law.harvard.edu/tech/rss</docs>

            <item>
         <title>The Evolving Triangle</title>
         <description><![CDATA[<p>Most project managers and team members are familiar with the quality - cost - time triangle  see <a target="New" href="http://www.jandrconsult.com/blogs/brian/archives/2005/02/the_delicate_ba.shtml">The Delicate Balance</a>. It represents the dependencies between competing aspects of a project. Some models label the sides of the triangle as scope, cost and duration. But quality or compliance is always a factor for LIMS in regulated industries and these projects will usually label one side of the triangle with quality and monitor this aspect of the project throughout its lifecycle.</p>
<p>It is of course most common therefore, that a LIMS project will identify quality as the first priority. It represents a relatively inflexible aspect of a regulated LIMS since compliance is mandatory. This is why it is important to rate the importance of each of these three factors at the onset of a project. It is also important to recognize that the prioritization of these factors should represent a broad definition of the project priorities and cannot be applied without variations to all circumstances within the same project.</p>]]></description>
         <link>http://www.jandrconsult.com/blogs/john/archives/2005/03/the_evolving_tr.shtml</link>
         <guid>http://www.jandrconsult.com/blogs/john/archives/2005/03/the_evolving_tr.shtml</guid>
         <category>Project Management</category>
         <pubDate>Thu, 31 Mar 2005 13:41:22 -0500</pubDate>
      </item>
            <item>
         <title>Documentation for Its Own Sake</title>
         <description><![CDATA[<p>IT projects in the pharmaceutical industry require documentation. Although this may be the least favorable aspect of a project for a technical professional, it is a necessary part of the system delivered. Documented evidence of all aspects of the project is required by regulation to achieve a validated state. This should therefore be the primary objective of the documentation for any validated system. However, a secondary objective should be producing documentation that is less time consuming and adds greater value to the project.</p>]]></description>
         <link>http://www.jandrconsult.com/blogs/john/archives/2005/03/documentation_f.shtml</link>
         <guid>http://www.jandrconsult.com/blogs/john/archives/2005/03/documentation_f.shtml</guid>
         <category>Project Management</category>
         <pubDate>Tue, 01 Mar 2005 16:27:34 -0500</pubDate>
      </item>
      
   </channel>
</rss>
