Marcel van Oosterwijk

Author: Marcel

  • Practice Note: The Project Is Not the Subject of the Change

    Projects have a peculiar ability to become the center of attention.

    We establish plans, milestones, budgets, governance structures and reporting mechanisms. We monitor progress, manage risks and eventually determine whether the project succeeded.

    Yet the organization rarely wanted a project in the first place.

    It wanted something to change.

    A testing improvement project exists to improve testing capability. A system replacement project exists to change a system or product. A transformation programme exists to develop organizational capabilities.

    The project exists in service of that change.

    But this raises an interesting distinction.

    The Project Is a Subject Too

    A project can itself be understood as a subject.

    It has boundaries, responsibilities, capabilities and characteristics that can be assessed and improved.

    There is nothing wrong with managing a project as a subject.

    The problem arises when we confuse it with the subject it exists to change.

    Consider a system replacement project.

    The project is one subject: a temporary organization coordinating change.

    The system being replaced is another. The organizational capability depending on that system may be a third.

    Each can be understood, developed and assessed.

    But evidence about one does not necessarily tell us much about the others.

    Two Different Claims of Success

    Suppose a project finishes on schedule, within budget and with all agreed deliverables accepted.

    That is meaningful evidence about the project.

    But has the intended change occurred?

    Does the new system deliver the expected outcomes? Has the organizational capability improved? Have the risks that motivated the project been reduced?

    Those are different questions requiring different evidence.

    The difficulty is that project performance is often easier to observe than the effects of the change.

    Milestones can be counted. Deliverables can be accepted. Activities can be marked complete.

    Capability development and organizational outcomes are harder to assess.

    So the visible subject can gradually substitute for the important one.

    A training programme is completed, so competence is assumed to have improved.

    A process is implemented, so behaviour is assumed to have changed.

    A system goes live, so the transformation is considered successful.

    But completing an intervention is not evidence that it achieved its intended effect.

    The Project as an Intervention

    Seen from the perspective of the subject being changed, the project is a temporary mechanism for coordinating interventions.

    It may introduce technologies, practices, roles, structures or governance arrangements intended to move another subject toward a desired state.

    The project therefore contains an implicit hypothesis:

    If we perform these interventions, we expect the subject to change in these ways.

    The project plan describes what we currently believe is necessary to produce that change.

    But what happens when an intervention is completed and the expected effect does not appear?

    Simply completing the remaining activities more efficiently may not help.

    The evidence may be telling us that our understanding of the subject, or of how to change it, was incomplete.

    The ability to adjust the interventions then becomes more important than adherence to the original plan.

    The Temporary and the Continuing Subject

    There is another complication.

    Projects are deliberately temporary.

    We create them with the intention of eventually dismantling them.

    Project teams dissolve. Governance structures disappear. Budgets close. Responsibilities are transferred.

    But the subject being changed may need to continue for decades.

    During the project, considerable understanding accumulates within the temporary organization.

    People learn why decisions were made, which alternatives were rejected, what assumptions proved incorrect and where uncertainty remains.

    What happens to that understanding when the project disappears?

    Traditional handover often concentrates on transferring deliverables, documentation and operational responsibilities.

    But continuity requires more than possession of artifacts.

    Can those who inherit the subject understand why it is the way it is?

    Do they know what outcomes were intended, which assumptions shaped the solution and what remains uncertain?

    Can they continue assessing and developing the subject without depending on the people who participated in the project?

    A project may successfully deliver a new realization while leaving the organization poorly equipped to understand or evolve it.

    The project is supposed to disappear. The understanding required to continue the subject should not disappear with it.

    What Does Project Completion Mean?

    Perhaps project completion deserves a broader interpretation.

    We need evidence that the project has been managed effectively.

    We need different evidence that the intended change has occurred.

    And we need confidence that the organization can continue managing and developing the changed subject after the project has ended.

    The project doesn’t need to preserve itself.

    Its temporary structures can disappear.

    But the understanding, responsibility and ability to learn must continue somewhere.

    Because the project is not the subject of the change.

    It is the temporary subject responsible for helping another subject become something different — and remain capable of evolving afterward.

  • Practice Note: Transformation Is Not an Intervention

    A recent discussion about Agile transformation made me wonder whether “mindset shift” is really the right way to describe transformation.

    Mindset matters. But organizations do not transform simply because people start thinking differently.

    They transform when the organization becomes capable of behaving differently.

    And that changes how we should think about transformation itself.

    Introducing Change Is Not Transforming

    Organizations introduce new frameworks, methodologies, technologies, governance structures and operating models.

    They reorganize teams, establish new roles, implement tools and train employees.

    These activities may be necessary.

    But they are interventions, not transformations.

    An organization can adopt Agile terminology, introduce Scrum ceremonies and appoint Product Owners without becoming particularly capable of delivering value iteratively.

    It can migrate infrastructure to the cloud without becoming more adaptable.

    It can introduce AI tools without becoming better at using information or making decisions.

    The intervention has happened.

    But has the organizational capability changed?

    From Interventions to Capabilities

    Perhaps transformation should begin with a different question.

    Not “What should we introduce?”

    But “What must the organization become capable of doing?”

    That requires understanding the current capability, defining the desired capability and identifying what prevents the organization from achieving it.

    Only then can we determine which interventions might help.

    And those interventions rarely operate independently.

    Introducing a new development methodology may require changes in requirements management, architecture, governance, competence development and decision-making.

    Improving one practice without addressing the surrounding organizational mechanisms may accomplish surprisingly little.

    Transformation therefore becomes an exercise in orchestrating interventions toward a desired change in organizational capability.

    Did Anything Actually Change?

    There is another problem.

    Organizations often measure transformation through the completion of interventions.

    How many employees have been trained? How many teams have adopted the framework? Has the new operating model been implemented? Has the technology been deployed?

    These measures tell us whether activities have been completed.

    They do not necessarily tell us whether the organization has become more capable.

    To establish that, we need evidence.

    Can teams now make decisions they previously couldn’t? Can the organization respond more effectively to changing requirements? Can it deliver acceptable outcomes more reliably?

    And do these improvements persist after the transformation programme has ended?

    A temporary improvement achieved through extraordinary effort is not necessarily a sustained organizational capability.

    The transformation is not the framework, method or technology we introduce. It is the sustained change in organizational capability that those interventions produce.

    Transformation as a Learning Process

    This also suggests that transformation cannot simply be a predefined sequence of activities.

    We may have a clear understanding of the capability we want to develop, but we cannot always know in advance which interventions will produce the intended effects.

    We need to observe what happens.

    Did the intervention work? What changed? What remained unchanged? Did we discover new constraints or dependencies?

    The answers should influence what we do next.

    In that sense, transformation is an iterative learning process:

    Current capability → Desired capability → Interventions → Observed effects → Learning → Adjusted interventions.

    The interventions are hypotheses about how to develop the capability.

    Their effects provide evidence about whether those hypotheses were correct.

    And the transformation progresses as the organization uses that evidence to adjust its approach.

    What Are We Actually Transforming?

    Perhaps the most important question in any transformation initiative is deceptively simple:

    What will the organization be capable of doing afterward that it cannot do today?

    If we cannot answer that question, it becomes difficult to determine which interventions are necessary.

    And even harder to establish whether the transformation has succeeded.

    Because introducing change is relatively easy to observe.

    Establishing that the organization has become sustainably more capable is a different matter.

  • Practice Note: Tomorrow’s Questions Don’t Exist Yet

    We tend to preserve information because we believe someone might need it later.

    We write documentation, record decisions, create knowledge repositories and organize information so that it can be retrieved.

    But there’s a problem.

    We don’t know what questions people will ask in the future.

    And perhaps that should change how we think about preserving knowledge.

    A Question Nobody Could Have Anticipated

    Imagine AI had access to my complete photographic library.

    In 2040, I might ask:

    “Compare this photograph from 2009 with this one from 2030. How did my composition change?”

    Nobody could have prepared that answer in 2009.

    The question didn’t exist yet. Neither did half the evidence required to answer it.

    But because the photographs were preserved, the question can now be investigated.

    The photographs weren’t created to answer that particular question.

    They became useful because someone could relate them to evidence that emerged much later.

    Perhaps organizational knowledge works the same way.

    Preserving Answers or Preserving Evidence?

    Organizations accumulate enormous amounts of information.

    Documents, presentations, requirements, architectural decisions, source code, test results, incident reports and project deliverables.

    Much of this information is organized around the questions people were trying to answer when it was created.

    What should we build? How should we implement it? Did it work? What went wrong?

    But future questions may be entirely different.

    A consultant might want to compare approaches used across several projects.

    An architect might want to understand why a particular technology was selected.

    A quality manager might want to investigate whether recurring defects originate in weaknesses in organizational capabilities.

    Nobody necessarily anticipated these questions when the original information was created.

    And no single document may contain the answer.

    Understanding emerges from relating evidence that was created at different times, for different purposes.

    Making Knowledge Interrogable

    Recently, someone in a team chat asked whether colleagues had material that might help prepare a customer workshop.

    People responded with suggestions, questions and references to previous work.

    The knowledge existed.

    But the consultant still had to locate the material, understand its context and combine it into something useful.

    Then it struck me.

    The question was already a prompt.

    What if the consultant could ask the organization directly?

    “What relevant experience do we have?”

    “What approaches have we used?”

    “What problems did we encounter?”

    “Why is this project relevant?”

    “Show me the evidence.”

    AI could help make an organization’s accumulated knowledge interrogable.

    Not merely retrieving documents, but relating information across sources and helping construct answers to questions nobody anticipated when those sources were created.

    Of course, those answers must remain traceable to their sources.

    AI can help construct an interpretation. It should not become the authority for whether that interpretation is correct.

    Interrogating the Product

    Consider a consultant maintaining a software product in 2030.

    The original architect has retired.

    The consultant wants to know:

    “Why was this function built? Why Java? What tests cover it? What incidents has it caused? How is it actually used?”

    The answers may be scattered across requirements, architectural decisions, source history, tests, incident records and operational data.

    Perhaps nobody ever documented the complete explanation.

    But the evidence may still exist.

    And if it has been preserved, AI could help reconstruct the understanding.

    This suggests that preserving organizational knowledge is not simply about documenting what we currently know.

    It is also about preserving the possibility of understanding things we haven’t thought to ask about yet.

    Tomorrow’s Questions Don’t Exist Yet

    We cannot document every answer that future people might need.

    We don’t know their questions, their circumstances or what additional evidence will become available.

    But we can preserve the sources from which future understanding might emerge.

    That doesn’t mean keeping everything indefinitely. Information still needs context, provenance, appropriate retention policies and protection against becoming misleading or inaccessible.

    It means recognizing that the future value of information cannot always be determined by its immediate purpose.

    Perhaps AI changes the economics of organizational memory.

    Instead of requiring people to anticipate every future information need, we can increasingly preserve evidence and make it possible to interrogate that evidence when new questions arise.

    The Body of Knowledge supplies the material.

    AI helps relate it.

    Humans ask, challenge and judge.

    Because tomorrow’s questions don’t exist yet.

  • Practice Note: The Illusion of the Feedback Loop

    Most feedback loops aren’t loops.

    Imagine telling an employee in a supermarket that the price on the shelf doesn’t match the price at checkout.

    The employee apologizes. Perhaps they correct the price for you. They might even inform their supervisor.

    Problem solved?

    For you, perhaps.

    But will someone correct the shelf label? Will anyone investigate why the discrepancy occurred? And if it keeps happening, will the organization change anything?

    The organization has received feedback and responded to it.

    But has it learned anything?

    When Feedback Travels Backwards

    Organizations have developed countless mechanisms for collecting feedback.

    Customer complaints, retrospectives, quality metrics, incident reports, assessments and lessons learned.

    We collect information, discuss findings, make decisions and initiate improvement actions.

    We call these feedback loops.

    But information travelling backwards through an organization doesn’t automatically create a feedback loop.

    The information must be capable of influencing the subsequent behaviour of the system.

    That doesn’t mean every observation must result in a change. Sometimes feedback confirms that everything is working as intended.

    What matters is whether the system can respond when the evidence warrants it.

    Closing Actions Is Not Closing the Loop

    Consider an organization that identifies a recurring problem.

    An improvement action is agreed upon, assigned to someone and eventually marked as completed.

    The action has been closed.

    But did it solve the problem?

    Perhaps the intervention addressed a symptom rather than its cause. Perhaps it introduced new problems. Perhaps it worked in one situation but not in others.

    Unless someone evaluates the effect, the organization doesn’t actually know.

    And if the next occurrence of the problem leads to the same discussion and another improvement action, the organization may be repeating a process without learning from it.

    A feedback loop requires more than information and intervention.

    It requires evidence about the consequences of the intervention.

    Closing an action is not the same as closing a feedback loop.

    When Organizations Become Good at Responding

    There is an interesting paradox here.

    An organization can become highly effective at handling individual problems without becoming better at preventing them.

    Customer complaints are resolved quickly. Incidents are closed within agreed timeframes. Retrospectives produce action lists. Assessments generate improvement plans.

    Every mechanism appears to be working.

    Yet the same underlying problems continue to occur.

    The organization has optimized its ability to respond.

    But perhaps it hasn’t developed an equivalent ability to learn.

    This distinction matters because responding to a problem and changing the conditions that produced it are different capabilities.

    The first restores normal operations.

    The second improves the organization’s ability to operate.

    Both are valuable, but they shouldn’t be confused.

    Where Does the Loop Close?

    Perhaps we should evaluate feedback mechanisms differently.

    Instead of asking how much feedback we collect, how quickly we respond or how many actions we complete, we might ask:

    What can actually change as a result of this feedback?

    Can it challenge existing assumptions? Influence priorities? Change practices? Redirect investments? Improve organizational capabilities?

    And when something changes, do we evaluate whether the intended improvement was achieved?

    These questions concern more than the existence of feedback mechanisms.

    They concern the organization’s ability to use evidence to adapt its behaviour.

    Because a process doesn’t become a feedback loop merely because information travels backwards.

    Perhaps the loop doesn’t close when we act on feedback. It closes when we learn whether our response actually worked.

  • Practice Note: When Organizations Cannot Use What They Know

    Organizations invest heavily in competence. They recruit specialists, establish communities of practice, develop methodologies and create dedicated functions to support delivery.

    But possessing competence and being able to use it are two different things.

    What if an organization’s greatest capability problem is its inability to make effective use of the capabilities it already possesses?

    A Project in Trouble

    Consider a software development project with more than ten predominantly junior developers, supported by one or two experienced leads.

    Testing is performed by a couple of QA specialists. Developers perform little meaningful testing themselves, and test automation is largely absent.

    As development progresses, testing becomes a bottleneck. Defects accumulate, regression effort grows, and delivery falls behind schedule.

    Management decides to add resources.

    Another developer seems the obvious choice. After all, the project is behind on software development.

    But additional developers produce more work requiring testing, while increasing the coordination and mentoring burden.

    What if another tester would improve delivery throughput more than another developer?

    Why does increasing development capacity seem like the natural response to delivery problems, while increasing testing capacity requires special justification?

    Perhaps the organization is managing the production of code rather than the delivery of acceptable functionality.

    Development capacity is not the same as delivery capability.

    When Knowledge Cannot Influence Decisions

    The people working in the project recognize problems and develop ideas for improvement.

    They may even discuss these in agile retrospectives.

    But if staffing, priorities and practices are decided elsewhere, what can they actually change?

    The organization has implemented the ceremony of continuous improvement without necessarily establishing the conditions that make improvement possible.

    It has competence, information about its problems, and people willing to address them.

    But the knowledge has no effective path to action.

    Suppose management responds by adding more developers.

    Testing becomes an even greater bottleneck. Coordination overhead increases. Defects and rework consume more time.

    The project falls further behind.

    More resources are added.

    The organization has monitored progress, recognized problems and taken action.

    Yet its interventions have reinforced the conditions responsible for poor delivery.

    And if the next project follows the same pattern, what has the organization learned?

    An organization can be highly responsive to problems while remaining remarkably incapable of learning from them.

    The Missing Capability

    Perhaps organizational knowledge management needs to distinguish between three things:

    • Possessing knowledge: Having people who understand relevant problems and mechanisms.
    • Sharing knowledge: Making their observations and expertise available.
    • Using knowledge: Enabling that knowledge to influence decisions, interventions and organizational behaviour.

    Organizations invest considerable effort in the first two.

    But the third requires more than documentation, communication and knowledge-sharing activities.

    It requires mechanisms for recognizing evidence, mobilizing expertise, challenging assumptions, authorizing interventions and evaluating their effects.

    This is itself an organizational capability.

    And like other capabilities, it can be assessed and developed.

    The relevant evidence would not be the number of retrospectives conducted, lessons learned documented or improvement initiatives launched.

    It would be whether those activities actually influence how the organization operates.

    Because an organization can be full of competent people and still make systematically poor decisions.

    Perhaps the knowledge required to improve already exists.

    The question is whether the organization is capable of acting on what it knows.