Making IT (Information Technology) Work

Here's an article I recently wrote on strategies for successful implementation of software in the pharmaceutical industry that will be published in a print magazine soon; meanwhile here it is:-

If a system does not benefit you and your colleagues, it will fail

Here’s a typical scenario. A software vendor is coming in to demonstrate its particular product. Staff members either volunteer or are ‘volunteered’ to come and hear the pitch, but they could probably write the script for the first 10 minutes themselves. An earnest sale representative starts to introduce his/her company: “We are the leading vendor of software that will make you more efficient, will save you money, get you to market faster and make sure you comply to the FDA’s regulations.” The audience smiles with fixed smiles and pretend to pay attention – they’ve heard it all before.

After a while, the presentation moves to the demonstration phase, probably given by a sales engineer who really knows the product. At that point the audience divides between those who try to follow along and those who have more information than they want.

In the end, pharmaceutical companies will buy some of the software that they see. Attempts will be made to use most of what they buy, but not all systems will ever be rolled out, and many of those systems that are will meet considerable user resistance, leading to deployment failure.

You could almost say that software and information technology are over-hyped and doomed to fail, but in fact, the right systems for the right purposes can be indispensable. I used a word processor to author this article and I’ll use e-mail to submit it; but I’m old enough to remember the time before such things existed. Things we really use become ‘part of the furniture.’

Just like drugs, most software candidates will fail, but the few successful, ‘blockbuster deployments’ will support everything else. So the problem is very similar: can we predict the blockbuster IT implementations, or at least make better decisions earlier to optimize our chances of success? Yes. In fact, IT project managers have developed some standard approaches to improving the chances of deployment success. Looking at such approaches as a potential end user on the business side, what contributions are going to be asked of you, and more importantly, can you have a role influencing future success while minimizing unproductive use of your time?

Success Criteria
We need to distinguish between software for single individuals working largely alone, departmental software for groups of people and enterprise software that is intended for most or all of an organization. If you are the end user of a single-user system, you are best able to determine if it is going to benefit you. But group software assessment is much harder – approximately in proportion to the number and types of users.

As I’ve described, software vendors usually talk about operational efficiency benefits, which is a message that appeals to management. In fact, experience has shown that end users of group systems are far more concerned about whether a given piece of software makes their job easier, than the overall benefits to their company. If it doesn’t make their jobs easier, they will usually resist efforts to implement it, which means that neither management nor staff will achieve the purported benefits. The more different users from different departments there are, the greater the challenge to successful deployment.

IT project managers are told to make sure that a proposed product will meet the needs of business users – that it will solve a critical business problem – that’s why software vendors now describe their products as solutions to problems rather than extolling the technology.

Validation Pains
Software used in the pharmaceutical industry must be validated if it is applied in critical applications that might put patient health or business continuity at risk. Readers may well be familiar with this approach either as quality managers or as they have seen it is used for control systems, but now it is applied more broadly to include most critical business software. The aim of validation is to ensure that the software and associated systems perform as required and that risks are identified and mitigated.

A first step in validation is to collect and document user requirements to produce a user requirement specification (URS). IT project managers will solicit your input. This information is incredibly important and is used as a basis to select software vendors and products in the early stages and ultimately to test the performance of the implemented system (performance qualification; PQ).

URS documents can vary widely in quality. Sometimes they are clearly the result of asking very different groups for their input and then making a master list with little integration. In worst-case situations, some individual requirements may be contradictory or even mutually exclusive! Thought should be given to better processes that might be enabled or optimal system design as URS documents are reviewed and finalized.

Often users give their input based on past experience and assumptions and do not know of alternatives. If you can, take the time to educate yourself about alternative technologies and other options, most importantly, consider whether a proposed software system will provide incremental benefit to a current process, or possibly a different and better process. Will the design of a proposed system force you to do things differently and if so will that be an improvement? Ideally an organization will recognize the importance of bringing all participating users up-to-speed before embarking on developing a URS.

There’s one warning: Often I see companies using validation expense and complexity as an excuse to maintain the status quo or justify slow roll-outs. User enthusiasm and support rapidly wane. Ultimately an inflexible or infrequently updated but validated system may become invalid as it fails to address evolving business and regulatory requirements. A validated, but unused, system may even encourage non-compliant user behaviors.

Successful Deployment
If you are asked about a new software system, make sure you give it proper consideration early on – if a given product is not going to unambiguously help you and your colleagues, say so. Later on, you’ll likely be asked to participate in a pilot implementation project. If you never really believed in the product then it will be a waste of your time to be trained and participate in the pilot only to report that the product was of no benefit when you suspected that all along.

If a pilot software project goes well, then IT managers will look for ‘power’ or ‘angel’ users to help roll it out to their colleagues. This is a proven approach to optimize user adoption: I am far more likely to listen to a colleague who has found genuine benefit in a product than to an IT manager.

On the other hand, if a given product makes your job easier and your efforts more productive, do you really want to spend a lot of time promoting it to your colleagues? Fortunately, for software deployment, many users enjoy the challenges and different experiences that promoting a new system can give – make sure you’re likely to be one of them before you get heavily into a new software project. Effective IT project managers are trying to address end user resistance and reduce the fear of failure, while looking for visionaries who can see the long-term benefits while accepting the near-term workload.

Executive sponsorship is essential. Nowadays IT project managers will look to get a senior business executive as a sponsor who can help overcome internal hurdles and encourage adoption. Also a steering or oversight committee will be formed and meet on a regular, but not necessarily, frequent basis.

Without such sponsorship, ultimate project success is much less likely, no matter how much enthusiasm there is among potential business end users. Before volunteering valuable time with a proposed software project, make sure the internal assessment and implementation efforts are well run.

Software Configuration and Customization
While sometimes a software product, touted as a “complete solution,” can do everything required to meet your needs, often it cannot. Simple configuration or customization may be required or software products may need to be acquired and integrated to achieve the required functionalities – so called “best-of-breed” systems. There are many options and forces at play.

In mature software sectors, an out-of-the-box product may fit your needs perfectly. Often some simple configuration options serve to optimize the software. But in less mature sectors, and in specialty applications, further customization may be required.

Here we have to strike a balance. Too often, one or more constituencies demand changes in a proposed software product, but will the proposed changes really produce a business benefit? The downside of any software customization is that it costs more money upfront, and continues to cost more money downstream, while making maintenance updates harder or often impossible. People realize this based on past failed projects or because the burden of validating systems increases dramatically with customization. Nowadays astute IT project managers choose to minimize customization to key features that are going to increase user acceptance and business benefit in a very tangible and measurable way.

As a business end user, you are the most important player in software assessment and deployment because in the end, if a system does not benefit you and your colleagues it will fail. You should lever that position to maximize the most effective use of your time while supporting efforts that will bring real benefits to your company.

No comments:

Post a Comment