Case Study – Project Structures DO WORK!


A small group of computer system validation specialists were working on a client project to help validate a legacy computer system in response to a regulatory citation.  On arrival to the site and during the elicitation of the user requirements (required as part of the validation package) it was identified that there was no formal document or change management processes within the IT department.

This is a serious finding as without controlling changes and documentation – there is effectively no control within the area.  There were some basic documentation and change management procedures approved and effective for the site, however the approved scope was grey with regards to computerised systems.

It was obvious to the team from the very start that trying to validate computer systems without a formal document or change control process was going to be firstly, very difficult and secondly a non-compliance in itself in accordance with applicable industry regulations and good practices.

Two options preceded the group:

1)      Revise the existing site change and document management procedure to fully include the scope of information systems and IT, then use these procedures and processes during the course of the project.

2)      Implement a project document and change control function that will satisfy all regulatory and good practice requirements without the overhead of involving the whole site when it isn’t necessary.

This Presented Two Potential Problems:

1)      A time delay in the revision of the site documentation to facilitate the IT section of the business.  Due to the amount of potential signatories, a political overhead may also appear and this could take up to 1 month to move from a draft document to an approved for use version of the document.  There would also be an element of re-training and a delay in the ability to move quickly, especially with changes in the project environment.

2)      A resistance to change that would impact the design and implementation of the project document and change control functions.  This would still require a reference to the project methodology in the site documentation and change management procedures in order to satisfy traceability requirements (unless QA would allow the Validation Plan only to mention this process, which of would fuel further debate).  Upon implementation, users of the procedures would still have to be trained.


In either case, a bedding-in period would be required during which usage of the new system would be potentially slower than usual, however the users would get up to speed quickly as projects invariably see lots of changes which causes lots of document updates.

After several discussions with the project stakeholders and IT management team, in conjunction with the quality group, we identified that there were several more IT projects on the roadmap which were a combination of prospective and retrospective validation projects.

Based on this information, it was decided that we should opt for project change and document control systems in order to facilitate a high volume of change and document updates whilst minimising external department involvement as far as possible (of course, major changes such as those that posed a risk to other systems or product manufacturing were still required to go to the site for review and approval).


We believed this to be the best approach as once the system was implemented, it meant that the client company had an effective system to use in the future, thus ensuring that all project activities were carried out in a controlled fashion whist at the same time providing a mechanism for the system to fall under the full site control once the project had ended and the system was returned to operational ownership.

Kestrel Life Sciences were commissioned to implement this new system in accordance with the existing company policies and document framework and this required input from IT and Quality Assurance personnel.

This had immediately caused our project scope to creep and even though the client company had no problem in the additional cost of this specialist work, they were still insistent on the actual initial scope of the project being delivered within the initial pre-agreed timelines.

Our business is focused on the actual outsourcing of specialist documentation so that we can perform our duties from our own offices and use technology to communicate – the only usual exception is when we sometimes deploy 1 or more specialists to a client site for finite period to either help with or conduct some approved test scripts.

In this situation, we sent two specialists to the client site to expedite the new document creation.  The resistance to the change in the first place was obvious and as a consequence, our business analyst decided to select the two most resistant members of the client team to work with the new document and change control process.  This was a very strategic movement because when the change resistant customers were actually involved with the planning and implementation of these new project documents, it quickly became clear to them that what was actually going on was really important.

Furthermore, they used their internal knowledge of the site to help drive the changes through quickly as they knew all of the relevant external departmental reviewers and approvers.  We also realised that during this exercise, the change resistant customers were resistant to the change, not to be obstructive but because they didn’t understand the criticality or value of formally controlling such changes to systems, processes and their associated documentation.  This was because they had often heard of various terms, such as validation and change control, however they weren’t actually sure what these terms involved or how it was applicable to their shop-floor environment.

Valuable Lessons

Our team gave a brief overview of the systems lifecycle and the reasons why the initial project had been started in the first place and once they understood that, they were more than happy to be part of the team.  A key lesson was learned for the client:  “Don’t just expect human conformity without rationale, people are more willing to help when they know why they are doing something, not least because this gives them greater worth in both their professional positions but as humans as well”.

Lessons were learned all through the initial phase of this project.  Firstly by taking away the resistance from their usual roles and giving them a voice through educational means.   This made them happy, but more importantly, as they were part of the design and implementation of the new process, they became the key advocates for change – they now understood the requirement for changes and assisted with the implementation of the project infrastructure which had been unexpectedly put in place;  they helped train their colleagues in the use of the system and mentored them through their first few document updates and changes – this helped to bring the team up to speed quicker and fewer people tried to continue making uncontrolled changes and not bothering to update the documents.  When instances of not being sure what do arose – these people also acted as the interface between the client team and their Kestrel Life Sciences counterparts, thus naturally becoming the leaders within their group.


The end result was that the two specialists that were deployed were able to return back to work on the Kestrel Life Sciences site one week early whilst the client project team were fully geared up to execute the initial project.  The initial project was delivered within the initial timeframe and because of the change resisters becoming advocates for change, the client saved money in the final project delivery because the quality of the documentation and clarity of the change requests was consistently in a good order, thus fewer review iterations were required.

The benefit of outsourcing as much of this type of project work as possible is that the company to whom this work is outsourced always has other work going on.  This means that rather than having specialists on the client site waiting for  the client, they are in their own office with planned work to be doing during these “lulls”, meaning that the specialists aren’t just “keeping up appearances” whilst the client isn’t paying for “lulls”.

Of course, not every situation is suited to this configuration, however a lot of situations are – in addition, this mechanism also provides for the company to be able to take on small and one-off scopes of work for companies who don’t have the resources or technical ability to deploy a large team.

This was exemplified for us further when a client (from Ireland) whose designated ISO specialist had had to go on sick leave just as the company were about to be ISO accredited subject to their imminent, final inspection; they asked us to complete two procedures for them.

This would have been must more costly if someone had to go to Ireland but once we’d agreed the terms, the work was completed in half a day by a business analyst who worked from home kindly volunteered to work late until the job was complete and thus having the work completed with that same day.  This would not have been possible is our resources were outsourced to client sites permanently.

Suggested Additional Reading

Benefits of Proceduralised Systems
An Easy Way to Validate an SQL Report
The Power of Word Processing and Typing Skills


Mark Richardson
Director of Operations
Kestrel Life Sciences
t: +44 (0) 1670 543837
f: +44 (0) 1670 551050

One Response to Case Study – Project Structures DO WORK!

  1. […] Blog Documenting a Network Infrastructure Case Study – Project Structures DO WORK! […]

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for?
Drop a comment on a post or contact us so we can take care of it!