An information system is not implemented in an organisation simply by starting installation, clicking next a few times to accept the defaults and a final click on ‘Done’ at the end. We know that systems need to be configured to fit the needs of the organisation. In fact the project begins much earlier than installation. Problem statements are written. Use-cases are defined. A range of products are explored, trialed and tested according to a matrix of prioritised needs. Does it function as required? Is it compliant and secure to the organisations required standards? How is it supported? What are best practises to tune it to perform well? How do we build in redundancy and restore data when required? These questions and many more are explored over time. Answers are found and evaluated. Choices are made, all contributing to the configuration of the production environment.
That sounds like a lot of work. It sounds like a lot of care and consideration is given, particularly for enterprise networks. The opening paragraph barely conveys the work that Information Systems teams and organisational leadership put into implementing technology.
Why then do we invest far less time, effort and resource on business involvement and ensuring the successful adoption of technology?
Why do we treat organisational change management and user adoption like a ‘next, next, done’ installation?
A problem statement is important to User Adoption too. It doesn’t just steer the exploration and choice of technology. A problem statement is also a summary of what matters to real people in the organisation and what matters to organisational leadership.
At least, it should be.
Use-cases aren’t just used for mapping features to needs. They are also working scenarios, defined and prioritised by real people in the organisation that focus our efforts on communication, learning and support.
At least, they should be.
Products are explored, not just by the IS group trialling it on themselves. Products are piloted by a range of real people from all levels of the organisation. Proof of Concepts are planned and run to explore technology in the context of a few organisational needs. The outcomes are more informed decisions on which technology to use and how to configure it to fit the needs. Champions are identified and chosen. Learning resources are curated and developed. Commuication plans are tested. Change plans are refined. The business is involved in the exploration.
At least, it should be.
If we want our technology to be better aligned with our organisation and be adopted successfully, we have to stop seeing User Adoption as a ‘next, next, done’ process. Give your people a voice in technology projects. Involve them in defining, prioritizing, exploring, communicating, learning, teaching and supporting the technology.