Voices on Project Management

by , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman

Recent Posts

Project Management Triangles and Integrated Reasoning

Best Practices for Managing Project Escalations

Questions from Project Management Central - Interviews

The Ying and Yang of Resilience

3 Tips For Simplifying Complexity

Viewing Posts by Marian Haus

Best Practices for Managing Project Escalations

By Marian Haus, PMP

Throughout any given initiative, project managers must deal with issues that are sure to arise. Some are solvable within the project organization, with or without the project manager’s influence. Others however — especially those that could affect the outcome of a project — go beyond a project manager’s range of influence and authority.

Such major issues and risks can lead to escalations, which require special handling and management.

Various project management guidelines and specialized literature insufficiently cover the escalation management domain.

Escalation means trouble — so it’s a word very few people want to hear about. It also means that a higher authority will need to be called up to take action before it is too late.

When necessary, and if done in a timely and appropriate manner, escalation management can help a project manager solve issues outside of their authority or influence.

Here are some tips and tricks for project managers to better deal with escalations.

1. Be Prepared

From the project outset, define a clear escalation path and mechanism. For instance, establish an escalation committee (e.g., your sponsors or upper management board) and agree on escalating major issues when necessary and bypassing certain hierarchy levels in order to escalate faster.

Don’t overdo it! You should not escalate every encountered issue—only escalate major issues that have considerable impacts.

2. Assess and Qualify the Risk

Is it serious enough to escalate? Is there anything else you can do to avoid an escalation? Is it the right time to escalate?

Certainly, in order to be effective, the escalation should be raised in a timely manner. Therefore, neither should you exaggerate with going through an elaborated risk assessment, nor should you wait too long until raising the escalation (e.g., do not wait until the next reporting period is due).

3. Communicate the Escalation

After you’ve done everything you could have to prevent the escalation (you raised awareness, you communicated, you have pushed and pulled), it is time to escalate!

To escalate effectively and efficiently, first keep a calm and clear head. Then, follow these tips:

  • Escalate via the channel that is most appropriate for your project context. Ideally, the escalation should be communicated in a face-to-face meeting or call. Emails can be the most ineffective escalation tools, because they can delay the resolution if the emails are not handled in a timely manner. Emails also can lead to misunderstandings if the context is not well understood. Additionally, they can lead to a deadlock if sent to multiple and unnecessary individuals or when it is unclear who the targeted person is for taking action. In short: Avoid escalations via email.
  • Avoid getting personal and refrain from finger pointing. Focus on the issue at hand. This should be communicated and addressed objectively.
  • Explain the major issue and its implications. Keep it short and simple, so that everyone requested to help you can understand.
  • Explain what you did to avoid the issue and escalation. Again, keep it short. Otherwise, you will end up in endless apologies.
  • If possible, make a proposal with two or three resolution options. Explain their potential effect on the issue at hand and ideally make a recommendation on which options to go for.

4. Follow Up

Generally, every escalation requires some resolution time for when the project manager and the project team will implement the decisions agreed upon by the escalation board.

You will need to regularly inform your escalation committee with status and progress updates until the risk and problem are completely resolved. And, after getting back on track, you should conduct a lessons-learned exercise with your project team to learn and grow from the encountered crisis situation.

Would you agree? How are you managing escalations in your projects?

 

Posted by Marian Haus on: October 06, 2017 12:45 PM | Permalink | Comments (18)

Best Practices for Moderating a SWOT Analysis

Categories: planning, risk management, swot

By Marian Haus, PMP

The SWOT framework is a very useful analytical tool for identifying risks and opportunities. It can be used across industries and in a range of scenarios, from project planning and risk management to strategic business and corporate planning.

When used in project management, SWOT can help capture internal project aspects (strengths and weaknesses), as well as the external aspects (opportunities and threats) that can positively or negatively influence the project.

Here are four steps for preparing and moderating a two-hour SWOT session:

1. WHAT: Explain what SWOT is, elucidating each of the four terms and giving some examples of each. For instance:

  • Strength might be the technical skills of the project team.
  • Weakness might be the team’s limited experience with the type of project you are conducting.
  • Opportunity might be a favorable technology trend that your team can leverage.
  • Threat might be hardened regulatory conditions in which the project is conducted.

It’s important to highlight that strengths and weaknesses are characteristics internal to the project, while opportunities and threats are external.

From the very beginning, it’s equally important to define what goal you’ll be assessing under the SWOT framework. This will narrow the focus from generic to articulated obstacles and prospects that can hinder or support reaching your goal.

For this part, allocate a time-box of 15 minutes from the total two-hour session.

2. HOW: Now that everyone knows what SWOT is, explain how the analysis will be conducted.

You’ll need to prepare in advance. First, get a whiteboard and draw a simple SWOT matrix, with a quadrant for each attribute (S, W, O and T). Highlight that “S” and “W” are internal factors, while “O” and “T” are external.

Next, make sure you have sufficient Post-its for capturing the SWOT information. I recommend using separate colors for each attribute—this will improve the visualization of the SWOT matrix.

Allocate a time-box of five minutes for this part of the session.

3. CONDUCT: Conducting the SWOT analysis is the easiest part. Now that everyone understands the approach, engage the participants in capturing the strengths, weaknesses, opportunities and threats on the colored Post-its.

For a team of 10 people, allocate 10 minutes for capturing and 30 to 50 minutes for presenting and posting the results on the SWOT board. Each contributor should individually capture the SWOT and present the results.

4. STRATEGIZE: Now that you know the strengths, weaknesses, opportunities and threats of your project, it’s time to do something about them. There are different strategies and approaches for dealing with the SWOT outcome.

One strategy is to apply a risk management approach: Qualify the captured information by urgency and impact, and define responses for risks and exploits for opportunities.

Another strategy is to convert weaknesses and threats into strengths and opportunities.

Or you can apply the simple USED approach, by addressing the following questions:

  • How can we use our strength?
  • How can we stop our weakness?
  • How can we exploit the opportunities?
  • How can we defend from threats?

For this important part of the process, you should allocate up to 50 to 60 minutes of the session.

The SWOT analysis is a subjective assessment because the level of knowledge and state of information might vary among the attendees. Nevertheless, the outcome could help to prevent issues or exploit opportunities during your project journey.

What tips do you have for moderating a SWOT analysis?

Posted by Marian Haus on: July 09, 2017 02:57 PM | Permalink | Comments (21)

5 Steps to Manage Project Dependencies

By Marian Haus, PMP

Projects are rarely conducted in a vacuum. Whether the project you’re managing is small or large, simple or complex, you will most likely encounter dependencies tied to assets outside your project organization.

Here five simple steps to help you manage project dependencies that are spread across teams, departments and assets.

1. Assess and document potential project dependencies: Determine each dependency’s type, profile, specifications, timeline and owner. For example, you might have to rely on the QA or legal department to check your work, end-users to validate your product or other teams that will have to adapt their products because of your project’s outcome.

You could document HR dependencies in your project’s HR plan. Non-HR resources could be documented in a hierarchical resource breakdown structure (RBS). Or you could just use a simple spreadsheet, where you store all your dependencies organized by types, ownership, etc.

2. Align and interlock scope: Define a clear and determined purpose/scope for each dependency and align with the team providing or fulfilling it. Interlock your dependencies with the related teams or organizations.

For instance, if your project will need a certain setup from your company’s infrastructure team, ensure that you define the requirements (how many servers you need, what the technical specs are, what software needs to be installed, etc.). Finally, confirm that this setup can be delivered as requested.

3. Align dependency timelines: Specify exactly when your dependency is required and for how long. Interlock the timeline to secure its on-time delivery or availability.

To continue the previous example, you might request your company’s infrastructure team to deliver the servers no later than July 31 so you can use the setup during a testing period that would stretch from August 1 to September 30.

4. Monitor and control dependencies throughout the project: It will probably be impossible to precisely plan for all of your project’s dependencies from the very beginning—and then stick to that plan until project closure.

Therefore, you should maintain and review your dependencies list, HR plan or RBS throughout the project. New dependencies might show up while others might become dispensable.

5. Collect sign-offs: Sign-offs are as important as interlocks. You have to secure and collect them from your counterparts.

Interlocks enforce commitment, responsibility and accountability, whereas sign-offs confirm the delivery or the fulfillment within the agreed boundaries.

For instance, an end-user outside of your project team will sign-off on the product change your project generated, confirming that it conforms with his or her requirements or expectations. Or an interface project team will sign-off on your revamped software component, confirming that your project’s outcome did not break their related components or business processes.

How do you identify all of a project’s related dependencies? How do you manage them as the project progresses?

Posted by Marian Haus on: April 07, 2017 03:10 PM | Permalink | Comments (15)

Authoritarian vs. Participatory Project Management

Categories: Communication, Leadership

By Marian Haus, PMP

Project managers have a major influence on the projects they run. Attitudes and leadership styles play a large part in how the team works together, how projects are delivered and the general environment for everyone involved.

Here’s a look at two very different project management approaches— authoritarian and participatory—and how they impact the entire project team.

Authoritarian Project Management

An authoritarian project manager dominates the project with his or her personality and ego, putting objectives first with a low emphasis on how the project team feels about the project journey. He or she imposes unquestionable edicts that must be followed no matter what. And goals and milestones are set without necessarily consulting the project team.

An authoritarian management and leadership style generally creates a tense project environment, with little room for independent actions and joy.

While an authoritarian style may be suitable in a rigid organization or in government or military institutions, this style will rarely work in other project environments where participation is encouraged or decisions must be made with the input of multiple departments.

Participatory Project Management

A participative project manager involves other team members or leaders in the decision-making process. A participatory project environment is, in general, a positive working environment, where responsibility and accountability are shared.

A participative project manager is typically more successful in small and collaborative teams and in projectized organizations where the project and its outcome are prioritized over obedience to the chain of command.

Without radical cultural changes, the participatory management and leadership style can be quite challenging when applied in a rigid and functionally organized project environment.

To quote author and management expert Kenneth H. Blanchard, a participative project manager understands that “the key to successful leadership is influence, not authority.”

What attitudes and leadership styles have you encountered? I’d like to hear your story.

Posted by Marian Haus on: February 15, 2017 04:53 PM | Permalink | Comments (12)

Risk Priority vs. Risk Urgency

Categories: Risk Management

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? 

Posted by Marian Haus on: November 17, 2016 04:36 PM | Permalink | Comments (12)
ADVERTISEMENTS

"It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons."

- Douglas Adams

ADVERTISEMENT

Sponsors