Before you impose a set of tools on your teams, certain considerations have to be taken into account. To start with, how effective are the tools at handling the tasks you have in mind? Then there is the issue of the actual users. Are they keen on taking up new tools? Workplaces often comprise different teams, all of which have staple applications they use to get work done. The tools your software development herd uses can be completely out of phase with those in the finance department.
This is where the technology acceptance model comes in. It can help you determine precisely how you can take advantage of predictable system usage variables to maximize their acceptance and productivity rates.
This post will shed light on the technology acceptance model. While it is a broad concept, I will focus on its relevance to the world of software-steered progress. I will show how the model is useful when procuring software applications (technology). And I’ll show you how to get the most from data obtained across departments, especially when they use different software applications.
Connect all the apps in your toolchain with Plutora
If it were possible to apply the bring-your-own-device (BYOD) model to software applications, a lot could be learned. The main idea would be to encourage higher productivity. As such, different applications would unquestionably be introduced by different team members. For instance, while some prefer working within G-Suite, others could say Office 365 gives them the edge. Both platforms accomplish the same tasks: collaboration, document handling, and file sharing among other features.
The technology acceptance model helps explain why someone would rather use one product over another. It can go as far as predicting how acceptable a piece of technology will be. But let’s not get ahead of ourselves. Before you can learn to apply the model at such depths, some variables need definition.
The Technology Acceptance Model
Fred Davis and his peers at the University of Arkansas theorized that for an endpoint system to be accepted and used by its intended target, certain factors must align.
It would be beneficial if you keep a third eye on your particular environment as we define and map the factors below to your business. As such, they include the user’s perceived usefulness (U) and ease of use (E). These two go on to influence the intended user’s attitude towards said technology (A). The attitude culminates with behavioral intention to use the system (BI).
The Technology Acceptance Model Variables
Figure 1 above illustrates the technology acceptance model. External variables in this case refer to the first time a user encounters the system. This can be in the form of brochures, webinars, or even through regular Google searches. First impressions often determine whether someone will want to continue. And in the case of software, features have to live up to marketing promises. When the features match the hype, a piece of technology should be capable of carrying out the promised tasks. How well it does this governs the perceived usefulness.
When the technology acceptance model was created, very few (if any) platforms were able to present a technology’s usefulness before users tried it out. But we have YouTube now. Video reviews and walkthroughs influence how useful a piece of technology is perceived to be in advance. Some sponsored reviewers are biased, but I digress. Through training and documentation, the two perceived variables can now bend to your liking.
This is well known and especially relevant if you need to get your teams on board with new technology.
When it comes to the attitude variable, you’ll get a positive response only if the previous variables are also good. A boring system might be hard to use. At the same time, the less capable a system is, the less it will appeal to its target users. The U and E variables (usefulness and ease of use) are directly proportional to the attitude variable. The behavioral intention variable (BI) comes next. It usually stems from what a user thinks about a system’s usefulness, but it can sometimes activate even if the user has no particular attitude toward an application.
You could say that BI is like the trial phase. It doesn’t guarantee system adoption. A user must have a positive experience before confirming acceptance and actually using the system.
Coming up With the Model
At this point, you should understand the various variables that determine a system’s acceptance among a pool of users. Perhaps more important is applying the model to your particular situation.
It would not be surprising to find several software applications in use across your company that deliver data. Integrating these applications across the board is a good way to benefit from insights derived from that data, but most data is compiled by systems that can’t communicate with each other.
Ideally, all your teams will log into a single system such as an ERP (enterprise resource planner), but this is not always possible. So instead, you can consider tools such as Slack that can communicate with file storage applications, code versioning platforms, and more. However, you have to ensure acceptance of the other tools to have seamless data visibility. So you might want to ask the following questions before bringing forward new technology for this mission:
- What is the new technology’s impact on overall work performance?
- Will it make work easier for everyone (the majority at least)?
- How easy is it to start using the product at full capacity?
- How long is the onboarding process?
- Is this the most cost-effective way to get things done?
At a glance you should see that these questions consider all the above-mentioned variables to varying degrees: usefulness, effectiveness, implied attitude, and even the managerial deciding factor of cost. All of these ultimately determine acceptability in the modern workplace. This is the firm foundation upon which to build a synergy of universally accepted technology for your business.
Technology Acceptance Model in Daily Use
Let’s say your company develops software. And let’s assume you have applied the technology acceptance model to procure technologies along your product value stream. It is still possible that your various teams use different applications. If so, you’ll have to log in to each application to stay at par with notifications and milestones across the floor. You’ll spend a great deal of your time doing just this. Given how you are better off innovating than simply monitoring, it could be counterproductive. This is where a value stream management platform like Plutora comes in handy.
With a value stream management platform, you can regain control regardless of the different technologies accepted in each department. Essentially, you can cut the time to value for every effort you invest in your product. For a practical example, consider a restaurant owner. The value stream starts when they buy fresh ingredients in the morning. It ends when the customer sits with a plate on the table. This process can be perfected by monitoring each step and ensuring they complement each other from start to finish.
Regardless of the software you choose to use, properly managing your value stream is the best way to achieve total acceptance across the board. The process starts with asking the right questions to keep your teams engaged. However, this process is not the end. The technology acceptance model sets the pace for what is a more manageable scenario in the workplace. The better chemistry you achieve between your teams and their tools, the easier it will be to eventually attain customer delight.
Want to know more about DevOps toolchains? Check out more great articles on our blog: https://www.plutora.com/blog