Senior Leadership has to make hard decisions about investments. We see headlines about mergers, acquisitions, partnerships, opting in on products that have exciting development or preclinical results. The headlines may also include significant investment in internal infrastructure. Hundreds of millions of dollars may be directed to building a new facility to manage the increased demand of an existing product or to prepare for a clinical candidate showing a high probability of success.
What rarely makes headlines is the decisions that this same leadership body has to make with regard to Information Technology. A significant amount of the annual budget is earmarked for IT system support and development and as the Pharma Industry faces a changing business environment more focus and challenge is being placed on the Information Technology space.
Historically, IT projects have been seen as a way to make processes more efficient. Eliminating manual processes, which are prone to human errors, can yield robust, efficient, compliant systems. However, often the desire to automate creates too many discrete, unique, siloed systems that often are not connected in a sensible way and puts the extensive burden on IT and the system users.
So, what does Senior Leadership in an organization see? High IT budgets that are taking a larger percentage of their annual budget. As a percentage of Sales/Revenue, Large Pharma can spend upwards of 3% on IT resources, systems, and projects. High numbers of dedicated resources are focused on the system design, development, validation, training, implementation, and ongoing support.
Small start-ups and established companies alike often have large numbers of people/ groups in the business who are designing and configuring IT systems which is not their core business. The systems are expensive and take a long time to deliver, with the realization of defined benefits often lacking or significantly delayed past the planned implementation date. Sponsorship and end-user engagement wanes the longer it takes to implement the defined solution.
The need for robust, effective systems that enable organizations to perform their work without interruption became even more obvious when the novel Coronavirus (Covid-19) appeared and spread across the globe. Companies around the world including Pharma had to figure out how to maintain their supply chains, in many cases enacting their business continuity plans, keeping essential workers safe while executing their business operations.
Essential workers came into the manufacturing plants to ensure the production supply of essential drugs and health care products continued to be available to support patient needs.
The balance of the workforce had to figure out how to perform supporting functions in a remote setting. Established business processes and systems, many of which were built in conjunction with in-person interactions, were in some cases stressed to their limits. Gaps and inefficiencies became more apparent which identified the need to modify existing processes and systems and to look for new solutions. It became very important to evaluate the ability of the solutions to alleviate the current issues and to consider how the solutions address future needs when the pandemic subsides, and when business may not return to “business as usual.” Attention should be placed on meeting the needs of the “new normal.”
So, a decision was made to design and implement yet another solution. How was that decision made? Was it Top Down with the expectation to “make it happen”. A senior-level executive wants the solution, so a team is established to achieve the executive’s goal. The team takes the challenge but spends a great deal of time building something that perhaps the area where it is intended does not see the problem in the same way. And what is being developed is not helping to fix their identified problem. Worse yet, the project takes a long time to develop, and by the time it is completed the sponsoring executive has taken a new position and the replacement sees things differently resulting in a change of scope, or the termination of the project and perhaps a new project in its place.
Conversely, a Bottom-up approach can identify specific gaps that need to be addressed but often are not holistic in their approach. Someone convinces their senior leader that the project is a necessity, provides a convincing and compelling rationale. It is obvious they must move forward. However, in the rush to solve their discrete issue, the process often fails to identify others who have a similar issue and could also benefit. Approval is given and the project moves forward. Later it is identified that others could and should be using the new solution but incorporating them into the project would cause delay.
Hard decisions have to be made either to delay and change the scope or drive forward and then revise the solution later. Worse, parties decide to go their own way and build their own solution. The net result is that the inventory of systems increases because nobody wanted to wait. It is not unusual over time to find multiple systems used for the same purpose in different parts of an organization. Worse is when you discover that multiple systems do the same thing in different ways and get differing results.
Top-down and Bottom-up approaches can work if a robust process is used to define the problem, if key stakeholders are identified and engaged, and if there is focus on how the identified solution fits into the overall strategy of the organization. Another way to think about this is how will this project be different from all of the previous ones that failed to deliver their intended benefits. It should be no surprise that Senior Leadership asks this question repeatedly-What will be different this time?
Data suggests that upwards of 75% of major IT projects fail. They are considered failures because they did not deliver the anticipated benefits, they were delivered late, key milestones were missed, and/or there are budget overruns. While it is important, especially when trying something new, to have a “Fail Fast” mentality, delivering a key project within budget, scope, and timeline is an achievable goal.
BUSINESS CASE DEVELOPMENT
Leadership is looking for a well-thought-out business case that makes their decision easy. To gain support, the current state needs to be clearly articulated, and show actual examples of problems and challenges that face the organization and the impact they create.
The future desired state needs to create a clear vision of what capability will become available and why it is essential. Business case elements vary but at a minimum, the following should be addressed:
Identification of a sponsor for a project is critical. A successful sponsor understands the vision of the project and can prioritize the request based on how it fits with the strategic direction of the organization. A strong sponsor will build support for a project with peers with whom the sponsor typically has more access and influence than a project lead. The sponsor is ultimately accountable for the project’s success. Is your sponsor willing to say, “if this project fails you should fire me?” I have been on several projects where the sponsor took full personal accountability and those have been some of the most successful projects. A strong, succinct business case is the starting point, not the endpoint, for getting a project supported and approved by Senior Leadership. As the business case is being developed, attention should be made to employee engagement - identifying the intended recipients/users, understanding their desire for the new capability, and identifying what other changes will occur as a result of the new solution. Setting expectations from the beginning is critical. Recalling the statistics about project failures, it is essential to identify the timing of benefit realization. Leaders in particular want to know when resources will be needed to support a project and when those resources will be available to deploy to other priorities. If a solution is expected to result in decreased headcount, department managers and leaders are required to plan for and commit to the reductions often before a project starts. Being very clear and consistent upfront will garner strong support.
“Creating a plan that captures early realization of benefits produces greater buy-in for the project...”
It is helpful if at all possible, to create a plan that allows incremental delivery of functionality and benefits. Realization of benefits early on signals the project is being managed and implemented as expected. If a course correction is required, it can happen before full implementation costs have been expended. Incremental delivery of functionality to users can be closely compared to the concepts of Agile Software Development, even if you are buying a product off the shelf that only requires minimal configuration. You create a flexible, adaptable plan, iterate the design/development, deliver subsets of functionality and build-in a continuous improvement process. In terms of rolling out incrementally, delivering a prototype to a representative target group, followed by a pilot, provides proof that the solution is viable, and the initial benefits can be realized. A lead site gets the solution with any modifications discovered during the pilot phase. Broad deployment follows to additional departments/sites building on the success of the previous implementations.
Creating a plan that captures early realization of benefits produces greater buy-in for the project. Identifying area champions helps the project team promote the solution to others in the department, organization, and often other sites in the network. Once the results of the pilot are generated and analyzed, the area champions, who have close relationships with their counterparts, work together with the project team to prepare a target department or site for the full implementation. Once that first area goes live successfully, other sites in the network are often anxious for the capability to be deployed and compete to be next. A successfully defined and implemented project can create an environment where sites are competing to go next, often making their own business case why they should have priority over other groups or sites in the networks.
This allows various projects to be grouped and prioritized based on organizational goals or directives. Typical IT categories include Efficiency, Foundational Data, Infrastructure, Compliance, Risk Management, Security and Life Cycle Management.
- What - What is the project intended to provide to the organization? The description should set the scope and succinctly define boundaries.
“The Business Case is the vehicle to articulate the purpose and benefits of a project and to obtain feedback and ultimately approval; to build a robust business case there are other critical factors to consider”
- Why - Why is this project important and why should the organization invest resources (time, people, money) in this project? What are the benefits, when will the benefits be realized and how will success be measured?
- How - How will the project be approached? Factors to be considered include what technology capabilities are required, dependencies, constraints, implementation approach.
- Cost - What will it cost, including software, hardware, internal resources, external support, licensing model? This needs to be defined. This may include detailed financial analysis depending on the organization’s financial practices. The total cost of the project should be detailed including cost for implementation and ongoing support
Benefits need to be included in the analysis. At a minimum, Senior Leadership will want to understand the Net Present Value (NPV) or Return on Investment (ROI). To determine the benefits, it is essential to look at the entire process lifecycle to understand who benefits from the new system/project, what work is changed or eliminated, what work is moved to another group. Depending on your organization, risk avoidance typically is not factored as a quantifiable benefit.
However, it is important to identify these potential benefits, but they should be categorized as non-quantifiable benefits. When one looks at the Project Category, there can be important reasons to approve a project with minimal quantifiable benefits. Examples include obsolete software/hardware where a failure/outage could be catastrophic, an upgrade to maintain vendor support, addressing a compliance gap that could result in a health authority observation or a more significant action. The Business Case is the vehicle to articulate the purpose and benefits of a project and to obtain feedback and ultimately approval; to build a robust business case there are other critical factors to consider.
EASE OF USE
Users are expecting new systems to be intuitive and rely on the vendor to have utilized user experience design standards in the development of their product. Can the project team implement a modified training approach such that users are not subjected to numerous, lengthy training courses which require extensive resources to build and deliver? Is the system so intuitive that training becomes focused on the process that the tool supports and not on executing actions in the tool itself? No one has to be trained on how to shop on an e-commerce site. Every day, users search for products, make purchase selections, establish shipping parameters and pay. The products are delivered “magically” to the purchaser’s front door and if not satisfied there is a very simple return process. IT solutions in our organization should be just as easy to access and use. As vendor solutions are being evaluated, the vendor’s usability approach should be aligned with the ease-of-use goals. Frequent users, those accessing a system on a daily or weekly basis, will learn any system, no matter how complex, and can become experts in a fairly short period of time. The infrequent user is a very important target for evaluating ease of use. When one uses the system periodically, perhaps less than once a month, or even no more than three to four times a year, the system should be designed and configured to allow the user to execute their required transaction without delay and without having to ask for help or the need to refer to training material that may be stored in another system.
EASE OF IMPLEMENTATION
Is the application/software considered highly configurable or customizable providing the organization with the ability to build a company-specific system which might have unintended consequences like integration challenges with other critical systems and upgrade difficulties? Is the solution managed as a Software as a Service or an off-the-shelf product where industry best practices have been built into the product allowing fast configuration of the solution within the organization, but which might require the business units to modify their business process to gain better alignment?
RIGHT FIRST TIME
Organizations want to remove inefficiencies from their processes. Errors create rework. Employees get distracted by fixing errors and higher priorities are delayed or can be missed. In companies where a robust quality culture exists, teams are continually exploring ways to build the appropriate level of error proofing into their tools and processes. Right First Time has a direct impact on many areas including the predictability of release timelines, production planning and inventory levels, and resource allocation. Articulate how a project will approach. Right First Time is linked directly not only to quantifiable and non-quantifiable benefits but also to system adoption and the change management experience.
Users expect to be able to work in a variety of situations and locations and on a variety of devices. Providing the ability to not only view data remotely but more importantly to act upon that data is an expected capability and a standard requirement. Global organizations have understood the importance of being able to work anywhere and at any time and have developed or implemented solutions to enable their employees to accomplish this. The desire to create improved work-life balance increased the need to provide solutions that enable employees to accomplish their work while away from the office. The pandemic caused millions of people to work from home, further supporting the need to have solutions that could be accessed remotely, allowing employees to continue their work. In the Pharma industry for example, in order to maintain supplies of critical medical products, essential workers had to be onsite to manufacture, test and ship the products. However, the majority of the other processes associated with a product’s lifecycle have been performed remotely. If a system had already been developed with remote work in mind, the process continued without significant interruption. However, companies that had not developed systems capable of remote work had to quickly plan, develop and deploy solutions. Remote capability must be a basic expectation of any new system being developed.
Many good ideas are brought forward for support and endorsement. The projects can range in cost from thousands of dollars to hundreds of millions of dollars. The amount of work required to gain approval will vary depending on the expense of the project, both cash and resource commitments.
For a business case to be solid, it is essential that the case define the problem, state the importance of the project, list the things it will improve, mention the project’s approach including dependencies and constraints, and outline the Cost and the Benefits. An effective project team/lead that can translate the business case into a compelling vision, gather champions and garner the support and advocacy of an Executive Sponsor will be in an excellent position to bring new capabilities with meaningful benefits to an organization.