Viewing Posts by Marian Haus
By Marian Haus, PMP
Trust is defined as a “firm belief in the reliability, truth, ability or strength of someone or something.”
Isn’t that what we all want in our professional and private lives?
Imagine a project with little or no trust between the project manager, team members and stakeholders. In such an environment, communication is opaque and piecemeal, and what’s communicated to you depends on your position in the organization. Silos are built to protect individuals, positions and knowledge. As for assignments, they’re meticulously planned and controlled, and work is delegated and rigorously followed up on.
I could go on and on.
Without trust, companies won’t survive for long in today’s world of VUCA (volatility, uncertainty, complexity and ambiguity). Without trust, for example, how can you as a project manager quickly respond to constantly changing customer expectations and environmental conditions?
The absence of trust is at the basis of the pyramid of The Five Dysfunctions of a Team by business consultant and speaker Patrick Lencioni. According to this model, conflicts cannot be solved creatively without trust. The lack of trust erodes people’s commitment, engagement and accountability—and therefore makes it difficult to attain goals and results.
I believe the evolution of project management over the past two decades is due in large part to the way trust is now valued in projects and in business. It’s an enabler for individual and organizational success. People are more empowered than ever to work independently (i.e., with no micromanagement) and to collaborate in trustworthy environments.
Companies that understand this have trust as a core value of their corporate culture and part of their corporate DNA. Leaders, project managers and employees of these organizations are not struggling to gain the trust of their peers. They are benefitting from and supporting the implementation of cultural changes based on trust, openness and fair collaboration.
How can project managers lead by example and work to create a trustworthy project environment? Here are some tips:
By behaving in a trustworthy manner and leading by example, you’ll gain your team’s confidence. People will rely and count on you in any circumstance.
How do you drive trust in your projects and organization?
Tips For Leading an Effective Taskforce
By Marian Haus, PMP
We’ve all heard about those projects in crises—the ones that required a quick and firm intervention with the help of a taskforce to bring it back on track.
No project manager wants to be in such a difficult situation, especially not with her or his own project.
But how do we, as the hero of the day, handle being tasked with saving a troubled project?
First let us examine what a project taskforce is and what it is good for.
A project taskforce is a mandate allotted by the project sponsors or the upper management of the project organization to a senior project manager or a senior leader. The goal is to find the best option for resolving a particular problem in a very short timeframe.
A taskforce is a management mechanism that should be only used in exceptional situations. It generally requires disrupting other project activities and deploying the best people to solve a particular problem under possibly highly stressful and energy-depleting conditions.
So how do we handle this? Here are some tips on what an effective taskforce needs:
If set up and executed properly, a taskforce can be an effective tool to resolving crisis situations in projects.
Have you ever worked on a project taskforce? What tips would you share?
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:
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?
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:
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:
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?
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?