Voices on Project Management

As project managers, we are entrusted with power. We assume three types of powers as soon as we become a project manager—legitimate power, the power to penalize and the power to reward. Also called powers of position. We often use these powers to get the job done, resolve conflicts among team members, pressure the team to fast-track, quickly make a decision, etc.

Yet the powers we use can come with a hefty price that we often ignore. In fact, that price can even outweigh the benefits we receive. Which raises the question: Why make this loss-making transaction?

One reason is that we pay the price either at a later date or we pay it gradually or indirectly. Therefore we don’t realize we are paying it at all, or we are just more interested in the short term.

For example, if a team member resigns, he may not give you the real reason behind his departure. We only realize there is a problem when several people quit! By then, too much damage may have been done to the organization or project.

Another reason we make this loss-making transaction has to with perception. Most managers think the power to penalize is bad. They believe using legitimate power is fine and using the power to reward is preferable. However, if you analyze carefully, you will find both of these powers have serious limitations.

Power Problems

You may find the only benefit of using these powers is saving time. What we sacrifice for quick results, then, are harmony, mutual understanding, unanimity, openness, fairness and justification.

By wielding power, we force decisions. If we penalize team members, we create fear. That makes people agree to what we want while putting their reservations aside. Openness is lost and communication breaks down.

When we use legitimate power, we tell people to do something because we are the project manager. Indirectly, we convey that we don’t have time to explain to you or convince you or respond to your reservations. The harmony and mutual understanding are lost.

The power to reward could be better than the other two, but it has several limitations and should be used very carefully. Rewards motivate people, but only if they are implemented with true honesty and transparency, which is not easy or common.

The risk is that people may agree with you in expectation of a reward, putting their legitimate doubts or questions aside. In addition, there may be more people who feel they are eligible for reward, but only one gets it, making others unhappy.

Our tendency to give rewards to excellent people does not allow us to recognize and reward average team members. They are not even getting motivated because they know they will not reach that league of excellence.

Or, people may be productive until they get what they are expecting. Then you have to continuously give something to everyone if you want them to be productive. It’s like keeping a carrot in front of a horse all the time—not as productive as it appears.

So what is to be done? The answer is simple: Give your powers to team members. In the end, this approach will be much more productive. It creates a healthy environment—healthier than what follows from deploying power in the traditional top-down ways.

In my next post, I‘ll discuss how we can give these powers to team members and how this will help create a productive atmosphere. Meanwhile, please share your experience and views on using powers below! 

By Dave Wakeman

For me, planning is the secret sauce of almost every successful business—and definitely of every successful project. But while most project managers probably agree on that, not everyone else does. So how do we sell planning to an audience whose first reaction isn’t to lead with planning?

Here are a few ideas.

Lead with a discussion about outcomes. When I get stalled by people who don’t want to discuss planning as a strategic tool, I ask them about outcomes and what success is going to look like in this situation.

How does this help you get back to planning?

Well, it makes people think about the future. By doing that, they logically have to draw a plan together that’s going to help them get there. And this is a tool that is easy for you to use.

Ask about failures on similar projects. Just like with the discussion based on outcomes, you can overcome a lack of planning in projects by asking your stakeholders or sponsors about similar projects. Specifically, ask what some of the problem areas in previous projects were and how they were handled.

No one wants to make the same mistake twice. So by forcing your project stakeholders and sponsors to confront the reality of some of their past failures, you can automatically refocus them back onto planning. You can now direct the conversation to how to avoid having these issues arise again.

For you, that means being brave enough to ask about lessons learned during your initial conversations so that you can control the conversation if you are getting pushback on a thorough job of planning.

Find out about key stakeholders and other important people in the project’s success. This is a back door into finding out what these other people hope will be successful about your project.

Sometimes if you are under a lot of pressure on a project, you will discover that the sponsor hasn’t done a good job of accounting for all of the key stakeholders and may be missing something that is essential for one stakeholder. By asking about other stakeholders, you get a chance to refocus on where you are trying to get to and you have more control on pushing for planning.

You can easily do this in your projects by making sure to ask a simple question like, “Has everyone who is essential to the success of this project been asked for input?” This should get the conversation onto favorable footing for you.

What do you think? Am I onto something here? Or have you used other tactics to refocus your projects back onto planning when necessary? 

By the way, I write a weekly newsletter that focuses on strategy, value, and performance. If you enjoyed this piece, you will really enjoy the weekly newsletter. Make sure you never miss it! Sign up here or send me an email at [email protected]! 

By Christian Bisson, PMP

In my last post, I discussed why you should manage projects via project management tools rather than via email. Let’s imagine you’re making the transition—a wise choice, congratulations! But it may not be smooth sailing as you embed the tool into day-to-day team life.

This post talks about challenges you might encounter a long the way, and how to address them.

1. Cannot use the tool

Not everyone can pick up a tool and learn how to use it on their own. And more often than not, training given to people is not fine-tuned to each individual’s needs.

Some will struggle, meaning they will avoid the use of the tool and revert back to emails or other means to get their work done. In this instance, you might even be asked to stop using the tool yourself because others struggle.

Although abandoning the tool might seem like a quicker way of fixing the issue, it’s actually addressing a symptom, not a cause. Avoiding the use of the tool is not going to be beneficial to anyone long-term.

Instead, take the time to help anyone who struggles, or prepare customized training for your team members. Ask them where they are having trouble, and show them how they can achieve what they need to do.

2. Annoyed by notifications

Oddly, one recurring complaint of using a project management tool instead of emails is receiving too many emails. For instance, when people comment within a task, the tool might email once per comment.

There are two ways you can mitigate the amount of emails:

• Guide people toward their notification settings so they are configured to meet their needs. Some like to have lots of emails; others prefer to use activity feeds or a notification dashboard within the tool.
• A project management tool should not replace a conversation. Invite people to discuss issues in person or via a conference call instead of having 10 back-and-forth debates within an item of the tool.

3. Partial access or multiple tools

Many organizations work with more than one tool, which can be very effective in some cases. However, what often happens is that team members are confused because they do not know where to go to see their tasks. In addition, sometimes team members in other locations do not have access to the tool.

All this means the project manager struggles to manage all the work of a project since tasks can’t be assigned to everyone or tasks are split into different locations.

This can be tricky to deal with if the project manager cannot select tools and access. However, the objective is to have everyone on board use one project management tool only. This lets all team members know where to get the information they need and allows the project manager to have a complete view of the project in one place.

4. Email lovers

There are some who feel they cannot live without email. Even when the project management tool has all the information and properly archives it, some team members still want that information emailed to them. Project managers should not resort to sending information within the tool and also sending an email to that person, which is duplicated effort for nothing.

In these cases, it is important to show the person that the same objective can be met with the tool. Show him or her how to access the information easily and how to archive a project workspace if that is a long-term concern when closing a project.

By Christian Bisson, PMP

In the world of project management, you will encounter the “email philosophy” and the “project management tool philosophy” of how project tracking/communication should be done.

Emails can be an effective way to communicate or keep written documentation to refer to. Heck, I love emails. But ultimately, a properly used project management tool will be more efficient for your team. Here’s why:

1. Documentation Efficiency

Email might be a great way for you to track your written communications, but how properly it’s used and archived depends on the recipient. In contrast, with a project management tool, the “documentation” will be stored somewhere within a task or other type of item within the tool. Everyone can refer to it, and it should be easily found in the appropriate location instead of somewhere in someone’s inbox.

For example, I once took over a project from another project manager who used emails to manage the project. To help me get up to speed, the project manager had extracted a dozen emails and sent them over. I had to go through all those emails threads, most of which were out of context or outdated.

A better option would have been to have the relevant information within a project management tool where I could have reviewed the available information and known exactly who was doing what.

2. Task management

You could send someone an email listing tasks to accomplish, but unless that person replies with a status or you regularly ask for one, you will not get an update. If an update does come, only you and maybe others from the team will be aware, assuming they even read the email.

A project management tool will allow you to track all those tasks, with a proper assignee and status. It will be simple for someone to have all his or her tasks displayed and ordered in priority, including a description of each task/issue. In the meantime, the project manager can easily track the status of the project without having to constantly ask for one.

In my next post, I’ll talk about how to overcome challenges when switching from managing via email to managing via a project management tool. 

By Conrado Morlan

If you’ve been a project practitioner for a long time, you’ve probably heard a variety of opinions about you and your colleagues. Many of those opinions may have reflected an oversimplified image of the project management profession. In other words, you and your colleagues were stereotyped.

The project management profession has given me the opportunity to travel across three continents and to work with people from different cultures and generations. I lost count of all the different stereotypes I was associated with, which involved my country of origin (Mexico), the country I lived in (the United States) and people’s previous experience with IT project managers, But many of the stereotypes were common despite the different situations where I worked.

Being stereotyped gave me the opportunity to change people’s oversimplified idea of me and my profession. On top of my daily duties, I had to transform that bad and/or ugly perception into a good one. Even when my title was IT project manager, my role was not purely technical—in many projects, the business function was also part of the project team.

Working with business and technical functions put me between a sword and a wall. On the business function side, people stereotyped me as too technical, while on the IT side, co-workers assumed I was not technical at all and too structured. In many meetings with business functions and IT team members, I had to show that the “real me” did not fit the stereotype they had in mind.

My credentials exacerbated the situation a couple of times. When team members learned I had several certifications, they feared I was going to “play by the book” and make them change the way they had been working.

Instead, I merely promoted discussions in which the team realized there were areas of opportunity in their way of working that could be improved.     

The “manager” stereotype popped up quite often. Team members openly told me I was not their direct-line manager and did not have authority over them. I had to address this stereotype and help people understand I was not there to manage but to lead.

So I held meetings with team members and their managers, in which roles were defined, the importance of the project was communicated and lines of communication were established.

At the end of the day, it’s incumbent on projects managers to face the stereotypes that are out there and work to change negative perceptions. As a project manager, how do you react to stereotypes? What are you doing to erase the stereotype you have been associated with?