Stoicism, at its core, is a philosophy of virtue, self-mastery, and service to society. Yet, in recent years, it’s been misinterpreted and co-opted in ways that distort its true meaning. It’s time to reclaim Stoicism from the caricature of “Broism” and return to its classical roots—not just as a philosophy, but as a practical foundation for how we lead, especially in complex environments like projects where pressure, uncertainty, and people dynamics collide.

Broism turns Stoicism into a veneer of emotional detachment, a justification for selfishness, and a badge of superiority. True Stoicism, however, demands something far deeper and far harder: it demands that we live justly, courageously, wisely, and with discipline—not for ourselves, but for the betterment of the world around us. In project leadership, this shows up in how we make decisions under pressure, how we treat stakeholders, and how we carry responsibility when outcomes are uncertain.

Key distinctions between classical Stoicism and its modern misinterpretations:

• Justice Over Ego: Stoicism isn’t about winning at all costs or asserting dominance. To be a Stoic is to contribute to society with fairness and equity, not to manipulate it for personal gain. In projects, this means prioritizing the success of the team and the integrity of the outcome over personal recognition or political advantage. Justice is the foundation of both Stoicism and credible leadership.

• Courage to Face, Not Avoid, Emotions: True Stoics don’t suppress emotions—they acknowledge and confront them with reason. Emotional avoidance is weakness masquerading as strength. Real strength lies in addressing tension, conflict, or uncertainty directly and choosing to act constructively. For a project leader, this means having the difficult conversations, making the unpopular call when needed, and staying present when things go wrong.

• Wisdom Over Simplicity: Broism offers easy answers—win, dominate, suppress. Stoicism asks harder questions: What is within my control? How should I respond to adversity? What does it mean to act rightly here and now? These questions demand reflection, not reflex. In project environments filled with ambiguity, this is the difference between reacting to noise and making decisions that actually move things forward.

• Discipline as a Daily Practice: Stoicism isn’t about bravado; it’s about quietly doing the work. Discipline means showing up every day to improve yourself, to help others, and to live up to your potential, even when no one is watching. In project leadership, this is consistency—following through, maintaining standards, and creating stability for others when circumstances are anything but stable.

Subscribe now

Stoicism isn’t about avoiding life or feeling superior to others—it’s about engaging with life fully and making the most of it. It’s about controlling what we can—our actions, choices, and judgments—while still taking responsibility for improving what we influence, including team dynamics, stakeholder alignment, and the outcomes we are accountable for.

The appeal of Stoicism lies in its demand for effort and excellence. It’s not a shortcut to power or emotional detachment. It’s a call to live and lead virtuously—to bring clarity in chaos, steadiness under pressure, and a consistent focus on what truly matters.

Let’s reclaim Stoicism from its misuses and restore it to what it was always meant to be: a philosophy for thriving in a chaotic world—and for leading others through it—not for self-aggrandizement, but for the benefit of all.

For Project Leaders & Consultants

The goal is to provide concrete advice and share experiences from delivering projects.

A little background

My name is Jim Morris.

I was born in the US, served in the US Army, and moved to Denmark in 1993. I completed a degree in IT and have spent 30+ years working on and delivering projects.

I started as a developer, moved into consulting and project management, and have also worked across most Agile roles—Scrum Master, Product Owner, Release Train Engineer, Agile Coach—before returning to “pure” project management.

From late 2023 to early 2026, I led a team of PMs in a Nordic ERP consulting company while also running smaller projects.

From about Jan 2026, I went back to focusing fully on leading ERP projects. I realized I prefer helping organizations directly over leading internal transformations.

Why Better Project Leadership exists

Around the time I turned 50, I started reflecting on what I actually knew about the job I’d been doing for years.

I began writing for myself. To structure experience. To cut through the noise. To think more clearly.

I wasn’t trying to build a framework or a methodology. I was capturing what actually works:

• Concepts

• Decisions

• Tools

• Trade-offs

That body of work is something I continue to refine.

Now, moving into my 60s, I want to share it.

That’s where Better Project Leadership comes in.

How I structure the content

To be the best project leader you can, you need a holistic view: how you develop, what you do, and how you decide & behave

Approach: Adaptability is key

Better Project Leadership (BPL) is built on four pillars:

• Mastery through Progression — build expertise through fundamentals and real-world application

• Respecting Foundations — use proven frameworks as a base

• Staying Current — adapt to modern tools and changing environments

• Mindset Resilience — lead with clarity, focus, and composure

These ensure you stay adaptable for whatever the future brings—and shape everything I provide here.

Capability: Four focus areas

To keep things practical, I write across four areas:

• Business Acumen — how businesses operate and create results

• Leadership — achieving outcomes through others

• Personal Health — sustaining energy and performance

• Skills & Tools — executing effectively

Philosophy: Dealing with complexity

Stoicism, for me, it’s a way to think and operate under pressure - and a guide to living a “good” life.

The four Stoic virtues map well to my work:

• Courage — act despite uncertainty

• Discipline — do what needs to be done

• Justice — treat people fairly

• Wisdom — focus on what matters

Free and Paid

BPL will stay generous with free content.

Short, practical insights from 30+ years of real project work. That’s the foundation.

But some want more than ideas or short information bombs.

Some of you want the “How?”—to apply it, adapt it, and make it work in your own context.

That takes more time and focus.

So I’m introducing a low-cost paid option to provide:

• More in-depth articles

• Practical “What, Why and How?” breakdowns

• Occasional small-group live sessions

• A chat to dive into your specific scenarios and share with others

Paying a nominal fee is also about commitment.

Free content is easy to consume. Paid creates intent—on both sides.

You invest a little. I invest more time going deeper and focusing on what actually helps you improve.

If you see yourself in any of this, you’ll likely get value here.

This is as much a continuation of my own journey as it is a place to share it.

Take what’s useful. Apply it. Make it your own.

ShuHaRi is a powerful concept from Japanese martial arts that illustrates the journey from novice to master. It’s a framework not just for learning but for transformation.

This philosophy helps form the backbone of Better Project Leadership and how we approach growth in project management.

The stages of ShuHaRi mirror the trajectory of a Project Manager’s career:

• Shu (守): Learn the Fundamentals
  In the Shu phase, you immerse yourself in the basics. It’s about mastering the core principles of project management, following established methodologies, and practicing rigorously. Think of it as building a foundation—solid, steady, and reliable.

• Ha (破): Break Away and Innovate
  In Ha, you start seeing the “why” behind the “what.” With a firm grip on the basics, you experiment and adapt. This is the stage where you begin to tailor processes to your unique challenges and develop your personal style as a Project Manager.

• Ri (離): Mastery
  Ri is about transcendence. The rules no longer constrain you because you’ve internalized the principles. At this stage, you’re not just leading projects—you’re evolving the practice of project management itself. You can mentor others, innovate, and contribute to the discipline at a higher level.

By framing your development in terms of ShuHaRi, it should help you grow deliberately and effectively.

Whether you’re just starting out, looking to refine your craft, or aspiring to become a thought leader in project management, this framework provides a clear path forward.

Adaptability isn’t just a buzzword—it’s the cornerstone of effective project leadership.

In an environment where technology evolves daily and market conditions can shift overnight, project leaders and teams who resist change are simply signing their own obsolescence.

Here’s why adaptability is non-negotiable:

• Projects Rarely Go as Planned: Even the most meticulous plans face unexpected hurdles. A key resource quits, a client’s priorities change, or a global event throws timelines into chaos. The question isn’t if challenges will arise but how you’ll respond when they do.

• Stakeholder Needs Evolve: Clients and stakeholders don’t always know what they want at the start. New insights or competitive pressures may lead to shifting expectations. Teams that adapt without losing momentum build trust and deliver value.

• Innovation Demands Iteration: Standing still is a luxury no one can afford. Teams need the flexibility to pivot, experiment, and course-correct quickly to stay competitive.

Adaptability in Project Leadership

For project leaders, adaptability starts with mindset. It’s about staying calm under pressure and making decisions based on principles, not panic. Adaptable leaders:

• Balance Justice and Courage: ensure decisions are fair to all parties while having the courage to make tough calls.

• Embrace Wisdom and Discipline: listen, learn, and act decisively, even when the situation is fluid.

Building an Adaptable Team

Adaptable teams don’t happen by accident; they’re nurtured. Here’s how:

• Foster a Safe Space: Encourage experimentation and normalize learning from failure. Teams that fear mistakes won’t pivot when needed.

• Build Resilience: Equip your team with diverse skills. Cross-training and exposure to different challenges prepare them for the unexpected.

• Communicate Ruthlessly: Transparent, frequent communication ensures everyone understands priorities, even when they shift.

Adaptability isn’t just a skill; it’s a survival trait. As a project leader, your ability to embrace change and guide your team through uncertainty will determine your success.

Projects may be unpredictable, but your response doesn’t have to be. Lead with adaptability, and your projects will thrive—no matter what comes your way.

Stoicism, a philosophy born in ancient Greece and refined in Rome, offers timeless wisdom for modern challenges. Rooted in principles of resilience, focus, and ethical leadership, it’s a guide for navigating the uncertainty and complexity of project management.

Here’s why embracing Stoicism can make you a better project leader.

• Focus on What You Can Control: Projects are riddled with variables you can’t manage—stakeholder opinions, market shifts, and unforeseen risks. Stoicism teaches you to distinguish between what you control (your actions, decisions, and mindset) and what you don’t. This clarity reduces stress and helps you channel energy into productive action.

• Respond, Don’t React: When projects go sideways, emotions run high. Stoicism emphasizes the power of response over reaction. By pausing, assessing, and acting intentionally, you avoid escalating conflicts and lead your team with calm and confidence.

• Embrace Setbacks as Opportunities: Marcus Aurelius wrote, “The impediment to action advances action. What stands in the way becomes the way.” Challenges in projects are inevitable, but Stoicism reframes these moments as chances to grow—whether it’s learning from failure or finding innovative solutions.

• Ethical Leadership: At its core, Stoicism prioritizes virtue: wisdom, courage, justice, and discipline. As a project leader, this means making decisions that align with long-term values, not short-term gains. Your team will respect you more for integrity than for quick wins.

• Daily Reflection Improves Leadership: A Stoic habit of reflecting on your day—what went well, what didn’t, and how to improve—builds self-awareness. This practice sharpens your ability to lead with intention and strengthens your resolve to tackle tomorrow’s challenges.

Project management isn’t just about Gantt charts and deliverables; it’s about managing yourself and others under pressure. By adopting Stoic principles, you become a leader who not only delivers results but also inspires resilience and clarity in your team.

The world of project leadership is chaotic. Stoicism is your anchor.

Many years ago I started using the phrase “Watermelon Project Management.”

A watermelon looks green on the outside, but red on the inside.

In projects this happens when the status presented to stakeholders looks healthy on the surface, while the real situation inside the project is struggling.

Most project managers have seen it. Many of us have probably been tempted by it.

Why it happens:

• Pressure to show progress

• Fear of disappointing the client or sponsor

• Hope that the problem will solve itself next week

• Desire to protect the team

But over time this approach almost always makes things worse. Problems grow. Trust erodes. And when the truth finally appears, the recovery becomes much harder.

The discipline that counters this is transparency.

However, transparency is often misunderstood.

For me, transparency does not mean:

• Escalating every small issue immediately

• Publicly exposing team mistakes

• Over-sharing internal discussions

• Being blunt or confrontational

Instead, I see transparency as a professional virtue in project management.

It means:

• Being honest about the real situation

• Raising issues at the right time

• Bringing potential solutions, not only problems

• Giving stakeholders the information they need to help the project move forward

Transparency builds trust. And trust gives a project the room it needs to solve problems early.

In the long run, stakeholders can handle bad news. What they struggle with is surprises.

So the goal is simple: no watermelon projects.

Just honest status, constructive conversations, and steady progress.

How do you practice transparency in your projects?

I had a recent conversation and was reminded of an opinion I’ve had for several years now: Technology (currently AI) is not coming for roles: consultants, developers or configurators.

It is coming for their tasks.

Background

Many people still follow a simple loop:

• Receive task

• Build slides, code or configuration

• Deliver output

This worked when information and execution were expensive. Now AI can research, write, code, test and configure faster than any team.

If our value is only execution, we become replaceable.

The real risk is acting like trained monkeys or dumb robots — waiting for instructions and repeating what we are told.

AI struggles with several aspects, but most relevant in this context:

• Understanding messy organisations

• Handling ambiguity and trade-offs

• Taking responsibility for outcomes

The people who thrive will:

• Take ownership beyond the deliverable

• Adapt when reality breaks the plan

• Redefine problems, not just solve them

• Connect dots across business and technology

The shift is simple: Move from task executor to problem owner; otherwise you compete with software... and it will win.

So how was your 2020? And what plans do you have for 2021?

About this time of the year, I think many of us reflect on how the last 12 months have been. My plan was to focus on giving back to my professional community (Agile Project Management), get in better shape (an original of course) and get back to riding a motorcycle (cliché I know for a man on the best side of 50).

So how did I do?

Giving back to the professional community: Well I started ScrumPatterns.dk(helped by another Scrummer) and LeanAgilePractitioners.com both have varying success - helped and hindered by Corona. Although we couldn’t meet in person, we probably got to meet more often.

I also was given the opportunity to help others in my community on their own professional journey through 1-on-1 talks, which didn’t have the formalities of coaching, but were close.

Get in better shape: Ever since being in the military, I have somewhat used their standards as a baseline. I can easily do the the sit-ups and pushups for a guy half my age, but the running… erhm, well who needs to run when I have a car?

I’m satisfied where I am and have even taken up fasting - which I recommend - and I’m currently working towards being able to bench my body weight 3 times (another baseline I strive for).

Get back to riding a motorcycle: A major success. After 30+ years of not riding, I purchased a used Honda in the spring, sold it to my son soon afterwards (to celebrate him completing his Masters degree, big congrats to him) and bought myself a newer BMW.

He and I have gone on many smaller trips and took a 6-day Tour de Denmark in the summer. We have plans for 2021 so I couldn’t be more satisfied.

So what about 2021?

Here is what I am planning:

• Continue to give back to my community as well as offering more professional services

• Deep dive in the Customer Relationship Management (CRM) universe

• Bench my weight 3 times (so either lose more or pump it up)

• A 6-day trip (preferably with my son) on my MC

Let’s see how next year goes - either way, I’ll give status here.

Here’s hoping you and yours are safe and healthy and the new year brings you happiness.

I was reading a blog post from Mike Cohn where he made a point of the dangers for an organization (Scrum team?) failing due to the ability to not take more risks.

I completely agree and offer a tool - a slide really - to help teams take more risks.

Risk adverse Scrum teams

In my experience, software development teams tend to consist of people who really want to get it right… preferably the first time.

I see this firstly when they want to have all the possible scenarios or paths covered in the Story. The level of detail gets to be overwhelming even if they attempt to split/slice the Story (which is another practice I encourage).

And once the Sprint starts, adversity to risk appears in the form of over engineering and gold-plating which I believe is due to a few traits:

• Pride: “I want to make sure it’s the absolute best code I can deliver because my name is on it”

• Fear: “I don’t want the others to criticize my work”

• Trust: “I’m afraid the others will…”

• … and likely others

The result is over burdensome discussions, slowed progress and general frustration.

Encouraging risk taking

Done well, Scrum is great at managing risk: the risk that you don’t deliver what is really required by your customers and the risk that you miss your deadlines.

To help encourage risk taking, I use the following slide:

There are several points I’m trying to make here:

• Not all questions need to be answered before we take a Story into Planning or the Sprint

• The Definition of Ready/Done are tools the team can use to help manage the risk and set expectations

• I’ve suggested some percentages, but the team needs to agree on what their acceptable level of tolerance is

• It’s OK to take risks and there is a certain level of uncertainty in what we are doing

• We’re expecting to fail due to a an acceptable level of uncertainty, but we’ll do it fast and adjust.

I tend to briefly point out the different areas of the slide and then ask the team for comments or input: “What thoughts does this trigger in you?”, “Which challenges do you see if we don’t have a common understanding of this?”.

I want them all - including the Product Owner - to get the same message directly from the Scrum Master: it’s OK to not be 100% sure.

Just having this slide up and speaking out loud gets the team to start having another midset and eventually taking more risks.

What’s needed

Trust is needed for this to work because you are likely asking people to change their behavior and to move their comfort level. There may be a organizational tradition of consequences for failing. In the extreme - careers may be affected. So keep this in mind if you decide to work with taking more risks.

Building trust is another article, but just taking this subject up during a Sprint Review or Retrospective, can get the ball rolling. Reminding people that it’s OK when a risk was taken and it bites back (risk is realized). Reassuring when you can see people struggling to take the leap (”Is this Story really Ready?”).

I also think it’s valuable to consider the impact of taking a risk. Often times, people don’t take risks because they can’t imagine or fully comprehend the impact if the risk is realized. By addressing this head on - “What is the impact of taking this Story in you don’t believe is Ready?” - you help them put words to their concerns and feel comfortable taking that step into the unknown.

Note: If you’re a Project Manager, I’m not suggesting to replace your existing risk management process - something I consider more strategic or long seeing. This is for the individual Scrum team members to work with.

Your experience?

So what do you think? Do you struggle with taking risks on your team? I’d be interested in hearing how you help encourage risk taking, if at all. Maybe you don’t think a team should take risks?

Whatever you think, I’d be interested hearing from you.

If the title of this article offends you, then you’re probably a Scrum/Agile purist. If it doesn’t, but piques your interest, then you’re likely someone who has recently started working with Scrum and are thinking, “I know the Product Backlog and even the Sprint Backlog, but I’ve never heard of the the Scrum Master Backlog”.

The Scrum Master Backlog is a term I started using after having to explain to the teams/stakeholders I work with, my somewhat structured plan for team development. If you’re a Scrum Master, then I’m sure you have this as well, you just may call it something else like… “what I do”.

So it’s basically all the topics, disciplines, best-practice, activities, etc. I take a Scrum team through while going from Forming to Performing (thank you Mr. Tuckman).

Where to start?

As an external consultant, I’ve had to roll onto projects at several clients, across a handful of industries and in several countries. I needed to orient myself and begin finding solutions to the areas which could be improved as soon as possible.

When the contract is to be a Scrum Master or Agile Coach, I look for telltale signs of the most fundamental concepts/practices I expect from a Scrum team.

These include, but are not limited to, what you’d typically expect:

• Definition of Done

• Definition of Ready

• Product Backlog

• List over blockers

• Team Working Agreement

• Explicit role expectations

• …

These are examples of items on my Scrum Master Backlog.

The list is not a sequential, step-by-step list that I have to follow, but it’s more like a catalog of “Greatest Hits” containing what’s worked for me before and from which I can use as inspiration.

Explicit Expectations

That last one in the above list is one of my key topics I start with. It’s important to express these openly and perhaps with some provocation.

For example, one of the responsibilities I place on the Product Owner (the PO), is that it is his/her role to get stories in a Ready state, so the team can bring them into the Sprint.

I also tell the development team, that they will likely need to help the PO with for example technical drawings, subtask, reasonable Accept Criteria, etc - but it’s the PO’s baby. The PO needs to drive any (refinement) meetings or clarifications in order to get the story Ready.

The development team’s “Definition of Ready” is the gate the PO needs to get through.

On the flip side, the development team needs to ensure that when they say something is Done, that it lives up to the PO’s gate - Definition of Done (DoD).

Don’t purely rely on what you find on scrum.org. Use your best judgement and define the roles as you feel is needed for your specific team. Don’t hold back here - dare to provoke and drive a conversation.

[As a side note, not having this one item - explicit role expectations - causes more frustration or drama than you’d imagine]

Pragmatism

Another one of my guiding beacons is doing what seems to makes sense, and then adjust as needed - but do something.

So you may object to the above section on explicit expectations. For example, if you think “The PO only represents the business and shouldn’t be concerned with refinement” or maybe, “The DoD is the development team’s so keep your hands off it, Mrs. PO!”, then I think you’re missing the point.

What’s important here is that there are clear expectations between each party and we have a chance to fulfill these expectations. That there is a baseline we can start with and adjust as needed.

I’m working here to change the mindset of the people to experiment - to not let the 20% (uncertainty) get in the way of an 80% solution.

Your Scrum Master Backlog?

The items in my Backlog tend to fall into these two categories:

• Something you can take with you back to your table after the meeting to help improve: concrete tools, definitions, visuals, …

• Something to affect your mindset, attitude or approach to a problem

I’m sure you have your own backlog - even if you’re not a Scrum Master. Maybe you’re a team lead or department manager. But you likely have a list of important values, working habits or goals you want to achieve.

As a leader of people, I feel a responsibility to serve them the best I can. Putting these items into a somewhat structured list with some prioritization helps me stay focused and try to live up to their expectations

So what do you think? Do you have anything like this? I’d be interested in hearing your thoughts.

Broadening my perspective

Every workday, between 0700 and 0900, I go through a list of selected blogs, articles and forums. These resources are purposly selected to keep my perspective on work-related topics as inspiring and broad as possible.

I try to completely get through this list everyday, but without fail, I usually end-up on some tangent topic far from where I started.

As an ex-developer who likes to experiment occasionally on iOS development, I like listening to David Smith‘s podcast called Developing Perspectives. One of his recent podcasts is titled “Insulated Perspectives“ and deals with the importance of keeping an open mind and looking for inspiration outside your usual circle of influence. The show notes are:

“...the importance of stepping back from the day to day inputs that can so easily mold or distort your views on things. The world is a varied and complex place and likely very different than the people and perspectives you interact with on a daily basis.” David Smith

I’ve lived this philosophy for some time now and have successfully applied it to my projects - especially during requirements gathering - and is a point I try to encourage when advising PMO organisations when defining (and monitoring) their success criteria. Getting out of your insulated environment to get other, not obvious input helps you understand your stakeholders better.

Feeling Smarter and not frustrated

David used an example of an iPhone owner who used an app - 2048. The 2048 app is (apparently) heavily inspired from another app and which was easier to score points than the original. Instead of a somewhat complicated approach to scoring points like the original, the 2048 app was easy to use and made the user feel like he was smart by making it easy to win.

This was an lightbulb moment for David as it caused him to reconsider if he was focusing on the right aspects in his own apps. Instead of David focusing on typography or graphics, maybe he should focus on the user experience and what works for him, the user, instead of what David, the developer, thought would be cool.

I believe much of what the others in David’s circle of influence tended to discussed making the apps profitable, technical aspects, AppStore politics

Where else could the PMO could look to get inspired?

So keeping in mind that the PMO is a service for the rest of the organization, the question the manager should be asking is, “What can the PMO do to make sure the organization regards us as valuable?” or “What can the PMO do to make our stakeholders (Executives, PMs, Finance Department, etc) easier?”.

Maybe it’s not the pretty graphics but up-to-date data aggregated daily. Maybe it’s not another template the PM needs to fill in, but helping them on the one they already have.

Chasing PMs from the water cooler

Consider that you are a member of the PMO and that you have a portfolio report you need to maintain which takes indivdual PM reports as input. You may be tempted to only focus on the PMs submitting reports on a regular basis and chase them from the water cooler when they don’t.

But what if you tried focusing on facilitating and assisting the PMs to gather the information they need for their reports? By making their life easier you end-up making it easier for them to submit their reports.

Customer-Focused Solutions

I read an excellent book several years ago about how different industries learned from each other. For example, how the airline industry learned a few tricks from NASCAR about getting a fast turn around while in the pit - a plane is only making money if it’s in the air.

So maybe as the PMO, you should look to another service like the reception area or the canteen. Are they doing anything special which allows them to provide a unique (valuable) service? How does publishing the weekly menu create a positive impact... if any?

At one company I worked for, the receptionist delivered the (snail) mail which created a good, personal relationship between them and the rest of us. Can implementing some personal - in person - service from the PMO create more value to the PMs?

So stop, take a look around and ask yourself: “Am I doing the right things, for the right reasons, for the right people?”

I was recently listening to a podcast over at Cornelius Fichtner’s PM Podcast and it brought back some experiences I had. The podcast interviewed Margaret Meloni who basically talked about trusting your intuition about resources’ actual progress on their tasks and some warning signs.

To illustrate the situation, Margaret tells the story of a line manager who told one of her direct reports not to spend too much time on project “B” before another piece of work was done on project “A”... even though the line manager had committed to allowing the direct report to be assigned both projects. This of course had a serious impact on project “B” when the time came for the resource to deliver his work.

For me, this really has to do with being professional and trustworthy. Every individual on the team is excepting the others to carry their load and to do what is expected of them or the project will likely fail.

How does this occur?

I may be naive, but I dont think anyone has purposely sabotaged one of my projects by not doing the work. When this has happened, I found the reasons included:

• Contradictory signals/”orders” from their line manager (like in the example above)

• That the resource didn’t fully understand how they contributed to the success of the project and/or how important the project was

• Over confidence in their ability to quickly get it done... waiting until the last minute

• The resource was just not good at managing their time and afraid of confronting the truth

Warning signs

Margaret brings up a couple of the warning signs when this could be happening:

• The “everything is fine...”, “no problems here, keep moving...”: I’ve seen this a few times at status meetings where, when everyone else had 5-10 minute discussions about where they are and challenges with their work, but their is one who just wants to get it over with... that are not as engaged as you’d expect

• Don’t attend status meetings: even worse, they don’t even attend status meetings or avoid you in the halls and lunch area

Key message: Trust your PM instincts and don’t be afraid to confront actual progress of a task.

What can a PM do?

First of all important to remember NOT to turn this into a witch hunt... that we dont let the resource get the feeling that you dont believe/trust them. Even if this person is deliberlately sabotaging the project, it’s important to focus on getting the task back on track, switching resources if needed.

But what can be done to prevent this? Can you have a canary in the mineshaft?

• Strive to have a deliverable for each member for at least every other status meeting... there needs to be some way for the resource to show tangible progress. This approach will also reduce risk about requirements gathered and better predict whether or not the project is on target

• Attend some kind of review meeting (ie. code review, documentation, etc)

• Followup with others who should be involved with the work that person should be doing (i.e. “Dear Mr Client, How did the meeting last week go with the developer?”)

• Make sure the Line Manager understands the importance of the task, that the project has executive support, that the project is part of a strategic initiative, etc

• Make sure the Line Manager is part of the reporting/communication plan - highlighting the work that person is (should be?) doing

• If your organization has a PMO, ask them to do one of the above as an audit

How the PMO can help:

As almost an outside 3rd party, the PMO can be a valuable resource helping deal with this:

• Remind the PM to stay proactive, to trust their instincts and confront the situation

• Offer to attend one of the status meetings to get their assessment

• Get formal (re-)commitment from the Line Manager. This should have been done during project selection, but there may be a need to remind everyone of the priorities

• Highlight the resource commitments. The Line Manager may be reluctant to fully commit resources because of not knowing what future resource commitments his resources have

• Make it easy for the Line Manager to report changes to resource commitments (more on this in next section)

• Make sure the process/methodology “strongly suggests” the PM get involved and maybe even have this as a metric... which would help the PM have a reason to followup with the resource “I know it’s it aggrevating, but the PMO says I have to join at least one review meeting pr month.”

What can the Line Manager do?

Ideally, the Line Manager should have been aware of the commitments his resources had before committing the resource to the project. But life happens, projects get delayed and knock-on effects impact other projects.

So the organization needs to have a culture of openly addressing the changes and have them dealt with. Maybe the Line Manager is on the stereo of the project where a change request or even an issue can be raised. If not, then contact the PM(s) of the affected projects and have them do it.

And sometimes back-room deals are done between line Managers. But at a minimum, the affected PM(s) should be made aware so the plans can be updated.

Why confront the situation?

You may be asking yourself, “Why even get involved? If someone doesn’t deliver, and they say they are working on it, then it’s on them”. Sure, you may have documented it in the minutes... that they gave a green light on progress and you have formal commitment from their line manager. But in the end, you, as the PM, are left holding the bag.

So it’s better to have the discussion at the begining of the problem rather than when you hit a roadblock and it can’t be managed between yourself (the PM) and the Line Manager... even worse, when the CIO or CEO needs to get involved.

The impact of a resource not delivering from your project will likely - somewhere - impact another project or part of the organization.

Plus, I’ve always found it just feels better not to pass the buck to someone else or hold someone hostage.

So let’s get this dealt with today.