Skip to main content

Tag: stories

PMTimes_Jun12_2024

Harnessing Polyvagal Theory and Neuroception for Effective Cross-Cultural Project Management in Agile Environments

Written by Dr. Geoffrey Vanderpal and Dr. Randy Brazie on . Posted in Articles.

In the rapidly changing developments in project management, professionals are continually seeking innovative approaches to enhance team dynamics and improve project outcomes. One such approach is applying insights from Polyvagal Theory and the concept of neuroception, particularly in managing cross-cultural teams within Agile frameworks. This article explores how these neuroscientific concepts can be used to better understand and lead diverse teams, ensuring successful project management outcomes.

 

Polyvagal Theory in Project Management

Polyvagal Theory, developed by Dr. Stephen Porges, provides a framework for understanding how the nervous system responds to various social and environmental cues. It emphasizes the role of the vagus nerve in regulating physiological states associated with social engagement and stress responses. In a project management context, especially in cross-cultural settings, this theory can help managers foster environments that promote cooperation and reduce conflict.

Applied Scenario: Consider a project team consisting of members from various cultural backgrounds working on a software development project using Agile methodologies. The project manager notices that during sprint planning meetings, some team members seem disengaged or anxious, which could be due to differences in communication styles and social interaction norms. By applying Polyvagal Theory, the manager introduces more frequent but shorter meetings with clear, structured agendas that provide all team members with the opportunity to prepare and participate comfortably, accommodating different communication preferences and reducing physiological stress.

 

Neuroception and Its Impact on Team Dynamics

Neuroception describes the way individuals subconsciously detect and react to signals of safety or threat in their environment. Understanding neuroception can be particularly beneficial in cross-cultural project teams, where unrecognized cues of threat can undermine team cohesion and productivity.

Applied Scenario: In an Agile project team, a new member from a different cultural background joins the group. The team’s initial interactions are somewhat formal and reserved, which might inadvertently send cues of threat or exclusion to the new member. The project manager, aware of the implications of neuroception, arranges a team-building activity offsite, designed to include elements of each team member’s culture. This not only helps in sending strong cues of safety and inclusion but also improves overall team neuroception, fostering a sense of belonging and security.

 

Strategies for Applying Polyvagal Theory and Neuroception in Agile Project Management

  1. Enhanced Communication Protocols: Tailor communication strategies to meet the diverse needs of the team. This includes using clear language, avoiding idiomatic expressions that might not be universally understood, and encouraging open feedback in a non-threatening manner.

Objective: Develop communication protocols that reduce misunderstandings and promote inclusiveness.

Actions:

  1. Customize Communication Styles: Adapt communication methods to suit diverse team members, taking into account varying cultural norms about directness, formality, and context.
  2. Clear Language Use: Simplify language to avoid idioms and jargon, ensuring that all communications are easily understandable by non-native speakers.
  3. Structured Socialization Processes: Integrate structured socialization processes into the project lifecycle. For example, start each iteration with a short, informal catch-up that allows team members to share personal updates or cultural insights, thereby enhancing interpersonal bonds and reducing potential threats perceived through neuroception.

 

Objective: Create regular, structured opportunities for team members to interact in a non-work context, enhancing interpersonal relationships and safety cues.

Actions:

  1. Scheduled Social Sessions: Integrate time for personal sharing or cultural presentations during regular meetings.
  2. Cultural Exchange Activities: Organize activities that allow team members to present aspects of their culture or personal interests, fostering mutual respect and understanding.
  3. Environment Optimization: Optimize the physical or virtual meeting environment to reduce cues of danger and enhance cues of safety. This could involve ensuring that the meeting space is welcoming and inclusive, using visuals and decorations that reflect a blend of team cultures, or utilizing virtual backgrounds and shared digital spaces that are culturally neutral and comfortable.

 

Objective: Modify the physical or virtual work environment to enhance neuroceptive responses of safety and reduce perceptions of threat.

Actions:

  1. Inclusive Decorations: Use culturally neutral or diverse decorations in physical or virtual spaces to promote inclusivity.
  2. Comfortable Settings: Arrange meeting spaces (physical or virtual) to be inviting and comfortable, with considerations for privacy and personal space respected.
  3. Training and Workshops: Conduct workshops that educate team members about the importance of the nervous system in social interactions and team performance. Include training on recognizing one’s own physiological states and understanding others’ reactions, which can be crucial in managing cross-cultural interactions.

 

Objective: Equip the team with knowledge about how their nervous systems influence social interactions and decision-making.

Actions:

  1. Workshops on Polyvagal Theory: Provide training sessions on how the vagus nerve affects emotions and stress responses.
  2. Training on Neuroception: Teach team members to recognize how their environment and interpersonal interactions influence their subconscious safety and threat perceptions.
  3. Regular Check-ins: Implement regular check-ins with team members to understand their comfort levels and gather feedback on the social and emotional aspects of team interactions. This can help in identifying hidden issues that may affect team dynamics and project outcomes.

 

Objective: Establish a routine of checking in with team members to monitor their comfort levels and gather feedback on implemented strategies.

Actions:

  1. Regular Feedback Sessions: Schedule time during meetings for team members to provide feedback on their feelings and any issues they are facing.
  2. Anonymous Surveys: Use anonymous surveys to allow team members to express concerns they might not feel comfortable sharing openly.

 

Next,  Monitor, Adjust, and Iterate

Objective: Continuously evaluate the effectiveness of the implemented strategies and make necessary adjustments.

Actions:

  1. Ongoing Monitoring: Regularly assess the impact of changes on team dynamics and project outcomes.
  2. Iterative Improvements: Be prepared to make iterative improvements based on feedback and new insights into team dynamics and project needs.

Incorporating neuroscientific concepts such as Polyvagal Theory and neuroception into project management practices can significantly enhance the effectiveness of cross-cultural teams, particularly in Agile environments.

 

Conclusion

Integrating Polyvagal Theory and neuroception into project management practices offers a sophisticated approach to navigating the complexities of cross-cultural teams in Agile environments. By understanding and addressing the underlying neurobiological factors influencing team interactions, project managers can create more cohesive, productive, and successful teams. These strategies not only improve project outcomes but also enhance the overall well-being and engagement of team members, leading to more resilient and adaptable project environments.

 

PMTimes_May28_2024

That One Project You Aren’t Sure You’ll Survive…

Written by Paul Gouws on . Posted in Articles.

We all had that one project—the one that made us question our career choices, doubt our sanity, and consider a swift exit from the world of project management. It took me a moment to recall mine. The late nights, the endless meetings, and the creeping feeling that I was steering a ship into a storm without a compass. Yes, that project—the one that left me pondering whether I had accidentally signed up for a one-way ticket to project manager purgatory.

But here is the twist: I survived. And not just survived—I emerged wiser, battle-tested, and armed with insights that no textbook or certification could provide.

So, why am I sharing this? Because somewhere out there, another project manager is teetering on the edge, contemplating surrender. Maybe, just maybe, my journey can offer a glimmer of hope—a lifeline to keep them afloat.

 

Lessons from the Trenches

What follows are my personal revelations from years ago, working on that one project we all know. I am not advising or guiding here; I am merely sharing my experience throughout the life cycle of the project. You might share similar experiences or see something completely new. Luckily, the project world has evolved over the years, but nothing can match up to the real project experience. Hard-won tricks, battle-tested strategies, and yes, confronting the dreaded burnout head-on.

 

The Burnout: A Dangerous Undertow

Now, let us delve into the next chapter of my journey—the one where burnout took center stage. It was not merely a buzzword; it functioned as a silent assassin. Picture this: nights devoid of sleep, days fuelled by caffeine, and a to-do list that multiplied faster than rabbits in spring. I had been there, but I was fortunate to be surrounded by top talent, including a mentor who guided me throughout. Together, we navigated the treacherous waters of that one project, skillfully avoiding the siren call of burnout.

As a naturally spirited individual, I have always approached life with unwavering positivity. To me, there existed nothing on this earth that could not be rectified, no challenge too daunting, and no issue too tangled to unravel. I excel at solving problems, whether they are complex or simple—until one day, I hit a wall. Wait, was I failing at something? Impossible. I resolved to try harder next time, right? But two weeks later, another failure. It dawned on me—I was caught in a loop, akin to a sales pitch endlessly replayed during an infomercial:

  • Are you perpetually failing on a project?
  • Are you working extra hours and days to evade failure?
  • Are you feeling utterly worthless?

 

These symptoms became my daily companions. I would gather myself overnight, only to wake up to the same emotional hangover the next day. I soldiered on, convinced that this was normal and that I would eventually power through. But stress insidiously crept in—I smoked more, drank more, and hoped it would all magically vanish. The harsh truth? It did not. Burnout was lurking, and I did not even recognize it until it had me in its grip six months down the line.

Burnout does not announce itself with fanfare. It tiptoes in, whispering exhaustion into your bones. And I, the sprinter—the one who thrives on daily victories—was suddenly running a marathon. You see, there are sprinters and marathoners in the project management world. Sprinters excel in short bursts, while marathoners maintain a steady pace over the long haul. Me? I was a sprinter on a six-year project. Sure, you can break down a colossal project into smaller goals, but it is not sustainable. The sprinter craves daily wins, not a development cycle that spans years. The funny thing is, I only realized that I had burned out after the burnout had already taken its toll, which could be six months down the line. The crucial lesson? Recognize burnout while it is happening, not after the fact.

Below were the three fundamental areas that I needed to improve on to survive:

  • The first thing I did was to start exercising; even if you just run for a bit, it needs to be for a minimum of 40 minutes at least. If you are in the habit of exercising, just check that you are not swapping out your exercise time for work. There will always be work, so making time for exercising will not cause any harm.
  • Watch full-on action movies with a lot happening in them at full volume.
  • Replace bad coping mechanisms with healthy ones.

 

Strategic Funding Approach for Ambiguous Requirements

In the realm of project management, grappling with vague requirements is a familiar challenge. When faced with this uncertainty, consider a strategic funding strategy that not only brings clarity but also optimizes your company’s resources.

 

Phase-Specific Funding

Rather than seeking the entire project budget upfront, focus on securing funds exclusively for the requirements phase. By doing so, you establish a clear boundary for the initial work.

Once the requirements phase is successfully completed, you can confidently request additional project funds. This approach minimizes financial risk and aligns funding with tangible progress.

Yes, I did hear we are following agile, agile, agile, and we will request funds as we go. It is all good… Please add all the funds that you have spent so far and link them to what has been delivered. I will stop there.

We followed a hybrid approach here, waterfall the requirements, and then you can follow any framework or methodology you prefer for the rest of the phases. We monitored a few aspects of the budget continuously:

  • Approved Budget – How much money did the company approve for the project or phase?
  • YTD actuals spend – How much money have you spent already to date?
  • YTD planned spend – How much money are you planning on spending for the remainder of the project?
  • Quality Check Spend – How much money did you spend, according to the finance team?
  • Variance – How much money will you have left at the end of the project?

Oh, and on a side note, do not think you will be called a hero if your budget ends up in a big positive, that is a sign of poor planning. We worked on a 5% variance either way to be good, and I thought it was fair.

 

 

Poor Planning: The Quicksand of Project Execution

Let us discuss the BRS—the unsung hero of projects. BRS stands for Business Requirements Specification—a fusion of the BRD (Business Requirement Document) and the BSS (Business Specification Spec). Think of it as the Rosetta Stone that translated business needs into design blueprints. We hired Business System Analysts instead of your run-of-the-mill Business Analysts (BAs) to save on funds. The BSA crafted an all-in-one document, weaving requirements and designs into a seamless tapestry. We did encounter scope creep where the business would sneak in extra requirements, citing the “we missed it at the start” clause.

Armed with the BRS, we generated work packages—bite-sized tasks that our team could chew on. It was like breaking a colossal chocolate bar into manageable squares.

We tracked the progress of each BRS in the war room (you will hear about this later) with a card like this:

 

Advertisement
[widget id=”custom_html-68″]

 

Development Without Design

Imagine constructing a house without blueprints. Initiating development without clear designs or requirements documents is akin to erecting a skyscraper on shaky ground. It is a recipe for chaos. With the solutions architect on your right and the business analyst on your left, create the as-is and to-be designs, with the plan in the middle—it is that straightforward. The solutions architect must advise you on any risks that might arise as you progress on your project journey, while the business analyst must keep you laser-focused on the customers’ requirements.

 

Untamed Timelines

Committing to timelines without consulting your team is like setting sail without checking the weather forecast. A big no-no. Involve all stakeholders, assess risks, and adjust your course accordingly. I am not talking about adding a buffer based on your experiences; I am just saying that if you are not a developer, then do not put estimates down for a new website to be built; ask the expert.

 

The War Room: Where Strategy Meets Unity

The term “war room” conjures images of battle-hardened generals huddled over maps, plotting tactical maneuvers to outwit the enemy. But in the context of this project, it is less about combat and more about collaboration. Allow me to demystify the war room—a sacred space where ideas clash, plans take shape, and unity prevails.

 

As a die-hard team player, I thrive in the war room’s charged atmosphere. Why? Because it compels us to gather, discuss, and align. Team meetings become our compass, pointing us toward shared goals. Unity emerges—the kind that transcends job titles and department silos. We are no longer lone warriors; we are a battalion with a common mission.

Picture it: four walls, each adorned with a whiteboard. This is your canvas. Now, let us map out the headings—the battle plans—inspired by the V-Model of testing:

  • Low/High-level Designs: The blueprints. Architects, developers, and UX designers converge. We sketch, iterate, and breathe life into concepts.
  • System/Business Requirements: Here, we decode the client’s vision. What problem are we solving? What outcomes matter? These requirements anchor our journey.
  • Development: Our troops mobilize. Timelines, milestones, and resource allocation take shape. It is the heartbeat of execution.
  • PDT/AIT/SIT/UAT: The litmus test. Testing engineers scrutinize, validate, and ensure our creation stands tall.

Sounds straightforward, right? But remember, the war room is not just about strategy—it is about camaraderie, resilience, and the art of turning chaos into cohesion. In the maze of project management, requirement cards served as our guiding leads. But these are not ordinary cards—they are color-coded keys to complexity, dependencies, and progress.

We created these cards to help us keep track of how each item is progressing. Each of the cards will represent a specific requirement, and each card will have the following on it:

  • Traceability number – Once you have completed your designs and have them up in your war room, you will be able to number every change required to the design. That number will be inserted in this block so that you have traceability between the requirements and the design. This card is only for business requirements, not interface requirements; there is a different card for interfaces. This means that when you walk into the war room, you can easily spot what part of the system you are touching and where it is based on the design.
  • Dependency number – Some items are codependent. They need each other to thrive. This box holds the magic number—the item that must precede another. Dependencies, untangled.
  • Phases from left to right – BRS, DEV, SIT, UAT, DEPLOYED. depending on which team currently owns this ticket, the indicator will move from BRS to DEV or to whichever stage it is in now: same ticket, different owners… We were busy with a custom version of Kan Ban, or whichever version you prefer… Survival was the key word here.

 

Something like this:

 

Card Color System –

  • Red Card The crimson flag. These cards represent the most complex items—the uncharted territories. None of your team members have ventured here, and their experience is limited. Brace for challenges.
  • Amber Card: The caution signs. These items have been glimpsed by 1 or 2 resources. Familiar, but not routine. Approach with vigilance.
  • Green Card: The Oasis. These cards signify easy items—your team has danced this tango before. They have mastered it and executed it multiple times. Smooth sailing ahead.

Remember, this card is exclusively for business requirements. Interface requirements have their own dance floor. Keep them separate, like parallel universes.

So, when you step into the war room, eyes scanning the system’s blueprint, these cards whisper: “Here is where you tread; here is where you leap.

 

Development (Crazy Stream)

Where Requirements Take Shape

  • The Quest for Requirements: Picture it—a developer picks a ticket and vanishes into the coding abyss, only to reappear days later, battle-worn and seeking aid. Sound familiar? We have all danced this tango. But fear not; we devised a remedy.
  • The Senior-Junior Alliance: We paired senior developers with their junior counterparts. Mentorship duets. It eased some challenges, but yes, development time took a hit. Still, the defect rate waned, and after three months, we found our rhythm.
  • Scope Creep and the Unseen Impact: Alas, scope management is our Achilles’ heel. Product owners, blissfully unaware, kept adding tweaks. “This button’s off,” they would say. “That field’s too snug.” The result? A deluge of tickets drowned our team.
  • The Cricket Field Strategy: Desperation breeds innovation. So, we turned to cricket. A whiteboard became our field. Each developer chose their cricket idols. The rules? For every ticket completed, a run is scored. But for every defect found, a wicket fell. Morning stand-ups played out on our “cricket field.” The results? Astounding. Quality soared, spirits soared, and our team hit sixes daily.

The Peer Review Revolution

  • Passing the Baton: As soon as a developer finished, they would pass the baton—the code—to the next in line. Peer reviews ensued. Quality improved, and knowledge flowed. It was our secret weapon against mediocrity.

 

User Acceptance Testing

More than halfway through the project, we decided to permanently move key users into the project team permanently. This ended up being the right call. As it was a complex project, by the time we got to user acceptance testing, the users permanently assigned to the project could act as super users in the UAT environment and did assist greatly with fast-tracking any testing that needed to be done. We would also assign a business analyst and a developer to each UAT session to resolve any questions or concerns on the spot.

The second value added to assigning permanent business users to the project for the duration is that they are part of the team, and they will fight for the project in other business forums. We did have a big gap between the project team and business when we started, but this move changed it really into a positive.

On a big, complex project, it is easy to get stuck in the testing cycle due to the business aiming for a bug-free system. There is not one single application that is bug/defect-free; if there is one that you know of, they are not sharing it with you. Coach or guide the business users to log defects but also prioritize them based on financial, reputational, and legal impact. Well, this is what we used. Low-level cosmetic bugs should not stop you from going live. Get a product out by fixing all the high and medium defects, and once live, the low defects can be fixed. But it’s super important to get something out. These days, they call it an MVP (Minimum viable product); we just call it and get it into production so that we can start making a difference.

 

The Operational Handover post went live.

Like the UAT team, it worked best for us to include one or two operational resources permanently on the project, as they would end up supporting the product once it was live. They also assisted in documenting all the information in the operational handover document. You will not be so lucky to do this on all the projects, but at least put it in place on strategic projects.

 

I trust the above will give you motivation to continue your project management journey and never give up.

PMTimes_Apr17_2024

Collaborative Decision Making

Written by George Pitagorsky on . Posted in Articles.

Meditation teacher Tejaniya advised, “Never try to force an issue. Just acknowledge, accept, and keep observing until things unfold naturally.”

 

This might be fine when there is all the time in the world for the issue to be resolved, but from a project management perspective, it sounds far too passive an approach.

However, when you consider what happens when you force an issue by using your power as a manager or a majority in a decision-making group, there may be some wisdom in acknowledging, accepting, and observing things unfold naturally.

 

Scenario

In a program to improve the way a complex organization operated, a narrow majority of the Program Steering Group that was responsible for making decisions regarding which of several projects was to be done and in what order decided by a slim majority to authorize a project to renovate a process in one department.

They hired a design consultant and created a Design Team to provide feedback regarding the design. The Design Team reflected on the decision and was influenced by some of the minority members of the program steering group. They came back to the steering group with their unanimous opinion that the chosen project was not the best one to take on first, provided their reasoning, and called for the steering group to provide an overall plan that identified all the projects that would be part of the program, a capital financial plan, and an overall architecture before deciding on which project would be done first.

 

The steering group pushed back using their authority. They said that the Design Team was asked to give feedback on the design and not question the steering group’s decision. The steering group forced the issue.

The Design Team grumbled, but since they reported to the members of the Program Steering Group were left with no choice but to quit or comply, so they chose to comply.

 

The result was, as the Design Team predicted, a well-designed process with supporting systems that within a few years needed to be significantly changed, at great cost to fit with the other processes and systems that emerged as part of the overall renovation program. The resulting architecture resembled a patchwork – “something composed of miscellaneous parts; hodgepodge.”[1]

Over time, system maintenance was a nightmare. Further, some useful renovations were not included in the program because avoidable costs of initial projects used up the program’s budget.

 

The Consequences of Forcing an Issue

Here we see that forcing a decision led to the postponement of due diligence. Not doing capital planning and architectural design led to avoidable consequences, as pointed out in my article The Karma of Postponing Due Diligence[2]. And there are other consequences of forcing an issue, for example, disgruntled staff, and loss of respect for the decision-makers.

 

A Path Forward

So what can we do? As leaders in positions of power, we can step back and assess our decisions in the light of feedback and conflicting ideas. We can apply emotional and social intelligence along with wise decision-making, and servant leadership concepts.

Emotional intelligence comes into play when the decision-makers apply self-awareness to see why they find it necessary to force an issue. Is it because they are emotionally attached to their decision or to their power? With social intelligence, they can assess the impact of their use of authority on their staff, superiors, and peers.

As wise decision-makers, they recognize the need to look at the issue from multiple perspectives – long and short-term impacts, financial and quality consequences, and more. Servant leadership involves respect for others and their opinions and the positive impact of helping followers become wise decision-makers.

 

In a recent article[3] the author points out “the value of working with those with whom we disagree.” The author relates how Dr. Daniel Kahneman, who explored judgment and decision-making and how easily people become less than rational when making decisions, “experienced real joy working with others to discover the truth, even if he learned that he was wrong (something that often delighted him).” Kahneman favored “adversarial collaboration.”

When adversaries work together, they face the issue rather than each other. This requires acknowledging that one can be all wrong or half wrong and that the other party or parties may be right or half right, whether they are peers, superiors, or subordinates.

 

Advertisement
[widget id=”custom_html-68″]

 

Don’t Force an Issue

Let’s return to Tejaniya’s advice, “Never try to force an issue. Just acknowledge, accept, and keep observing until things unfold naturally.”

 

I try never to say never. There are times as a manager that we will choose to use authority to force a decision. But that is a last resort, for example when faced with a tight deadline leaving no time for further dialogue. Acknowledging, accepting, and observing until things unfold naturally is a superior way of operating. But only when we have a clear sense of what that means.

Acknowledging, accepting, and observing are active, not passive. Acknowledge and accept that there are differences of opinion and different positions. Observe your own and the other parties’ positions and behavior. Listening to content and tone is part of observing as is seeing others’ body language and facial expressions and observing your own.

Open your mind to the possibility that your position is not the best or only effective alternative. This is part of accepting. You let go of your attachment to having it your way (even if your way is not the best way).

 

Then clarify, present your view, and consider that to be part of what is unfolding naturally. You are letting go of your position and allowing the right expression of your knowledge and experience for the situation. You seek to understand the needs and wants, facts and opinions.

In the example from the article cited above, Professor Kahneman and his adversary found through a collaborative effort that they were both partially right and partially wrong. They came to a resolution that they could not have reached working on their own.

 

Never say Never

What if your opponent is closed to a collaborative approach? Then you acknowledge and accept the reality that collaboration is no longer possible and naturally force the issue (if you have the power to do so.) When you do, if you have been open-minded, asked the right questions, and objectively considered the answers, your decision might not be the same one you made before you tried to collaborate.

 

[1] Merriam Webster https://www.merriam-webster.com/dictionary/patchwork.
[2] https://www.projecttimes.com/articles/the-karma-of-postponing-due-diligence/
[3] The Nobel Winner Who Liked to Collaborate With His Adversaries https://www.nytimes.com/2024/04/01/opinion/nobel-daniel-kahneman-collaboration.html