Voices on Project Management

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

Our profession faces some consistent myths. During my career, I’ve came across three that I’d like to debunk:

1. Project management is administrative.
When I first applied for a project manager position many years ago, I talked to a PM and he told me: “It’s an administrative role.”

Despite this, I applied and was accepted—and I turned the “administration” into valuable delivery. The administrative part was not created by the project management role, but by the organization around project management in an effort to follow the budget and check the quality of the project; each person wanted a Word document to be filled to check if the project was on the right track.

Documentation is needed on a project…but what level of documentation? And what level of detail?

If someone tells you project management is administration, answer with this:

• “The level and details of documentation required is defined by the organizational culture in some companies; we must evaluate the aim of the documentation.”
• “I’m an advocate of always seeking out improvements in documentation.”
• “As a project team, we will define the level and detail of documentation for onboarding newcomers and for handover.”

2. Project management is repetitive.
In another role, a colleague told me: “Aren’t you going to be bored? Once you deliver this project, all the other ones will be the same.”

But he was wrong, because each project is unique. Of course, in this particular role, there were some commonalities—but the requirements were different, and the people I worked with were diverse. Plus, I could refine the processes and improve the way I worked with practice and experience. I could also train newcomers to the team. So, I didn’t get bored at all.

For some people, project management is not innovative or creative, because they think there are activities or roles with higher status. But project management is creative in that we need to create a path, aggregate knowledge, practice, use tools—and also use intuition. Now with globalization and the hybrid workplace, we are at the forefront of innovation.

If someone tells you project management is repetitive, respond with this:

• “Each project is unique given its context, requirements and teams.”
• “Just because the external flow of actions looks the same, that does not mean the path to resolution will be the same. We need to set new norms and rituals. We need to explore the causes of problems.”
• “In each project, we make retrospectives or lessons learned. These are great moments of collaboration and creativity.”

3. Project Management is about processes.
Project management uses processes to organize the work and define a plan. In some domains, processes are more prevalent than in others, and for good reason: If security issues are involved, processes have to be followed.

But more than processes, project management is about people and how to work together as a team—of knowing how your behavior is going to impact others.

If someone tells you project management is about processes, answer with this:

• “Processes are used to organize; when you facilitate the work, project management is not used for the sake of processes.”
• “Processes are not carved into stone; change them if they don’t work.”
• “The backbone of the project is teamwork.”

As a community and as practitioners, we need to be role models and change the image of project management—which some people like to keep negative narratives about. Don't let others' perceptions diminish the impact you're making on the world.

What other PM myths have you faced? Share your comments below

Customer satisfaction surveys are one of the most used feedback mechanisms. I have conducted several surveys for internal tools used by engineers within the companies that I worked at, and here I summarize my experience. While I talk about internal surveys, most of what I describe here is applicable for external surveys as well.

Before starting any survey, think through the three questions—why, what and how:

1. Why are we counting? It takes up valuable time creating a survey, administering it, analyzing the results, and acting on it. Respondents must spend time as well. Without a clear “why,” it’s a waste of time and effort. So always start with the “why.”

2. What are we counting? The next obvious question is the “what.” Determine what you are going to count. Ensure there is no ambiguity in the attributes you plan to count.

Also determine which metric you are going to use. There are several metrics: Net Promoter Score (NPS), Net Satisfaction Score (NSAT), Customer Satisfaction Score (CSAT), etc. Based on my experience, NPS is often used for external surveys, and it is often just one question followed by an optional open-ended question for feedback. This might not give you a good enough signal for internal tools. NSAT and CSAT are the most common ones that are measured for internal tools.

3. How are we counting? To eliminate any biases or fallacies, we need to determine how we are going to count. Here are some sub-questions to think about:

• How many people are we going to survey? This is to make sure we have a statistically significant sample size before we draw conclusions, and we are not prey to any base rate fallacy.
• Do we have a representative sample? We need to make sure the survey studies different personas that use the internal tools. Example: If the tool is a reporting tool, executives, engineers, researchers etc. might be some of the personas involved.
• Are the definitions clear? This is to ensure that people do not interpret definitions differently. If you use any abbreviations or acronyms, elaborate what they mean in the survey.
• Framing the questions will impact the survey responses. Keep the following in mind:
  • Pseudo opinions - People give an opinion even if they do not have any opinion. To prevent this, include options like “Don’t know enough to say” or “Don’t know.”
  • Answer sets - Open answer sets allow people to give their automatic perceptions. Closed answer sets provide options that the user might not have thought about. Closed answer sets will get higher completion rates and have the potential for more extreme answers. Ensure the surveys are a mix of both closed and open questions.
  • Response scales - Scales will skew the data. Example: If you are looking to determine how many times the users use the tool, the answer set could be daily, weekly, monthly, or once a week, twice a week, thrice a week. So, think through what makes more sense for the scales.

Here are some dos and don’ts to keep in mind when you think of a survey:

Do’s:

1. For every question you want to include in the survey, think about what you are going to do with the responses.
2. Keep the number of questions to the absolute minimum.
3. Anonymous surveys ensure that the respondents are candid; however, the drawback is that if you have any follow-up questions, you will not know who submitted the feedback. My recommendation is to go with non-anonymous surveys for internal tools.
4. Always follow up on the feedback coming out of a survey and publish the results. Let the respondents know how the survey results have been used. This encourages them to submit the survey the next time.
5. Be mindful of the number of times you send out a survey and carefully choose the cadence. I have seen quarterly, half-yearly and yearly cadences. Choose the one that gives you enough time to act on the feedback.

Don’ts:

1. Do not ignore survey fatigue. It is real, particularly for internal surveys.
2. Do not use a survey if there are other ways to get meaningful feedback.
3. If you are not going to use the responses to a survey question in any meaningful way, do not include that question in the survey.

By Conrado Morlan

In project management, communication is a core competency that significantly impacts the outcome of a project. Most likely, you have worked hard to master your communication skills. Then all of the sudden, the way we communicate changed. The style had to adapt, evolve and amplify with the support of technology during the pandemic.

We were accustomed to more traditional ways of communicating, such as in-person meetings (with groups, or one-on-one with stakeholders), spontaneous conversations around the office, and conference calls, among others. But most of these methods were totally erased when, by necessity, we started to work remotely.

In a matter of weeks, we had to close the communication gap by learning on the fly how to use new technology tools featuring virtual rooms with a mosaic of participants, featuring screen sharing, tool chat, or instant messaging (IM). We faced the challenge of having to define new rules of communication and common ground (like having cameras on or off during the meeting, and muting your microphone if you aren’t talking).

In just a few months, we adjusted to a new way of communication: online calls instead of phone calls; recorded online meetings with automatic transcripts instead of handwritten meeting minutes typed out afterward; more IM communication instead of email communication.

For many project managers who are still remote, this continues to work well; for others who have returned to the office, they are starting to readapt to (or are missing) the “old way of communication.”

Readapting to the “way things were” won’t be an easy task. Many people have lost that sense of personal interaction, and it is becoming more difficult to bring several people together at the same time in a meeting room to discuss the project. People’s preferences have also changed, and many prefer a virtual meeting as they think that there will be no difference to a meeting’s outcome if the meeting is in-person or virtual.

Perhaps the outcome of the meeting will be no different, but what about in-person human interaction—a key element for communication? Reading non-verbal cues is becoming more difficult, a valuable element that will confirm if a “yes” is truly a yes or instead a “maybe.”

As a project manager, what has been your biggest challenge in adopting and adapting the “new way of communication” in your projects?

After a recent project progress meeting with my team, one of the senior members and I discussed the face-to-face communication challenges we have with other members. We concurred that when the person receiving the information has low retention, it results in false assumptions and a misunderstanding on the topic of discussion.

Why is this happening? If the person receiving information confirms that everything is clear, why do we still have communication issues in projects? Usually, it's because taking notes in a meeting is going away, as many team members wait for a meeting recap that summarizes their action items.

In face-to-face communication, we spend most of the time listening—and apparently, we're not good at it. We filter what we want to hear, and that may result in a broken message.

That senior member of my team is part of the silent generation. He mastered his listening skills in an environment without all of the ways to "replay" conversations that we use today. In addition, he mentioned that the communication environment before was "less polluted" than today, where we are bombarded with things that affect our ability to pay attention.

I asked the senior team member what the key elements of good listening skills are, based on his experience. He recommended:

• Pay attention to the dialogue and receive the message.
• Acknowledge the message using positive expressions, such as "Okay" or "I see."
• Confirm the message was received by summarizing what was discussed.
• Ask questions to the person giving information during and after the discussion.

What are the face-to-face communication challenges you have experienced with your team? Do your team members pay attention when you speak? What advantages and disadvantages do virtual meetings have?

As part of starting my technology career, I augmented my undergraduate degree in computer science with a minor in economics. Over the years, I began to appreciate more the inherent wisdom of the demand and supply relationships as it pertains to labor forces. In particular, the laws of economic supply and demand are playing themselves to new heights in these uncertain times.

We see it every day in the news: Jobs by the thousands of all types are going unfilled with nobody stepping forward to fill them. In our industry, we are seeing multiple factors converging to create difficult times for project and product managers. The exponential growth in technology, changing demographics in work forces as well as COVID-19 have all greatly impacted what we do on a day-to-day basis.

For project and product delivery, I am observing that labor shortages that impact our delivery efforts take on two different forms:

1. For new projects and products, the ability to find new resources is extremely difficult. Staffing durations are taking longer and it’s ever more challenging to find skilled, experienced team members.
2. In addition, existing project and product resources are being consistently overcommitted, which leads to multiple negative outcomes—including their potential loss as they explore other options due to burnout.

As a project and product manager, these market conditions create a confounding set of risks that need some refreshed thinking in order to mitigate their impacts. Here are a few of my thoughts on ways we can manage around these challenging times:                                                           

1. Up Your Game on Scope, Schedule and Resource Management
One of the hallmarks of a great project manager is their ability to synthesize threats to scope, schedule and resources. They rigorously examine and take action to curtail creeping scope, aggressively monitor planned versus actual schedule progress, as well as frequently check resource utilization.

In addition to giving more emphasis to these areas than ever before, project managers need to look beyond their project for external threats. By taking more of a portfolio manager mindset and looking for external threats including other projects, they can better anticipate and address challenges to their own delivery commitments.

For high-speed, iterative agile product delivery, labor shortages make for even more challenging times. One of the benefits of a dedicated set of resources for an agile product team is that over time they reduce the learning curve and improve decision-making efficiency. Swapping resources in and out of agile product delivery due to labor shortages creates damaging disruption to both schedule and quality. This environment compels agile product managers to be even more vigilant when it comes to managing scope, schedule and resources.  

2. Get Back to Basics
As the complexity of project and product delivery grew over the years, the amount of supporting reporting, analysis and review meetings grew in lockstep. In addition, the complexity of indicators, metrics, narratives and other project metadata increased as well—the intent being to quantitatively identify delivery volatility before it becomes an issue.

While the increased frequency and depth of examination improves stewardship and has helped with early detection of delivery volatility, in these times there may not be enough capacity to warrant this level of detail.

To help mitigate impacts of labor shortages while not adversely impacting delivery, take a good hard look at the project and product metadata that is currently being produced. For the level of uncertainty and risk on your project or product, can the frequency of reporting, analysis and review meetings be reduced in order to spend more time on activities that directly impact delivery?

For the depth of metadata, explore simplified methods for conveying progress against a plan. For example, the use of additional done/not done milestones to measure progress would take less effort than gathering timesheets to calculate total effort. Rationalizing where it makes sense, the frequency and breadth of supporting metadata creates more capacity for direct project and product activities.

3. Restore Real-Time Individual Engagement as a Norm
People are both the most valuable and the most fragile when it comes to project and product delivery. One of my post-graduate professors in an organizational design class once shared, “The greater the level of uncertainty, the closer the level of interaction is required between people.” Loosely translated for modern times, this means: Don’t try to solve complex problems by email.

Pre-pandemic, there was a lot of personal interaction in an office or site; these days, we rely on online collaboration tools as a primary means of connection and communication. Despite the ability as a group to remotely connect audibly and visually through the use of these tools, difficulties remain in terms of the effectiveness and efficiency of personal engagement, especially at an individual level. Individual connection has always been a means of identifying both new ideas as well revealing challenges that may not arise in a group setting; all the more reason to make it an increasingly frequent activity when managing projects and products.

While modern times present new challenges, it’s still possible to connect on a person-to-person level. Outside of the normal cadence of group meetings, set up recurring individual connection sessions with team members. These can still be done with collaboration tools—but they have all the advantages of what private conversation can provide. I’m finding these individual meetings have a great propensity to really help us understand the underlying dynamics of project and product delivery. (If you happen to live in reasonably close proximity and abide by any local regulations, that doesn’t mean an espresso in person to stimulate conversation would be out of the question!)

These are indeed challenging times, the likes of which I have never before seen in my project and product management career. Labor shortages as well as volatility from resource overcommitments are all causing us to rethink our day-to-day activities on how we interact with people. While we can long for the days when walking down the hall in an office to connect with a team member was the norm, we as project and product delivery managers still need to take steps to overcome these challenges in our drive for successful delivery outcomes.

I welcome any comments on what others are doing to help reduce the impact of labor shortages with creative project and product management techniques. Share your insights below!

by Christian Bisson

For far too long, I've seen new teams being set up with barely any time allowed to actually enable their success. There are many aspects of creating a new team that people forget or underestimate, and it can create short-term and long-term problems.

With all of the different topics the team should cover at the beginning, an effective setup could easily take two or three full days.

Here are several aspects that should be included:

Meet & Greet

If there’s one thing I've seen being left aside because "it takes time we don't have," it is allowing the people who will work together to actually get a chance to get acquainted with each other. This is an important aspect as it helps to build trust among team members, and trust is the foundation of any efficient team. Trust will not be built overnight, but planning a team-building activity to allow people to share about themselves will at least give it an initial boost.

The team-building activity can take many forms. Regardless of what is chosen, it should be something anyone would be willing to jump into. Some people will be shy at the beginning and not everyone will feel very open, so make it something accessible. 

Identify a Framework

Another important aspect is to identify the framework the team will be using. Is it scrum, Kanban, waterfall? Typically, this is already decided. Assuming everyone is an expert in the framework, the team just "jumps" in it. It's important to plan time for training on the topic, and a decent training could easily take a full day or more.

Let's use scrum as an example. Training should include an overview of the framework and other aspects like the roles within a scrum team, backlog management (ex. writing user stories, how to properly split them, etc.), how context switching can affect productivity, etc.

Discuss Ways of Working 

Along with the framework, there are other aspects that the team members need to agree on. These will vary depending of the framework and the team's circumstances, but here are a few examples:

• Team agreements: The team should agree on day-to-day aspects of how they will work. For example: What time are the scrum ceremonies? What's the decision-making process? What tools will be used? What are the communication channels? What standards dictate how to work (ex. coding standards)? 
• Definition of ready: This is a definition agreed upon by the whole team on what is required for an item in the backlog to be considered "ready" to start working on it. For example, it would need a properly formatted summary, acceptance criteria, etc.
• Definition of done: Another important definition the team should agree on is what is considered "done" for a backlog item. For example: test coverage, approved by someone, code review was done, etc.

Agreeing on these can easily take a few hours depending on the size of the team and the maturity of good practices.

Knowledge Mapping

Clearly identifying each team member’s skills is likely the most forgotten aspect of setting up a team that I've seen so far, and yet it's crucial to:

• Identify missing competencies
• Identify the gap between team members
• Track team development
• Identify missing resources

Once this is mapped, it's easier to plan accordingly on how knowledge will be gained. For example, if a technical skill is only known by one expert among the team, it could be planned for that person to train the others. It might be knowledge about the system the team will be working on that will require ramping up. You might also notice that some expertise is completely missing from the team and needs to be acquired from a source outside the team.

Having the team discuss what skills are required, having them map out their strengths and weaknesses, and then discussing next steps is not in itself very time consuming, yet many teams skip that part and thus risk hitting roadblocks along the way.

Conclusion

I've written a few examples of what should be part of a team setup agenda. You can see that for it to be an efficient setup, the team will need time—which will pay off immediately. So "just do it!" 

How are you setting up your teams? What topics are necessary?