Making IT Work
If a system does not benefit you and your colleagues, it will fail
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.
Here's a typical scenario: A software vendor comes in to demonstrate a 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.
"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 FDA regulations," the earnest sales rep says.
The audience smiles with fixed smiles and pretends to pay attention-they've heard it all before. After a while, the presentation moves to the demonstration phase, probably 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. 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.
It's easy to 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. A word processor was used to author this article and e-mail to submit it; things we really use become "part of the furniture."
Project managers have developed some standard approaches to improving the chances of software 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?
From Validation to Success
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 and is proportionate to the number and types of users.
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.
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 end user 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, companies use validation expense and complexity as excuses 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.
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 time to be trained participate and 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.
Often, companies use validation expense and complexity as excuses 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.
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. These days, 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 will 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.
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, it is important 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. 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 leverage that position to maximize the most effective use of your time while supporting efforts that will bring real benefits to your company. �
Martin Sumner-Smith, Ph.D. is vice president of Pharmaceutical and Life Sciences Solutions at Open Text (Ontario, Canada). Reach him at 905-762-6214 or msumners@opentext.com.
No comments:
Post a Comment