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:

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

Past Contributors:

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

Recent Posts

A Roadmap for Continuous Learning

The Power of Agile Team Cohesion

What Qualities Do the Best Project Managers Have?

The Power of Pauses and Silence

3 Agile Disconnects We Need to Address


2020, Adult Development, Agile, Agile, Agile, agile, Agile management, Agile management, Agile;Community;Talent management, Artificial Intelligence, Backlog, Basics, Benefits Realization, Best Practices, BIM, Business Analysis, Business Analysis, Business Case, Business Transformation, Calculating Project Value, Canvas, Career Development, Career Development, Career Help, Career Help, Careers, Careers, Categories: Career Help, Change Management, Cloud Computing, Collaboration, Collaboration, Collaboration, Communication, Communication, Communication, Complexity, Conflict, Conflict Management, Consulting, Continuous Learning, Continuous Learning, Continuous Learning, Cost, COVID-19, Crises, Crisis Management, critical success factors, Cultural Awareness, Culture, Decision Making, Design Thinking, Digital Transformation, digital transformation, Digitalisation, Disruption, Diversity, Documentation, Earned Value Management, Education, EEWH, Enterprise Risk Management, Escalation management, Estimating, Ethics, execution, Expectations Management, Facilitation, feasibility studies, Future, Future of Project Management, Generational PM, Governance, Government, green building, Growth, Horizontal Development, Human Aspects of PM, Human Aspects of PM, Human Aspects of PM, Human Resources, Inclusion, Innovation, Intelligent Building, International, Internet of Things (IOT), Internet of Things (IoT), IOT, IT Project Management, IT Strategy, Knowledge, Leadership, Leadership, Leadership, lean construction, LEED, Lessons Learned, Lessons learned;Retrospective, Managing for Stakeholders, managing stakeholders as clients, Mentoring, Mentoring, Mentoring, Methodology, Metrics, Micromanagement, Microsoft Project PPM, Motivation, Negotiation, Neuroscience, neuroscience, New Practitioners, Nontraditional Project Management, OKR, Online Learning, opportunity, Organizational Project Management, Pandemic, People, People management, Planing, planning, PM & the Economy, PM History, PM Think About It, PMBOK Guide, PMI, PMI EMEA 2018, PMI EMEA Congress 2017, PMI EMEA Congress 2019, PMI Global Conference 2017, PMI Global Conference 2018, PMI Global Conference 2019, PMI Global Congress 2010 - North America, PMI Global Congress 2011 - EMEA, PMI Global Congress 2011 - North America, PMI Global Congress 2012 - EMEA, PMI Global Congress 2012 - North America, PMI Global Congress 2013 - EMEA, PMI Global Congress 2013 - North America, PMI Global Congress 2014 - EMEA, PMI Global Congress 2014 - North America, PMI GLobal Congress EMEA 2018, PMI PMO Symposium 2012, PMI PMO Symposium 2013, PMI PMO Symposium 2015, PMI PMO Symposium 2016, PMI PMO Symposium 2017, PMI PMO Symposium 2018, PMI Pulse of the Profession, PMO, pmo, PMO Project Management Office, portfolio, Portfolio Management, portfolio management, Portfolios (PPM), presentations, Priorities, Probability, Problem Structuring Methods, Process, Procurement, profess, Program Management, Programs (PMO), project, Project Delivery, Project Dependencies, Project Failure, project failure, Project Leadership, Project Management, project management, project management office, Project Planning, project planning, Project Requirements, Project Success, Ransomware, Reflections on the PM Life, Remote, Remote Work, Requirements Management, Research Conference 2010, Researching the Value of Project Management, Resiliency, Risk, Risk Management, Risk management, risk management, ROI, Roundtable, Salary Survey, Scheduling, Scope, Scrum, search, SelfLeadership, SelfLeadership, SelfLeadership, Servant Leadership, Sharing Knowledge, Sharing Knowledge, Sharing Knowledge, Social Responsibility, Sponsorship, Stakeholder, Stakeholder Management, stakeholder management, Strategy, swot, Talent Management, Talent Management, Talent Management, Talent Management Leadership SelfLeadership Collaboration Communication, Taskforce, Team Building, Teams, Teams in Agile, Teams in Agile, teamwork, Tech, Technical Debt, Technology, TED Talks, The Project Economy, Time, Timeline, Tools, tools, Transformation, transformation, Transition, Trust, Value, Vertical Development, Volunteering, Volunteering #Leadership #SelfLeadership, Volunteering Sharing Knowledge Leadership SelfLeadership Collaboration Trust, VUCA, Women in PM, Women in Project Management


Viewing Posts by Christian Bisson

The Power of Agile Team Cohesion

by Christian Bisson

Agile team cohesion is the seamless collaboration, effective communication, and shared goals and values among team members. I frequently prompt new teams to reflect on a time they thought things were going great; consistently, "the team" emerges as the primary factor contributing to that moment’s greatness.

Being intangible, team cohesion is often undervalued, with some viewing it as simply as an overhead. For example, team building activities, or even retrospectives that have a bit of fun included in them can be seen as a waste of time. Heck I’ve also been told by team members that it was an insult to their intellect! 

Despite that, the impact of team cohesion is far-reaching, offering substantial benefits to the team and the project at hand.


Enhanced Communication

Cohesive teams communicate more effectively, leading to smoother workflows through several key mechanisms:

  • Shared Understanding: Team cohesion fosters a shared understanding of goals, objectives, and project/product requirements among team members. When everyone is on the same page, communication becomes more targeted and relevant.
  • Open Communication Channels: In cohesive teams, trust and mutual respect is built over time which creates a culture of open communication. Team members feel comfortable expressing their ideas, concerns, and feedback. Not only does this transparency helps in addressing issues promptly, but it also provides the team with collective creativity to find solutions to whatever challenge they face.
  • Adaptability to Change: In agile environments, where change is frequent, cohesive teams are more adaptable. Effective communication ensures that everyone is informed about changes promptly, and the team can collectively adjust its strategies and tasks to accommodate new requirements.


Increased Productivity

  • Alignment of Efforts: Shared goals provide a common purpose that aligns the efforts of each team member. When everyone understands and commits to the same objectives, individual tasks and activities naturally complement one another, avoiding conflicts and redundancy.
  • Motivation and Engagement: Having shared goals fosters a sense of shared ownership and commitment. Team members are motivated to contribute their best efforts when they see how their work contributes to the overall success of the team and the achievement of common objectives.
  • Efficient Capacity Management: A united team optimises their capacity by ensuring that each team member focuses on tasks that align with the team's goals. This prevents duplication of efforts and ensures that time and expertise are utilised efficiently.
  • Collaborative Problem-Solving: Shared goals encourage collaborative problem-solving. Team members are more likely to work together to overcome challenges and find innovative solutions when they share a common objective. This collective approach enhances problem-solving efficiency and effectiveness.
  • Mutual Support and Knowledge Sharing: A united team promotes a culture of mutual support where team members readily assist each other. This support extends beyond task completion to knowledge sharing, where individuals leverage their strengths to help others, fostering continuous learning and skill development. Furthermore, this prevents “points of failure” where one member only can execute a certain task or has a certain expertise, lowering risks if team members leave the team or are missing.


Team cohesion is important, and it’s important for all members of the team to understand its value so that everyone contributes to it.

How do you actively contribute to your team's cohesiveness? Share your insights and any noteworthy team-building activities you've found effective.



Posted by Christian Bisson on: April 01, 2024 11:37 AM | Permalink | Comments (3)

4 Pitfalls of an External Product Owner

Categories: Agile, Best Practices, Teams

By Christian Bisson

Within the realm of agile project management, the composition of a team greatly impacts its success. While all team members play a vital role, the inclusion of an external product owner (as opposed to an internal one) poses challenges that can hinder teams’ potential to deliver value to users. 

In this post, I will highlight four potential pitfalls of having a product owner external to the team, with real-life examples underscoring the benefits of an integrated team approach.


1. Misalignment and Unclear Vision

When a product owner is external to the team, misalignment and an unclear vision can arise. The absence of direct day-to-day collaboration stifles the shared understanding of project goals, priorities, and user needs. This lack of alignment makes it difficult for the team to make informed decisions and deliver a product that meets customer expectations.

Example: Imagine a software development project where the product owner is external and has limited interaction with the team. This separation hinders effective communication and prevents the product owner from gaining in-depth knowledge of the project domain. As a result, misaligned priorities and a fuzzy vision emerge, leading to a disconnect between the team's efforts and the desired outcomes.


2. Inefficient Prioritization and Decision Making

An external product owner often leads to inefficient prioritization and decision-making processes. Without a direct line of communication, the product owner's expertise and insights may not reach the team effectively. As a result, crucial decisions regarding scope, timelines and trade-offs may be delayed or misinterpreted, leading to project inefficiencies and missed opportunities.

Example: In a marketing campaign project, an external product owner who lacks real-time interaction with the team may struggle to grasp the evolving market trends and user preferences. Consequently, delays in decision making occur, preventing timely adjustments to the campaign strategy, ultimately impacting its effectiveness and return on investment.


3. Communication Gaps and Feedback Delays

With an external product owner, communication gaps and feedback delays become commonplace. The limited availability and reduced involvement of the product owner hinder continuous communication and the timely exchange of information. This results in a slower feedback loop, preventing the team from promptly addressing concerns, adapting to changing requirements, and delivering high-quality increments.

Example: In a mobile app development project, an external product owner may have competing priorities and limited availability for sprint reviews. As a result, feedback on delivered iterations may be delayed, preventing the team from incorporating valuable insights—and potentially leading to inefficient use of development resources.


4. Detached from User-Centric Mindset

When the product owner is external, the team risks losing touch with a user-centric mindset. The direct contact between the product owner and end users diminishes, inhibiting the team's understanding of user needs, preferences and pain points. Without this critical insight, the team may struggle to develop solutions that truly resonate with the target audience.

Example: Consider an e-commerce project where an external product owner has limited interactions with actual customers. The team, lacking direct access to user feedback and insights, may fail to anticipate user behavior, resulting in an e-commerce platform that falls short of meeting customers' expectations and inhibits business growth.



In the agile realm, the inclusion of an external product owner introduces several pitfalls that can hinder project success. Misalignment, inefficient decision making, communication gaps, and a detached user-centric mindset are among the challenges an integrated team approach aims to mitigate. By recognizing the drawbacks of an external product owner, agile teams can foster collaboration, transparency, and a deep understanding of customer needs, ultimately leading to more successful project outcomes.

The above points assume there is one external product owner for the team. However, if there are multiple external product owners in a team, all the challenges mentioned earlier become even more significant. It not only amplifies the existing issues, but also adds to the tension and confusion within the team.

Posted by Christian Bisson on: July 18, 2023 09:22 AM | Permalink | Comments (2)

Stop Patching: 5 Steps to Find the Core Problem

When facing a challenge in a project or during the evolution of your product, it's natural to look for quick solutions that can help you move forward. However, this approach can lead to "patching" the symptoms rather than addressing the root cause of the problem. 

In the context of agile software development, a good example of patching that I see trending is relying too much on the Scrum Master as a "Swiss army knife," where any problem is fixed by expecting them to compensate in some way.

While it's true that the Scrum Master is a versatile member of the team, it's important to remember that their primary responsibility is to facilitate the Scrum framework, not to be a jack-of-all-trades.

Instead of treating the Scrum Master as a catch-all role, it's crucial to find the core problem that's causing the challenge and address it directly. This may require some investigation, analysis and collaboration among the team members, but the payoff can be significant. By identifying the root cause, you can avoid repeating the same issue in the future, improve the overall quality of the product, and increase the team's productivity and morale.

So, how can you find the core problem when facing a challenge? Here are some steps that can help:

1. Define the problem. Start by clarifying what exactly the challenge is that you're facing. Is it a technical issue, a communication problem, a misalignment of expectations or something else? Write down a clear and concise description of the problem that everyone can understand.

2. Collect data. Gather information about the problem by talking to stakeholders, reviewing documentation, analyzing metrics or conducting user research. The goal is to get a holistic view of the problem, its impact and its potential causes.

3. Analyze the data. Once you have collected the data, you need to make sense of it. Look for patterns, trends and insights that can help you identify the root cause. This may require some critical thinking, brainstorming or hypothesis testing.

4. Validate the hypothesis. Once you have a working theory of what's causing the problem, test it by gathering more evidence, conducting experiments or soliciting feedback from the team. The goal is to confirm or refute your hypothesis and refine your understanding of the problem.

5. Address the root cause. Finally, once you have identified the core problem, take action to address it directly. This may involve implementing a new process, fixing a bug, improving communication or changing the team's dynamics.

By following these steps, you can avoid the temptation to patch the symptoms and instead focus on solving the core problem. This not only benefits the current project/product, but also builds a culture of continuous improvement and learning that can help the team succeed in the long run. 

So, the next time you face a challenge, resist the urge to rely on the Scrum Master as a Swiss army knife and instead use their expertise to facilitate the process of finding the root cause.

How do you deal with challenges?

Posted by Christian Bisson on: April 17, 2023 03:00 PM | Permalink | Comments (5)

Measure, Measureā€¦and Measure Again!

by Christian Bisson


In a complex world where we strive to improve, there is one trending weakness that I’ve seen amongst many teams and organizations—they measure little to nothing, and make decisions based on “gut feeling.”

Having key metrics is a powerful tool to identify areas to improve, and not just for weak points—you want to recognize strong points as well so that you can continue them. Here are a few examples…



How many times have you seen teams happy to deliver something—only to have absolutely no idea what value was ultimately gained from that delivery? There are a few ways you can be blind to the value being delivered (or not delivered):

  • Not knowing how many users actually used a new feature (maybe none?)

  • Was anything gained out of it? (Money? New hires or better retention?)

  • What was the actual cost compared to the gain?

All too often, people waste money when they could focus their resources elsewhere if they measured the return on investment (ROI) and adapted accordingly.


Delivery predictability

What will be delivered, and when? Every organization faces a challenge to know this. And all too often, typical random delivery dates are given to stakeholders—and forced on teams. This in turn hurts the quality of the deliverable (not to mention the very small odds that the dates are even being respected).

By measuring on a small scale (like a team’s velocity throughout sprints) or a larger scale (like being familiar with SAFe and its “product increments”), you can compare results to actual data to make more reliable predictions (at the end of the day, it is still a guess).


Product backlog health

Throughout the years, I’ve seen many backlogs, from small to gigantic. And I rarely see any of them being measured to make sure they’re actually healthy.

The definition of “healthy” varies, but in this case let’s assume it means that the backlog is an ordered/usable artefact that teams can rely on to know what to work on next to bring value to stakeholders.


Here are a few things that can be measured:

  • How many items are ready to be used by the team (i.e., refined)?

    • Is it too much? Too little?

  • How many total items are there in the backlog? (If there are too many, it becomes clutter.)

  • How much time do items spend in the backlog before they get started? (I’ve seen items rot in backlogs for years, never getting done,)



There are so many things that can be measured and used to properly align next steps—and they require the proper tools to do it efficiently. You want to spend as little time as possible getting the data and results that you need, and utilize reliable “live” information (with little cost to get it).


What will you be measuring in 2023? What do you think your blind spots are?

Posted by Christian Bisson on: February 01, 2023 04:47 PM | Permalink | Comments (5)

Should We Have Longer Sprints?

Categories: Agile, Teams

by Christian Bisson


I’ve recently been part of a discussion concerning changing the length of sprints from two weeks to three weeks, and the product increments (“PI” from SAFe) from 10 weeks to 12 weeks. Hearing the arguments throughout the meeting made me realize how the impact the sprints have on teams is greatly underestimated. Also, it’s important to note that in this case, the sprint length is aligned for all teams—meaning all teams need to change.

In the discussion I was in, the arguments for having longer sprints were that it would reduce the number of meetings (therefore deliver more value), and that we would have better sprint reviews. Let’s review those arguments, and other factors to consider


The Number of Meetings

Assuming we are only referring to “agile” meetings, it’s true that the events (ceremonies) will occur once every three weeks instead of two weeks. However, aside from the daily scrums, the length of each of those meetings is expected to be extended accordingly. 

For example, a good rule of thumb for sprint planning length is about one hour per week in the sprint, so a two-week sprint would have a two-hour sprint planning meeting, and a three-week sprint would have a three-hour meeting—making it an average of one hour per week, and thus not really saving time. The same goes for the review and the retrospective.

The daily is the exception; that would remain at a maximum of 15 minutes every day, so no gain there either.


Better Sprint Reviews

In theory, since sprints would be longer, teams should deliver more within them (more on that under “Predictability” below)—and that will allow teams to present more accomplished work.

Depending on your circumstances, one could even argue that stakeholders would need less travel time to attend the review since it’s once per three weeks instead of two (although these days, even that argument has lost its value!).

But let’s look at the other side of the medal. The review is a key event to gather feedback from stakeholders and obtain precious information to move forward. That now happens less often, and could risk gaps in communication. In some cases, releasing an increment of work is not possible without having approvals within the review, meaning that value could be delivered slower.

So for this argument, I would caution analyzing your circumstances properly before deciding it’s a good idea to change the length of the sprints.


This argument was the “con” discussed in our meeting, which I felt was underestimated. For organizations and teams, having good predictability means delivering all (or almost all) of what we forecast to deliver within a specific timeframe. This is key for planning product roadmaps, aligning dependencies, forecasting budgets, etc.

Predictability in our world is a challenge though; as we know, things change, and what we thought would bring value is only confirmed by empirical information that allows us to adapt as needed. This means that the longer the forecast is needed, the less chance we have to be accurate.

Don’t get me wrong—teams that have gained a certain maturity are expected to get to a point where they can accurately forecast the work they’ll accomplish within their sprint, and moving to a longer sprint would be viable for them. 

But the maturity of the team may vary, and in our case, we were talking about brand new teams that had a decent amount of carry-over from sprint to sprint already, so it was a no-brainer that they would struggle with longer sprints.


Scope Stability

Another element to take into account when selecting the length of sprints: Are the circumstances related to the scope stable enough to be able to focus on a sprint that doesn't (or barely) changes? The longer the sprint, the longer a potential “change” would have to wait—and if it can’t, then the sprint’s scope risks being changed.


Estimating and Splitting Stories

In order to properly plan and deliver sprints, it’s a good practice to split stories so that they fit within a sprint. Therefore, the smaller the sprint, the more it’s important to split stories—and that’s a habit teams develop as they grow.

On the flip side, if a team has not yet developed a good habit of splitting stories, a larger sprint will give it the impression that “it can be delivered within a sprint.” This results in a higher risk of having a backlog of large items that the teams struggle to deliver.



The length of a sprint largely impacts the ability for teams to forecast and deliver accurately. It’s not a decision that should be taken lightly. It’s also important to involve team members in the discussions.

What factors do you consider when deciding the length of your sprint? Any lessons learned to share?


Posted by Christian Bisson on: March 05, 2022 02:57 PM | Permalink | Comments (5)

"My way of joking is to tell the truth. It is the funniest joke in the world."

- George Bernard Shaw