Voices on Project Management

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

The ability to maintain a learning mindset is a top hiring quality that can potentially be more important than experience. Despite that, no one explicitly explained to me how to do it. I’m curious and ask many questions, which has helped me gain new insights.

However, given the pace of change in the world, this is not enough. Based on my experiences, I’d like to share a three-step roadmap to make the motto “learn continuously” a reality.

1. List your obstacles

First of all, you have to acknowledge it is not so easy. You are bombarded with information from social media, with successes from former colleagues or university friends. We may be tempted to follow all the paths and then abruptly stop in the middle. You may also have work-mandatory training.

At the same time, you want to prepare yourself for the next role and take other training courses. How can you squeeze in learning now and tomorrow in between all your work and your personal life?

This is where you need to reframe your mindset.

2. Change your mindset

Don’t be too hard on yourself. Stop repeating, “I have to do A and B,” “ I don’t learn so much” or “ I’m lazy.”

Learning doesn’t only take place in formal classes—something I’ve only recently understood. Being aware of this will help you be more satisfied with the learning you pick up along the way.

Also accept that it’s okay to be less ambitious; it is better to learn a little daily rather than not at all.

Force yourself to learn things in completely different fields. For example, talk with a video expert if you work in compliance, or have lunch with a marketing colleague if you work in technical fields.

Last but not least, be open to changes along the way. You might need to learn a new tool or technology you were unaware of at work. Or you might become overwhelmed by work or personal issues that stop your plan—and that’s okay. If you accept these changes, you will not feel frustrated.

3. Sharpen your approach

Define clear objectives for what you want to learn (hard skills or power skills), and for when (short term, mid term, or long term). It will help you prioritize them.

Then you have to map how you would like to learn these skills—taking a training course, preparing for a certification, etc.

Engaging in communities within your industry to keep abreast of the latest trends and having conversations with experts is also important. You can also watch a webinar, listen to a podcast, or read a blog or a book.

The key is to not insist on doing all the different things at the same time.

Learning continuously is a lifelong project to develop yourself professionally and—more importantly—as a human being.

How do you learn continuously? Share your feedback below.

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.

Conclusion

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.
 

By Dave Wakeman

I caught myself listening to the 2Bobs podcast recently and the episode about the qualities of the best project managers. David C. Baker shared a list with his co-host, Blair Enns: 

1. Command authority naturally 

2. Quick sifting abilities 

3. Re-evaluate project priorities frequently 

4. Listen to stakeholders…really listen 

5. Predictable communication cadences 

6. Domain expertise in project management 

7. Consensus-building skills 

8. Informal networks 

9. Didn’t just happen into project management 

What do you think of the list? Let me know in the comments below. What do I think of the list? Let me share a few thoughts. 

First, the ability to get people’s attention and command authority to lead is key in any leadership position.  

This one rings true. For us, I’d also like to point out that being commanding doesn’t mean being loud or outgoing. It means having presence and having people believe you’ll get them where they are going.  

Second, sifting abilities and evaluation skills go together.  

I write about business acumen here regularly. David’s list items would fit the idea of business acumen because you need to be able to consume data quickly, organize it, and take action within the context of your environment.  

Third, being an effective communicator has been at the heart of this column for years. It is also the No. 1 reason I would put down if you asked me why project managers fail—they don’t do a good job of communicating up and down the chain of their project.  

To me, this goes to the idea of consensus building as well. If you aren’t a good communicator, you aren’t going to be able to build consensus because you are going to miss important points.  

Fourth, informal networks. I love this one because I’ve spent a long time building them. I have my newsletters, podcasts and community, all with people from a diverse section of industries, countries and backgrounds. I like to tell myself that this is one of the keys to my success.  

The key point that David and Blair were making is that the wider those informal networks, the broader your frame of reference for your experiences. Having a broader experience base is going to help you, no matter what experience you might have.  

Finally, project management as a practice and an area of expertise. I have found that some of the best project managers I’ve ever met wouldn’t necessarily call themselves by that title, but they’d agree that they get things done.  

But getting things done is a special skill—one that you don’t just happen into, and can’t really wing. You might develop it outside of the normal project management practices (I developed mine in marketing, nightclubs, and sports business), but the key idea is that you develop expertise in project management with the same attention to your craft that any other respected professional would (even if you don’t call yourself a project manager).  

Overall, I like David’s list. As a challenge to myself, I’m going to make next month’s post about my own list of attributes of “the best project managers.”  

I’ll also be curious to see what attributes you think the best project managers have. You can leave those in the comments section (I’ll even try and use your ideas in an upcoming piece).  

The business world is busy. It is busy with words: emails, messengers, phones and videos. It is busy where we work: open spaces, flex desks, public transportation and crowded cities. It is busy in matrix organizations: transversal meetings and redundant communications.

How can we translate this noise into building relationships with people?

Why we fear silence
Sometimes, we make an effort to speak uninterrupted so we don’t leave space for uncomfortable silence or questions, or because we are stressed. It is situational.

In other cases, this is part of our image of being a leader. You may have been influenced by former leaders you saw, or colleagues who you admired because of their energetic way of talking.

You may have deduced that this is a good way to be a leader and have tremendous executive presence—that taking up “speaking space” signifies power, of someone who has knowledge and wants to share and mentor.

There are also cultures (national, corporate, educational) where you are pushed to speak up, give your point of view, or express yourself. It is valued. It is a sign of engagement and interest. When people are silent in these cultures, they may be judged as less engaged and even less competent.

Some languages don't bear pauses and silence. Others need it. I became aware of that in an exciting way. I work with Spanish colleagues remotely, and we usually speak English. I am looking for the point when some Spanish colleagues talk in English; I feel like the sentences have no end (like in French). When we speak in Spanish, I don’t have this feeling at all.

Pauses and silence make you a better leader
You can improve your communication when you take care of pauses and silence—if you use them in the proper context.

In some languages (like Japanese), making small sounds when people talk is essential to confirm you are following the conversation. By mistake, I began to do the same in French and said "yes" regularly. The person thought I wanted to talk and, at a certain point, told me, “Can I speak, please?" These small sounds in French were interpreted as interruptions.

I have also worked with British colleagues a lot in the past by phone. When I finished a sentence, I wondered what happened: My colleagues waited a bit before talking. I thought there was a network issue. But when I paid more attention, I noticed how important it was to leave some seconds between the end of my sentence and the beginning of their sentences. It was a way to ensure I finished speaking, and not to interrupt or overlap.

This small break is also practical when you don't use video and don't see if the person wants to add something. It was a practice I didn’t have. I tended (and still tend) to speak right away after the end of a sentence. Now, I count five seconds before talking.

When you immediately jump to the next sentence, you look more aggressive and less respectful. But when you begin to pause and stop speaking, you leave more space for others—and you listen more to silence.

Learn to listen to pauses and silence in your teams
Silence can have different usages:

• It helps you and your teams digest information and think about what was said.
• It helps you and your teams prepare an answer, or answer in a quiet way, to hurtful comments or questions.
• It helps you and your teams to breathe and step back.

Silence can also have different meanings:

• It is a cultural way of communicating.
• It can express some disagreements people don’t dare say.
• It perhaps signifies a lack of interest in the topics.
• It may show a lack of understanding and/or a fear of asking questions.
• People do not have time, or do not prioritize your projects.

When you work remotely, you may send emails and don’t get any answers—despite the good relationships you have built. There might be simple reasons: people have personal issues; there are other problems in the organization (or the country); people have other priorities. That’s why it’s crucial to have different sources of knowledge—people who know the country.

How can you distinguish between these different meanings? You need to observe, listen properly, and learn to decipher pauses and silences. They are part of the rhythm of communication. Adapting to different rhythms can forge better relationships with your team members and create a more collaborative environment.

What are your experiences with pauses and silence while communicating in your teams

By Lynda Bourne

The never-ending debate between agile and waterfall seems to be fuelled by different groups of people talking about completely different concepts with little understanding of other’s perspectives. From my viewpoint, some of the key disconnects are:

Agile vs. Agility: In the modern VUCA^[1] environment, agility is important. But organizational agility is not the same as the organization choosing to use an agile project delivery process.

Organizational agility is constrained by the nature of the organization and its assets. A major mining company cannot suddenly decide to stop mining iron ore and focus on rare earths; is has billions invested in its existing mines, and new mines take many years to bring on-line. It can refocus investments “immediately,”, but the results take decades to be fully realized?and suddenly deciding to reverse the decision in a few years’ time will waste millions. Adaptability is important, but decisions have to be nuanced.

Conversely, a small consulting business whose main asset is its people can decide to shift focus on an almost daily basis to keep up with fast moving trends?think of applying AI in almost any sphere.

However, any type of organization can choose to use an agile methodology to help deliver those projects that benefit from an inherent flexibility in working.

Agile vs. Projects: Agile methods are not exclusive to projects, and not all projects benefit from agile.

Agile methods such as Kanban and Scrum can be used for operational maintenance (particularly of software) without the overhead of project management. The maintenance team use its preferred method to prioritize the repair and upgrading of the operational system and keep track of the backlog. New requests are added to the backlog, prioritized, and completed in a stable business-as-usual function.

Where using a project approach to undertaking a defined scope of work is desirable, some projects are suitable for the use of agile methods, others are not. Most “soft” projects creating an intangible product such as software will benefit from an agile approach to development. But heavy engineering projects where safety and structural considerations are paramount need a fully planned and disciplined approach to avoid disaster.

There is a continuum from projects that are suited to agile through to those where a tightly controlled planned approach is essential. Deciding on how to best manage projects along the spectrum is as much a cultural decision as a technical one.

Non-Agile Projects vs. Waterfall: Agile advocates continue to try to divide the world into “agile = good”, “waterfall = bad”. I discussed this issue in my post “The Problem with Waterfall, Agile & ‘Other.’”

The simple fact is very few software projects use waterfall; the concept was promulgated by the U.S. Department of Defense in 1988 for software development and abandoned in 1994, but some organizations have hung onto the perception of “control” for various reasons. However, outside of the software industry, no one uses waterfall.

Contrary to the view of most agile advocates, the concept of change as defined in the Agile Manifesto and change in almost all other projects is based on the same premise. From the Manifesto’s second principle: Agile processes harness change for the customer's competitive advantage. Change that destroys customer value is no more welcome in an agile project as any other.

Every contract for the delivery of a project to a client I’ve seen in the last 50 years has included clauses for the management of change. What varies is the cost of implementing the change. If you have delivered 15 out of 20 software modules and the client asks for five more, there will be time and cost implications based on the 25% increase in scope. If you have built 15 stories in a 20-story high-rise building and the client demands an additional five stories be added, the only option is to demolish everything, install stronger foundations and start again. But if the client decides to change the building color scheme from pale grey to pale blue before the paint is ordered, the cost of the change will be minimal. Regardless of the project delivery approach, change is only beneficial if it creates additional value.

Where the Agile Manifesto is of value across all project type is in its focus on relationships, people, and communication. These concepts are becoming more important in all industries and across all project types.

Conclusion
We need to move on from the “agile/waterfall” debate and recognize:

1. An appropriate level of organizational agility is essential in the modern VUCA world.
2. Agile project delivery methods have benefit in the right situations; they are not a silver bullet to solve all project delivery challenges.
3. Waterfall is not a synonym for bad project management; no one uses waterfall, but there are plenty of examples of bad project management around.
4. Good project management focuses on relationships, communication, and people by motivating the right people and using the best approaches to deliver value to the project client. But the best approach depends on the nature of the project deliverable.

What do you think?

^[1] VUCA stands for volatility, uncertainty, complexity, and ambiguity.