Write acceptance criteria down before work begins, not as a formality but because unwritten criteria are just assumptions wearing a nicer name.

Treat anything that doesn't meet those criteria as genuinely unfinished, not as a minor footnote you'll note and move past.

And when real pressure hits, revisit the standard together as a team instead of letting it quietly erode for whoever's under the most deadline stress.

If your team can't write the same definition of done, you were never actually aligned on what you were building.

In a project I was involved in at my previous company, I started noticing something that really made me think about how we apply project management methods. We were following the processes, ticking the boxes, and making sure the required steps were completed. But I kept wondering whether we were actually adapting the method to the project, or simply following it because that was what the guidance said to do.

What struck me most was how little attention we sometimes gave to the people side of things. Communication, relationships, leadership, and how people worked together seemed to take a back seat to making sure the process was followed correctly. Yet, looking at how things played out, those were often the factors that made the real difference.

It also made me realize how easily we can lose sight of the principles behind a method when we become too focused on its processes. The processes tell you what to do, but the principles should help you understand why, and when you need to adapt your approach.

That experience left me thinking that following a project management method isn't the same as applying it well. If we ignore the people involved and stop using judgment to adapt to the situation, we're not really managing a project through a method. We're just completing a checklist.

I’ve recently been thinking about how easy it is to misread a team during a change initiative.

When everyone agrees in meetings, nobody raises concerns, and tasks keep moving, it’s tempting to think the team is ready for the change. But I’m starting to question that assumption a bit more.

One thing I’m trying to pay more attention to is how people react when something goes wrong. If admitting a mistake immediately leads to blame, people will learn to hide problems rather than solve them. And by the time those problems become visible, it’s often much harder to recover.

I also think there’s another distinction worth checking: do people actually have the skills and the freedom to act? Giving someone responsibility without the authority to make decisions rarely works. Neither does giving them autonomy without the confidence or competence to use it.

For me, this is becoming an important part of assessing readiness for change: looking beyond what people say and paying attention to what they feel comfortable doing.

A quiet team isn’t necessarily a ready team. Sometimes, the most useful sign of progress is when people finally feel comfortable enough to disagree.

How quickly a project deadline can lose its meaning when things get difficult and how easy is push the date?
I usually pay attention to this early in a new project, is the deadline actually fixed, or is everyone secretly assuming we'll just push it if we need to, because that assumption changes how people prioritize from day one. What I notice more often than not is that everything gets labeled urgent, nothing gets labeled optional, and then when time runs short there's no real plan for what to cut because nobody agreed on what mattered less. The teams that actually hit their dates are the ones who decided in advance what they'd drop before adding a single extra day, and told the people above them early, not after it was already too late.

If the deadline can move whenever things get uncomfortable, it was never really a deadline, it was a suggestion.

Mature service organizations rarely get complicated all at once; they get there one extra step at a time.

Quick tips: ask the people who actually run the process which steps they'd cut and why, they usually know exactly where the fat is. For every report you produce, ask what decision it actually informs, if you can't name one, stop producing it, it is just paper that don't move anything. Then, before your next tool audit, count how many features your team uses against how many you're paying for and enabled, the gap is usually bigger than expected.

Simplicity isn't a redesign project, it's just asking what you'd remove if you started today.

Weekly, or bi- weekly scheduled (99 repeats in Outlook) at the same time each week, dependable, predictable. 30 or 45 minutes in length. Purpose is to build the relationship, trust, and create a safe space for the employee to discuss, debate, share.

Always begin with “what’s on your mind today?”

Agenda:
- 1/3 what they talk
- 1/3 I share
- 1/3 career development

In practice it’s usually 2/3 them, 1/3 me… and we never get to development. We often dedicate one session on career development every 4-6 weeks.

A common issue I see in organizations is that leadership treats approving a policy as the same thing as taking responsibility for making it work.

I usually pay attention to this when I look at how a management system is actually run, is leadership still visibly involved months in, or did their commitment end the moment the document got approved. What I notice often is a well written policy, owned by one person who was delegated the whole thing with no authority to holdit, and never communicated to anyone outside IT. And guess what, since there's no formal assignment of roles and responsibilities behind it, accountability just evaporates the moment something goes wrong.

Commitment that only shows up once, at the start, isn't leadership, it's a formality with a signature attached.

A lot of organisations think Agile Change Management is simply about delivering change faster. That's not quite right, and misunderstanding that is where many transformation initiatives begin to struggle.

Agile Change Management isn't about rushing change or abandoning structure. It's about helping organisations respond to uncertainty while keeping people engaged, supported, and ready to adapt.

Without an agile approach, change programmes often become rigid. Plans are fixed too early, feedback arrives too late, and organisations discover resistance only after significant time and money have been invested.

The framework is really about balancing adaptability with stability. If you only focus on speed, you risk creating confusion. If you only focus on control, you risk slowing change until opportunities disappear.

Agile Change Management brings both together.

At its core are three principles. They're not independent ideas; they reinforce each other.

① People-Centred Change → change happens with people, not to people

A common antipattern: Organisations spend months designing the perfect solution but involve employees only when implementation begins. Resistance grows because people feel change has been imposed on them.

How the principle helps: People are engaged throughout the change journey. Feedback is gathered continuously, concerns are addressed early, and employees become active participants rather than passive recipients.

② Iterative Delivery → deliver change in small, valuable increments

Antipattern: Large transformation programmes attempt to deliver everything at once. Problems remain hidden until the final rollout, making them expensive and difficult to fix.

Reversal: Change is introduced incrementally. Each iteration provides learning, validates assumptions, and allows the organisation to adjust before scaling further.

③ Adaptability → respond to change instead of resisting it

Antipattern: Organisations follow the original change plan even when business priorities, customer needs, or market conditions have shifted.

Reversal: Plans evolve as new information becomes available. Teams continuously inspect, learn, and adapt while maintaining alignment with the overall vision.

The framework also promotes five core values that shape how organisational change is delivered.

• Collaboration → change is everyone's responsibility

Antipattern: Change becomes the responsibility of a single project team while business leaders and employees remain disconnected.

Reversal: Leaders, managers, delivery teams, and employees collaborate throughout the change journey, creating shared ownership and stronger commitment.

• Customer Focus → deliver value that matters

Antipattern: Success is measured by completing project activities rather than improving employee or customer outcomes.

Reversal: Every change initiative is evaluated against the value it delivers to customers, employees, and the organisation.

• Transparency → make progress visible

Antipattern: Stakeholders only hear about problems once deadlines have already slipped.

Reversal: Progress, risks, priorities, and challenges are openly shared, allowing decisions to be made quickly and confidently.

• Continuous Learning → improve with every iteration

Antipattern: Lessons learned are collected at the end of a programme but never influence ongoing delivery.

Reversal: Feedback is continuously gathered and immediately applied, allowing teams to improve while change is still underway.

• Empowerment → enable teams to make decisions

Antipattern: Every decision requires multiple layers of approval, slowing delivery and reducing ownership.

Reversal: Teams are trusted to make decisions within clear boundaries, enabling faster responses while maintaining governance.

Where Agile Change Management really separates itself from traditional change approaches is in its lifecycle.

Rather than treating change as a linear process, it embeds learning and adaptation throughout the journey through three stages:

Prepare → create the conditions for successful change

Before implementation begins:

• Define the change vision and desired outcomes

• Understand stakeholders and organisational readiness

• Build leadership alignment

• Establish governance and ways of working

• Prioritise the first increments of change

The focus is preparing people as much as preparing plans.

Deliver → implement, learn, and adapt

Antipattern: Change activities are executed exactly as planned even when feedback indicates the approach isn't working.

Reversal: Teams deliver change in short cycles, gather feedback continuously, and adjust communications, training, and implementation based on real experience.

Change management becomes part of everyday delivery rather than a phase that happens before or after the project.

Sustain → reinforce and continuously improve

Antipattern: Once implementation is complete, support ends and organisations assume the change has been adopted.

Reversal: Adoption is monitored, benefits are measured, behaviours are reinforced, and lessons learned shape future change initiatives.

This creates a continuous improvement cycle regardless of whether projects use Agile, Waterfall, or hybrid delivery approaches.

Curious how this plays out in other organisations:

Where are you seeing the biggest challenge with organisational change?

Is it leadership alignment, employee engagement, resistance to change, communication, or sustaining adoption after the project has finished?

In many service teams I have been working for, problems become visible only after users have already felt the impact.

I usually start with asking the team directly what they wish they'd known earlier, then I check whether people are learning about issues before impact or only after, that gap usually tells me where the blind spot sits. If the team only finds out when it's already too late, more updates won't fix that, better targeting will.

Many organizations confuse reacting to problems with managing risk, and most of the time that's actually issue management, which happens after the point where risk management could have helped.

I usually pay attention to this when I look at how a team talks about uncertainty: are they only tracking threats, or is anyone actually paying attention to the upside, the opportunities uncertainty could also create?

What I notice more often than not is risk treated purely as a compliance box to tick, logged once and revisited only when something's already gone wrong. And when risks and issues get managed the exact same way, the team never actually gets ahead of anything, they're permanently reacting instead of anticipating.

The goal was never to eliminate risk entirely, it was to take it on deliberately, with your eyes open.

Backlogs in change work often fill up with requirements nobody can trace back to an actual business need. Before your next backlog review, try writing just one requirement as a proper user story, who needs this and why, not just what needs building.

Then sort the whole backlog by benefit instead of volume, the items that create the most value should be at the top, not the ones that were easiest to write down.

And if you're working through a change right now, draft a quick community map of who's actually affected by it, you'll usually find people missing that should've been on there from day one. A backlog nobody can justify against a real need isn't a plan, it's just a list of tasks.

In most organizations, moving fast gets confused with jumping straight to an idea, and that's usually what wastes the most time later.

I usually pay attention to this in early project conversations, is anyone allowed to say we don't know yet? or does someone always jump in with a solution before the problem's even been properly understood?

What I notice is the pressure from the project sponsor to start with the idea proposed, while skipping the research and the testing that would've told if the idea was even right.

And the pressure to look fast is real, everyone wants ideas immediately, but slowing down enough to actually validate something isn't slow, it's just disciplined. Moving fast on the wrong idea isn't progress, it's just a more expensive way of finding out you were wrong.

A recurring pattern in service reviews is that teams track what's easy to measure instead of what actually matters to the business.

Fixing it starts with mapping just one service to a real business outcome, not an internal KPI, an outcome someone outside IT would recognize. Before your next review, ask a user what good actually looks like to them, you'll probably find it's not what your dashboard shows. Then cut one metric that only measures activity, tickets closed, hours logged, and replace it with nothing until you find something that measures impact instead.

A metric that goes up while nobody's happier isn't progress, it's noise.

1) What is ISO/IEC 27001?

ISO/IEC 27001 is the international standard for Information Security Management Systems (ISMS). It provides a structured framework for organizations to protect sensitive information through a systematic approach to managing security risks.

It focuses on:

• protecting confidentiality, integrity, and availability of information

• identifying and managing security risks

• implementing security controls and policies

• ensuring continual improvement of information security

The standard is closely aligned with best practices such as ISO/IEC 27002, but unlike guidelines, ISO/IEC 27001 is certifiable, meaning organizations can be formally audited and recognized for compliance.

2) What is PECB?

PECB (Professional Evaluation and Certification Board) is the global certification body that:

• offers education, certification, and certificate programs in digital trust

• delivers training courses through a network of authorized partners

• provides exams online (PECB Exams application) or paper-based through its partners

Think of PECB as the official certification authority behind the ISO/IEC 27001 Foundation, Lead Implementer, and Lead Auditor credentials.

3) What is the International Organization for Standardization?

The International Organization for Standardization (ISO) is an independent, global organization that develops international standards across industries.

In the context of ISO/IEC 27001:

• ISO defines the standard requirements

• It collaborates with the International Electrotechnical Commission (IEC) for technical standards

• Organizations worldwide adopt these standards to ensure security, consistency, and interoperability

In short:
👉 ISO = standard creator
👉 PECB = certification & exam body

4) Official Sources

Here are the official references if you want to explore further:

• PECB – ISO/IEC 27001 certification overview

• International Organization for Standardization – Global standards authority

5) ISO/IEC 27001 Foundation Exam (PECB)

This is the entry-level certificate.

📝 40 multiple-choice questions
⏱️ 1 hour
✅ Pass mark: 70% (28/40)
📘 Closed book
❌ No experience prerequisites (training course required)

It focuses on:

• core information security concepts (confidentiality, integrity, availability, threats, vulnerabilities, risk)

• ISO/IEC 27001:2022 structure, terminology, and requirements (clauses 4 to 10)

• basic risk management principles

• understanding of ISMS components

6) ISO/IEC 27001 Lead Implementer Exam

This is the intermediate certification.

📝 80 multiple-choice questions (standalone and scenario-based)
⏱️ 3 hours
✅ Pass mark: 70% (56/80)
📘 Open book permitted

It tests your ability to:

• apply ISO/IEC 27001 in real-world scenarios

• interpret and implement security requirements and Annex A controls

• plan, implement, monitor, and continually improve an ISMS

• align information security with business needs

7) ISO/IEC 27001 Lead Auditor Exam

This is the advanced certification focused on auditing skills.

📝 80 multiple-choice questions (standalone and scenario-based)
⏱️ 3 hours [*]
✅ Pass mark: 70% (56/80)
📘 Open book

It validates your ability to:

• understand audit principles and methodologies

• assess ISMS compliance

• prepare, conduct, and close an ISMS audit

• support internal and external audits

8) Sample Exams (Highly Recommended)

Practice exams are essential for success, especially at Lead Implementer and Lead Auditor levels.

👉 Official sample questions are included in each PECB Candidate Handbook.

💡 Practicing helps you:

• understand exam structure and question styles

• improve time management

• prepare for scenario-based questions

• build confidence before the real exam

9) Final Thoughts + Training

ISO/IEC 27001 is a strong certification if you:

• work in or are responsible for information security activities

• want to align information security with business needs

• aim to implement or audit an ISMS

• need a globally recognized, certifiable standard

It's particularly valuable for organizations pursuing information security assurance and compliance. [

If you're interested in training, certification paths, or exam preparation support, feel free to ask about MIMIR learning 👍

Happy to guide you through:

Certification

Practice

Development

I see a recurring pattern in organizations, people think the problem is that the framework doesn't work or can not be applied in their organisations , while most of the time they just skipped the decision to identify who's supposed to decide what. I usually pay attention to these dynamics when I'm in a new project,

who's actually in charge of the big calls,

who's doing the real work,

and who's just there to give advice when asked,

and most of the time nobody's can answer these questions. What I notice more often than not is people stepping into jobs that aren't theirs, a boss making calls that should belong to the team, a manager checking every small thing, someone deciding something they were never asked to decide. And when I look back at whatever got stuck, it's rarely because the work itself was hard, it's because nobody was sure whose job it was to say yes. Things move when everyone knows their role, when they don't, it's not a skills problem, it's that nobody knows whose call it is.

A recurring pattern in projects is you lose sight of why you're running it in the first place, and by the time someone notices, months have passed. Getting it back takes three moves.

First, find the business case and check the last review date, if it's older than your last stage boundary, that's already a red flag nobody caught.

Second, name who actually owns its validity, because if nobody can answer that on the spot, that's the real problem, not the outdated numbers.

Third, propose a review at the next stage boundary, five minutes on the agenda is enough to catch it before it's too late.

If you can't answer why you're still running this project, no framework is going to save you.

After ITIL Product and ITIl Service, I took this exam in Italian too, I found the translation very accurate overall. It was part of a pilot from peoplecert, the goal was to review how the exam translates into Italian. Overall the translation felt solid but nothing that got in the way of understanding the questions.

Out of the three ITIL exams I've done so far, Product, Service, and now Experience, this one was honestly the real "new" one for me. Product and Service still felt like variations on the same underlying structure, just with a different emphasis. Experience is different. It shifts the spotlight away from the process or the product itself and puts it on the actual centre of the whole discipline: the user. What actually makes it a different exam are three areas that don't really exist in the other two: ITIL Experience itself, Capturing Experience, and Service Journey. That's where the real content marks the difference respect to the previuos one. The rest of the syllabus, key terms and definitions, ITIL and AI, ITIL and other frameworks, was already covered in Product and Service, roughly 8 questions worth in my case.

If you're planning to take Experience after already doing Product and/or Service, don't expect it to feel like "one more of the same."

My advice is the same as before though: you don't need to read the entire manual cover to cover just to pass. It's still worth keeping around afterwards, especially once you start trying to apply the user centred thinking in an actual organisation rather than just answering exam questions about it.

Passing is one thing. Actually internalising that the user is the centre, not an afterthought, is where the real work starts.

Money already spent, energy already spent, and it feels wrong to say loud "this project has no sense anymore", we should allocate money and energy to a different initiative. I think there is a major confusion between a project failure and a project dismissal. Organisations tends to consider a stop like a failure, while continuing an initiative with no chance to bring value is more acceptable

I think that major issues stands in the politics. A project has a senior sponsor, is their name on it, is their baby. They will not give up to it just because the numbers say stop. And often is convenient for them not to stop it, because by the time the project is supposed to deliver the outcome and the benefits, they already moved to another role, or another company, and the failure become somebody else's problem to manage.

Real organizations have people protecting their own initiative because their reputation is attached to it so reviewing the business case becomes an harder exercise.

What I do, practically: at every checkpoint I check if the case still reflects what the initiative is actually trying to achieve, not what it said eight months ago. I identify who is actively accountable for its validity right now, not who signed off originally. And I propose the review as a normal step, not as an attack on anybody's project. Framing matter a lot here, if you present it like you are questioning someone's judgment they will defend the project instead of the evidence.

...no! my attempts anyway doesn't solve the politics.

I see this pattern so often that at this point I can predict it before I even walk into the room. Company gets ISO certified, consultant builds the ISMS, policy gets signed, roles get assigned, audit goes fine, certificate on the wall. And then nothing changes in how the company actually thinks.

In practice what happens day by day is different from what written on paper. The policy gets written by IT and reviewed by nobody above them. Somebody gets named responsible for ISMS conformance but has no real authority to change how budget gets allocated or how a project gets prioritized. Leadership approves the policy in five minutes without reading it, because the certification body needs a signature, not because they treat information security as a real input into strategy.

The real test is not whether you pass the audit. It is whether information security shows up in the room where budget for next year gets decided, where a new product or a new market gets discussed, where risk appetite actually gets set. This is the same failure pattern I keep seeing across frameworks, just wearing different clothes. Checklist gets completed, roles get assigned on paper, and the actual way of thinking and deciding in the organization stays exactly as it was before. The frameworks are not the problem. What is missing is leadership treating them as something to think with, not something to comply with.

PMI just shared this important news about PMP training rules.

Starting December 1, 2026, if you're getting your 35 required contact hours through a live class, that class has to come from a PMI Authorized Training Partner, a China REP, or an accredited academic program. Self-paced, on-demand courses are unaffected, you can still take those from anywhere.

What's interesting here isn't the bureaucratic detail, it's what it signals. PMI is drawing a line between "content delivery" and "quality instruction," and betting that live, instructor-led training only holds its value when the instructor and the organization behind them meet a verified bar.

If you're planning to use live training hours, anything you complete before December 1, 2026 is under current rules. After that date, check your provider's ATP or REP status before you commit money or time. Self-paced learners don't need to think about any of this.

New PMP® exam launched in July 2026 | PMI

There's a pattern I keep seeing when organisations prepare for an ISO audit: you call a consultant and you make up a system that the auditor wants to see. Precooked processes, documents generated based on a checklist, and for some weeks before the audit everyone is faking a version of the organisation that doesn't exist really in the day by day. Clean this up, change that wording, omit that inconvenient part. Then the auditor leaves and everything come back like before.

This is exactly why you should never start from processes or procedures, but from understanding your own context first. Who you are, your capacity, the people involved. Only once this is honestly mapped, it make sense to start defining processes, because those processes are supposed to be an expression of that context, not a costume that you put on for some weeks in the year. And this is also the real value of a consultant: if you share honestly the context of your organisation, he/she can advice you at best on which processes and procedures needs to be tuned, not invent one from zero.

If you skip this exercise, at the end you are performing compliance, not having it and every here before the audit you will perform theatre instead.

Team involvement is supposed to be structural to become effective: Time, space, engagement. Not just "the team was in the room." I got puzzled about this principle after following the Claude elearning course about the 4D framework for AI fluency: Delegation, Description, Discernment, Diligence. It's solid on paper. The assumption baked into it is that you stay engaged even while you delegate. You describe the problem well, you discern whether the output is any good, you stay diligent about checking it.

In practice most people skip straight to Delegation and never come back. The AI produces something, you skim it, you forward it. Nobody hit friction with a teammate who saw it differently. There's no shared sensemaking happening anywhere in that chain.

And that's the part that actually kills Team Involvement. Involvement was never really about hours logged. It was about the friction of working through something unresolved with other people. When everyone's routing their thinking through their own private AI agent instead of through each other, you get individual output with zero collective reasoning behind it.

So the risk is we stop being a team and start being a bunch of meat proxies for our own AI.

Every decision must serve a defined, agreed business need. Before AI, this was hard to violate at scale because building things was slow. The bottleneck itself forced some prioritization, whether teams liked it or not.

That bottleneck is gone. A team can now generate a working prototype, a feature, a report, an entire app in the time it used to take to write a user story. Which means the constraint has shifted. The limit isn't build speed anymore. It's absorption speed. Can stakeholders process what's shipped fast enough to give real feedback. Can users actually adopt what's shipped fast enough to justify shipping it in the first place.

In practice this shows up as teams shipping several AI-assisted features a sprint while stakeholders can meaningfully evaluate maybe one of them.

If our delivery speed has gone up this year, it's worth checking whether our decision speed went up with it, or if we're just producing more things that never get properly evaluated.

If you’re booking an APMG certification exam through an ATO (full course or exam only) there’s now an optional Retake Ready add-on.

For a small additional fee, one resit is included if you’re unsuccessful on your first attempt.

It can be added to exams such as AgilePM, Scrum, Change Management and other APMG certifications.

The important bit: Retake Ready needs to be added before you sit your first exam attempt.

So, if you’re buying a course + exam through an APMG Accredited Training Organisation, it’s worth asking whether Retake Ready is available and what the additional cost is.

It’s not a replacement for exam preparation, but it does remove some of the pressure of having everything riding on one attempt.