Voices on Project Management

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?

Individual decision making is fraught with biases and fallacies. In one of my earlier blogs I talked about common fallacies and biases in program management. We can mitigate these biases by using group decision-making techniques, where you encourage participants in a group to brainstorm a solution/decision. Group decision making taps into the collective intelligence of the group and increases the acceptance of the decision by all the group members.

However, group decision making has its own drawbacks. A couple of key drawbacks are:

• Groupthink – A psychological phenomenon that occurs within a group of people in which the desire for harmony or conformity in the group results in an irrational or dysfunctional decision-making outcome.
• Possible domination by the most vocal or senior person.

We can avoid these drawbacks by using some facilitating techniques that bring out dissenting opinions and give everyone in the group a chance to present their thoughts/ideas.

Here are three facilitating techniques that we can use to bring out dissenting opinions:

1. Devil’s advocate method – As the name indicates, in this technique we identify one person or a subgroup to act as “devil’s advocate.” One subgroup iden=tifies the solution or decision and corresponding assumptions. This subgroup then presents the decision to the “devil’s advocate” subgroup/person. Responsibility of the devil's advocate subgroup/person is to present a contrarian view and poke holes into the assumptions and the decision/solution. Intent of this facilitating technique is to think through alternate scenarios.
2. Dialectical inquiry method – This is very similar to the devil’s advocate method. The main difference is that in this method, one subgroup is assigned to think through one option and the other subgroup is assigned to think through the opposite option. Both the subgroups then come back and talk about both the options. The team then comes to a final option based on the group discussion. One key thing to remember when using this technique is to ensure there is diversity in terms of gender, experience, personality types etc. when creating the two subgroups.
3. Step-ladder method – In this technique…

• In the first round we ask everyone in the group to come up with their own ideas. 
• In the second round we bring in two people, have them present each others’ ideas and agree on a temporary decision/solution.
• In the third step, the third person presents his/her idea to the first two and the three of them come to a temporary decision/solution.

This continues until everyone has a chance to present their ideas in an unbiased way and their feedback is incorporated into the final decision. This is a time-consuming process, so use this cautiously.

In situations where we end up with more than one decision/solution, we can use objective criteria to converge into a single solution/decision. Here are a couple of frameworks we can use to make rational decisions:

1. Mediating assessment protocol: Daniel Kahneman, a Nobel Prize-winning psychologist, suggested this approach for making important strategic decisions. In this method, we identify assessments or criteria that are important for analyzing a decision. We then assign individuals to conduct the assessments. Once all the assessments are done independently, the group then makes a collective decision based on individual assessments. Interviews conducted by major tech companies like Google, Amazon and Facebook follow this protocol, wherein there are multiple interview loops like system design, coding and behavioral assessments that are conducted by individual interviewers. A group decision is made on the interview candidate based on these individual assessments.
2. Relative weighting: In this method, we identify a set of criteria that are important in making the decision and assign relative weight for each of those criteria. We evaluate the decisions based on the relative weights of the criteria and pick the one that has the maximum weight. As an example, when we must finalize a list of features to implement, we can assign complexity, feasibility and impact as the criteria—and each of these have relative weights. We then evaluate the features against these criteria.

What are some of the ways in which you have debiased group decisions? Let me know in the comments.