The system is there. It does what was agreed. And still nobody works with it. That is not bad luck, it is a pattern. And it can be prevented, if you treat change as a design choice instead of as training afterwards.
It almost always goes like this. A company chooses or builds new software. Delivery hits the planning, the demo looks slick, everyone gets a login. A quarter later you look again: the quotes live in the old spreadsheet again, agreements sit in somebody's head again, and the new system gets updated now and then. For appearances.
The reflex is to point at the technology. Too slow, too many buttons, that one field in the wrong place. Sometimes that is right. Usually, though, the software does exactly what was asked for. What is missing is use. And use is not a feature you bolt on afterwards.
Change is not training afterwards
In most projects the change sits right at the end. An explanation session in the final week, a manual, maybe a lunch presentation. After that it is called live. At that moment, though, the most important question has still not been answered: why would your team work differently tomorrow than today?
The old spreadsheet is familiar, fast and theirs. The new system is unfamiliar and belongs to the project. As long as you do not take that difference seriously, the spreadsheet wins.
Not out of unwillingness. On a busy Tuesday everyone does what feels quickest.
Change therefore belongs at the front of the project, as a design choice. In how the system looks, and in how you roll it out.
Four questions that decide whether someone comes along
Whether a colleague switches depends on four simple questions. Answer one of them with no and that person falls back on the old way. We test them in every engagement; the model behind it, our Change Compass, is in the knowledge base.
