Peace in our Time? R&D and the IT Department

Add bookmark
John Trigg
John Trigg
12/20/2011

 

 

What Does The Future Hold For Electronic Lab Notebooks In 2012?

Download the free 2012 ELN Global Forecast eBook now to find out!

One of the consequences of the increasing convergence of science and technology is the nature of the relationship between R&D and IT.  As scientists increasingly depend on information technology as an integral component of laboratory work, they become increasingly dependent on the IT infrastructure and IT resources.  It hasn’t always been like this; in the days when most laboratory computers were basically standalone devices, dedicated to specific data acquisition and/or data processing tasks, life was a lot simpler; scientists could tinker with their systems whilst IT managed the mainframes.  But inevitably, as the demand grew to connect things together and transfer data from one system to another, it became necessary to start a relationship with the IT Department.  And so began a courtship that, to all outward appearances, was not made in heaven.  It was not unusual, and in some cases, still isn’t, to find a significant degree of tension in the relationship.  Scientists still complain that IT is holding up progress, and in return IT complain that scientists want to do crazy things and break all of the rules.

The essence of the problem was captured in a blog post (1) by Clay Shirky discussing aspects of this relationship under the heading: ‘You Hate the IT department, and They Hate You Right Back’.  Well, it might not have been quite that bad, but Shirky goes on to offer a rational explanation of the tension.  Basically, the IT guys are there to guard the infrastructure, to stop bad things from happening – a private police force, if you like.  This flies in the face of any creative or innovative process that depends on technology i.e. if you’re in a job where you need to push back the barriers, you’ll probably find yourself at odds with the IT guys.  In other words, we have a clash of cultures; ‘out of the box’ has a significantly different meaning in these two communities!

In my previous article (2), I discussed some work by David Snowden on Multi-ontology sense making, pointing specifically to a ‘landscape of management’ model.  Using this model, it’s quite clear that the IT department belongs in the ‘Process Engineering’ box, whereas R&D belongs primarily in the ‘Social Complexity’ box.  In other words, IT and R&D are diametrically opposed in terms of their ‘cultures’.  And this is the essence of the problem, which is exacerbated by corporate directives to drive down total cost of ownership and adopt one-size-fits all solutions - great from an accountancy perspective, but scientists will always favour a best-of-breed approach to their selection of IT tools.

The solution adopted by a lot of organisations is to create an R&D IT team that fulfils a liaison role (peace-keeping force?) between the respective departments.  This framework would typically include business analysis and project management functions, as well as the provision of application-specific training and first-line user support.  In addition, and R&D IT Team is in position to take ownership of any business (laboratory) problems that may arise.  From the laboratory side, most of the communication with IT used to have a ‘solution-centric’ message; “I need this”.  The reply would frequently be along the lines of: “You can’t have it - it isn’t an approved product/service”.  By turning the conversation away from the solution and focusing on the problem, it is possible to get a more receptive response.  In the main, most people like to be helpful, like to be liked, and like to solve problems.  Structuring the conversation to play on these behavioural tendencies can bring about positive results.  In real life it’s not always easy, but this is a role the R&D IT Team can take on, ensuring that the conversation is based around “how do WE solve this problem and achieve business benefit”.
[inlinead]
This approach generally eases the tension, but is it enough?  It plays very specifically on the encouragement of cooperative and collaborative behaviours to solve a problem, which is good, but may still leave concerns about how well integrated are we in an organisational sense, and how well equipped are we with respect to the knowledge, skills and expertise to address the issues being raised through the convergence of science and technology.  Concerns have been expressed about whether our formal education programmes adequately address the demands of this area of modern laboratory work(3).  Technology is now at the heart of science, not on the periphery, and it increasingly demands to be considered as a core competency for laboratory work.   In the laboratory, there is an increasing expectation that technology could, and should deliver enhancement to all aspects of the acquisition, processing, management, preservation, use, re-use, searching, etc. of data and information.  Inadequacy in the knowledge, understanding and delivery of the appropriate skills will impact laboratory efficiency.

This throws the emphasis back on our formal education systems and recruitment policies; a lot of ‘laboratory’ people with IT responsibilities have acquired their knowledge and skill through personal initiative and hands-on experience.  We need to think whether this is the best way forward.  Scientists need to be better equipped in terms of the knowledge and practical expertise of information technologies, and IT specialists need to have a better understanding of laboratory requirements. 

In the context of organisational integration, hopefully the days are over when the selection and implementation of laboratory systems is seen as an IT project.  In reality there is no such thing as an IT project anymore, there are business projects that include IT.  The dearth of platform standards, communication standards and data standards in the laboratory world places a significant emphasis the challenge IT faces in helping the laboratory transition towards a fully electronic and integrated environment.  This provides a viable rationale for the need for R&D IT functions, which, properly staffed will not only resolve IT vs. R&D conflicts, but provide a better skilled and more knowledgeable community capable of exploiting the convergence of science and technology, and delivering real benefits.

References:

1. P2P Smuggled In Under Cover of Darkness  (http://openp2p.com/pub/a/p2p/2001/02/14/clay_darkness.html)

2. Management Buy-in and User Acceptance in an ELN Project  (http://www.pharma-iq.com/informatics/columns/management-buy-in-and-user-acceptance-in-an-eln-pr/)

3. Lab Managers Survey: Lab Staff Qualifications for Modern Laboratories (http://www.institutelabauto.org/research/LabMgrsSurveyReport.pdf)


RECOMMENDED