What is required of employees – and how does it translate into desired behaviour?
How do we, as project managers, create learning and unlearning in a busy everyday environment filled with deadlines, deliverables, budgets and steering‑committee reporting?
Project managers already juggle many responsibilities, so this cannot become an academic exercise that requires extensive preparation. The process must fit naturally into the daily project workflow. Just as risk management is not a one‑off workshop in the scoping phase but a continuous activity, learning and unlearning must be addressed continuously – as close to the point of use as possible.
The process of identifying and working with learning and unlearning needs can be outlined in four phases:
- Identification
- Clarification
- Activities
- Evaluation
Identification – what is changing?
When something changes in your context, objectives or strategy, it is important to pause and analyse the nature of the change. For example, the project shifted phase, which created a need for new competencies among line managers.
The key is to consider the practical situation: What is required of the employee, and how should the desired behaviour manifest itself?
Clarification – which learning objectives must be achieved?
Desired behaviours can be translated into learning objectives. These describe what must change in terms of observable behaviour. In the earlier example of line managers who needed to change, the desired behaviour included engaging with employees, being visible, taking the lead and driving the transformation. This is a classic example of a learning need.
Unlearning, however, can be harder to imagine. We cannot simply “forget” how to ride a bike. But many IT projects introduce new technology or processes, and here unlearning becomes essential.
Consider this example:
“During the implementation of a new finance system, the project team was defining new processes. The enterprise architect objected, arguing that the proposed process was impossible because the integration to the ERP system could not handle the file type in question.”
The architect was anchored in knowledge of the old system and applied this to conclusions about the new system. The example is simple, but the point is crucial:
Unlearning is the process by which individuals or organisations recognise, release and let go of previous learning (including assumptions and mental models) to make space for new information and new behaviour (Source: ‘Aflæring – en forudsætning for læring?’ by Henrik Holt Larsen).
When clarifying needs, we must determine whether we are dealing with learning, unlearning or both, to design the right approach.
Learning and unlearning in practice
In the example above, the architect struggles to imagine how processes should work in the new system because they are constrained by prior knowledge. Unlearning requires creating space for new information and new ways of thinking. This means using reflective processes and new scenarios that place employees in situations where old assumptions no longer work.
Reflective questions can be powerful catalysts for unlearning. Returning to the earlier situation, we might ask the architect:
- “Which file types can the new ERP system handle, and what does that mean for the process?”
- “Imagine we meet after the project closure celebration and look back – which changes to the ERP integrations were key to our success?”
The first question encourages linear problem‑solving.
The second invites reflection – prompting the individual to explore possibilities rather than limitations.
This shift lays the groundwork for unlearning: stepping away from old assumptions and opening up to new mental models.
Want to know more?
