Voices on Project Management

by Dave Wakeman, PMP

On a recent visit to Reddit, I noticed a trend from some project managers—who were asking questions about how you can tell if your company is doing project management all wrong.

That got me thinking about some signs that an organization doesn’t have a healthy PM culture—and three big ones came to mind. Do you experience any of these where you work?

1. No idea why the role of project manager is key to a project’s success: I believe we’ve all been there—we see someone assigned as the project lead due to being in the wrong place at the wrong time.

Why do I say that? Because just throwing out the PM assignment is never a case of being in the right place at the right time.

This is truly the biggest warning sign that an organization isn’t project manager ready—they just have no definition of why the role of PM is so important to a project’s success.

Instead of having a clear expectation of the PM’s role with a defined process in place to help with achieving specific goals (including communication expectations, a definition of success, and an understanding of how the project ties into the organization’s strategy), the organization basically sticks its hand into a paper bag with pieces of paper, drawing one name out. (Or worse.)

Beware!

2. No clear definition of success: This one seems to take hold in a lot of organizations, and it is usually coupled with the impression that “I’ll know it when I see it.”

This kind of attitude almost guarantees failure. There are exceptions where a project comes together well without this definition in place—but that is very rare.

Why? Because without an understanding of what success looks like, any direction is a good direction.

This can be frustrating for all stakeholders, because when pressed for objectives or measures, a lot of time the feedback comes back as fluffy terms that aren’t related to the project’s success like “man hours,” “activities” or something else.

Bad project organizations judge success by “feel.” Good project organizations judge success with metrics.

That way, you can say, “We hit our target. Here is why…”; or, “We missed the mark. Here’s why, and here is what we can do to change it next time…”

3. No resource investment tied to specific projects: This is one I’ve been blindsided by in the past.

Why? Because I’ve fallen prey to the answer, “Whatever it takes!”

Trust me: “Whatever it takes!” is never actually “Whatever it takes!”

Organizations without a project culture underestimate the resources needed to make a project successful. This leads them to offer “commitments” or “promises.”

Most of the time, when a PM tries to cash in on those “promises” and “commitments,” it is impossible. The resources aren’t actually available.

This stands in contrast with an organization that is built for project management—where you have the scope, you know what success is going to look like, and you have a clear understanding of the resources that are going to be needed to hit the project’s objectives.

Does this mean that there are never changes or limits to the resources available? No. Not even close.

What this does mean is that a good project organization starts with some base level of commitment of resources, not just “commitments” and “promises.”

To me, every project requires these minimums from an organization in order to give success a chance:

1. An appreciation of the role of the PM. You are a leader, not a magician.
2. A clear definition of success, not just platitudes.
3. Resources. Maybe not everything I wanted, but more than “promises” or “commitments.”

I’m curious what things you have noticed that set an organization’s projects up for failure. Let us know in the comments below.

As program managers, we have to deal with various conflicts in the workplace. The book Think Again: The Power of Knowing What You Don't Know by Adam Grant calls out valuable insights into distinguishing between task conflicts and relationship conflicts—and this proves useful in reaching effective resolutions.

According to Grant, task conflict refers to disagreements or differences of opinion that arise between team members regarding the tasks they are working on. On the other hand, relationship conflict refers to personal disagreements or clashes between team members that are not related to the tasks they are working on. Relationship conflict could be due to power struggles, personality conflicts or prior conflicts leading to mistrust.

Task Conflict
Task conflict is encouraged as it promotes creativity, critical thinking and innovation. Some examples of task conflicts are: differing opinions on how to design the user experience for a particular product, or the technical architecture for implementing a system.

By having diverse opinions and having team members debate various options, we get an exploration of ideas and solutions. Task conflict often stimulates healthy debate and increases team motivation, as team members feel that their input is valued. Grant states that some organizations build challenge networks (groups of thoughtful critics) into their cultures to stir up task conflict. If your team does not have task conflicts, it might be a sign of lack of trust or other underlying issues.

While task conflict is beneficial, it is important to manage it properly. As program managers, we can play a crucial role in resolving task conflict by implementing the following strategies:

• Clearly define roles and responsibilities of program members. Use tools like RACI.
• Encourage open communication and active listening amongst your team members.
• Maintain focus on the task. Clearly identify the outcome that you are expecting. Team members should focus on finding the best possible solution, and it should not be about winning arguments or proving others wrong.
• Identify points of agreement and points of contention. This will help team members gain consensus easily.
• Use one of the three facilitating techniques (or any technique that you already have in your repertoire) mentioned in my prior blog post, ‘How to Foster Effective Group Decision Making,’ to gain consensus on points of contention.

Relationship Conflict
While task conflict can be beneficial to team dynamics, relationship conflict is detrimental. According to Grant, if task conflict is not managed properly, it can easily escalate into relationship conflict.  Relationship conflicts at work will lead to negative emotions and decreased productivity.

Occasionally, relationship conflict can manifest as task conflict. If you notice that the same individuals have recurring task conflicts even when it is not necessary, it should signal that there are some underlying relationship issues.

I have noticed this a few times with a few of my team members—and upon further investigation, I was able to find that the individuals in question had relationship conflict.

Here are a few tips for dealing with relationship conflicts:

• Set ground rules on how team members should conduct themselves, which includes acceptable behavior and procedures for handling conflict. You can add them as part of your program charter.
• Similar to how open communication and active listening is important for resolving task conflicts, it is important to resolve relationship conflicts as well.
• Identify the root cause of the conflict by talking to the team members involved in the conflict in a one-on-one setting. Avoid taking sides or showing favoritism.
• Resolving relationship conflicts requires handling people’s emotions. Sometimes this results in heated arguments and personal attacks. If you are comfortable facilitating discussions to resolve relationship conflict, go for it. I personally do not try to get into solving team member’s relationship conflicts, as these need to be handled sensitively and might require manager or HR intervention.

While it is not possible to avoid relationship conflict completely at work, you can minimize them. One way to keep relationship conflicts to a minimum is by creating professional boundaries at work and not oversharing your personal information. Getting too involved in others’ personal issues or oversharing your personal information can create unnecessary emotional investment and conflict.

I have had my share of conflicts as well—and wondered why I felt uncomfortable dealing with some conflicts versus others. This insight about task versus relationship conflict helped me figure out the reason why. 

In conclusion, I can attest to the importance of understanding the differences between task and relationship conflict. While task conflict can be constructive if managed properly, relationship conflict is often detrimental. By understanding these differences, we can better manage conflicts and create a more positive, productive environment for everyone involved.

What strategies have you found to be most effective in resolving conflicts? Leave your ideas in the comments below!

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.

Conclusion
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?

By Yasmina Khelifi, PMI-ACP, PMI-PBA, PMP

We’re one quarter into 2023, and hectic days are succeeding. Routine is back as you keep your nose to the grindstone.

But stop for a moment and ask: What do you envision for yourself as a project manager for the coming year? You may have (or become) a mentor, or you may have a personal board of advisors.

Ultimately, you are the origin of your own change. To help you take the reins, I'm sharing three ideas to level up your leadership:

1. Embrace passion and diversity. You may have been in the same role for a while, or with the same team—and entrenched in routine. Ask yourself these questions:

• What energizes you with work? This can be something related to technology, innovation, new problems to solve, new ways of working, etc.
• Are you taking advantage of the diversity on your team? Teams can be diverse by age, gender, profession, knowledge, culture, academic backgrounds and more.

​​​​​​​​​​​​​​By embracing your passions and the knowledge that comes from diversity, you can unleash fresh energy because you’ll get new perspectives, meet new people and discover new environments.

If your day job doesn’t bring the novelty and diversity you need, look for other opportunities within your organization—or outside of it. What communities can you join? I joined a marketing community, and it has become a great source of creativity. You can also try new activities, like sports, music, or learning a new language. Who knows? You might discover new strengths you never knew you had.

2. Get involved—and go beyond. Regardless of the years of project management and leadership experience you have, you can make an impact through your knowledge and lessons learned.

For example, through my work, I was asked to talk at a high school about my job as a project manager. Not long ago, I would have considered the opportunity a waste of time—but it was interesting to hear the perspectives and questions of young people.

In another volunteer activity, I got contacted to present on project management to some students at a university. It was unpaid and involved some work and preparation. Before, I would have shirked the opportunity—partly because of my fear or not being able to answer all their questions, and partly because of the benefits (or my perceived lack thereof) that I could earn from it.

Now, I hesitate less as it is a way to give back and go beyond my day job. More importantly, it is a way to share my knowledge and learn how to present my expertise comprehensively. I just need to adapt my communication, which is a learning experience for me.

In both cases, it was a short one-off event. What about you? Are there conferences where you can help or present? Were you contacted by your alumni community? Did you ever accept or decline a similar engagement? What about volunteering in your community?

3. Ask for feedback. If you work in the corporate world, you most likely have regular performance reviews. Perhaps it is systematically done; and sometimes, it doesn't happen. And yet, feedback—both positive and negative—is a great way to uncover things you are not aware of. It can strengthen your brand—and more importantly, help you gain confidence. Do you take the opportunity to ask for feedback from your colleagues?

Many years ago, I took part in a 360-feedback assessment where the consultant sent an anonymous survey to colleagues. This year, I did the same by myself. I wanted to get new insights about the way I manage projects from a technical and behavioral point of view. I also wanted to see what strengths people identified for me. It didn’t take me long to create the survey. The outcome was insightful and gave me new improvement paths.

What other things have you planned to level up your leadership?

By Lynda Bourne

Agile in its various forms is becoming mainstream, and this means an increasing number of commercial contracts are being delivered by contractors who either choose, or are required, to use an agile methodology to create their contracted deliverables. While this is probably a good thing, this shift in approach can cause a number of problems. This post is a start in looking for practical solutions to some of these issues.

Two of the core tenets of agile are welcoming change to add value, and working with the client to discuss and resolve problems. While these are highly desirable attributes that should be welcomed in any contractual situation, what happens when the relationship breaks down, as it will on occasion?

The simple answer is that every contract is subject to law, and the ultimate solution to a dispute is a trial—after which a judge will decide the outcome based on applying the law to the evidence provided to the court. The process is impartial and focused on delivering justice, but justice is not synonymous with a fair and reasonable outcome. To obtain a fair and reasonable outcome, evidence is needed that can prove (or disprove) each of the propositions being put before the court.

The core elements disputed in 90% of court cases relating to contract performance are about money and time. The contractor claims the client changed, or did, something(s) that increased the time and cost of completing the work under the contract; the client denies this and counterclaims that the contractor was late in finishing because it failed to properly manage the work of the contract. 

The traditional approach to solving these areas of dispute is to obtain expert evidence as to the cost of the change and the time needed to implement the change. The cost element is not particularly affected by the methodology used to deliver the work; the additional work involved in the change and its cost can still be determined. Where there are major issues is in assessing a reasonable delay.

For the last 50+ years, courts have been told—by many hundreds of experts—that the appropriate way to assess delay is by using a critical path (CPM) schedule. Critical path theory assumes that to deliver a project successfully, there is one best sequence of activities to be completed in a pre-defined way. Consequently, this arrangement of the work can be modeled in a logic network—and based on this model, the effect of any change can be assessed.

Agile approaches the work of a project from a completely different perspective. The approach assumes there is a backlog of work to be accomplished, and the best people to decide what to do next are the project team members when they are framing the next sprint or iteration. Ideally, the team making these decisions will have the active participation of a client representative, but this is not always the case. The best sequence of working emerges; it is not predetermined.

There are some control tools available in agile, but diagrams such as a burndown (or burnup) chart are not able to show the effect of a client instructing the team to stop work on a feature for several weeks, or adding some new elements to the work. The instructions may have no effect (the team simply works on other things), or they may have a major effect. The problem is quantifying the effect to a standard that will be accepted as evidence in court proceedings. CPM has major flaws, but it can be used to show a precise delay as a specific consequence of a change in the logic diagram. Nothing similar seems to have emerged in the agile domain.

The purpose of this post is twofold. The first is to raise the issue. Hoping there will never be a major issue on an agile project that ends up in court is not good enough—hope is not a strategy. The second is to see if there are emerging concepts that can address the challenge of assessing delay and disruption in agile projects. Do you know of any?