Business case development and project management Building a Smart Laboratory 2012


Business case development and project management


Building a good business case requires a thorough and systematic approach to understanding current limitations and future requirements for the business. It is important to see laboratory informatics as a component in a lab ecosystem (technology, processes and people), rather than ‘just another laboratory application’. Te following points should all be considered in formulating the case for a new informatics system: • Why do we need a new system? • What is the problem that needs to be solved?


• Is there any quantitative data that illustrates the problem?


• Which laboratory areas will be involved in the project?


• Who makes the go/no-go decision? • What are the issues relating to IP (internal/ legal/patent)?


• Are there any regulatory compliance requirements? Clarify why the organisation thinks it


needs a new system. Tis is best achieved by developing a problem statement that quantifies a specific problem, or set of problems, about the laboratory’s productivity and or knowledge management performance. Te scope and scale of the problem (and hence, the solution) should be identified. Te key decision makers/ budget holders should also be identified, plus any other interested party who may have influence over a go/no-go decision. It is important to know what business level constraints may apply in terms of internal, legal or regulatory compliance.


Laboratory/company background: • Use organisation charts to clarify roles and responsibilities and organisational relationships;


• Identify the nature and scientific disciplines of the laboratory work and how they relate to each other;


• Are outsourced agencies (contract labs) involved? Establish the way in which the laboratory is


organised, the nature of the work it undertakes and how it relates to internal and external organisations with whom it collaborates.


32


Current laboratory processes and systems: • Which laboratory systems are already in use? (Are there SOPs?)


• Which data acquisition systems are already in use?


• Which teamwork/collaboration systems are already in use?


• Which document management systems are already in use?


• Who is responsible for the management and support of these systems?


• Is there a (electronic) records management policy?


• Are there any specific policies and restraints relating to the introduction of IT systems? Establish how the laboratory is currently


working, paying specific attention to the use and effectiveness of manual systems such as worksheets, paper lab notebooks and data


“It is important to know what business level constraints may apply in terms of internal, legal or regulatory compliance”


management. Also identify major electronic systems used for the acquisition, processing and management of data, and ask what happens to this data, where is it stored and for how long? Is it communicated or transferred elsewhere – if so, how? Is it backed up and/or archived? Can it be found? Furthermore, consider if laboratory data


is the responsibility of the lab, or does IT have any involvement, and what level of involvement does IT have in the purchase and implementation of laboratory systems?


Future laboratory processes and systems: • Based on interviews with laboratory managers and staff, formulate a model that illustrates the major relationships between lab data and information;


• Construct data workflow and laboratory process diagrams;


• Identify any conflicts in nomenclature and establish an agreed taxonomy;


• Identify the role (scope and scale) of existing laboratory systems in the model and diagrams;


• Test the model and diagrams against each of the lab areas and other interested parties (IT, legal, QA, records management). Put together a high-level plan showing


the relationships, processes and data flows that describe a future state for the laboratory. Tis should include an identified role for each of the lab systems and should clarify the specific functions of each. Any problems with terminology should be resolved and the plan should be tested by presentation and discussion with the interested parties.


Business plan development: • Quantify the benefits of the proposal, in particular productivity gains, ROI and knowledge management, and support these estimates with case studies;


• Undertake a risk assessment, paying attention to process, technology and people- related risks. Align the risk assessment to the set of user requirements;


• Prepare, and include in the business case, a high-level implementation plan that addresses any specific requirements and/or risks that have been identified. Quantitative benefits should be identified,


along with all risks. An implementation plan should address known risks and/or potential problems, in particular the strategic approach to roll out, e.g. a progressive deployment, the composition of the project team, change management and user support.


Human factors: • What practical problems do laboratory workers experience with existing lab processes and data workflows?


• How well will laboratory workers accommodate change?


• Are there any cultural, political or other internal relationships that could have an impact on the project? Identify potential problems associated


with change management. Tis may be at an individual level (early adopters vs. laggards) or at an organisational level: R&D vs. legal, etc.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36