Cloud Adoption: Remember the Human Element
One of my regular themes when talking about the cloud are the barriers to adoption or, to put it more coarsely, how we can remove the friction and allow more organizations to enjoy the benefits that the cloud can bring. It’s an area that a number of my colleagues talk about also – we pundits have the advantage of time to explore and enjoy the benefits that cloud brings, but we remain aware of the fact that many within organizations, pounding the realities of nine-to-five, don’t have the same visibility.
It was interesting then to read a post on the Appirio blog that referenced a report written by respected enterprise software commentator Michael Krigsman. In the paper Krigsman focused on the importance of user adoption in the quest for business goals.
Some key takeaways from the post, and Krigsman’s research include:
- When deploying a new software solution it is imperative to talk in a language that end users will understand. As Krigsman points out, the human element is always more confusing than the raw technology and hence it is this human and cultural part of a software project that needs plenty of attention.
- The iterative development process, something that cloud projects tend to embrace, generally achieves a higher level of alignment between the business needs and IT delivery. As a project gradually gets deployed, users have time to gradually get used to a solution.
- User adoption results from an ongoing dialog and process between users and developers that creates a cycle of continuous improvement.
- Choosing a development or deployment partner with experience in high-adoption projects is key to being able to repeat that success on future projects
Clearly adoption of a new project is a result of myriad factors, but one of the key things to remember is that it is the non-technological human factors that are often the blockers to a successful project. By focusing on these issues an organization gives itself the best possible chance of success.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)