Voices on Project Management

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

A few years ago, I joined a new team and took over some projects from the team’s manager (let’s call him Alex). Alex was helpful: He participated in all of the meetings I conducted, was available to give me advice, explained former issues he faced to help me anticipate problems, and supported me during meetings when my answers were not correct. In this new role, I lacked self-confidence—and it was a great relief to feel helped and supported.

The conflicts came a few months later when Alex didn’t change his behavior after I had gained knowledge and confidence. He wanted to take part in all of the meetings; I told him I wanted to manage by myself and contact him when I needed help. “Why?” he answered. “What is the problem if I take part?”

I didn’t know how to reply. I felt like he wanted to deliver projects with me (which is what he did most of his life before becoming a manager). He also wanted to learn and see how I handled things. When he was in the meetings with me, even if he didn’t say much, I felt like I didn’t have any wiggle room.

On the other side, he complained a lot of being overloaded, and he was late with managing administrative tasks.

As a manager, as a mentor, as a mentee and as a project manager, how do you find the right balance between mentoring and micromanaging? Here are some simple strategies I’ve observed—and am trying to practice myself:

1. Set ground rules. Talk with your manager or your mentor about the ground rules. You can ask: Are there weekly check-ins? Shadowing opportunities? What’s the frequency? What if I think you’re too intrusive?

If your mentor is also your leader, you can also enquire about how he/she usually onboards people.

You also need to clarify your needs…

• As a mentee and team member: When there is a technical issue, do you need the leader to jump in, or do you prefer some time to think and find paths you can share and discuss?
• As a mentor and a leader: If you love mentoring, perhaps you can have several mentees or be part of corporate or external programs. If you love keeping your fingers on the projects, perhaps you can volunteer for other projects. Do you really need to have all the technical details?

I always remember an excellent manager I had—when there was an issue, he asked general questions to help me step back and see the big picture. It was a very helpful strategy.

Mentoring is a gift—but can become a burden if the mentor’s help overlaps your responsibilities.

2. Agree about the volume of information to share. I love helping and sharing information. When there is a new team member or mentee, I send several emails with a lot of information to pave the path—well, that is what I think, anyway.

But I sometimes got feedback like this: Which email should I look at? There is too much information. I prefer receiving information when I need it.

It reveals a blind spot for me: Not all people work like me, and some colleagues need information on a different cadence—and not all at once.  People can feel stressed when they receive too much information, like they’re unable to keep up with the onslaught of emails. Some perceive me as invasive.

When I remember Alex, I try to refrain from guiding too much. I need to let people decide what to do with the information—and get back to me when they want to. I need to talk openly about how and when to share information; provide information when it’s required; and not inundate people without discussing it.

3. Know your boundaries—and accept the boundaries of others. As a leader and mentor, you must acknowledge the needs of your teams. If you love explaining and helping, perhaps you can invest this energy into volunteering or blogging.

You also must accept your team members' needs to explore first, to make up their own minds and make mistakes, which is all part of the learning process. Have an open mind; listen to their worries and issues, and be ready to help when needed.

By doing so, you will encourage your team members not to hide or downplay problems—and to learn from their mistakes. You also carve out your position as a role model. This is not a one-off exercise, but it’s worth the effort.

Mentors and micromanagers encompass two different behaviors, but can overlap when we don’t realize it. By mentoring too closely—even through goodwill—you can undermine a person’s performance, their well-being and, ultimately, their growth.

Have you been—or experienced—a micromanaging mentor? Share your comments below.

by Dave Wakeman

My mind is on summer break. Anytime I start thinking about my summer plans, I also think about how I can use this to teach a lesson. I think I’ve come up with a pretty neat way to tie a trip to the beach into the jobs that project managers do every day. Let me explain…

As PMs, the job is to manage stakeholders, communicate, adapt and adjust, put out fires, and to end up as a clearinghouse for everything that has to do with your projects. We also hope to achieve a break because we want people to be able to make their own decisions and to take actions independent of us doing all the thinking.

This is where my vacation comes in, because when I am away, I like to be totally away—independent of any decisions for my business. Which brings us to the question: “How do we create an environment where our teams go on without us?”

Let’s take a quick tour through three ideas:

1. Give people some autonomy.

I remember reading the book The 4-Hour Workweek, where Tim Ferriss talked about turning over problem solving to his outsourced sales and service team. His solution was to set parameters when the outsourced team should just act.

Such as, “If solving this problem costs $100 or less, you make the best decision and let’s move on.”

How can we apply that to our work?

As a PM, you might set parameters for your purchasing agents that tells them, “If the purchase is under $1,000, you do what you think is best.” The number isn’t important, the transfer of authority is.

The same idea applies for correcting errors, changing a process, or communicating an issue. Set up the parameters for when you need to know (or don’t need to know). Then, you stick with them…no matter what.

2. Don’t be the first to respond to everything.

Some of the worst habits that we encourage when leading a project or a business happen because we feel like we must do everything ourselves.

Look, I’m as guilty as the next person of doing that—responding to emails at all times of the day and night, trying to juggle what can feel like 30 or more different things at once.

When you give yourself a few moments to think about it though, it won’t work for taking a real vacation. It doesn’t allow you to be a really effective PM.

Why? Because you become a bottleneck.

How do we not become a bottleneck? First, you set those parameters like we discussed at the top.

After that, you want to be more in control of your time and how you use it.

Do you check your emails constantly? I used to. Now I don’t.

Instead, I might check them once an hour or every few hours even. And, on vacation, I’m likely to check my emails twice a day.

You can do this even in your normal workday. I do two things to force myself into better habits:

• I schedule things aggressively, meaning that I set out my priorities for the day and I schedule those into my calendar so they have the time I need to complete them. I schedule writing posts like this one for the same recurring time every month. I get them done.
• Second, I use a tool called “Focus To-Do,” which is an app that I have on my desktop, laptop, iPhone and iPad. It is a timer. I use the Pomodoro Method of 25-minute chunks of deep work, with five-minute breaks. It might seem too simple, but I’ve trained myself to set aside that 25 minutes to only focus on the task in front of me. If I finish early, maybe I check my email or do a different task. But the key is blocking out the distractions and setting the expectations that I’m only going to be available at certain times. That works well on vacation, sure. But it also works well all year round.

3. Be gentle on yourself and others.

Most mistakes aren’t fatal and can easily be fixed. Which makes the constant churn of work and the constant need to be “on” seem less necessary.

I worked on some political campaigns, and I’d train folks to write campaign ads. They’d always start with apprehension, because a lot of folks would snap under pressure, yelling and screaming about an ad that didn’t work the first time.

I took a different approach by saying, “If we mess up, we will fix it. No one is perfect.”

What happened was removing the pressure of perfection (or near perfection) enabled my teams to do better work. They felt freed from the need to get everything exactly right the first time because they knew that I was going to say, “We are off here, but let’s see what we can do to fix it.”

That’s something we should all be paying attention to. On vacation, I can turn over tasks to people and they feel comfortable doing them because they know I’m not going to freak about an error or something having to be redone.

In our projects, giving people that freedom probably gives us a break from being the bottleneck we talked about before. But it also gives our team members the chance to do their best work without fearing that wrath will rain down on them.

That may not mean you are on vacation, but certainly it can make your job easier…and that might really feel like just the break you need.

I’m off to the beach! See you next month

By Soma Bhattacharya

In discussions I’ve heard within Scrum teams over the years, three common concerns often come up:
1. “We need longer sprints.”
2. “We always have spillovers and can’t seem to fix them.”
3. “Ad hoc tasks always mess up sprint planning.”

I think this often originates from general discomfort people have when problems surface; but for me,
dealing with things like this is exactly what agile is all about. So, here’s an alternative way to think
about these three problems:
1. Sprint durations: It’s common knowledge that with the change of a sprint duration, the team
capacity changes as well. So, when teams complain about needing longer sprints to finish the
work, it’s clearly due to a lack of planning (and having no time to cover up the lack of it). So
instead of bringing up what needs to be ready during planning, teams will usually take it all on
because someone has told them to. This can be easily resolved by the team simply looking at
its velocity trend and recognizing how much work can be taken and delivered.

2. Spillovers: These are not the villain here. What matters most is discovering why the
spillovers are happening. Sometimes when ad hoc works comes in, instead of going for a
tradeoff (because capacity is limited), teams just take it all on and then end up with a
spillover. Oftentimes, waiting for a dependency with other teams or external partners messes
things up. Teams refrain from speaking even if they see risks because everyone is waiting for
someone else to raise the flag. This is where team empowerment and decision making can
be improved upon.

3. Unplanned work: Sprint reviews can be a good platform to talk about unplanned work
seeping in. The best way to bring that up can be to see what the percentage of unplanned
work is within a team’s capacity. A simple way to track this is by creating a user story and
keep adding to its unplanned work, along with the time spent. So, during a sprint review, the
spillovers or tradeoffs are easy to talk about—and the “blame” (if any) doesn’t always fall on
the team. Everyone gets the needed clarity.

Being agile is very different from just being part of standups. The main issue is that leadership often
does not sponsor the agile teams—and in the process there’s more confusion. The team is forced to
attend agile ceremonies, but sees no benefits because it is still forced to work on things that weren’t in
the plan. Bringing up blockers (and how much time is spent on them) or costs will allow a simple
decision to be made: Do you want to continue being agile? And if “yes,” how much decision making is
the team empowered to make?

What common issues have you encountered on your Scrum teams, and how have you dealt with
them?

Kevin Korterud

In this high-demand/low-availability labor market, we all have to start re-thinking about how to staff one of the increasingly most pivotal roles in large, complex technology delivery: the program PMO lead.

In the past 10 or so years, we have all seen the size and scale of delivery dramatically increase as the business and technology landscape becomes more complex with multiple solutions, architectures, geographies, suppliers and organizations—and enabling layers such as cloud platforms. For new technology solutions as well as transformations, program delivery leads now spend more time than ever navigating this highly complex landscape—which leaves less time for traditional program management activities.

This situation has put an increased premium on the PMO lead role, which typically was portrayed as more of an administrative function. Ever more frequently, the PMO lead role has become closely integrated with the program delivery lead role in terms of guiding the trajectory of delivery…to the point where they resemble an adjunct delivery function to the program delivery lead.

The common dilemma today: Where does one find a PMO lead that can oversee the typical delivery operations activities such as risks, issues, workplans and tools—as well as assist the program delivery lead with critical delivery assurance efforts? In addition, how can we fill a PMO lead role with the right person in a timely manner as not to impair the mobilization progress of a delivery program?

As opposed to the traditional approach of trying to staff at the last minute when demand arises for a PMO lead role, the most effective path is to have the next generation of PMO leads on hand before you need them. Keep these three points in mind:                                                          

1. Recognize that large, complex and transformation PMOs require a unique mix of leadership skills. Programs are typically known to be a collection of delivery projects that directly fulfill a unified set of business needs. However, the landscape of programs has changed over the years where they now have to be implemented in a highly integrated, more complex technical and business environment. In addition, there can be transformative enablement capabilities such as value realization, organization change management and dependency management.

Given this landscape, PMO leads that solely oversee the execution of serial recurring PMO processes will not be successful. The PMO lead of today needs to have skills that transcend pure administrative execution by serving as a broker of conflicts, predictor of delivery volatility, as well as an organizational enabler of progress. In addition, to do so PMO leads now engage at a much higher level in an organization.

To achieve success, PMO leads need to have prior experience with complex delivery leadership, senior executive engagement as well as an ability to quickly grasp the delivery “big picture” in order to take action in a proactive manner. Traditional administrative backgrounds are not enough to prevail in today’s delivery environment.  

2. Domain and local knowledge is highly valuable. In addition to delivery leadership, executive engagement and the ability to sense prevailing conditions, it’s very helpful to have additional knowledge in the areas of business domains, as well as localized organizational characteristics.

For example, the learning curve of a PMO lead that spent most of their career in healthcare would have to be enormous to grasp the terminology and concepts of energy exploration; the converse is also true, when an energy exploration PMO lead serves on a healthcare program. In addition, organizational entities in companies may differ between regions and product lines.

There are a few methods to help ensure that domain and local knowledge needs are fulfilled. Where possible, prioritize PMO leads that have prior business experience in a specified domain area. To assist with understanding the organizational entities, consider the PMO lead shadowing the overall program delivery lead in recurring leadership meetings.

Where there are no available PMO leads with the necessary business domain nor local knowledge, consider providing business domain training as well as conducting immersion sessions for the prospective PMO lead in advance of their start of their role. It’s much quicker to take PMO leads with the right mix of modern-day competencies and incrementally bring them up to speed in these areas than it is to try and instruct a business domain lead on complex delivery.

3. Rotational PMO lead roles build more effective delivery leaders. In order for PMO leads to stay ahead of the game, their role needs to start in advance of delivery activities. In today’s complex environment, any delay in staffing a PMO lead will be detrimental. The best way to avoid this problem is to make the PMO lead role a rotational staff function. This enables it to be a training ground for future delivery leaders.

In the military and other organizations, the notion of a rotational staff assignment is quite common. In addition, it is highly prized given the visibility it provides—as well as the ability it creates to foster further career growth (which might not be found in a traditional assignment).

Current delivery leadership that needs to gain experience with more complex delivery, as well as experienced new joiners, are both examples of candidates for modern-day PMO lead roles. In addition, standard PMO lead training should be designed, built and deployed. Organizations that identify, groom and deploy PMO leads in a timely manner are already starting out ahead of their competitors. This model is not limited to employees of an organization; performing the same function with suppliers is also valuable to reduce the chance of late PMO lead fulfillment.

The function of a program management office has been both an integral and essential component of complex industrial delivery for almost 100 years. Over the past few decades, technology delivery leaders—as well as stakeholders—have gained a similar level of appreciation for the importance of the program PMO lead.

As demand continues to increase with no end in sight to the shortage of capable PMO leads, it’s best that companies start to build their own cadre of future PMO leads; this is essential for both staffing this role in a timely manner, as well as to ensure the growth of delivery capability.

I welcome any comments on what others are doing to help both staff program PMO roles, as well grow this function in your own organization.

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

I recently touched upon fighting imposter syndrome, which we can all suffer from as project managers. But as a leader, and even as a colleague, we can also unintentionally foster impostor syndrome on our teams. Let’s review three ways I’ve observed (and unfortunately practiced) this over my career—and what we can do about it.

1. Credentials and work experience don’t define human beings

Many years ago, I worked with a project manager who managed a strategic account. I was skeptical of our ability to lead; she was not an engineer, and she didn’t have a technical academic background.

As always, I had many ideas and began to regularly push them—and to ask many questions. I always have suggestions on how to do things differently—in other words, my way. I also talked with contempt to show her that (I thought) she was not a legitimate candidate for the position. My behavior stressed her out.

I've often heard this concern: "I'm not considered as a project manager even though I'm a PMP certified and I've been doing the work for a while". That’s the kind of comment that can shutter self-confidence.

When I took on a new role, a woman on the team told me: “You were chosen because you can speak Arabic.” I cannot speak Arabic (neither do I understand it), and I was hurt because she negated—unintentionally—my skills as a project manager.

How can we improve? Work doesn’t define you completely as a human being. It’s important that when team members introduce themselves, you don’t focus just on their academic credentials and work experience; listen when they share what they like outside of work, and what they struggle with. Understand how they aim to contribute to the team and what added value they bring beyond academic degrees.

2. Start with the positive

Are you always objective? Do you always provide criticism or feedback on something from a factual perspective, or might it differ depending on who developed the work?

When a colleague enthusiastically shows you something they have done and your first response is, “It's good, but...,” that can dampen their enthusiasm and spirit—especially if relates to an area where they lack confidence.

For instance, I’ve improved my skills in PowerPoint, but I still feel insecure about them. So if a colleague modifies a lot of my presentations, it reinforces my inner voice that I’m not good with the application.

How can we improve? Simply asking people to redo things doesn’t help them improve; be sure to use positive reinforcement and explain what needs to be improved, with some best practices or guidelines. This way you help your colleague grow.

3. Follow good role models

In workplaces where technical expertise is valued and technical resources are needed, we sometimes overlook inacceptable behaviors. For instance, a technical expert silencing a less technically savvy colleague in front of everyone, highlighting that what was said was wrong. Or talking with a very authoritative voice, as if giving an order. These types of behaviors should not be followed or encouraged.

How can we improve? Ask yourself: Does my comment add value to the problem that needs solving? Is this an intellectual debate? Or is it a personal attack or an ego booster?

In what ways have you fostered impostor syndrome in your teams? Share your comments below.