Voices on Project Management

by Dave Wakeman

I just got back from taking a road trip, and while I was away for the month, I had my website rebuilt from the ground up. It turned out nicely and makes me look like I really know what I’m talking about.

All kidding aside, having to put my website in the hands of an expert in web development taught me some lessons about project management that either I forgot or needed to learn.

Let me share a few of them with you…

1. Being clear on the outcome you hope to achieve is crucial. At the end of the project, I debriefed with my web developer and she said that the nice thing about working with me is that I respect her work and don’t micromanage.

As we continued talking, I realized that the reason I didn’t micromanage the project was because I was pretty clear in the project brief with exactly what I needed to achieve and what success looked like to me.

Due to that, I was able to give her clear instructions and allow her to do the work I brought her in to do.

In managing projects, all of us should be aware that if we spend a lot more time at the start of the project being clear about the results, we are likely to need to spend less time micromanaging or “handling” things during the project.

2. Communication is key. I’ve been talking about the people aspect of projects since I started writing this column back in 2012. In doing a project to rebuild myself under constraints imposed on me by the pandemic, I remembered the importance of clear communication.

In the past, I know that I have written that the keys to successful communication are for your messages to be:

• Clear
• Concise
• Easy to understand

Over the years, maybe I’ve been guilty of getting away from those three principles, but I was reminded that these are essential communication qualities and that it is good to keep them in mind—especially when managing remotely.

3. Let experts be experts. One of the key ideas in my project management talks and writing is that as the leader, you can’t be the smartest about every aspect of your project. That’s why you work so hard to build strong teams.

As often as I remind myself, I know that I can still slip up and throw out bad ideas.

It causes two problems when I do this:

• First, it slows down things because the people on my team often have to explain to me why I am a knucklehead and why I am wrong.
• Second, it slows the team members down because they have to do their work and they end up thinking about the way that they are going to have to justify something to me. Even when that isn’t what I really want, my actions tell them something different.

Strangely, my website project came together very well and I managed to keep myself from micromanaging the whole process. I was reminded that as a leader you have to:

1. Be clear in your vision
2. Communicate effectively
3. Give experts room to do their job

What do you think? Let me know in the comments below.

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

Are you a micromanager in your projects? Of course not! (Who would answer “yes” to this question?)

However, after 20 years of work experiences with several managers and project managers, I’ve met micromanagers—and I was also one of them.

Let’s review some language that reveals repetitive micromanagement behaviors observed during my career…

1. “I want to help you.”

A few years ago, I had a micromanager. He was full of good intentions and always wanted to help me. He liked to brainstorm together, whereas I needed to brainstorm alone first and then share with the team. Without knowing it, he was stymying my creativity and motivation. I tried to explain to him I preferred to work independently and that I would come to him when I needed to, but he was offended by that as he wanted to help—and at the same time know it all. Ultimately, although the work was interesting, I left the team. His help was counterproductive.

I’ve also proposed (even insisted) offers of my help to colleagues; now I try to refrain from doing that, remembering that manager.

2. “You are responsible for this work package—it would be good to do this…”

I worked with a very competent technical project manager who wanted to know the details of the work. He once assigned me the management of a study with external stakeholders. He delegated the work package to comply with good management rules—but couldn't help interfering because he had a precise idea on how to do the work. I asked him if he wanted to manage it himself. My question waked him up, and he was less intrusive.

When I managed my first software project, the sponsor wanted to know everything. He asked me questions, which I transmitted to the software engineers. They answered them reluctantly, complaining that we should let them define the way they wanted to implement the product. They considered it a lack of trust, which generated conflict.

3. “Don’t forget to ask her to call us if she needs more information.”

Some project managers also told me: “At the end of the email, don’t forget to mention that we can have a conference call if more information is needed.” I thought in silence: “Don't you think a professional who needs more information will call? Do we need to add this sentence?” (Or another sentence about an email sent to a top manager: “Are you sure he transmitted the email we sent to him?”)

This excessive control translates into wordy emails that don't bring value—and it increases our stress.

4. “Copy me on all emails.”

In the software project mentioned above, I also wanted to be copied to all emails, anxious about missing any information. I didn't read them all, but I didn't ask to be removed from them. It gave me the illusion of knowing all about the project.

Getting out of the micromanagement trap
What triggers these behaviors? Is micromanagement a personality trait? I’m not an organizational psychologist, but over the years I've found the main reasons for micromanagement are:

• an excess of perfectionism
• the “shame” of not knowing
• a lack of maturity in people skills, especially if an SME becomes a project manager
• top management is distrusting and thus too inquiring, going beyond their role in an attempt to learn every detail

The way to get out of this trap that we can all fall into is to honestly express what you need to work efficiently and healthily—and also express what triggers frustration and stress. You have no guarantee that sharing this will solve the situation, but it will help avoid frustration from building up and bursting out.

We want to share our work experiences and help others avoid the traps and mistakes we've gone through, but making mistakes is part of the learning process. In addition, explaining these things to a seasoned project manager may be perceived the wrong way and come across as hurtful. Mastering how to help your team without micromanaging is a top competency in the hybrid world.

What other micromanagement behaviors have you observed (or exhibited)? How did you deal with them? Share your comments below.

By: Lynda Bourne.

Has agile killed the organization chart? The concept of business management evolved with the development of factories during the early days of the Industrial Revolution. Initially, factories followed the same system as pre-industrialized enterprises where the “Lord of the Manor”/owner made all of the significant decisions and told others what to do. But this straightforward command-and-control process was limited by the capacity of the owner to stay on top of the flow of information and decisions needed.

As organizations grew larger and more complex, the delegation of authority became necessary—but initially appears to have been very ad hoc and dependent on personalities. But as the concept of an organization evolved in the 19^th century, management structures became more formalized—and one of the early tools used to demonstrate the management hierarchy, and the division of labor, was an organization chart. The example below is from 1917:

This view of an organization give rise to concepts such as departmentalization, chain of command, span of control, centralization, work specialization and formalization. The business appears well organized (at least on paper), but is not very adaptive.

Traditional project management grew out of business management, and uses the organization breakdown structure (OBS) linked to the work breakdown structure (WBS) to define the person responsible for each element of the work. The OBS fulfils the same function as an organization chart in general business, defining the management hierarchy and reporting lines within the project or program.

But is this type of thinking useful in today’s flexible working environment? In one respect, knowing who is going to be responsible for delivering each element of the project and ensuring their work integrates with the other parts of the project is important, as is the need to balance the delegated levels of authority and responsibility with the capability of the assigned person.

The OBS is also useful for informing the people doing work who they need to keep informed of progress, issues and the completion of the task. These concepts are central to the way earned value management is designed with the management cells above becoming control accounts.

But does the effective management of human resources need a hierarchy, or can distributed responsibility work as effectively and more dynamically? There are many success stories built around self-organizing teams, cross-functional teams, and agile ways of working. And in business, matrix structures are probably more common than the hierarchic structure depicted by an organization chart.

The organization chart has been around for a very long time, but does the type of structure and management theories built around the concept of a management hierarchy really help at the project and program level when confronted with “alien” concepts such as self-organizing teams and agile? The two questions posed for discussion are:

1. Do you think the OBS is useful, and is something similar used in your project or organization?
2. What options are available—or need inventing—to replace the OBS in an agile, self-organizing workplace?

 By Soma Bhattacharya

Never fear challenging the norm.

A standup seems like the norm for any agile team, part of the identity associated with being agile. As many of us all now work remotely, it seems that the right way to start the day is by attending the standup and getting the status items, questioning team members—and dealing with interruptions from multiple stakeholders.

Whether you like it or not, there’s no one rule for getting the standup done. It’s about connecting with the team and being there for each other without ruthless questioning.

So, if you are not answering the standard three questions (What have you completed? What will you do next? What is getting in your way?), what else can you do? Here are what I call the three acts:

1. Socialization: Working alone from home for more than a year under pressure and deadlines hasn’t been all cozy, so take the time to just catch up with each other. Listen and get to know each other. Simple games like this one can help you still feel like part of a team and that you aren’t working in silos: The scrum master as the facilitator can ask the team to write down “one act that makes you feel proud,” written anonymously on (virtual) sticky notes and tacked to the team board. During the standup, ask team members to identify who wrote which sticky note. It’s fun, and you get to know each other—especially any members that have joined most recently and never met the team face to face. It gives them a better idea of who everyone is, and knowing something personal will always make you work better around them. No one forgets a good story.
2. Intrigue: Look at the burndown chart, as this will allow conversations to start naturally on how things are working out for the team. This ensures there is no finger pointing and brings the group together. Decisions are made by the team based on the data and the general team trend. I find it far more effective than just the three questions. Another tip that always helps: Look at the buffer usage as a health check for the teams. Start with a 10% buffer in sprint estimation. Look at the burndown, and if you see the buffer is being completely utilized, find ways to uncover why and where the estimation went wrong, or if more tasks are being added later. Increase the buffer and continue to keep on checking on the team trend; you will either fix the leak or find the root cause.
3. The wrap: Support and positivity should always be the closing thoughts. Even if the team is behind schedule, team members should find ways to work together and use the learnings for better estimations and strategies next time. This is a marathon, not a sprint. Your behavior, bonding and team experiences matter in keeping the team together during these trying times.

Changing the norms to ensure things are working for you—and keeping it that way—is agile. No one shoe fits all, so find what your team needs and try it out!

During the long duration of the pandemic, each of us had to shift our work/life balance. We had to curate a new workday schedule, perhaps adding more flexibility to support multiple needs between work and family. A changing focus with customer and colleague engagement, repurposing commuting time, tending to family needs, caring for those affected by COVID-19, and supporting relief efforts are just some of the changes we had to adapt to. The pandemic forced each of us to make personal and conscious ethical decisions on the tradeoffs, but most have of us have set into a new work/life balance.

After almost 20 months, the world is deploying COVID-19 vaccines under health authorities like the U.S. FDA and Europe’s EMA, who have expanded access protocol for emergency use. The world is hopefully on a trajectory toward a post-pandemic world. Many organizations have established their return-to-work policies, criteria, and expectations of colleagues. One may observe a continuum of return-to-work guidelines built by organizations as a highly collaborative model focused on high-touch customer experience, an innovation-driven design model, or task-based transactional work. Each organization is calling to us to spend some time back in the office or in front of our stakeholders.

How does this affect us, and what do we do to prepare? Our choices can be to simply go back to a pre-pandemic “normal”; stay in the work-from-home pandemic style; or re-engage in a post-pandemic style. Regarding this last choice, we should consider how to maneuver ourselves into a post-pandemic style while still maintaining the agility of working from home. This disruption to our current way of working creates a sense of stress and anxiety as it asks us to re-engage. One must re-learn and adapt to new behaviors and approaches.

One opportunity to be better prepared may be to create a personal contract for the post-pandemic work world. The contract can be a statement or a list of priorities. Here are some tips that I will use to help make the transition better and reset myself:

1. Revisit what you and your colleagues are professionally devoted toward, and why.
2. Curate the difference of a workday at home versus in the office (or traveling).
3. Coordinate specific dates and times for in-person versus virtual meetings.
4. Make lunch plans with newly hired colleagues.
5. Start a back-to-work focus group to help facilitate colleagues’ transition back.
6. Be clear about your constraints on social distancing, work hours, and time off.
7. Schedule healthy eating times, sleeping and exercise habits, family needs, etc.
8. Identify your new peeves and triggers; be mindful of behavioral changes (from both you and your colleagues).
9. Start a journal and chronicle your path and learnings.
10. Remember: Everyone has a different path—but together we will get through it!

What would your list include to enable a post-pandemic transition back to work?