Digital is different, and it’s taking us a while to realise that. The expectation is that a Digital HR project is just like any other IT project, but nothing could be further from the truth. If we want AI in HR we need to understand how Digital is different, change how we run projects accordingly – and move Employee Experience to the centre of everything we do.
The seven tips in this article help to explain what has to stop, what we need to learn to do as we roll out Digital HR projects, and why we will benefit.
1. You need to know the difference between Digitization and Digital
Many people misunderstand the difference between Digitization and Digital. Jeanne Ross in her excellent 2017 article “Don’t Confuse Digital with Digitization” succinctly explains the difference:
- Digitization is a noun: “Digitization involves standardizing business processes and is associated with cost cutting and operational excellence”. A Workday project is a great example of a Digitization project and is generally a conversion from one system to another with a series of processes at its core. “Digitization is an Operational Necessity”.
- Digital is an Adjective [which] “refers to a host of powerful, accessible, and potentially game-changing technologies like social, mobile, cloud, analytics, internet of things, cognitive computing, and biometrics”. “Digital is a Customer-Centric Value Proposition”.
Firstly, you can’t really build Digital unless you’ve done Digitization first. Digitization builds the foundations on which Digital sits. Secondly, a Digital project is Customer-centric, so you have to…
2. Stop Process Mapping. Start Experience Mapping
We’ve become brilliant at designing processes because Outsourced Service contracts are built around a Statement of Work which clearly defines what is done and by whom. Because money rests on these processes, our thinking has become focused almost entirely on them. If the process works, KPIs are met, everyone is happy.
But they’re not! Users have to fit into the process. Their experience is not the driver, the process is. It’s there for the benefit of HR and others, not for the users.
One of the biggest things I’ve learnt about HR Digital Transformation happened during my first ever Experience Mapping session. Amazingly, asking users about their journey allows you to devise Interfaces which support what they need, not what they have to do.
Designing an Employee Journey in the form of an Experience Map, prototyping it with real people, and ultimately building the processes around the experience is a game-changer.
3. Understand the difference between a Minimum Viable Product and a Minimum Valuable Product
For many people, a system has to do everything! There are understandable reasons – you can’t really run two HR Information Systems concurrently, so anything less than complete lift and shift is probably not viable.
But deciding priorities centrally can lead to the loudest voice having the final say. On the other hand, engaging with users allows you to determine the value functionality will give to the business. If Time = Money, then perhaps the functionality which saves the most time is more important?
In a post-Covid world you need to know the financial value of a piece of functionality, so that you can first deliver use cases which provide the greatest return on investment for the lowest cost.
Delivering a small number of functions with a high return, rather than a high number of functions with a lower return, allows you to prototype earlier and demonstrate value quicker.
4. Change from Waterfall to Design Thinking/Agile Prototypes
It should really go without saying but putting the employee at the centre of Digital Development, by starting with Experience Maps and then developing experiences which will quickly give value to an organisation, completely changes the conventional approach to an IT project. Waterfall projects (again so beloved of SOWs), in which everything is planned to the last second and last deliverable, are a thing of the past.
Those long Requirements phases – in which clever people sit down and come up with a huge list of what the system should do – are replaced by user-centred Design Thinking sessions, quick prototypes and feedback to develop User Stories for inclusion in a prioritised backlog.
Clearly defined Build, Test, Deploy phases, punctuated by quality gates, are replaced by constant iterations, and fast feedback loops.
Consequently, Iterative development of quick prototypes allows you to bring value to the user, and by extension the business, quicker.
5. A ChatBot needs to understand the User
A website and a Chat/Bot are exact opposites.
In simple terms, a user interacting with a website has to understand it and, by extension, learn what it actually does. On the other hand, a conversational chat/bot needs to have been trained to understand what the person is asking (their intent) so that it can do it for them.
In the US, for instance, a Manager may use “How do I give someone a raise” as an utterance. In the UK they may use “I want to give Keith a pay rise” but in India they’d probably use “Pay hike”.
This means that in a global environment, the system needs to learn these culturally different linguistic approaches, not the other way around. The person who once said to me “we don’t need to worry about this, people know what language to use when they speak to us” found out very quickly that they didn’t.
6. Change your development approach to include Artificial Intelligence training
It therefore follows that the phases of a project which includes some form of AI, be it (for example) predictive analysis or, in the case of a Chat/Bot, language understanding, need to change.
People often forget that Digital HR Projects require systems/algorithms to be trained. It’s a misconception that AI “just knows” and it can come as a shock that the human Training element is so important.
What’s more, people often consider Training and Testing to be the same thing. I tell Chatbot clients that Testing proves that a Chat/Bot is working, whereas Training – in this case Language Training – is where you teach the Chat/Bot how to understand when people ask it to do something. Most importantly, this can’t be done centrally – it needs local people.
If you are to build a useful Digital product you need to change the form of your IT project so that it includes Training.
7. Move from Broadcasting to an Employee to an always on Conversation
In her article, Jeanne Ross writes that Digital companies “…embrace information-enriched customer solutions delivered as a seamless, personalized customer experience”
- Understanding that Digital is different leads you to stop Mapping HR Processes and start Mapping Employee Experiences.
- Moving from a Minimum Viable Product to a Minimum Valuable Product only works if you ask Employees what their pain points are and assign a (provable) value to them.
- Realising that Artificial Intelligence (in this example, a Chat/Bot) needs training by the people who speak the language that it needs to understand democratizes the development of a product and, ultimately, humanises it.
- All of this puts the employee at the centre of an always-on conversation. We stop telling people what to do and start talking to them about what they need. It becomes their system, and that leads to adoption.
My old boss used to say: “The problem with HR is that we tell you what we want, then we tell you how to do it, and in the end we do it for you”.
We seem to have this approach wired into our DNA – think of those sessions writing FAQs. They weren’t Users’ Frequently Asked Questions at all, rather they completely avoided the User’s needs, and essentially gave him/her a list of the things he/she needed to know to be able to navigate the system we have produced.
In the end, only HR cares about HR processes and we need to understand not only that the Digitization of those processes is simply the start, but also that Digital HR is Different, and we have to learn how to build it.
Related articles: Why your HR Technology Project needs a Purpose