Difference between revisions of "User:Shawndouglas/sandbox/sublevel10"
Shawndouglas (talk | contribs) |
Shawndouglas (talk | contribs) |
||
Line 133: | Line 133: | ||
====3.2.1 A note about focusing too much on ROI==== | ====3.2.1 A note about focusing too much on ROI==== | ||
Undoubtedly, discussing topics like ROI and budgetary requirements are a vital part of any project proposal, and a cost-benefit analysis of most any potential project is a natural and expected part of effectively running an organization. In particular, account and purchase managers traditionally turn to ROI as an accounting tool for making decisions about proposed investments and purchases. However, it turns out that ROI may not be the most important topic of a LIMS project proposal. We already mentioned in the previous chapter how there are intangible benefits to acquiring and deploying a LIMS in your lab, and those intangible benefits can be difficult to translate into any ROI calculations, potentially painting an incomplete picture based on economics. Now consider another reason why ROI may not paint a complete picture to stakeholders participating in your proposal: a LIMS is also a "survival system." | [[File:Cost Risk Return vv.svg|right|400px]]Undoubtedly, discussing topics like ROI and budgetary requirements are a vital part of any project proposal, and a cost-benefit analysis of most any potential project is a natural and expected part of effectively running an organization. In particular, account and purchase managers traditionally turn to ROI as an accounting tool for making decisions about proposed investments and purchases. However, it turns out that ROI may not be the most important topic of a LIMS project proposal. We already mentioned in the previous chapter how there are intangible benefits to acquiring and deploying a LIMS in your lab, and those intangible benefits can be difficult to translate into any ROI calculations, potentially painting an incomplete picture based on economics. Now consider another reason why ROI may not paint a complete picture to stakeholders participating in your proposal: a LIMS is also a "survival system." | ||
Let's consider why stakeholders may have a strong bias towards using ROI to evaluate your proposal. The further removed a stakeholder is from your laboratory in the corporate organizational chart, the less familiar they will be with what your lab does, its operational workflow, and how it contributes to the organization's operations and success. They may not be aware that the progress of research programs depends upon the results your lab generates, or, in the case of QC labs, that the lab is tasked with ensuring that incoming raw materials are suitable for production and avoiding off-spec products from being produced and shipped, catching problems before they become serious. They may not be able to see the bigger picture of lab operations for lack of understanding and knowledge, but they may very well understand and have knowledge about budgets, accounting terms, and the ROI concept. As such, they may not fully appreciate the impact that a LIMS can have on your lab and how it can improve corporate information flow. In short, you have an education problem to resolve if you want their understanding and support. Instinctively, you may want to turn to ROI discussions in your proposal in an attempt to meet them halfway. But there's more to consider with this approach. | |||
Let's look at a comparison, using laboratory equipment add-ons vs. base laboratory instrumentation as an example. Within the laboratory space, discussions about ROI are appropriate if you’re discussing upgrading the capabilities of an instrument with additional equipment. For example, suppose you have an instrument, and you want to add equipment to it, such as a chromatograph or an atomic absorption spectrophotometer. Back in the day, they were sold without computers and used a strip chart recorder to record their output. The analyst's work included sample preparation, introducing the sample into the instrument (manually), and taking the strip chart output and converting it to usable results when all the samples were processed. All the work was performed manually. | |||
If we wanted to add a computerized tool to capture the instrument data and perform the analysis, we could build a case that the computer system would cost a certain amount, and we'd then determine how much time it would save the analyst, as well as any other benefits, and finally justify the purchase. Adding an auto-injector could be done the same way, and adding both would create a synergist improvement that far outweighs the equipment cost. Here ROI is a perfectly useful basis for justification of the equipment add-on. But that doesn't extend to the basic instrument. | |||
The lab's role is to carry out testing to meet its goals. The instrument is needed to make it possible to do the required testing. The justification for the instrument isn't based on ROI but rather on the need to accomplish the lab's goals so the overall organization benefits. The justification for having and maintaining the instrument is a survival issue. The lab can't fulfill its role without the instrument, as the data needed to support research and production hinges upon having that reliable, accurate, well-maintained instrument. Without the data, the research program is hindered, and production won't know if its products will meet specifications. | |||
Similarly, a LIMS can be argued as a survival system during project proposal, without which the lab could not effectively meet its goals. (Again, this is where tying LIMS acquisition to organizational goals, as discussed at the beginning of Chapter 2, is vital to your proposal.) The LIMS, as detailed throughout this guide, can be seen as a transformational system for most any lab. Sure, small labs can manage to function with paper-based or spreadsheet systems. Still, they will soon become overwhelmed with data management, reporting, and inefficient/ineffective operations management issues. Properly implementing a LIMS will increase the operational effectiveness of a lab and help it meet organizational goals and regulatory requirements. It is not just an incremental addition to a lab product set but rather the basis for reorganizing how the lab works to meet its goals, supports its clients with electronic communications, and prepares it for its future development. In short, you will be moving from completely manual (paper) or near-manual (spreadsheets) operations to an electronic system that permits both local and remote operations simultaneously, an improved working environment with reduced administrative overhead. | |||
If upper management and other critical stakeholders have trouble understanding the LIMS from the standpoint of being a survival system, you can take several approaches. First, if stakeholders tend to think in terms of dollars more than "laboratory workflows" and "computerized audit trails," help them understand LIMS as a survival system in terms of dollars. That may looks something like this: | |||
<blockquote>Well, Stakeholder A, I'm not sure we can survive this competitive market in the long term without a LIMS. Can we afford any fines ($) from lack of compliance with Regulation B, which we must firmly adhere to? Can we afford a potential decrease in clientele ($) and business income ($) by not streamlining our laboratory workflow and freeing up full-time equivalent (FTE) hours ($) to take on more paying work ($)? A LIMS helps us meet Organization Goals C, D, and E, which are critical to the organization's overall survival ($) and success going forward.</blockquote> | |||
Here, you are weaving something they understand into something you're trying to educate them on: your laboratory's operations and how its survival may very well depend on the LIMS. If they need something more they can identify with, you can also compare the laboratory and a LIMS to their department and its systems. How vital is the company accounting information system to the accounting department, and how would it operate in a paper-only environment? What would the production environment look like if it were relegated from using its enterprise reporting program (ERP), [[manufacturing execution system]] (MES), or product lifecycle management (PLM) solutions to using manual operations? Then compare their responses about regulatory concerns, lost contracts, and production delays to similar concerns related to your lab's operations, highlighting that their systems are no different a "survival" concern than the LIMS. As such, acquiring and deploying a LIMS isn't primarily an ROI concern; it's a matter of the organization surviving in an increasingly competitive and regulated environment. Yes, ROI discussions are important, but be sure to impress upon stakeholders in your proposal that there's more to it than that. | |||
Revision as of 17:21, 21 July 2023
This is sublevel10 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see my discussion page instead. |
Sandbox begins below
3. Gaining buy-in from management and other stakeholders
Laboratory-based organizations have projects, which ideally align with organizational goals. These projects may be small and simple (e.g., acquire new hot plates and stirrers as ours are currently failing) or large and complex (e.g., combine our data lakes, reduce IT requirements, and acquire software tools to better manage the data). In all cases, these projects inevitably have some impact on organizational stakeholders, and they often require some sort of approval before they begin. This means gaining buy-in from upper management or some other set of stakeholders.
The key to gaining buy-in for a project lies in "understanding"; if organizational leadership and other critical stakeholders understand why a proposed project is important to the organization, they are more likely to do what they can to support your project and ensure the project goals are met.[1] Is there still a possibility a proposed laboratory information management system (LIMS) acquisition and deployment may get rejected by management despite understanding the potential benefits to the organization? Of course there is, particularly if the organizational budget is tight or some other external factor is influencing the decision. But those factors are largely out of your control; you can only focus on prompting greater understanding of the organizational and personnel benefits that can be realized and taking the time to better understand any resistance made to the proposed changes. That's what the previous two chapters of this guide have helped you prepare for.
This third chapter will, ideally, help you put what you've learned from the prior two chapters together to pitch a LIMS acquisition and deployment proposal to not only upper management but also any other critical stakeholders that should be involved with the decision. It will also help you better understand stakeholder engagement and address resistance to the proposal.
3.1 The importance of manager (and stakeholder) buy-in
Upper management is usually who we think of when considering who has an important stake in a proposed LIMS acquisition and deployment project. There may be other stakeholders who have a say in the project, especially whether or not it is approved financially, but upper management buy-in is critical for your project. Depending on who those people are and what experiences they have with laboratory automation, this process may vary in difficulty. Upper management who are educated in the various details of the laboratory business and the value of automation will likely be easier to pitch to versus those who know little about optimizing laboratory workflows. This is where all the work from the previous two chapters comes in; it's time to help them understand how the organization and its people can flourish with the LIMS.
If you're dealing with knowledgeable management, you may see this justification process as a straightforward task. However, regardless of the level of laboratory knowledge management has, these stakeholders may raise one or more concerns about LIMS acquisition. Some of their perceptions and concerns might be rooted in past experiences or comments about computerized systems from the late twentieth century, or the failures of similar software projects by other organizations. Among those management concerns could be the following:
- They may ask why the LIMS is important now versus six months ago, wanting to know what has changed.
- They may ask what happens if the organization waits six to twelve months to decide whether a LIMS makes sense.
- They may have investigated the subject of LIMS, seen it as another software project, and been concerned about opening a financial black hole.
- They may be concerned about adding more stress to an already overloaded IT organization.
- They may ask if the implementation can be done in a reasonable amount of time, and if the organization has the financial resources and expertise needed to get the job done.
- They may ask if there are alternatives to LIMS that might be less costly and easier to implement.
Don't be put off by these concerns, or most any other rejection or resistance; trying to change people or an organization naturally leads to resistance, as people typically don't care much for change itself. This fact is vital to understand in the scope of acquiring buy-in for your LIMS project, which will require involving the right stakeholders from the very beginning. In her book Leading Business Change: A Practical Guide to Transforming Your Organization, author Karin Stumpf highlights this fact as such[2]:
When you try to change people or an organization, you will encounter a multitude of rejections. If you do not deliberately and successfully extend your circle of influence to include the right people and stakeholder groups, you will undoubtedly encounter major resistance—from critical gatekeepers, from peers, from subordinates, and from all those affected by the changes. Some issues might just be individual ones, linked to power, social hierarchy, or self-interest. However, some resistance might be well-founded and, if addressed adequately, can help you avoid major pitfalls.
I have seen change leaders wait until the populating phase of a project before reaching out to an affected stakeholder group for the first time. By then, the rumors had spread and resistance had taken a foothold.
Even if the attempt to gain upper management's buy-in is made early on, resistance is natural, whether it's emotionally based or a rational response to the proposal. This is where the "understanding" mentioned in the introduction comes into play; in both emotional and rational rejection, a lack of understanding from the stakeholders, and even the project proposer, is often the root cause. In some cases, an actual need may not be met from the proposal, requiring further dialogue. Stumpf further highlights these issues[2]:
Sometimes resistance is emotionally based. Perhaps a person fears getting out of their comfort zone or resents being given more work. Often, though, resistance is a rational response. If someone does not see the need for change or disagrees with the solution, they may try to block the project. Also, if an employee does not know how to effectively interact with a new tool or how to be productive in the process, the employee may resist. Last but not least, people may resist because there is a real problem—your plan may have not addressed a real need, the tools may be substantially flawed, or the structure may leave a serious gap in operations. It could be that some people see that you do not have the requisite budget or buy-in from upper management. Because they believe your project will ultimately fail, why should they invest their time and energy?
Stumpf's statements emphasize the importance of upper management and critical stakeholder buy-in, as without it, an under-funded, under-supported LIMS project hindered by lack of understanding and lack of stakeholder engagement has cascading effects. This means taking your LIMS acquisition proposal seriously, involving upper management and other stakeholders, helping them understand the implications of the project, addressing their concerns and resistance, and conducting the necessary research to make the most relevant and convincing proposal as possible.
So far we've talked about primarily winning over upper management for a proposed LIMS acquisition and deployment project, but it's not always that simple, especially within larger organizations. While management is often a stakeholder in an organizational project, there often are other stakeholders inside and outside the organization. A "stakeholder," as defined by ISO 26000 Social responsibility, is defined as an "individual or group that has an interest in any decision or activity of an organization."[3] As such, identified stakeholders of the decision to acquire and deploy a LIMS could be anyone from IT personnel to the laboratory's clients, and anything in between. In some cases the number of apparent stakeholders, at first glance, may become daunting, requiring a formal stakeholder identification process that asks questions such as "who can help the organization address specific impacts?" or "who would be disadvantaged if excluded from stakeholder engagement?" Once identified, those stakeholders may be further separated into those most directly impacted by the LIMS decision vs. those who are only indirectly impacted.[3] From there, more refined decisions can be made as to who will be included in the LIMS justification process.
Conducting relations (i.e., interacting) with these stakeholders—management and otherwise—can be seen as stakeholder engagement. Involving management and other stakeholders demonstrates a commitment to the engagement process, as well to its importance. Kujala et al. define "stakeholder engagement" as "the aims, activities, and impacts of stakeholder relations in a moral, strategic, and/or pragmatic manner."[4] Their definition, based on a literature review and descriptive analysis of academic literature, provides a wide level of applicability to organizations of many types, and it highlights the benefits of engagement, as well as why it's valuable in particular to gaining buy-in of LIMS acquisition.
Table 9 shows an adapted version of the work of Kujala et al., highlighting how the different components of stakeholder engagement can benefit the organization. From this chart, we can see how a stakeholder may be more likely to buy into LIMS acquisition (or any other organizational decision) through a stakeholder engagement process that takes into account multiple aspects. If, for example, a stakeholder is involved with determining the potential strategic impacts (from Table 9, find the Strategic row and move right to the Impacts column) of a LIMS, the potential end result of that stakeholder engagement could yield improved efficiency, a greater competitive advantage, greater innovation, and an enhanced reputation for the organization overall.
|
Outside of upper-level organizational management, LIMS consultancy Third Wave Analytics breaks down a laboratory-based organization's LIMS stakeholders into five groups, while adding what value a LIMS adds for each group. When you seek buy-in from any of these stakeholder groups, it will be useful to keep these potential benefits in mind during justification processes[5]:
- Laboratory technicians and sample testing personnel: These stakeholders realize improvements from knowing sample status and location, using sample processing protocols, having automated data capture and analysis, and managing training activities.
- Laboratory managers and supervisors: These stakeholders realize improvements from having more granular sample management tools, tracking inventory, managing analytical test scheduling, and verifying regulatory training requirements are met.
- Laboratory directors and clinical lab scientists: These stakeholders realize improvement from having the tools to manage sample review and sign-out, identifying documents that require review and approval, and tracking quality control procedures for reagents and instruments.
- Quality assurance and quality management services personnel: These stakeholders realize improvement from ensuring the appropriate review and storage of all testing and quality control (QC) data, managing controlled documents, and auditing lab data and records.
- Research personnel: These stakeholders realize improvement from ensuring the difference between clinical and research samples, seeing which samples and data are associate with which studies/projects, and querying data from a single location.
Now that we've discussed why gaining buy-in from upper management and other critical stakeholders is important, let's take a closer look at the actual LIMS proposal process.
3.2 Pitching the LIMS project
We now better understand that engagement with stakeholders is important to any LIMS acquisition and deployment plans. But what of the proposal itself? What are some optimal approaches to proposing a LIMS project to upper management and other relevant stakeholders?
The most common approach to pitching a LIMS project is developing a formal project proposal document. You or someone in your lab may have experience with creating such a document, but it's just as likely that you and your peers haven't needed to pitch a formal proposal to management before. This guide assumes you have limited experience at best in such an endeavor and offers some suggestions.
A project proposal is a document (and an initial phase of project management) that condenses critical project aspects such as goals, challenges, timeline, and budget into a form that is succinct and more able to persuade stakeholders to buy into your project emotionally, fiscally, and intellectually. The presentation of this proposal happens early on in the overall project pathway. Note that the project proposal, however, differs slightly from project charters and business cases. A project charter comes after the proposal has gained approval, acting as a reference document that drives the project objectives, scope, and stakeholder requirements stated before and further developed after project approval. Business cases often come after the project proposal has been made, usually requested as an extension to any basic explanation of budget and return on investment (ROI) made in the project proposal. The business case further explains any financial requirements in greater detail for stakeholders, and it can even be integrated into a project proposal to make a more highly detailed initial proposal.[6][7][8][9][10]
In the case of pitching a LIMS proposal to upper management and other stakeholders, the project proposal will largely be unsolicited unless those stakeholders specifically came to you and other staff with a request for a proposal concerning quality and efficiency improvement in the lab. In either case, your research and writing still needs to be persuasive and compelling, as it likely won't be clear if the stakeholders have the necessary knowledge and understanding of what a LIMS could bring to your lab.[6] Chapter 2 has already addressed the organizational, economic, and practical justifications you may use to make your proposal more persuasive and compelling; these will serve you well. However, organizing these justifications, revelations, and other information in a succinct and clear fashion is another skill worth practicing (we'll talk about that organization shortly). Like other types of writing, knowing your audience well is also critical to making your proposal more compelling. For example, will the stakeholders respond better to a formal tone or a more casually written tone?[8] Finally, be willing to play the part of expert, even if you're feeling a bit like a fish out of water. Your proposal should clearly indicate why you think the LIMS option is the best option for your lab, followed by a ranking of any alternative options proposed. If you've done the necessary research, your proposal will demonstrate sufficient expertise and give further confidence to stakeholders.[9]
While there is some room for flexibility in how you organize your proposal, the most common way includes[6][8][9][10]:
- An executive summary of the proposal;
- A project background, including the organizational goals, challenges, and risks being addressed;
- A project solution, including how your solution(s) complement the stated goals and address the stated challenges and risks;
- A set of defined deliverables and goals, including projected timelines, expected ROI, and other metrics for measuring success;
- A declaration of resources, including any projected budgetary and operational requirements and allocations; and
- A conclusion, which confidently and clearly restates your case.
The executive summary should be brief and succinctly address the goals, challenges, and risk the LIMS project plans to address; how the LIMS will address those goals, challenges, and risks; and the impact the LIMS will demonstrably have upon implementation and use. As these topics will be addressed later in more detail in the project proposal, remember that this introduction serves as the "hook" that will help keep stakeholders engaged with your proposal from the beginning.[6] The project background will then tap into the organizational justifications we talked about in Chapter 2.1, including organizational goals and how the current organizational challenges and risks undercut those goals. You also have an opportunity to discuss prior attempts to address those same challenges and risks and how those attempts were inadequate.[6] Your project solution—the LIMS—is then discussed. Here you'll be examining how organizational goals intersect with how a LIMS would positively address organizational challenges and risks. In presenting your solution here, you'll include a vision statement of how the LIMS will positively impact and improve the laboratory environment, as well as the organization overall. You'll also discuss the timeline for the project, who will be involved and what role they'll play, how risk will be mitigated through LIMS implementation and use, what will be delivered, and how progress will be communicated and reported.[6] You'll then address your deliverables and goals, helping to give stakeholders a clearer view into what their approval and resources will gain them. Here the stakeholder should discover the final actionable goals of LIMS acquisition and deployment (they should be specific, measurable, achievable, realistic, and time-bound [SMART]), a clearer timeline of the project, and any other deliverable-based metrics of project success.[6][11] The project's declaration of resources will more clearly describe how resources will be allocated to costs and other operational requirements. You may have already mentioned ROI previously in the other sections, but you'll likely want to get into more details at this point to make clearer the projected costs, budget, and resource allocations requirements needed to finally convince stakeholders to approve your LIMS project. Finally, your conclusion should briefly state how the points in the executive summary were addressed, while emphasizing the impact the LIMS will have on the lab and organization in a relevant and clear fashion.[6]
The order of the items may be negotiable if a strong case can be made. While your executive summary and conclusion should necessarily remain as the bookends to your proposal, the items in the middle may have some room to move. However, the above order still has advantages. As Purdue University notes[8]:
As you organize the rest of your proposal, consider what makes the most logical sense. Is it a good idea to present success metrics before your plan? Perhaps, if you believe these metrics will be very compelling and viewing them first will appeal to your client. Always consider your audience when creating a proposal.
Additionally, it’s smart to keep resource requests toward the end. Use the earlier sections to sell your idea as best you can. Proving your value early can get stakeholders excited about your ideas and increase the likelihood that they will accommodate your requests.
3.2.1 A note about focusing too much on ROI
Undoubtedly, discussing topics like ROI and budgetary requirements are a vital part of any project proposal, and a cost-benefit analysis of most any potential project is a natural and expected part of effectively running an organization. In particular, account and purchase managers traditionally turn to ROI as an accounting tool for making decisions about proposed investments and purchases. However, it turns out that ROI may not be the most important topic of a LIMS project proposal. We already mentioned in the previous chapter how there are intangible benefits to acquiring and deploying a LIMS in your lab, and those intangible benefits can be difficult to translate into any ROI calculations, potentially painting an incomplete picture based on economics. Now consider another reason why ROI may not paint a complete picture to stakeholders participating in your proposal: a LIMS is also a "survival system."
Let's consider why stakeholders may have a strong bias towards using ROI to evaluate your proposal. The further removed a stakeholder is from your laboratory in the corporate organizational chart, the less familiar they will be with what your lab does, its operational workflow, and how it contributes to the organization's operations and success. They may not be aware that the progress of research programs depends upon the results your lab generates, or, in the case of QC labs, that the lab is tasked with ensuring that incoming raw materials are suitable for production and avoiding off-spec products from being produced and shipped, catching problems before they become serious. They may not be able to see the bigger picture of lab operations for lack of understanding and knowledge, but they may very well understand and have knowledge about budgets, accounting terms, and the ROI concept. As such, they may not fully appreciate the impact that a LIMS can have on your lab and how it can improve corporate information flow. In short, you have an education problem to resolve if you want their understanding and support. Instinctively, you may want to turn to ROI discussions in your proposal in an attempt to meet them halfway. But there's more to consider with this approach.
Let's look at a comparison, using laboratory equipment add-ons vs. base laboratory instrumentation as an example. Within the laboratory space, discussions about ROI are appropriate if you’re discussing upgrading the capabilities of an instrument with additional equipment. For example, suppose you have an instrument, and you want to add equipment to it, such as a chromatograph or an atomic absorption spectrophotometer. Back in the day, they were sold without computers and used a strip chart recorder to record their output. The analyst's work included sample preparation, introducing the sample into the instrument (manually), and taking the strip chart output and converting it to usable results when all the samples were processed. All the work was performed manually.
If we wanted to add a computerized tool to capture the instrument data and perform the analysis, we could build a case that the computer system would cost a certain amount, and we'd then determine how much time it would save the analyst, as well as any other benefits, and finally justify the purchase. Adding an auto-injector could be done the same way, and adding both would create a synergist improvement that far outweighs the equipment cost. Here ROI is a perfectly useful basis for justification of the equipment add-on. But that doesn't extend to the basic instrument.
The lab's role is to carry out testing to meet its goals. The instrument is needed to make it possible to do the required testing. The justification for the instrument isn't based on ROI but rather on the need to accomplish the lab's goals so the overall organization benefits. The justification for having and maintaining the instrument is a survival issue. The lab can't fulfill its role without the instrument, as the data needed to support research and production hinges upon having that reliable, accurate, well-maintained instrument. Without the data, the research program is hindered, and production won't know if its products will meet specifications.
Similarly, a LIMS can be argued as a survival system during project proposal, without which the lab could not effectively meet its goals. (Again, this is where tying LIMS acquisition to organizational goals, as discussed at the beginning of Chapter 2, is vital to your proposal.) The LIMS, as detailed throughout this guide, can be seen as a transformational system for most any lab. Sure, small labs can manage to function with paper-based or spreadsheet systems. Still, they will soon become overwhelmed with data management, reporting, and inefficient/ineffective operations management issues. Properly implementing a LIMS will increase the operational effectiveness of a lab and help it meet organizational goals and regulatory requirements. It is not just an incremental addition to a lab product set but rather the basis for reorganizing how the lab works to meet its goals, supports its clients with electronic communications, and prepares it for its future development. In short, you will be moving from completely manual (paper) or near-manual (spreadsheets) operations to an electronic system that permits both local and remote operations simultaneously, an improved working environment with reduced administrative overhead.
If upper management and other critical stakeholders have trouble understanding the LIMS from the standpoint of being a survival system, you can take several approaches. First, if stakeholders tend to think in terms of dollars more than "laboratory workflows" and "computerized audit trails," help them understand LIMS as a survival system in terms of dollars. That may looks something like this:
Well, Stakeholder A, I'm not sure we can survive this competitive market in the long term without a LIMS. Can we afford any fines ($) from lack of compliance with Regulation B, which we must firmly adhere to? Can we afford a potential decrease in clientele ($) and business income ($) by not streamlining our laboratory workflow and freeing up full-time equivalent (FTE) hours ($) to take on more paying work ($)? A LIMS helps us meet Organization Goals C, D, and E, which are critical to the organization's overall survival ($) and success going forward.
Here, you are weaving something they understand into something you're trying to educate them on: your laboratory's operations and how its survival may very well depend on the LIMS. If they need something more they can identify with, you can also compare the laboratory and a LIMS to their department and its systems. How vital is the company accounting information system to the accounting department, and how would it operate in a paper-only environment? What would the production environment look like if it were relegated from using its enterprise reporting program (ERP), manufacturing execution system (MES), or product lifecycle management (PLM) solutions to using manual operations? Then compare their responses about regulatory concerns, lost contracts, and production delays to similar concerns related to your lab's operations, highlighting that their systems are no different a "survival" concern than the LIMS. As such, acquiring and deploying a LIMS isn't primarily an ROI concern; it's a matter of the organization surviving in an increasingly competitive and regulated environment. Yes, ROI discussions are important, but be sure to impress upon stakeholders in your proposal that there's more to it than that.
3.3 Developing a cheat sheet for management
Pitching a LIMS acquisition project is no simple task, to be sure, but one can arguably make the proposal process more effective if they provide information and tools that help stakeholders more effectively and rapidly understand the value and costs associated with the proposed LIMS project. As such, you may want to consider making a "cheat sheet" of sorts for critical stakeholders who will be the recipients of your proposal.
This cheat sheet could take many forms, homogenous or varied, but in the end it should be readily accessible and organized such that it's easy for recipients to make sense of its contents. Those contents will also vary, based upon the level of familiarity stakeholders have with LIMS and laboratory informatics solutions. If management isn't familiar with a LIMS, you'll probably want to include a broader list of bullet points as to how LIMS can benefit labs of all types. That list might look something like this:
A LIMS can...
- Increase efficiency: LIMS can help laboratories manage data more efficiently by eliminating data silos, managing standard operating procedures (SOPs), generating custom reports, facilitating data interoperability and exchange, tracking reagent inventories, and managing staff training. This in turn can minimize wasted resources.
- Improve process control: LIMS can help laboratories better manage test/sample status and workload evaluation, resulting in better customer support and smoother workflows. With a LIMS, these and other tasks are automated, so we can spend more time on what really matters: research and testing. As an added benefit, LIMS also reduces errors by automating manual processes and eliminating the potential for human error.
- More rapidly disseminate business data and analytical results: LIMS can help laboratories communicate test results more quickly and accurately. In research, this means faster project execution and better decision-making. In production, this means faster release of products, quicker evaluation of incoming raw materials, and prevention of wasted products.
- Enable access to data anywhere, anytime: Many LIMS can help laboratories access lab data from anywhere, particularly cloud-based LIMS. With cloud-based LIMS software, we can access lab data from anywhere with an internet connection. That access capability means we can work remotely or collaborate with team members across different locations, all with a high level of security.
- Provide safer, more secure storage for critical lab data: LIMS can help laboratories centralize and secure their various data and information. LIMS software provides a centralized location for all lab data, making it easy to access and share data with other team members. It also ensures that data is secure and protected from unauthorized access, especially when the LIMS is purpose-built to meet data- and information-related regulatory requirements.
- Facilitate better results interpretation and retrieval: LIMS can help laboratories interpret and retrieve results more quickly, increasing customer satisfaction and lab productivity.
- Improve billing processes: LIMS can help laboratories streamline their billing processes, improve record access, and provide greater insights into organizational financials.
- Increase productivity: LIMS can help laboratories realize 10-20% productivity benefits based on a reduction in clerical work alone. By automating manual processes and providing easy access to lab data, LIMS software frees up time for researchers and analysts to focus on their core work. Using automated reporting, and giving clients controlled access to the system—i.e., through a secure, administrator-controlled client portal—for sample logging, along with having automated instrument connections for worklist downloading and data entry, will greatly increase those productivity gains.
- Facilitate collaboration: LIMS can help laboratories share data and collaborate on tasks and projects, resulting in improved communication and streamlined workflows.
As Chapter 2 points out, you'll also want to address how the LIMS acquisition and deployment specifically addresses organization goals and challenges. At this point you've already linked tangible and intangible benefits to organizational goals and challenges as part of your proposal research, and you'll want to make these connections clear to stakeholders. This might be best visualized in an easily digestible table, for example. Table 10 provides a few representative examples of this effort; your table may be larger and more extensive, but remember to keep it succinct and easy-to-understand.
|
As for the economic and practical justifications and considerations mentioned in Chapter 2, you can find help in managing those in a compact way in Appendix 1 of this guide, which provides you with an Excel workbook containing many of the tools referenced in this guide. The LIMS Acquisition and Deployment Justification Workbook has five tabs addressing on-premises vs. cloud LIMS account costing and overall five-year costing, as well as the barcode benefits analysis tables and the tangible and intangible benefits of LIMS acquisition and deployment in tabular form, with value calculation fields. These tools can be readily implemented in any cheat sheet you pass on to upper management and other critical stakeholders as part of streamlining your overall proposal process. That it's already in Excel format makes it easy for you to add additional tabs for the above-mentioned broad LIMS education points and the expected organizational impact of the LIMS, as well as any other information that needs to be conveyed quickly in a tabular form.
References
- ↑ Mills, R. (20 December 2021). "Getting stakeholder buy-in across a siloed organization". GatherContent. https://gathercontent.com/blog/getting-stakeholder-buy-in-across-a-siloed-organisation. Retrieved 19 July 2023.
- ↑ 2.0 2.1 Stumpf, K. (2015). Leading Business Change: A Practical Guide to Transforming Your Organization. CRC Press. pp. 80–82. ISBN 978-1-4987-2662-7. https://books.google.com/books?id=Lu35CQAAQBAJ&pg=PA80.
- ↑ 3.0 3.1 "Stakeholders". Quality Resources. American Society for Quality. https://asq.org/quality-resources/stakeholders. Retrieved 19 July 2023.
- ↑ 4.0 4.1 Kujala, Johanna; Sachs, Sybille; Leinonen, Heta; Heikkinen, Anna; Laude, Daniel (1 May 2022). "Stakeholder Engagement: Past, Present, and Future" (in en). Business & Society 61 (5): 1136–1196. doi:10.1177/00076503211066595. ISSN 0007-6503. http://journals.sagepub.com/doi/10.1177/00076503211066595.
- ↑ Third Wave Analytics (14 September 2022). "How Each Lab Stakeholder Can Benefit from a Laboratory Information Management System (LIMS)". Third Wave Analytics, Inc. https://thirdwaveanalytics.com/blog/how-each-lab-stakeholder-can-benefit-from-a-laboratory-information-management-system-lims/. Retrieved 19 July 2023.
- ↑ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Team Asana (8 November 2022). "6 steps for writing a persuasive project proposal". asana - Resources. https://asana.com/resources/project-proposal. Retrieved 19 July 2023.
- ↑ Martins, J. (5 October 2022). "The beginner’s guide to writing an effective business case". asana - Resources. https://asana.com/resources/business-case. Retrieved 19 July 2023.
- ↑ 8.0 8.1 8.2 8.3 "3 Quick Tips for Creating a Successful Project Proposal". Purdue University. 16 September 2022. https://www.purdue.edu/projectmanagementcertification/news/3-quick-tips-for-creating-a-successful-project-proposal/. Retrieved 19 July 2023.
- ↑ 9.0 9.1 9.2 Guthrie, G. (28 March 2021). "Everything you need to know to create a winning business case". nulab - Learn. https://nulab.com/learn/project-management/everything-you-need-to-know-to-create-a-winning-business-case/. Retrieved 19 July 2023.
- ↑ 10.0 10.1 McDowall, R.D. (1995). "The Management of Laboratory Information". In Christy, Alfred A.; Einax, Jürgen; Hutzinger, Otto. Chemometrics in environmental chemistry - applications. The handbook of environmental chemistry / ed. by O. Hutzinger Vol. 2, Reactions and processes. Berlin: Springer. pp. 281–2. ISBN 978-3-540-49150-7. https://books.google.com/books?id=YeyjBwAAQBAJ&pg=PA281.
- ↑ Martins, J. (19 July 2022). "How to write SMART goals (and why they matter)". asana - Resources. https://asana.com/resources/smart-goals. Retrieved 19 July 2023.
Citation information for this chapter
Chapter: 3. Gaining buy-in from management and other stakeholders
Title: Justifying LIMS Acquisition and Deployment within Your Organization
Edition: First Edition
Author for citation: Joe Liscouski, Shawn E. Douglas
License for content: Creative Commons Attribution-ShareAlike 4.0 International
Publication date: