The Twelve Towers - A Project Management Novel: Excerpt 2 – Identify Stakeholders

Written by Bruce Fieggen - VP of Project Management & Training

Below is the second excerpt from the Project Management novel Bruce Fieggen, QPharma’s V.P. of Project Management, is writing in his ‘spare time’. The book follows the Project Management Body of Knowledge Guide (PMBOK) but uses the format of a novel, and promises to be much more readable. The novel tells the story of a Gwilym, a Project Manager, charged with building twelve towers scattered throughout King Arthur’s Britain. Gwilym’s oldest son, Bleddyn, also appears in this excerpt. There is some overlap between this excerpt and the one posted November 1 2010, so you can see where it fits in the novel. 

Readers, think about the various projects you are tasked with and see how you can use the tools shown in these blog posts to assist you in ‘building your towers’.

This second excerpt shows the development of the second tool: The Stakeholder List.

 King Arthur stood, gravely shook Bleddyn’s hand, then Gwilym’s and told them he would be keeping a close eye on this tower and on them. “And there is no need to worry about Tarrant. I didn’t trust those beady eyes when he came here. You, I trust.”

Gwilym and Bleddyn were asked to join in the feast in exchange for a tale to add to the merriment. He told a story of his travels as a young man. “I was in a bazaar in an Arab town near the Holy Land”. This caught all the knights’ attention. “The men there sold their wares to all comers and it was to their advantage to guess the language of their customers as they walked by and to speak to them in that language with what little they could pick up. I passed a seller of brass-works in a street full of brass. He looked at me, smiled and shouted, in highly accented English, ‘Just looking! Just looking!’ He must have heard these words so many times from other Englishmen he became sure this was a greeting of some kind.”

The knights roared in laughter and toasted Gwilym, begging for more stories. He obliged them once, then turned the conversation back to them and listened to their stories until he saw his son stifling his third yawn. “I must return early on the morrow, gentlemen. Thank you so much for your hospitality. My king; thank you for the royal charter. I shall not disappoint you.”

Bleddyn walked by his father’s side on their way to the tavern, looking up at him with a new respect. “Did you really have those adventures, Da? I never knew you had traveled so far. Was I with you?”

“No lad. That was during my misspent youth. I did many dangerous and fool-hardy things at that age that I don’t want you to try. Please forget the stories.”

“But Da, what did your father say about the things you did while you were traveling?”

“My Mother and Father were dead when I was quite young. I did no-one else’s bidding at that age.”

                           ___________________________

At the second cock crow, they left Caerleon, arriving at the ferry dock in time to see the boat approaching from Brycgstow. While they waited, Bleddyn asked his father about the charter.

“It’s a document that describes the project to everyone who cares about it. That way there can be no arguments about what to do. It’s also a contract between all the people who work on the project and King Arthur. And that includes me. I have to make sure I build it for the amount of silver I promised and as quickly as I promised.”

“Who are all these people who care about the project?”

“The quarryman is one. He’s the one who started this whole thing and caused me to make up the charter. I’ll be looking forward to showing him King Arthur’s signature. But there will be others who argue in the future and I can show them the charter at that time.”

“Why not show them the charter first, Da, before they make any trouble?” Bleddyn questioned. “That might save some time.”

“That’s a grand idea, son! Let’s make a list of everyone we should show it to while we wait. There are all the builders on the site, Father Drew, the quarryman, the bishop, the forester, the masons, the carter, the village chief, the inn-keeper who brings food to the site. Who else?”

“What about Tarrant?”

“Now that’s an interesting point. I should also be thinking of people who want the project to fail. I’ll have to keep them in mind for this list of people who care. Though I may not go out of my way to find him, I’ll keep the charter safe so I can show him if he argues again. It clearly says who’s in charge.”

“What do you call this list of people, Da?”

“They are all people who have a stake in this project, one way or another. I’ll call it a list of ‘stakeholders’ then.”

The ferry arrived and they made their way back to Brycgstow and spent the rest of the day and night there. Gwilym hobbled from square to square, sitting down in each and allowing Bleddyn to explore each place. He was exhausted when they returned to the tavern and fell immediately to sleep. Bleddyn, his mind racing from all he’d seen, lay awake for another hour, and then fell into a contented sleep.

They arose early again and rode as fast as Gwilym was able to the quarry near Huish, and found the quarryman hard at work in the pit.

LabWare LIMS Validation

Written by Kimberly Stanton - Associate, Validation Manager

As with all LIMS applications implemented in regulated environments, LabWare LIMS implementations must go through Validation prior to being released for routine use. LabWare implementations present unique challenges due to the ability for companies to create complex static data and work-flows, configure many different Sample Types, manage Standard/Reagents, manage Equipment/Instruments and the ability implement Stability Studies.

A Validation Plan for any LIMS implementation must be created to detail the Purpose, Scope, Deliverables, Responsibilities and the Acceptance Criteria to release the new LIMS application in the Production environment for routine use. If the LIMS application is to be installed in multiple sites with different hardware and potentially different requirements due different regulatory constraints or business work-flows it maybe necessary to create more then one Validation Plan.

User Requirements for a LabWare LIMS application should document the following to ensure a smoother implementation and Validation effort: 

• All applicable Regulatory requirements 
• System Administration requirements 
• Multiple Site requirements if applicable 
• Laboratories that will be utilizing the new LIMS application 
• User Roles that will need to be implemented 
• All Sample Types that will need to be implemented 
• Work-flows to include Lots, Samples, Projects, Batches and Stability as applicable 
• Test Methods functionality must be documented, however, since the amount of Test  Methods that will need to be documented will vary, the use of an Appendix to the URS or a reference to Data Migration plan may be considered  
• Product Specification functionality must also be documented and similar to Test Methods mentioned above if there are many Product Specifications to be implemented an Appendix or Data Migration plan reference may be considered 
• Reports to include Certificate of Analysis, Standard and Reagents, Stability Results, and any other applicable reports 
• Any Interface requirements such as Instruments, SAP, TrackWise, etc. 
• Standard Operating Procedures applicable to the LIMS implementation

A Risk Assement(s) should be created to determine the Risk Level of the Requirements documented for the LIMS application. Risk Levels will help determine the level of testing that will need to be performed, Standard Operating Procedures that should be created and the level of Training that should be conducted. For example if there is Requirement that has a high Impact if it fails, high Probability that it will fail (mainly if it is a configured or customized part of the application) and Data Integrity could be impacted if the Requirement fails, testing activities would include Unit Testing, Operational Testing and Performance Testing. A corrective action for this Requirement could be User Training and Standard Operating Procedure development. If a Requirement is considered less of Risk if it fails, for example a core part of the LIMS application that satisfies the Requirement, testing may not even be necessary if the company implementing the application is satisfied with the level of testing LabWare performs on their core product, this would be verified during a Vendor Audit or minimal testing in the Operational Testing could be conducted.

Considerations regarding how to document Design/Configuration Specifications should be planned, since the complexity of a LabWare implementation can vary it may be helpful to create multiple Design/Configuration Specifications. For example a separate Design/Configuration Specifications for System Administration, Material Management, Lot Manager, Batch Manager, Project Manager, Sample Manager, Stability Manager and any applicable Interface functionality maybe a good approach. This approach will need special attention from the Project Manager since managing multiple documents can be very difficult.

One of the most overlooked pieces of a LabWare implementation is Static Data planning, configuration, verification and process testing. Static Data, depending on the Data’s complexity can be as or sometimes more complicated then the software piece of the LabWare implementation.

A Data Migration plan is key to Static Data planning, the plan should include references to all of the Static Data that will be implemented into LabWare, the instance (environment of the application) the Data will be configured in, how the configuration of the Static Data will be documented (separate Design Spec to include LIMS Basic Code design) and how the Data will be verified prior to being imported into the Validation (and Training environment if applicable) environment.

As with other LIMS and regulated applications implementation there should be multiple instances (environments) of the application one for software development, one for Static Data development, one for Validation testing, and the Production environment. It is also recommended that a Training environment is available, the Training environment should include verified Static Data for the new Users to train with. If it is not possible to obtain a Training environment one of the Development environments can be used as the Training environment as long as verified Data is available and software developments/updates are not taking place during training sessions.

The Validation and Production environments must go through an Installation Qualification. It is not required that the Development or Training environments go through an Installation Qualification, however, there must be adequate controls in place that ensures that any software changes or Static Data updates are implemented into all of the environments that are not required to go through IQ verification.

Since LabWare implementations can be very ‘data centric’ careful consideration must be made regarding what Static Data will be used during testing, if the Static Data has not been setup correctly any testing conducted has a potential of failing due to the Data. For example say a Product Specification that has Test Method that cannot be completed unless the Sample the Test Method is associated to is added to a Batch and the Quality Control Samples are not properly configured in the Batch Protocol has been selected for testing, the Sample will never be able to be Reviewed or Approved and the Lot the Sample is associated to cannot be approved if the Sample is not Approved the testing will fail.

Also, careful considerations on Requirements that may require special Static Data setup must be made. If a script requires the tester to verify that a Result entered on a Component of Test Method can be canceled, the Test Method selected for testing must have ‘Allow for Cancel’ option selected in order for the Result(s) to be canceled. If the configuration of the Static Data is not correct the script will fail.

Prior to formal Validation testing informal Unit Testing maybe considered, informal testing can minimize deviations either caused by system inconsistencies (nice way of saying Bug) or script errors. The Unit Testing can be conducted with Operational Qualification scripts created by the Validation team. This also provides the testers the opportunity to learn the system and become familiar with Test scripts that will be executed during the Operational Qualification.

The Operational Qualification testing phase for a LabWare implementation should include functional and negative testing much like any other Validation project, however, a LIMS OQ can be a large undertaking due to the complexity of the configurations of the Software and Static data, therefore, multiple testers (preferably from different Labs) should be used to reduce the amount of time it takes to execute OQ test scripts. Since the training of the testers on the new LabWare application maybe limited it is important for the OQ scripts to be created using a ‘point and click’ methodology, this will make the execution effort easier for the testers.

User Training must be conducted prior to the Performance Qualification testing phase of the LabWare implementation. Training tailored to the individual Labs may help be a better alternative as oppose to large Training sessions that include all users. Since the Labs using the new LIMS application will have different access to functionality of the system an overall Training session may confuse Users. For example let’s say if one Lab will primarily do their work in the Batch Manager and they do not have access to Lot Manager, Training on Lot Manager will be lost on them.

Performance Qualification testing can either be conducted in a simulated Production environment of the LabWare application or in a live Production environment depending on the confidence level of the implementation. If the Performance Qualification is conducted in a simulated Production environment it recommended that Performance Monitoring testing phase is conducted once the application is considered approved for routine use. Critical business/regulatory processes and Products/Testing for all Laboratories involved with the new LabWare application should be included in any Performance Qualification testing phase to ensure the new LIMS application is meeting all business and regulatory needs.

A Traceability Matrix is recommended to ensure testing coverage, corrective actions for non testable requirements and/or reasoning for lack of testing for all User Requirements documented for the LabWare LIMS implementation. The Traceability Matrix will also trace Configuration Requirements and possibly Standard Operating Procedures where system Configuration Requirements cannot satisfy a User Requirement.

There are many points to consider when implementing a LabWare LIMS application; this blog just highlights some of major components to ensure a successful implementation. We sincerely hope that the information presented is helpful.

Auditing Your Aggregate Spend Program

Written by Alexis Stroud, Director Quality and Compliance, QPharma

1. What components of the audit process need to be implemented to ensure compliance with state aggregate spend and Healthcare Reform regulations?

In order to comply with state aggregate spend and healthcare reform legislation and regulations, you need to have policies, procedures, systems, controls, and monitoring and auditing processes designed to maintain data integrity and compliance with the various state and federal reporting requirements.

Life science companies must clearly understand and interpret the regulatory challenges to comply with each States’ reporting requirements, as well as begin preparation for the Patient Protection and Affordable Care Act (PPACA) – and possibly new state legislation. Based on these interpretations, their policies, procedures, monitoring controls, and auditing steps need to be developed and implemented to ensure reporting compliance is maintained.  This becomes even more challenging for a life science company, because the necessary data and systems are generally not centrally located or maintained (i.e. a cross-functional effort). In addition, the required data elements required to comply with the current Federal reporting requirements may be incomplete or non-existent within these systems.

Using a process-based audit approach enables a company to understand all of its interactions with Healthcare Providers (HCPs) and how those interactions are performed and recorded within its existing systems.  This type of assessment delivers a detailed understanding of the current environment in which your company is operating; identifies policy and procedure gaps, control weaknesses, and opportunities to implement industry best practices; and positions your company to ensure accurate and complete state and federal disclosure.
Note: Some of the state laws (NV and MA, for example) require certification that a manufacturer has conducted audits as part of its compliance program.



What should your Auditing and Monitoring Program consider?

•  Is the process documented?  What is the process for reporting findings?
• Does the compliance auditing and monitoring program incorporate key approval points such as HCP credentialing, needs assessment, payment authorization, and reporting accuracy?
• Have you built into the formal compliance audits a degree of independence?
• Are audits performed at least annually?
• How aware are your Internal Audit teams of the requirements of the state and federal regulations.  
• When reviewing past audit reports, how comprehensive were those reviews?  Were findings investigated and closed out?

Things to consider when auditing your aggregate spend program:

• Do you have a Federal- and State-specific reporting policy?  Is it adequate and is it being followed?  How are you keeping up to date with the changing legislation and regulations and how is that information being communicated within the organization and to any third party providers?
• Do you have assessments of third party vendors?
• Third party vendors are acting as agents of a Company. Their activity is ultimately the activity of the Company.
• Monitoring/auditing should include activities of third party vendors.  Perform contract reviews.
• Third party vendors should be informed of this requirement and will have to potentially provide data and other documentation for the audit.
• Do you understand the underlying data controls?
• Process – How is data captured, approved, and updated?
• Systems – What systems are the data maintained in and what are the relevant controls and validation procedures?
• Data – What data elements are available to meet the reporting requirements?
• Procedures – What processes are necessary to capture accurate and complete relevant data?
• What are your data collection challenges? How can you improve current processes to address these challenges?
• Are there enough resources within your organization to perform various data gathering, validation, and reporting functions?
• Have you had any prior incomplete or inaccurate State reporting filings?
• What tools/procedures (checklists, sign-offs, sub-certification process) and monitoring controls are in place to address the day-to-day process designed to enhance compliant state reporting?
•  ensure accuracy of data through consistent and efficient data review
• identify and investigate outliers and compliance red flags
• Have you tested any system-based tools to ensure they are working properly?
• Is your system flexible enough to change and adapt over time with new/updated laws and are you collecting data at the most granular level?
• Has training been provided to all levels of the organization related to the current and future reporting environment requirements, company policies and standard operating procedures, and monitoring and auditing techniques?
• Is the company using the information obtained for state reporting requirements to enhance business operations, as well as overall corporate compliance?
• Do you have disciplinary actions for employees that do not comply with your procedures?

Breaking News! FDA to Audit Pharma's Electronic Recordkeeping

We sent our valued clients and colleagues this update last week, but for those of you who are not on our mailing list...

The FDA will begin auditing pharmaceutical companies electronic recordkeeping capabilities to evaluate the industry’s compliance with 21 CFR Part 11.



According the article by Ed Silverman of Pharmalot, “…the FDA is about to begin a series of so-called inspectional findings at many drugmakers… The precise timing and number of facilities to be audited - and these are audits, in effect - has yet to be determined, but they will be conducted by the FDA’s Center for Drug Evaluation and Research, or CDER.”


To view QPharma’s webinar on how to stay Part 11 compliant with your training systems, visit our website here. Simply register on the site to take advantage of the Part 11 recording that, when aired live, attracted over 200 attendees from 7 different countries worldwide. It also contains a high-level overview of iCertify 3.0, QPharma's 21 CFR Part 11 Compliant training system for the life science industry.

For the full article, click here: PharmaLot