Voices on Project Management

In my project management career, I’ve been very fortunate to have worked on different projects all over the world. As with most things in life (like having a flat auto tire or forgetting to pay the electric bill), projects mirror the practical realities of life. One of the takeaways from those experiences has been the commonality of successful project management approaches no matter the geographical location of the projects.

A key characteristic that I have observed over time is how projects and project management resemble a meritocracy independent of personal bias. Projects need to be complete with desired outcomes in a specific period of time. As one completes ever more large and complex projects, one grows in their career as a project manager. This career growth occurs regardless of the race, gender or other characteristics of the project manager.

As with many other merit-based professions such as healthcare, aviation, athletics and science, the introduction of personal bias with project management would be detrimental to the completion of any project. That’s why project management as a profession is a great equalizer given its heavy dependence on the skills and capabilities of a project manager.

In thinking about how project management is a great equalizer, I offer the following thoughts:                                                           

1. The project doesn’t know who is managing it. Projects are an interesting construct that is hard to categorize under the typical laws of physics; they don’t have weight, exhibit motion or temperature. Projects do have the characteristic of being a collection of activities and assets that need to be brought together to produce desired outcomes.

In this regard, a project by definition is immune from any personal bias; it’s a matter of solving a three-dimensional problem using people, process and technology. A project manager needs to be skilled at resource, schedule, dependency and stakeholder management in order to solve for desired outcomes. The project itself does not prefer the personal background of the project manager; it awaits the proper project management disciplines to be employed in order to complete its required objectives.

2. Successful project managers find the best people. People represent one of the key factors in any project. When compared against process and technology components, the acquisition of the best people plays a more significant factor in the success of any project. However, the acquisition of people for a project also poses the possibility for personal bias. As a project manager, you have to be able to find the best people for the project independent of subjective perceptions.

A CEO of a global company once said it took him 20 years to get a point where he could identify good people more than half the time. My observations of project managers early in their careers bear this out; they tend to be more subjective in selecting resources that they like and perceive would work well on their team; read this behavior as easier to manage. The more experienced project managers more discreetly evaluate competencies than subjective factors; this is key, as no matter the personal affinity or how easy (or difficult) the person is perceived to manage, the most critical dimension of people for a project is their competencies. 

3. Project management metrics show no bias. One of my favorite quips about project metrics, especially when they are not favorable, is “You can’t beat the laws of physics.” If metrics show a project to be over budget or with late milestones, those are intractable project “laws of physics” that need to be addressed by the responsible project manager.

To a great degree, project metrics are designed to not show any personal bias. They are a physical expression of project reality that can’t be influenced by personal factors of the project manager. Metrics are equal in every regard to serve as an unbiased foundation from which remedial project actions are taken.

In my early years as a project manager, I have to admit I made every possible project management judgement error on my projects. Over time and with some valuable guidance from experienced project managers, I grew into leading ever larger initiatives. As part of that growth path, I observed that the most experienced project managers had left any notion of personal bias behind in their project management execution. Their focus on the core dynamics of a project, finding the best people and anticipating conditions that would lead to unfavorable metrics were key factors in their success.

I welcome any commentary on the concept of project management being one of the purest forms of meritocracy that by design can’t rely on personal bias to achieve success.

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!