Voices on Project Management

by Christian Bisson, PMP

The project manager role is often underestimated or inaccurately interpreted. Because organizations can have different definitions of what project management means, there is sometimes a lack of clarity around the role, especially for non-project management professionals. In this type of environment, people fall back on basic stereotypes.

If you find yourself typecast in one of these roles, take heart. You are not alone.

1. The Note Taker

One of the most stereotypical expectations of project managers is that they’ll be the meeting note taker. I’ve experienced this time and time again. During a large client presentation, for example, one of my colleagues was asked if he would be taking notes. He replied, “Well, I have a project manager for that.”

Yes, project managers take notes. But they shouldn’t be the only ones doing so. Meeting attendees tend to focus on the notes that directly impact their work. A designer, for example, will focus on conceptual and visual comments, while a developer will focus on features and functionalities.

Furthermore, if the project manager is leading the meeting it will break the meeting flow if he or she is also responsible for note taking.

2. The Meeting Organizer

Project managers will often be expected to set up meetings—and to a certain extent, that makes sense. For large meetings, such as internal presentations or milestone check ins, it makes sense to have the project manager take care of the planning. It allows him or her to rally everyone and set expectations for the meeting so the team can come in prepared.

But there is a line.

Teams shouldn’t expect project managers to organize meetings when they just need to gather for a brainstorm or a quick chat. Sadly, it happens. For example, I was once asked by a colleague from another office to book a meeting so that he could talk to another colleague that was sitting just 10 feet (3 meters) from him.

Project managers should encourage teams to be responsible for setting up those smaller meetings or one-on-ones themselves.

3. The Accountant

There is a misconception that the project manager is the only team member who should care about budgets, or worse, the only one that should be responsible for a budget’s health. This mindset is tough to change because it’s true that a project manager’s role, amongst other things, is to manage the budget.

However, the project manager cannot take everyone’s actions on his or her shoulders — and it wouldn’t be fair to expect that. If a feature was estimated at 50 hours and the team took 100 hours, it takes collaboration to fix the negative impact to the budget or schedule. The team must warn the project manager, everyone must discuss solutions, and then the project manager should take the appropriate next steps with stakeholders, etc. Obviously, this should be done as proactively as possible, not after the fact.

To think that no one should care about the budget, and only project managers should fetch this information and “figure it out” on their own is absurd. Yet, it’s a common expectation.

Have you found yourself in any of these scenarios? What other project manager stereotypes have you faced? How do you deal with these misconceptions?

By Lynda Bourne

The effective management of knowledge has received some extra attention in PMI’s A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)—Sixth Edition (to be published in 2017).

And it should—it’s an important area.

While there are many aspects to effective knowledge management, in this post, I want to take a look at the foundation: transforming data into wisdom from a project controls perspective.

As astronomer Clifford Stoll once said, “Data is not information, information is not knowledge, knowledge is not understanding, understanding is not wisdom.”

He had a point—information changes in character as it is processed. Consider work performance data, the raw observations and measurements made during the execution of project work. For example, knowing that an activity is 25 percent complete on its own has little direct value.

Basic information starts to be created out of this data when it is analysed and assessed. For example, an analysis of this data might reveal the activity should be 75 percent complete and, as a consequence, is running three days late.

This information then becomes useful when it is placed in context and integrated with other relevant bits of information. For example, a report might explain that the activity is on the critical path and the delay has a direct effect on the predicted project completion date.

Converting that useful information into knowledge means communicating it to the right people. For example, when someone reads the report, he or she becomes aware that the activity is running late.

Understanding that knowledge requires the person to interpret and appreciate the consequences of the delay. Interpreting one piece of information to create understanding can happen in many different people’s minds (lots of people may read the report) and each will derive very different insights from the same set of facts. One person may see the delay as relatively minor, while another may think it’s critically important. Understanding is based on the frame through which each person views the fact.

Finally, using the person’s understanding of the situation to inform wise decisions and actions is completely dependent on the capabilities, attitude and experience of the individual.

Who Controls that Conversion of Data?

PMBOK® Guide Fig. 3.5

As shown in the extract from the PMBOK^® Guide Fifth Edition above, project controls professionals drive the conversion of data into useful information. By using work performance reports to communicate effectively, they can actively encourage the transition of information into knowledge in key people’s minds, and by providing context and advice they can positively influence the development of that person’s understanding to support wise decision making (manifested in the “project management plan updates”).

But achieving this effect requires more than simply collecting and processing data. It requires analysis, insight and effective communication skills.

How effectively do you transform raw data into useful information that helps your key stakeholders make wise decisions?

By Lynda Bourne

The way decisions are made can lead to division and discord—or to understanding and commitment. What’s your style?

The Divisive Decision Maker

Divisive decision makers give the appearance of strength and speed.  Every issue is quickly reviewed by the manager (even when they don’t necessarily need to be involved) and a decision is decreed. The manager then expects everyone to comply with the outcome; dissent and alternatives are not tolerated (to do so would be a sign of weakness).

The problems with divisive decision-making include:

• The assumption that, in all things, the leader knows best.
• There is a lack of consensus—people are expected to do what they’re told.
• There is no commitment from the rest of the team to implement the decision.
• There is a high likelihood the decision will stop being implemented when the manager looks away to focus on the next important decision.

Unfortunately, in many situations, being seen as an assertive decision maker is confused with being an effective decision-maker.

The Decisive Decision Maker

Decisive decision makers recognize that making a decision is only one step along the road to a good outcome. They know they need others to collaborate if the decision is going to achieve the intended result and actually stick. Rather than rushing, they spend time thinking through the decision-making process.

Considerations for the decisive decision maker include:

1. How urgent is the decision? As with the divisive decision maker, decisive decision makers know that a prompt decision is better than a delayed decision. And, in an emergency, the best option is for the decision maker to issue an order and use his or her authority to enforce the decision. However, the vast majority of decisions do not need an immediate answer (even if a senior manager is asking for one “NOW!”). And in those instances, the decisive decision maker spends time thinking through the best options to achieve the outcome he or she would like.
2. Does the leader need to make the decision or does the leader need to facilitate a decision-making process? Unlike divisive decision makers, decisive decision makers do not need to be the fountain of all decisions. They let the right people make the decision and let those people take credit for the work. They use their authority to support an effective process, taking the actual decision-making role only when needed to get the best outcome.
3. What type of decision is being made? Decisive decision-makers understand there are various types of decisions (ranging from simple problems to dilemmas and beyond) and use this knowledge to determine the best decision-making process for each situation.

Decisive decision making allows the leader to use the decision-making process to reinforce the team and build commitment to the overall project and to making the specific decision stick.

Also, because the decisive decision maker focuses on achieving the best outcomes, they are better positioned to review and adapt any decision if later or better information shows that an improvement or change is desirable. (At the same time, however, decisive decision makers know the difference between dithering—the hallmark of people who cannot make decisions—and making prudent changes to a decision based on new circumstances.)

A divisive decision maker, on the other hand, tends to see any change to a decision they have made as a threat to their credibility as a decision maker.

What tips do you have for dealing with divisive decision makers?

By Kevin Korterud

Beware: Strategic initiatives aren’t the same as typical projects—they tend to be considerably more complex. For example, strategic initiatives are usually bound by some form of dramatic urgency around schedule (regulatory, market), costs (process improvement) or consumer satisfaction (subscription, satisfaction).

But the differences don’t end there. Let’s look at some other complex dimensions that must be considered when leading a strategic initiative:

1. Stakeholder Management

The stakeholder landscape is much more broad on a strategic initiative than a project. In strategic initiatives, stakeholders typically span multiple departments within a company, creating multiple primary stakeholder groups. And these stakeholder groups will often have nearly equal shares in the success of the initiative, thus creating potential authority conflicts.

In addition, there are also governance functions—risk management, legal, etc.—that will have either a primary or secondary stakeholder role.

2. Communications

The complex stakeholder landscape necessitates communication processes that serve vastly different audiences. There exists both a two-dimensional communications problem: one dimension is horizontal (i.e., across stakeholders) and the other is vertical (i.e., involving higher levels of leadership). What once was a linear communication process on a project now becomes more of a matrix process to deal with the breadth and depth of stakeholders.

Communications will need to be carefully tailored to different functions and levels of stakeholders. For example, more detail for operational functions, and simple, high-level summaries for leadership consumption. 

3. Progress Tracking

Strategic initiatives bring with them inherent complexities that can quickly overpower the progress report tracking processes that are commonly used to manage projects.

For example, strategic initiatives will typically have more suppliers than on a typical project. These additional suppliers bring with them different commercial arrangements, delivery methods, status reporting formats and progress metrics. On top of that, all of these progress tracking components need to be harmonized across the various suppliers in order to achieve a cohesive and durable view of progress position.

Project managers will need to review, refine and agree on common progress tracking processes, reporting and metrics that are universally accepted by all suppliers. By creating this single harmonized view of progress tracking, you are more readily able to identify and address delivery volatility.

When first presented with the prospect of leading a strategic initiative, project managers need to balance the excitement of leading a high-visibility engagement with the practical realities of effectively and efficiently managing delivery. By putting essentials in place, project managers can successfully move on to the next step in the career journey: leading their second strategic initiative!

What essentials can your share with project managers new to strategic initiatives that will put them on the path to success?

By Marian Haus, PMP

How do you identify the most important risk(s) to focus on during a project? It is the essential challenge of risk management.

One technique is the qualitative risks appraisal—using qualifiers to assess risk importance. Two popular qualifiers are risk priority and risk urgency. While the terms can have overlapping meanings, they each reflect different qualitative dimensions of project risks.

The Terms Defined

Risk priority combines the assessed likelihood of a risk to occur (i.e. risk probability) and its projected impact. Risk urgency, on the other hand, is a different risk dimension. It reflects the time criticality of a risk to occur.

By assessing risk priority, project managers can identify and focus on the high-priority risks. By appraising risk urgency project managers can ascertain the time left before measures or responses would need to be implemented. With risk priority the main focus is on the impact, whereas with risk urgency the main focus is on the measures or responses that are to be implemented in a timely fashion.

I see risk priority and risk urgency as complementary dimensions of risk management. They both deserve an equally important treatment from project managers.

Assessing Priority and Urgency

For some projects, project leads might treat risk priority and urgency separately. For others, they might combine the risk priority and the risk urgency to amplify the risk priority.

When treated separately, a very common approach to assess priority is the (probability x impact) matrix. Additionally, a (impact x urgency) matrix helps project managers focus on the high-impacting and immediate risks.

When treated together a (priority x urgency) matrix can help project managers assessing the risk severity, which is a derived qualitative risk dimension.

Here are two examples:

Risk #1: Our database will exceed its available disk-space capacity during the project.

Probability: Medium (considering the data volume increase observed over the past x months)

Impact: High (considering this could lead to business interruption and financial loses)

Urgency: A response might be needed in 4 to 6 months (the project runs for 12 months)

The (probability x impact) matrix will rank this risk as a high priority risk, yet the low urgency will categorize the same risk in a (impact x urgency) matrix as requiring monitoring rather than immediate action.

Risk #2: An approaching heavy storm may lead to power outages in our manufacturing line.

Probability: Medium (considering this has happened a few times in the past and our power reserve infrastructure is reliable)

Impact: High (considering this could lead to temporary production standstill)

Urgency: Verify immediately the status of the power reserve capacity

The (probability x impact) matrix will tell us that this risk cannot be ignored and the (impact x urgency) matrix will tell us that this risk requires immediate action and continuous risk monitoring.

The big takeaway: Risk #2 is both a priority and urgency risk.

How do you distinguish between risk priority and risk urgency?