John Buletza's Weblog tag:www.jandrconsult.com,2006:/blogs/john//6 2005-09-25T21:08:10Z Movable Type 3.2 The Evolving Triangle tag:www.jandrconsult.com,2005:/blogs/john//6.36 2005-03-31T18:41:22Z 2005-09-25T21:08:10Z Most project managers and team members are familiar with the quality - cost - time triangle see The Delicate Balance. 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. 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.... John Buletza Most project managers and team members are familiar with the quality - cost - time triangle see The Delicate Balance. 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.

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.

]]> Every project, other than those of a very small scope, will evolve over time. With that evolution will inevitably come a change in the triangle. A project that spans years, or other form of budget cycles, will typically experience a change in the project funding. There will be periods were costs must be reduced. This will result in an effort to shrink the cost side of the triangle. Certain costs may be postponed or deferred and some costs will be reduced. It is most common to see a reduction in the number of external resources since these will result in a reduction of capital or operating expenditure.

Just as common is another stage in a project where time becomes the primary objective. Certain deliverables are needed by specific dates to meet business objectives or commitments. During this phase the resources will typically increase or at least be focused on specific tasks.

It is also likely that at yet another stage, quality/scope will again take precedence. A certain aspect of the project, a report for example, will be found to be less than ideal to meet its intended objectives. It is important to then alter the scope to retain its value towards the project as a whole.

It is therefore important to recognize that priorities assigned to a project at inception must evolve over time, as do all other aspects of a project. The priorities defined at the start of a project, cannot be expected to apply explicitly to all aspects of a project or throughout all phases of a project. It must be understood and managed based on the individual circumstances of a particular phase or aspect. In the end this will prove to be the successfulness of any project, its ability to adapt over time to changes or specific details. The overall priorities of the triangle should be maintained but will always have to be adjusted; constantly balancing conflicting sides of the triangle to meet the needs of a project phase or the detailed objectives of specific design elements. In reality, it may be best to think not of a single project triangle, but a complex hierarchy of project triangles representing various stages or aspects of the project. It its entirety, this hierarchy should comprise the corresponding sides of the overall project triangle and priorities.

]]> Documentation for Its Own Sake tag:www.jandrconsult.com,2005:/blogs/john//6.20 2005-03-01T21:27:34Z 2005-09-25T18:12:20Z 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.... John Buletza 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.

]]> Too often the objective for producing documentation becomes its own justification- documenting for the sake of the requirement to document. This will inevitably lead to poor quality documentation and more effort. How often have we seen a requirements document produced at the wrong stage in a process because poor planning failed to produce the right content for requirements at the right stage in the project? Poor documentation will always result in additional work as well. A design specification can not hope to document design of a well built, validatable system unless it can draw corollary to the functional and user requirements. Likewise, a validation protocol can not be conceived at the validation phase. Poor validation protocols can attempt to verify that a system functions as it was designed. But without the foundation of acceptance criteria in the user requirements and functional specifications, it can never prove that the system performs as intended. When all the pieces of documentation don’t fit together in their correct chronological order and with appropriate content, then the entire team inevitably becomes encompassed in the tasks of trying to make the pieces fit retrospectively.

Project documentation must start at the beginning and follow a sound plan. Each document must be constructed with appropriate scope and content consistent with that plan, always looking forward to the needs of the next document or next project phase. Documentation can also not be left to the validation team. The entire team must contribute to, review and be thoroughly familiar with each document. Team members from all involved areas, users, customers, developers, testers, quality, IT, project managers, and senior management must recognize documentation as part of their responsibility and actively participate in each.

]]>