Book:Justifying LIMS Acquisition and Deployment within Your Organization/Gaining buy-in from management and other stakeholders/Pitching the LIMS project

-----Return to the beginning of this guide-----

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.

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. 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? 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.

While there is some room for flexibility in how you organize your proposal, the most common way includes:

1. An executive summary of the proposal;
2. A project background, including the organizational goals, challenges, and risks being addressed;
3. A project solution, including how your solution(s) complement the stated goals and address the stated challenges and risks;
4. A set of defined deliverables and goals, including projected timelines, expected ROI, and other metrics for measuring success;
5. A declaration of resources, including any projected budgetary and operational requirements and allocations; and
6. 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. 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. 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. 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. 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.

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:

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 (spreadsheet) 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 the lab 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 also 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 departments 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.