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

Recent Posts

Are Traditional Scrum Masters Becoming Obsolete?

Kick-Off Meetings: The Beginning of Success or Failure

Hackers: A Safety Issue

Leaders exert influence for success

Business Transformation With the End in Mind

Viewing Posts by Marian Haus

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 (13)

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 (10)

The Common Sense of Risk and Opportunity

By Marian Haus, PMP

The discipline of project risk management is all about limiting and hindering the adverse impacts of negative events. The complementary discipline of project opportunity management is all about increasing and enabling the beneficial outcomes of positive events.

In this post I want to look at both practices and treat them as a whole— Risk and Opportunity Management (ROM)—while showing that managing them is nothing more than common sense.

Internal vs. External

The risks and opportunities that are triggered by external project sources are generally out of the control of the project manager’s influence (e.g. organizational changes, political climate changes, strategy changes, technology shifts, etc.). External risks and opportunities are generally difficult to anticipate, avoid or eliminate. The best strategy to approach external factors is to mitigate their impact when they occur.

Most often, however, the source of project risks and opportunities are internal and can generally be controlled by the project manager and the project team (e.g. technical and quality issues, stakeholder requests, scheduling, requirements, budgets, etc.). Internal risks and opportunities are generally easier to anticipate, mitigate, control or exploit, since such events will show up in the day-to-day project work.

Now let’s talk about ROM.

The key of practicing effective ROM is twofold:

1. Awareness: The project team has to be aware that ROM will be conducted regularly, like any other project activity.

2. Active: ROM will have to be conducted actively and not reactively (e.g. when really needed).

Allowing things to happen, letting opportunities slip, or, even worse, being risk averse (i.e. zero tolerance for errors and failure) is not only project management negligence or ignorance. It is yet another project risk (of project-internal nature). Hence, make sure you as a project manager will not fall into this trap and become a risk for your own project!

Capturing ROM

What is the easiest way for your team to be aware and actively conduct ROM? First, put it on the paper—or even better, put it on the board. Allow the project team to write down every risk or opportunity they will encounter during the project course. Next, have the team split the board into four quadrants, based on probability and impact (i.e. low-probability + low-impact, low-probability + high-impact, high-probability + low-impact, high-probability + high-impact).

Then in regular project status meetings validate and agree within the project team on the recorded probabilities and impacts. Certainly there are several more elaborate ways to further qualify and analyze risks and opportunities (e.g. likelihood distributions, decision threes, etc.), but I prefer to keep it simple if possible.

Last but not least, actively capturing and talking about risk or opportunities is not enough. You also have to do something! You need a risk and opportunity response or strategy—whether it’s changing the project plan, getting more resources on board, changing project scope, etc. But that’s a topic for another day.

What do you think? Is ROM nothing more than common sense (at least in its basic form)? What’s your approach to ROM?

Posted by Marian Haus on: October 12, 2016 03:54 AM | Permalink | Comments (6)

Project Management in the Age of Digital Transformation

By Marian Haus, PMP

Welcome to the age of digital transformation.

New technologies such as 3-D printing, augmented and virtual reality, and digital currencies are becoming commonplace. Connected and autonomous cars, and holographic displays are on the horizon. This is all on top of the various mobile devices—smartphones, tablets, laptops—that we can’t let go of.

All this has changed consumer expectations and behaviors for good. Services must be fast and easy-to-use (RIP user-manual/guide), fully transparent (in terms of product offering, quality, price), always available (24/7) and multi-device accessible (via desktop, mobile, wearables, etc.).

Fearful of being left behind, businesses look to understand and predict consumer needs through deep and semantic web search, machine learning and big data customer analytics.

The Upshot for Projects

But digital transformation is not only changing our lives and disrupting businesses. It’s also reshaping and speeding up project delivery models. The planning and execution of innovative projects in today’s digital era can no longer be done at the same pace, with the same methodologies and tools. To attain increased time-to-market results, speed and flexibility are key—so project managers must adapt their approaches.

So what’s a project manager to do? Here some thoughts.

1) Remain calm and confident! Remember when agile disrupted the well-established waterfall world? Project managers had to adapt their approach, toolsets and methodologies. We can adapt again.

2) Enable organizational and structural simplicity and dynamism. Foster flexible structures, smaller project teams and increasing collaboration within the project team. (Here are some tips on how to set up your team and organization.)

3) Improve execution speed by tailoring and simplifying your approach and methods. For instance, embark on some rapid prototyping as a proof of concept before implementing the final product. Or breakdown the project into several smaller projects that can move independently faster as together.

4) Foster new and innovative ideas. Encourage open-mindedness and increasing failure tolerance.

5) Focus on results, not process. Plans, Gantt-charts, budgets, forecasts, risk plans and stakeholder lists are important. But while prototyping or going through trial-and-error iterations during product development, don’t let methodology and specific techniques get in the way of the needed results.

6) Adapt your communication approach by providing stakeholders with rapid access to real-time project information. For example, establish an online project community that can easily be updated with the latest information. (Here are more ideas on how to improve communication.)

Finally, enjoy the exciting and intense times we leave in, driven by dynamism, innovation and more networking and collaboration than ever.

I’d like to hear from you on how you are managing projects and embracing change in the modern digital age.

Posted by Marian Haus on: August 03, 2016 04:34 PM | Permalink | Comments (3)
ADVERTISEMENTS

"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."

- Tom Robbins

ADVERTISEMENT

Sponsors