Project Management

Voices on Project Management

by , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

cyndee miller
Lynda Bourne
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Wanda Curlee
Christian Bisson
Ramiro Rodrigues
Soma Bhattacharya
Emily Luijbregts
Sree Rao
Yasmina Khelifi
Marat Oyvetsky
Lenka Pincot
Jorge Martin Valdes Garciatorres

Past Contributors:

Rex Holmlin
Vivek Prakash
Dan Goldfischer
Linda Agyapong
Jim De Piante
sanjay saini
Siti Hajar Abdul Hamid
Bernadine Douglas
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Kelley Hunsberger
Taralyn Frasqueri-Molina
Alfonso Bucero Torres
William Krebs
Marian Haus
Shobhna Raghupathy
Peter Taylor
Joanna Newman
Saira Karim
Jess Tayel
Lung-Hung Chou
Rebecca Braglio
Roberto Toledo
Geoff Mattie
Dmitri Ivanenko PMP ITIL

Recent Posts

Mind Map Your Way to Trust on Virtual Teams

Dare to Hope and Dream—Our Future Depends on It

Virtual Teamwork Makes the Virtual Dream Work

The Time to Start Vertical Development Is Now

Become a Better Servant Leader

Viewing Posts by Christian Bisson

Mind Map Your Way to Trust on Virtual Teams

by Christian Bisson

Building a solid team starts with a solid foundation. And one of the best ways to build cohesion is with a steam activity. It can take various formats. What matters is that team members understand the purpose, the importance of trust and the long-term benefits.

Without getting into the details of all the team building activities available out there, allow me to share the latest I’ve did with one of my teams: digital mind maps.

As we know, current circumstances have forced us to switch from typical physical sessions to more virtual interactions. Right now, I’m using a collaborative software, so for this activity, I’ve built the appropriate workspace and invited everyone on my team to work in it. If answers are absent or wrong, you can always jump in, but you need to get the team’s buy-in from the start.

For this activity, I asked them to create a mind map. But before they began, I showed them one I had done. By doing so, I managed their expectations, provided guidance and built trust that I believed that they could do it.

When each team member presented their mind map to the group, it served as an ice breaker and allowed team members to warm up to one another even though we weren’t together physically.

Afterwards, I asked for feedback and learned that the team found the exercise fun and allowed people to connect. We also discovered that we’re all parents, all learning to deal with this new remote life together.        

What kind of activities do you use to build trust on your virtual team?

Posted by Christian Bisson on: October 29, 2020 07:32 PM | Permalink | Comments (2)

3 Steps Toward Resolving Team Conflict

Categories: Conflict, Team

by Christian Bisson

Conflicts arise on any team. It’s inevitable. What’s important is making sure they’re resolved before they grow into something bigger.

It often feels like unfamiliar territory to some, but resolver of conflicts is one of the many hats a scrum master must wear. And while there’s no singular right way to resolve conflict, I’ve found success with following steps:


Ensure those in the conflict have someone they can talk to. Once they get their feelings out, the door is open for them to act more rationally toward the other, or it gives you an opportunity to go deeper (see below).

Encourage a conversation.

It may sound simple, but a big part of conflict resolution is allowing both sides to hear one another. By default, we work to avoid conflicts and we’ll avoid the conversation that we know we should have as adults to make our conflict go away. 

As a scrum master, there’s room to suggest bringing the other party into the resolution. The worst that will happen is that the team member will refuse, giving you an opportunity to dig deeper to gain a greater understanding and then ask questions to understand what’s really going on.

Dig deep.

Even after you listen and encourage a conversation, it still may not be enough to resolve the situation. You may have to dig a bit deeper. Analyze the situation: Who initiated the conflict? In other words, who seemed to respond negatively to an event/response? That’s the first person you want to talk to. Ask open-ended questions to help the team member arrive at a rational thought/answer. And hopefully, that person will open up.

What are your biggest lessons learned from resolving conflict within your project teams

Posted by Christian Bisson on: September 27, 2020 03:00 PM | Permalink | Comments (7)

Will the Real Agile Please Stand Up?

Categories: Agile

By Christian Bisson 

It appears as if “agile has become the buzziest of buzzwords. But are organizations using it correctly? As I’ve evolved towards agility in the last several years, I’ve come across many job descriptions that claim and demand agility. Sadly, the term is often only used to lure people in. 

Today, the younger workforce expects agility in certain industries. But when the term is used as a buzzword rather than in its true meaning, that can lead to problems later on. 

So, how do you spot the difference between real agility and yet another buzzword? Here are a few things to look out for in organizations: 

Job Descriptions 

Analyzing job descriptions is one of the fastest ways to spot anti-agile patterns before you invest any time in interviews. These descriptions will often use words that actually go against what you would expect from an agile organization.  

For example, if you look at the scrum master’s job description, you may find traditional project manager responsibilities, such as: “create project plan,” “coordinate team,” or even “responsible for the product backlog.” 

For other rolessuch as a developer, you will see all the standard requirements about programming languages, architectural experience, etc.but the description will fail to mention anything about being on a multidisciplinary team, a self-organized team or anything you would expect from an agile team. 

Another description to watch out for is the typical “can work in a fast-paced environment” mandate, which is more often than not code for “lots of overtime” and goes against having a sustainable pace for teams. You may risk joining a chaotic work environment and delivering poor quality work because of all the demanding deadlines. 


Prioritizing work at an organizational level is key to being able to deliver value and avoid waste. And those priorities must be communicated to teams in a timely manner so they can plan their sprints properly.  

If this is not the case, you will notice that sprints are not respected and always change, the work delivered does not bring value to anyone, and the word “urgent” is repeated every single day. 

Some organizations struggle with this but are working toward getting better. Here are a few behaviors to look out for: 

  • Are teams listened to when they challenge priorities, or are they expected to just do what they are told? 

  • Are emergencies communicated in a concise manner to allow opportunities to react and pivot, or are they communicated at the last minute over and over again?  

  • What happens when the team cannot complete deliverables on time? Does everyone collaborate to reach a solutionor is the team left to their own devices to figure it out? 

Team Dynamic 

A well-powered team that is set up for success will deliver value. But if the team is expected to execute without any discussion with upper management, then you may be in a traditional management type of organization instead of an agile one. 

Pay attention to things like: 

  • Is the team able to make any kind of decisions other than simply how they code? 

  • If the team makes a mistake, what is the reaction? Is it a collaborative effort to improve or are actions taken to prevent the team from further being in control (such as adding a layer of micro-management)? 

  • Are there management roles within the team telling them what to do? 

  • Is how the team members complete their work dictated to them?  

To be fair, lots of organizations simply misunderstand agile and its related lexicon, and might not actually intend to lure anyone through outright manipulation. But there are many that doand those are the ones to look out for. Chances are, if they are being misleading in order to attract people to work for them, these organizations will act similarly to keep talent working for them—and not necessarily in the best of circumstances. 

How do you see agile being misused in organizations?  

Posted by Christian Bisson on: May 06, 2020 07:11 PM | Permalink | Comments (5)

The Misunderstood Scrum Master

Categories: Agile

By Christian Bisson

Inspired by The 8 Stances of a Scrum Master (a great read if you haven’t done so already), I want to focus this article on a few of the “misunderstood” stances of the scrum master.

Recently, I asked colleagues to share what they think a scrum master does, and the answers revolved around organizing scrum events (secretary) or note taking (scribe). It’s even expected that they make sure the office has coffee (coffee clerk).

Although there is nothing wrong in helping the team with any of the above—especially when it’s a brand-new team figuring out everything from setting up their work station to getting to know each other—there is a line between helping and not fulfilling your potential as a scrum master. This is important for you as an individual, but also for the team in the long term (even if they don’t know it).

So how can we fix this?

Stop Doing It

As a scrum master, you have to factor in everything when making a decision about whether or not to do something for your team. So, if the team is used to you doing a task and all of a sudden you stop, this might have a negative impact.

On the other hand, it might be what they need to break bad habits. If you do stop doing it, the team will have no choice but to do it themselves. However, in this case, you should warn the team or give them a heads up that you will stop by the next sprint, for example.

Never Start Doing It

If you are new to the team, or the whole team is new, you might have the opportunity to simply never start doing a given task in the first place. Although it seems counterintuitive to “not help” the team, you’ll avoid creating any habit that will affect them in the long term—and will be challenging to break.

In this case, you should explain to the team that it’s everyone’s responsibility to handle these tasks and to build good habits from day one.

I personally did this with note taking a few years ago. It was challenging at first, but now I go to meetings without any apparent ways of taking notes, making it obvious that I won’t be doing it. (I do have my phone in case something important comes up that I need to note for myself, of course). Now in meetings, I’ve gone from the note taker to being able to focus on facilitating the meeting and help the team get the best out of the conversation.

In Conclusion

It’s quite challenging to avoid all the “misunderstood” stances of the scrum master, but we have to do our best to be true to the real value scrum masters can bring to teams.

What misunderstood stances have you fought against? How have you tried to combat them?

Posted by Christian Bisson on: January 21, 2020 11:57 AM | Permalink | Comments (6)

Lessons Learned From an Inspiring AI Project

By Christian Bisson

When I was asked to write about a project that inspired me in the last 50 years, I didn’t have to look back further than last year. That’s when I had the chance to act as scrum master for a newly formed team.

The Challenge

We had seven weeks to build software from scratch that would be demonstrated at a conference and used by hundreds of people. Since the conference was centered on artificial intelligence, it was mandatory that our demo used AI. Our idea was a game where the player spelled words using real sign language. The game was displayed on a television hooked up to a camera, which filmed the player’s hand.

The hand’s position was then recognized and matched to a letter of the alphabet. The player received points based on the speed at which he was spelling the words displayed on the screen.

The Team

We had a great team composed of two developers, a designer, two AI researchers, a product owner and me (scrum master). Our small, dedicated team would empower us to deliver the software we needed to build from A to Z.

Although concerned about the short time available, everyone was motivated and excited to build this amazing software, knowing the visibility it would get.

How We Would Work

Since the scope wasn’t fully defined and the user experience was key, we needed to deliver usable increments to test. We needed a framework that would allow us to deliver quickly and adjust to the requirements as they were refined. Scrum was the obvious choice, even though most of the team was completely new to it. The majority of the team came from a software background, so they knew what it was on paper. However, for the AI researchers, it was completely unknown.

Where it All Came Together

Many start off with the team they need, but then obstacles come their way and prevent them from moving forward. These could be anything from unavailable stakeholders to people being pulled off the team to poor requirements.

However, in this case, it was everything you would want from agility/scrum:

  • A team collaborating together without anyone coordinating them
  • Busy stakeholders making themselves available for us to collaborate
  • Everyone following scrum, even though it was new to them
  • The team working at a sustainable pace
  • A usable increment of the game delivered every sprint
  • Continuous improvement through the retrospectives
  • A healthy backlog that was properly refined by the team

It was amazing to see the collaboration when we needed users to test; after a quick Slack message to everyone in the company, we would suddenly have a lineup of people available to play the game.


What Inspired Me

When I think back on our success, all I remember are the people working together to create something great. It wasn’t even about being “agile.” For the team it was, “Let’s get this done!” and for everyone who supported us, it was “Let’s help our colleagues!” There was nothing more, nothing less—exactly how it should be.


I’d love to hear about the most inspiring project you’ve worked on in your career. Please share below!

Posted by Christian Bisson on: November 13, 2019 03:13 PM | Permalink | Comments (7)

While hunting in Africa, I shot an elephant in my pajamas. How an elephant got into my pajamas I'll never know.

- Groucho Marx



Vendor Events

See all Vendor Events