Voices on Project Management

By Soma Bhattacharya

The phrase “quiet quitting” is all over the internet as the trend has gained in popularity over the last few years of the pandemic. The one thing you need to confront the temptation: motivation.

Motivation for today’s generation is something that’s in sync with purpose and autonomy. In one of his Instagram posts, Adam Grant—an organizational psychologist and best-selling author—says this about quiet quitting: “Doing (the) bare minimum is a common response to bull$#!* jobs, abusive bosses and low pay.”

While it may be true for some, for others it can be lack of alignment in seeing the purpose they serve within the organization. So, we might need to fix the flawed system and also highlight what’s in place.

In any agile team, most of the ceremonies always carry an inherent meaning (at least that’s what I have always stressed). Release planning or “big room planning” is about communicating the purpose, the big picture and how each team or individual comes together to contribute.

If done correctly, teams are happy to have the knowledge and prepare for it. It also allows team members to raise concerns and flex their mastery at what they are going to work for the next three months. It’s designed for social communication, bringing in multiple teams in one room or platform.

Encouraging teams to participate and normalize conflicts is a healthy practice—as long as it’s moderated and everyone is looking at the end goal. Conflicts can foster higher creativity and better solutions within teams. That in turn that will also engage individuals and negate the “quitting mentality.”

A small team brings in autonomy to a great extent and allows everyone to feel empowered, like they’re playing their part. The whole concept of limited size in scrum teams means better communication, stronger bonds and faster decision making. The bonhomie improves team harmony and creates its own culture, one that can only come together with openness and trust.

A simple initiative like buddying up, mentoring or pair programming is a common practice. Giving everyone a way to relate and connect to the big picture and to a team can also result in better learning, and an enhanced social life at work—leading to a sense of belonging, which is essential for growth and individual engagement.

Any team or organization that practices any of the above will tell you than when team participation is higher, so is the interest in coming back to the office—and that a better quality of work is a byproduct.

Often in any agile teams, we forget why we chose agile. Building a culture of trust, openness and empowerment can benefit everyone. Choosing wisely to see what needs to be changed or adapted can allow for better vision and a stronger roadmap for the team—not just for the product, but for team building. Choosing the right team imbibes a great attitude.

We must all be aware that with every generation, social change and work environments go through major shifts. So, what worked five years ago might not be the right environment post-pandemic. So, blaming the system or organizations for certain practices might not be the right choice. Understanding a team and what it wants out of work is equally important to confronting negativity. Maybe consider that change is a refreshing thing—not just for newcomers, but for management as well.

By Sree Rao, PMP, PgMP, PMI-ACP

Have you ever made a program or project decision that did not turn out to be the right one? As program managers, we not only need to make several decisions over the course of a project or program, but we also need to guide our teams with decision making.

Here is a framework to help you make decisions based on data and objective criteria. I heard about the RICIE model in a strategic management course, and found it to be really helpful to internalize the steps needed for rational decision making. Here I am proposing the RISCIE model, which is a minor modification to that model.

The RISCIE framework has six steps:

1. Recognize the problem/opportunity: In this phase, identify an opportunity or a problem that you want to solve. If it is a problem, identify the root cause of the problem. Do not mistake symptoms for problems. Example: Team members are consistently missing deadlines. This is a symptom that is a result of either bad planning, unclear requirements or team members’ lack of experience.

2. Identify solution criteria: Most of the time, we jump to solutions instead of identifying the solution criteria. To choose the best solution, come up with a list of criteria that the solution must meet. Example: The solution must be implemented in three months to meet the launch date, or should cost below a certain amount. Prioritize the criteria.

3. Solutions exploration: Analyze possible solutions that would fit the solution criteria. Do not stop with just one solution—explore multiple ones.

4. Choose a preferred course of action: In this step, evaluate all the solutions against each of the criteria that were identified in Step 2. Choose the solution that meets the most criteria. If there are multiple solutions that meet all the criteria, evaluate if there is a possibility to do a quick prototype or proof of concept of each of the solutions. This would uncover any pros/cons of the solutions that were missed in Step 3.

5. Implement the preferred course of action: The next step is to implement the chosen action. Ensure that any solution criteria that were defined upfront are indeed being met with this solution.

6. Evaluate the results and follow up as necessary: Lastly, evaluate the results. Ensure all the KPIs are being measured, and operationalize the solution. Do a lessons-learned or a retrospective session to use them for subsequent decisions.

Ensure everything is documented and that all the key stakeholders are involved in every step of this process. While this process does not guarantee successful outcomes, it does guarantee that your decisions are based on data and objective criteria. Do not measure the success of a decision based on the outcome (outcome bias). I plan to write my next post around this topic. Stay tuned!

What tips do you have for rational decision making in your projects and programs? What mistakes have you made, and what are your lessons learned?

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

At school in France, we were primarily evaluated by the number of mistakes we made and less by our progress. What was importance was to attain excellence and perfection.

Fast forward to my professional career, I have worked in many teams with many people—and some of them have proudly said of themselves, "I'm a perfectionist.”

I recently thought about all of the different project managers I have worked with over the years, and how I managed teams. Being in a technical environment, I have worked with technical experts and many demanding people. I used to think I was a perfectionist…until I worked with many of them. I now see how damaging it can be.

Here are some things to keep in mind with perfectionism…

1. It results in an individual mental burden.
On the individual level, being a perfectionist forces you to redo and rework (documents, slides, speeches, etc.). It is exhausting because your mind is not at peace until everything is done exactly as you want it to be done. You wrestle with your inner critic. And when you get a negative comment, your self-confidence takes a hit and you work even harder to reach so-called perfectionism. The cycle continues.

In the long term, it can damage your mental and physical health. In some cases, perfectionism stems from a stress reaction. It can serve as a wake-up call that you need to alleviate your stress.

Think back to the last moment you were a perfectionist in your activities. How did you feel? Was it worth it? Next time, can you try to let it go and see what happens?

2. It’s a teamwork killer.
When you work alone, being a self-perfectionist can damage your mental health. But if you work in teams and apply the same level of so-called perfectionism (or is it mania?) to them, you can trigger an even more damaging reaction. (I had some colleagues who worked with perfectionists, and they had to rework the slide deck a hundred times because the slides were not quite perfect.)

You must recognize the bigger responsibility here. “I’m a perfectionist” is a refrain you can use to explain your requirements. Don't fall into the trap of this easy excuse! Find an accountability buddy who can help you refrain from this burning desire for perfectionism. Working on changing habits and behaviors is an essential skill for leaders.

Unfortunately, when collaborating with some colleagues, you can also foster impostor syndrome. For example, take Mike—a new project manager in a new field. He doesn't have strong self-confidence. If you are a perfectionist for the work he delivers to you, it may foster impostor syndrome for him. It can also demotivate him, which will be counterproductive. (For more, read my entries Fighting Imposter Syndrome as a Project Manager and Do You Foster Imposter Syndrome in Your Team?.)

Ultimately, the expected impacts are that your coworkers will try to avoid working with you or become numb to your feedback.

3. Adopt a continuous learning mindset.
What is important is to balance the value of perfectionism with the expected outcomes. If you’re giving a presentation in front of a multimillion-dollar client, of course you'll need to polish it and have it reviewed repeatedly. But in general, accepting mistakes from yourself and your team members is the first step in acknowledging that we are humans and that we are learning every day.

Paving the way to improve step by step will be more beneficial and less stressful for you—and your team. In addition, you’ll become a role model as a leader.

If you work with perfectionists in your projects and you’d like to help curb the trend, perhaps you can follow a few tips:

• Send regular surveys to all stakeholders about the organization, content and format of whatever you are working on (you can even make feedback anonymous). This provides an opportunity to see an external view and helps to illuminate the perfectionist about their behavior.
• Debrief the team (including the perfectionists) on the results.

In doing so, you also instill a continuous learning mindset.

What are the acceptable boundaries you set up for yourself and your team in your projects? When can you squander? How has perfectionism helped or hindered you as a project manager?

by Dave Wakeman

I was reading an article the other day about understanding the signs of burnout. The list was pretty much representative of what most people share when I talk with them about it these days: It included things like trouble focusing, missing deadlines, not feeling like they know what they’re doing, and struggling for motivation.

Then I saw a reminder of how we are in the third year of the pandemic—and that’s when I realized that we are all likely dealing with some level of burnout. So let’s take a step back and figure out how to help our people during tough times…

1. Be aware of what is going on.

I’ve had to slap myself upside the head a few times to remind folks that we are currently dealing with a situation that can rightly be referred to as “toxic stress.” We are still struggling as a society to get COVID under control, many of our economies are showing signs of recession, people have new routines, there are climate issues…I could go on.

I won’t because that would be too depressing. But the starting point of addressing stress and burnout is recognizing what is going on. You can’t solve a problem you can’t see.

If you are feeling a little stressed or under pressure, you can imagine that most people around you are feeling something similar.

2. Be open about these challenges.

In working with my clients, I try to give them room to talk with me—even about things that aren’t related to our projects. Sometimes, just getting things off your chest can just help you cope with challenging times.

Unfortunately, many of our organizations (and our culture) try to reinforce a feeling of stoicism around troubling times and encourage us to keep our issues pent up inside.

As a leader, you have to recognize that the default is unfortunately to not mention anything and to not seek help or a sympathetic ear. So, you may have to force this issue a little bit; that’s okay. The payoff for your team will be huge, and your ability to help people will make you a better leader in the long run.

3. Look for ways to release the pressure valve for folks.

Everyone has deadlines, meetings, internal and external pressures, and much more. We can’t control everything for our teams, just like they can’t control everything around them. But we can often find solutions to help relieve some of the pressure.

In North America, I see a lot of businesses letting their teams have Summer Fridays off. I also see team get-togethers at ballparks, picnics and other places where they can be outside together in an informal way (as mentioned above, anything simple where we can just provide an ear). You might encourage this by setting up “bull” sessions where there is no agenda.

Going even further, you might be able to relieve some of the deadline pressure or the feeling of endless connectivity by setting expectations around turning off devices, response times, or turning on your out-of-office notifications to get a break. The big idea here is that you have to actively engage in this process with your team.

In my world, I think I find that this is the key to everything when you are dealing with people, especially in an environment where everything can feel like a struggle. Put on the brakes and take a step back. Then, be deliberate in finding ways to give people an ear to bend, a feeling of support, and a little space to catch their breath.

Maybe I’m crazy, but we all need that right now.

What signs of burnout have you noticed in yourself and your co-workers, and how have you dealt with it? Share your thoughts in the comments below. And for more on this topic, read The Danger of Project Manager Burnout.

By Lynda Bourne.

Over the last few months, I have been part of a group working on a series of papers looking at the history of project management and project controls. This required the classification of the various stages in the development of the practice of project management. However, almost every author of project management history has a different view of the major change points.

Our take on the major phases of development of project management is driven by changes in the project control tools and processes being used. Better control processes provide new insights, allowing improved or changed management approaches. Based on this framework, the major phases in the development of project management seem to be:

1. From early times through to the 1960s – the traditional management of projects
2. From the 1960s through to the present – modern project management
3. Future interactive and intelligent systems – to be determined

Prior to the 1950s, the primary control tools showed static representations of cost and other deterministic data. The sophistication of both the management data and its representation in reports improved over the centuries, but the controls processes focused on reactive management actions to correct observed deviations from the plan. The people managing projects were priests, builders, engineers or other authority figures.

The current phase of development of project controls uses largely deterministic information to predict future outcomes. This phase of development started in the late 1950s with the creation of PERT and CPM schedules, and has progressed through to the point where there is general acceptance that earned value and earned schedule are among the best of the predictive control tools.

This phase saw the creation of “modern project management” as the pioneers of computer-assisted project controls worked together to form the various project management institutes (including PMI in October 1969), and the institutes in turn defined and codified the practice of “modern project management.”

As a result, the people managing projects were increasingly identified as project managers. Various styles of project management are emerging (this was discussed in my post on The Entropy at the Heart of Project Management), but regardless of the approach, the concept of a project—run by a project manager, to create value for a client—is consistent. Project management is now expected to be proactive, working to minimize the negative effect of future problems identified using predictive tools, as well as dealing with any current negative variances.

The next generation of project controls is starting to emerge. These tools are predicted to be integrated, adaptive and intelligent, with a focus on maximizing the efficient use of the project’s resources. They will use machine learning, and be integrated into the systems used to design and develop the project’s outputs rather than operating as standalone processes.

One example is the emergence of 5D BIM (five-dimensional building information modeling) in the construction/engineering industries. A three-dimensional design is integrated with the schedule (4D) and cost information (5D) to provide a single system accessed and used by everyone involved in the design, construction and future maintenance of a building or facility. Project control tools with embedded intelligence are also emerging.

These developments are too new to have much impact on the nature of project management today, but by the end of the 2020s we are likely to see as much change in the way projects are managed as occurred in the 1960s.

Do you think these phases in the development of project management are reasonable, or are there other major inflexion points?