Getting Use to IT

Imagine you are in IT and you are involved in an application project. A group of users tested it, they liked it, and you bought it. You then implement the application across the enterprise, train the organization’s users, and tell them to use it. The big question is how are you defining “use”?

Use shouldn’t just involve training the users, telling them to go back to their cubes, log in, and figure things out. There first should be a strategy that involves measuring the user’s perceptions of the application before and after its implementation. Before users started using the application they might of had a perception of how their jobs will be impacted, whether positive or negative. It is important to ensure that if the perception is positive it continues to stay that way by making sure that user’s expectations are being met. If the perception was negative, then it is equally important to ensure that negative perceptions will be reversed by addressing the foundation of that perception. Otherwise, you risk loss of interest or effectiveness of the application in the organization resulting again in a failed project.

Next, evaluate the current work processes before the users interact with the application. Chances are that past processes and procedures will no longer be effective or needed. Current processes and procedures should be rewritten and augmented to fit within the context of the new application.

Lastly, the IT team should collaborate with users as they interact with the application. Evaluate how the users interact with the application. What areas are being used frequently and what areas aren’t being used? Next, you should be asking why. The reason for this is because too often the use of an application suddenly changes due to issues with performance, problems with a user interface, limited functionality, or it simply corrupts or displays the wrong data. These are things you need to know, but sometimes get shrugged off as “it’s not worth complaining about because nobody will fix it anyways". Adopting and implementing an application only gets you half of the way there in an IT project. It’s equally important to finish the last half of the project by measuring and evaluating how the application is used and the effects it has on the organization.

Checks and Balances

So you found a third party application that you like. The vendor tells you it will meet all your needs, you liked the demo, and you are ready to hand over a substantial amount of money. But are you really ready? You need to balance the benefits with the risks. Let’s say you buy the application and a couple months down the road you find out the application is missing a critical piece of functionality. How about you implement it and it doesn’t fit within your current technological architecture or processes? How about the current data doesn’t fit within the new system? Or maybe the application doesn’t just flat out work? The list of scenarios is endless.

The point of these questions is that you need to ask the vendor, what happens if we are having trouble making this work? Good vendors will offer to develop application changes and bring staff engineers to your company to ensure their product meets your organization’s needs. The purpose of this is to ensure that you aren’t left owning a bad application that can’t meet your requirements. Also, see if you can run a proof of concept or pilot implementation using a temporary license. Create a test case with a small sample of users and data.

There is low risk and high reward in taking an application for a test drive. Now, if you are thinking that, “this is a waste of time”. I have another question. Isn’t it a waste of time, money, and resources to implement a full blown enterprise application across the organization and not have people use it and lose exponentially more valuable time and money in the process? Let’s say your application costs one million dollars. For about $25,000 in labor and resources, you can see if the application in a proof of concept test will work. If it doesn’t, you are only out $25,000 vs. the one million dollars that you would’ve lost in a failed enterprise rollout. If it does work, you have a functioning baseline environment to compare against and an internal knowledge base to use for the enterprise implementation. Next, make sure you have assessed the requirements of your users and IT staff and the scope of their needs. The application should meet their needs. Lastly, make sure the application will be compatible with your infrastructure.

Wait Loss

What do weight loss solutions and third party applications have in common? More than you think. The other day I was listening to the radio and I heard an ad for a weight loss product that promised to help you lose weight. It promised to do this without the need for you to change your dietary and exercise habits. I began to reflect on the same promises I have heard from third party IT application vendors. I’ve heard promises stating that their products can help improve their operations, profitability, efficiency, and so on. But again, what is conveniently absent is the need to change your processes and/or business habits and putting some effort into its implementation and administration.

I bring this up because recently in a class I’m taking, we were talking about the processes that organizations should follow when they adopt a new technology and implement it. Factors that organizations like to discuss are what is the cost benefit, how more efficient we could work, or how new and cool these applications are. So without much thinking, the organization spends millions on an application, without giving much thought to a specific question. What are the risks of implementing this solution? You might be saying, that’s obvious…..right? Well, try Googling “Failed Technology Projects”, and see what comes up.

Millions of dollars are spent each year on technology projects that fail. Do you think that the employees at these organizations one day got out of bed and said, “Boy, I can’t wait to attempt to implement a hopeless million dollar boondoggle?” Of course not. But, what they probably did was enthusiastically embraced a brilliant and noble notion of improving the organization and figured that proceeding to purchase a readymade third party solution based on a presentation and a short demo will be the answer to their problems. There are steps that should be taken before you hand over a signed check to an IT vendor. You should be excited to improve your organization. But at the same time, you need to take a step back, wait, and analyze the situation. Like in weight loss products claims, the claims of organization improvements through technology solutions may prove to be deficient. In future blog posts I’ll address what can be done to improve your chances of implementing a technology that will be successful.