Skip to main content

Author: George Pitagorsky

George Pitagorsky, integrates core disciplines and applies people centric systems and process thinking to achieve sustainable optimal performance. He is a coach, teacher and consultant. George authored The Zen Approach to Project Management, Managing Conflict and Managing Expectations and IIL’s PM Fundamentals™. He taught meditation at NY Insight Meditation Center for twenty-plus years and created the Conscious Living/Conscious Working and Wisdom in Relationships courses. Until recently, he worked as a CIO at the NYC Department of Education.

Trust and Verify in Project Management

Written by George Pitagorsky on . Posted in Articles. 4 Comments on Trust and Verify in Project Management

Experts agree that trust is a major factor in performance and relationship health.

Exploring some of the philosophical takes on trust, one can come away with the simplistic idea that trust is good without qualification. For example, trust is a frontal cortex mental process while distrust is related to the reptilian brain. That distinction, together with the idea that one part of the brain is better than another reinforces “trust good; mistrust bad” thinking.

The reality is that we need a proper balance between the reptilian brain’s reflexive protective mechanisms and the frontal cortex’s mindfulness, openness, analysis, and awareness of our interconnectivity to function in the world.

Related Article: Project Management is All About Trust

Looking at it from a practical project management perspective, trust is complex. Trust, like most things, is not just all good. It is a force or energy, and like all forces, it needs to be applied skillfully. Opening to the realities of what happens when one either blindly relies on trust or unconsciously mistrusts, and understanding the factors that lead to greater trust makes us better managers, business analysts, and performers.

Trustee and Trustor Perspectives

There are trustees (the ones being trusted) and trustors (the ones trusting). As a trustee, being trusted is intrinsically good. You can’t go wrong if you cultivate trustworthiness.

However, when you are in the trustor role, it is practical and skillful to base your trust on evidence rather than an idealistic idea that everyone is worthy of being trusted in all circumstances.

For example, if you blindly trust that a stakeholder will perform his or her role in a project, you can find yourself disappointed and your project in jeopardy. There will be unnecessary conflict and long-term repercussions. That is the primary reason for having frequent (but not too frequent) points at which actual deliverables can be assessed as proof that what was promised was delivered.

A client once asked me if I trusted her. My response: “I trust that you will do whatever it is that you think is in your best interest. Let’s come to a mutual understanding of what that is.”

As project managers, we trust and verify. We base our trust on clearly stated agreements, concrete, measurable results, and past performance rather promises and wishful thinking.

What Trust is

Trust is “belief that someone or something is reliable, good, honest, effective, etc.”1 Trust creates confidence in the ability of a person, tool or method to perform and, with people, be candid and honest.

In project management, the PM trusts the good intentions truthfulness of the people working for and with him, the effectiveness of the process, the accuracy of estimates, and his or her own experience and intuition.

The capacity to trust others is strongly influenced by psychological and personality based tendencies – we learn to trust or mistrust starting in early childhood. Some have a tendency to be extremely trusting, others to be extremely distrusting. There is a trust continuum between the extremes. Being mindful of one’s own tendencies and the tendencies of others, the effective PM will set the stage for effective planning and performance monitoring.

A key principle is to be mindful of unconscious tendencies and how they show up in behavior.

Applied Trust

Trust is applied differently depending on the role played in a project. Project performers need to trust the integrity and intention of the PM to treat people fairly, add value, protect them from unreasonable demands and more. Throw one team member under the bus, and you have probably lost the trust of the entire team. Failure to address accountability for errors and omissions will also result in loss of trust. Once lost, trust is hard to regain.

A PM trusts individual performers and functional managers to provide accurate estimates, report problems, and risks at the appropriate time, and do the work. How far this trust goes depends on the specific situation. The best practice of defining tasks with concrete deliverables no longer than a week or so in duration supports not having to rely on trust. We verify that work has been done, objectives are accomplished, quality results have been delivered, and emerging risks, issues, and changes are identified and addressed.

Project and program sponsors and executives – depending on their perceived criticality of the project, their level in the organization and the number of levels between them and the project manager – trust the project process and the project manager to get things done and inform stakeholders when something unexpected happens. Here we might have a month or quarter between formal checkpoints with regular reports coming weekly or monthly or more frequently, perhaps in the form of a dashboard and informal one-on-one meetings.

Trust is broken if the executive is blindsided or surprised by something that he or she could have been informed about earlier. For example, trusting becomes very difficult when at the last minute before expected delivery there is an announcement that there will be a six-month delay and the budget will be twice what was expected. To be trusted, make sure there is transparency and candid reporting.

Distrust leads to a degradation of performance. Time and energy are wasted in protecting oneself from the weaknesses and failings in others. The mistrusting manager will tend to micromanage. Micromanagement requires excessive intrusions into the work process, over control, performers with a sense of being demeaned, excessive time and stress for the PM and for the performers.

Trust with verification in a trusted system frees performers from unnecessary reporting, communicates confidence in them and reduces the stress that comes from both thinking you need to be looking over someone’s shoulder and having someone looking over your shoulder.

The Motivation for Speed and Dedication

“Speed happens when people at work truly trust each other.” Edward Marshal2

Trust engenders motivation. When speed is needed to meet a tight deadline or extra effort is required to take on a challenging change, there is great advantage in having a relationship in which performers and change subjects trust that their leaders are taking care of them rather than treating them as mere cogs in a wheel.

Motivation to go the extra distance, sacrifice for the good of the team or organization is high. When that trust is not present attitudes change and there is a tendency towards anger and frustration, leading to subtle and not so subtle behavior that slows progress.

At the same time, trust by the leadership to give performers the permission to get work done without being micromanaged adds to the ability to go into hyper-speed mode. There is a right balance between giving the team its head and making sure it is heading in the right direction and knows when to stop.

Integrating Trust

Cultivate an attitude that everyone and the universe in general is intrinsically good, supportive, well-meaning and capable of learning. Balance that with the attitude that there are exceptions and a healthy understanding that in projects it is necessary to rely on verifiable performance indicators – particularly deliverables and actions – to ensure that people are doing what is expected of them.

Doing that will motivate effective performance and ensure that the unnecessary fear and anxiety created by uncertainty and the mistrust generated by the reptilian brain are minimized, if not eliminated.

 

References
1 http://www.merriam-webster.com/dictionary/trust 
2 http://www.marshallgroup.com/building-trust-at-the-speed-of-change/ 

When Can We Estimate? – Managing Conflict Between PM and Performer

Written by George Pitagorsky on . Posted in Articles. 5 Comments on When Can We Estimate? – Managing Conflict Between PM and Performer

This article is about how to manage conflict about providing estimates before scope and performance conditions (for example, availability of resources) are adequately known.

Conflict is any disagreement about anything ranging from minor disagreements to major ongoing warfare. It is a natural and useful part of any project or relationship. People will disagree with one another about any number of things from how long it takes to do a task to whether the project should be continued or canceled. Conflict enables the discovery of optimal solutions and becomes an opportunity to promote and sustain healthy relationships.

Related Article: Make Confident Estimates in 5 Steps

When Can We Estimate?

Let’s take an example. Imagine a situation in which a project manager (PM) and a functional manager (FM) contributing to the PM’s project are at odds about when to estimate the cost and duration of an activity to be performed by the FM’s team. The PM is responsible to the sponsor for putting together a plan and estimate that would enable the sponsor, operational line managers, sales and marketing, training and other business functions to understand better how and when project results will affect the organization and their departments. Finance and sponsors want a sense of the cost. The senior stakeholders want the project estimate before they authorize expenditures on the project. The PM needs an estimate now.

The FM knows that they don’t know enough to come up with a definitive estimate. They have been burned in the past by making an estimate that was too optimistic and has been forced to lower estimates that were perceived as too pessimistic. The FM wants to wait until there are clear requirements and committed resources before giving the estimate.

Best Practices Eliminate Conflict

If the organization follows best project management practices, there is no conflict. Best practices say that estimates can be given based on a high-level understanding of scope but that they must be given in ranges that clearly communicate the level of uncertainty to be expected along with assumptions and risks. Best practices include iteratively refining the estimate as more is known.

The further away from performance, the greater the uncertainty. If the functional group has never done this kind of thing before, the greater the uncertainty. The more volatile the environment, the greater the uncertainty. With this understanding, the FM can feel safe in providing an estimate early on. She puts it in writing along with the assumptions and conditions the estimate is based on. She relies on the PM to represent the project to the sponsor and other stakeholders in the same way. She relies on the opportunity to revise the estimate as more information is available and as actual results unfold.

Conflict Management Under Less Ideal Conditions

There will be conflict under less ideal conditions, for example, if the organization does not have a healthy project management process and has a long history of blaming when it comes to missed deadlines and blown budgets. Best practices are often known but not yet followed as part of the organization’s standard operating procedures – they have not been institutionalized.

The PM wants an early estimate and wants the FM to have some skin in the game. The FM wants to hold off from estimating until there is more information – maybe three months down the road. As is often the case each may stick to their position without regard to the other parties position. A win-lose conflict is the result.

Conditions, Positions, Wants, and Needs – The Evaporating Cloud

Healthy conflict management relies on knowing the conditions surrounding the issue and the difference between wants, needs positions and solutions. The wants and needs lead to positions. Solutions emerge from communication and decision making in the context of goals and conditions. Positions are often based on erroneous assumptions.

An approach called the Evaporating Cloud is used in Theory of constraints. The idea is to dissolve the conflict, like an evaporating cloud, by finding the underlying needs, goals, interests, and assumptions that cause the parties to think they are in conflict.

“A position is a point of view or mental attitude, neutral, for or against something. It is an opinion held in opposition to another. It represents a “want.””[1] Wants are driven by perceived needs, assumptions, and interests. Every conflict is based on the difference between the positions held by the parties. Conflicts can often be resolved by understanding the wants, interests, needs and beliefs that underlie the positions. With this understanding, it is more likely that common ground can be found. Common ground makes it easier for the parties to change their positions and still have their needs or interests met.

In the case of the estimates, the FM’s position is that there will be no estimates until definitive requirements and resource availability are known. The PM’s position is that he must have estimates now. If instead of arguing about positions that seem to be irreconcilable, the PM and FM sit together to explore their wants, goals, needs, and assumptions, they can find a way to proceed that satisfies them both. Even if only one of them took the time and effort to separate the positions from what they really needed, he or she might be able to shift positions to enable an effective compromise.

A Needs Fulfilling Proposal

Here is one way that may play out:

The PM explains the need for an early estimate, and the FM expresses their fear that they and the team will be held to the estimate even if the assumptions they identify turn out to be incorrect because scope and other conditions change. The PM acknowledges that the FM’s fears are quite rational, given past performance. The PM tells the FM that they have the same issue about giving the project estimate. The two agree that they share the common goal of satisfying the sponsor and client – the senior stakeholders. The two turn to face the conflict rather than each other.

The PM agrees to put their overall estimates in a form that clearly states the probability of a significant variance between the high-level estimates and the more definitive estimates that will be made when requirements are firmed up. They further agree to copy the FM on these estimates as they are submitted to the sponsor and client and to include the FM’s estimate, assumptions and statement that the estimate can be off as much as 50 – 75% in either direction.

This proposal not only satisfies the FM’s need to be protected from fallout resulting from changes to the estimate but also enables the PM to properly manage the expectations of his key stakeholders. The proposal is so reasonable that it would be difficult for the FM to stick to her position. The transparency resulting from the sharing of the overall project estimate creates a trust relationship between the two parties. The need for safety and the need for an early estimate are both satisfied.

When It Doesn’t Work

This resolution relies on the rationality of the senior stakeholders and their commitment to live with a degree of uncertainty regarding the real cost of the project. If there are estimate changes as the project progresses and the senior stakeholders blame the PM, the PM may resort to blaming the FM and others for the variance. This will make getting early estimates for future projects more difficult, if not impossible.

The courageous PM will take the heat. They will remind the seniors of the assumptions and risks identified in the early estimate. There will be preplanned revision points at which estimates will be revised, and the reasons for any variance clearly stated.

If there are irrational expectations at the senior level, the conflict is now between the PM and senior stakeholders, not between the PM and FM. In this case, the same approach can be used – what are the stakeholders’ goals, assumptions, needs and wants and how can they be reconciled with the needs and wants of the PM? With a hierarchy in place (PMs are usually well below the client and sponsor in the pecking order) the Evaporating Cloud approach is more difficult. The seniors may not care about the needs of the PM. In that case, the PM must find a way to convince the seniors that it is in their best interest to have rational expectations and to not perpetuate a cycle of missed targets and blaming.

[1] George Pitagorsky, Managing Conflict in Projects: Applying Mindfulness and Analysis for Optimal Results, 2012, PMI publishing.

From the Archives: Blending Agile and Formal Project Management

Written by George Pitagorsky on . Posted in Articles. 5 Comments on From the Archives: Blending Agile and Formal Project Management

“Truth is one, paths are many.”
Swami Satchidananda

As Agile has moved from a revolutionary manifesto to a mainstream approach to product development and project management, project teams have created hybrid approaches that suit the needs of their projects and work environments. The question of whether Agile is compatible with formal project management has been asked and answered. The answer is yes, of course it is.

The first step in transitioning to a hybrid approach is to drop the capital ‘A’ in Agile. That leaves us with “agile”. This change is a symbolic one that begins to eliminate fundamentalist thinking. Then we can begin a rational and practical process to find an approach that is suitable to the situation at hand.

The right approach is neither too loose nor too tight. It is like tuning a stringed instrument. Too tight or too loose and the music is not good. We want an approach that is tuned for optimal performance. Too much control and formality wastes time, costs too much and requires unnecessary effort. Too little control and formality risks errors, unnecessary conflict, poor performance, legal ramifications and unmet expectations. It wastes time, money and effort.

Project Approach

The policies, procedures and practices that are followed to manage and perform a project is the project approach. There are many valid and effective approaches. No single approach is best for all projects. The project type, its environment, size and level of complexity are critical factors in determining the right project approach.

At the same time, there are basic principles that underlie all effective approaches. Among these are 1) clear values, objectives, requirements and roles and responsibilities must be mutually accepted by all stakeholders; 2) stakeholders must be identified and engaged; 2) communication must be candid, clear and regular; 3) risk, conflict, change and issues must be effectively managed; 4) take a situational approach to neither over do or under do documentation and adherence to process. How these principles are executed is the question to be addressed to craft an effective project approach.

Arguing about whether Agile is better than a more formal approach, may be interesting and entertaining, but it misses the key point. The key point is to find the right blend of agility and formality to satisfy the need to successfully complete projects and satisfy stakeholders. The right blend varies from situation to situation.

Agility

Every rational organization wants to be able to move with speed and grace; to be nimble. That is the definition of agility.

The Agile manifesto says: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.”1

Formality

Formality is defined as being rigorous in methodically adhering to established rules or processes. It is also linked to a ceremonious adherence to rules or customs; something that is required but lacks real meaning or importance. In project management, a formal approach is one that has a prescribed process and that includes concrete written documentation – plans, contracts, artifacts, reports, etc. Clearly, we want to avoid formal processes that lack real meaning or importance. The PMOs that insist that every project develop every document identified in the methodology are heading for failure.

PMI’s PMBOK® Guide project management approach is an example used by many to exemplify formal project management.

The PMBOK® Guide is not prescriptive. It does not say one must do PM in a particular way. It allows for, in fact insists that, each project develops a specific plan that identifies how the project will be managed and performed. What the guide does say is that there are basic common project management elements (Knowledge Areas) – the integrated management of scope, time, cost, quality, human resources, communication, risk and procurement. For each of these there are a set of processes and artifacts, which together describe the knowledge area.

A parochial view of the PMBOK® Guide’s processes can, and have, led many astray. They think that the processes dictate a highly formal approach that must be taken to successfully manage a project.

Hybrid

A hybrid approach includes all the principles and elements identified in both agile and formal approaches in the right measure and prioritizes the critical ones.

Individuals need processes and tools. Documentation is as much a part of the product as the working software. The manifesto does not mean to trade contract negotiation away for customer collaboration. Contract negotiation, if done well, can promote more effective collaboration. Similarly, the manifesto does not imply that one should not plan. In fact one needs to plan in order to effectively respond to change.

PMBOK® Guide does not dictate a strict adherence to rules. It does not promote the development of documentation that is not useful or appropriate. It is a guide.

Take for example requirements definition. How much and to what level of detail requirements must be defined and in what format and media will vary from project to project. To maintain that requirements can be completely informal and undocumented is foolish. Such an approach will in all likelihood lead to conflicts and disappointment. Insisting upon highly formal documentation of every detail in every report or product feature with sign-offs by multiple levels of stakeholders in a project in which requirements are evolving is equally as foolish.

What then is the right approach? It is an approach which satisfies business, client and project team member needs.

There is no cookbook, there are principles and guidelines which can be combined in the right measures to create a balanced approach that when applied fits the needs of the situation at hand. This makes it the responsibility of organizations and project managers to create a hybrid approach, or multiple approaches, to suit the needs of their projects.

Don’t forget to leave your comments below.

The Importance of Process Thinking

Written by George Pitagorsky on . Posted in Articles. 4 Comments on The Importance of Process Thinking

Process thinking is a critical success factor in managing projects as well as operational processes. At a recent meeting, after the term had been used several times, the question “what is a process?” came up.

The answer was narrowly defined as “a documented, standardized set of steps to accomplish an objective.”

Related Article: 5 Steps to Creating a Process-Centric Organization

Every Outcome is the Result of a Process

In fact, a process is any set of steps to reach an outcome. It need not be documented nor standardized. Every outcome is the result of a process, under a set of conditions. Processes exist even when you might think they don’t.

Why Process Thinking is Important

Processes are what add value. Processes cut across functions, departments, and organizations.

The concept that any outcome is the result of a process is fundamental to effective management. Whether you are managing personal relationships, projects, or any operational activity, knowing that the end you wish to reach or have reached is the result of a process enables you to be better at what you do.

If you are looking forward, as in planning a project, it is pretty clear that you will be defining the way you will proceed. You will be defining your process.

Looking back in time, as in trying to figure out how you either succeeded or failed at something you have done, you will be defining and assessing the process that was used. You do that because you know that every outcome is the result of a process under a set of conditions.

You would think this is obvious. Well maybe the idea of planning processes is, though, there are plenty of examples of plans that do not resemble processes. They identify deliverables, dates, and costs without describing how they will be delivered. The process is often left open to the discretion of the performers and defined at the time the work is performed with a focus on silos rather than the process as a whole.

It is a better practice to step back to see and define the process up front; keeping options open for changes that might be needed as real world conditions become known.

The 85/15 Rule

When it comes to figuring out what went right or wrong, there is a common tendency to focus on who did what as opposed to what was done.

Dr. Juran, a pioneer in quality management, described the 85/15 rule. This wisdom says that people making errors cause 15% of problems while process issues cause the rest.

Process thinking makes it less likely that the blame game will be played, or heroes venerated. Instead, analyze the process to determine the causes of problems and successes. Fix the process and the people will succeed in their work. Ignore the process and failures will be repeated.

The best people can be brought down by a bad process.

Conditions of Processes

Processes take place under conditions. The same process may have different outcomes if it is performed by people with different skill levels or cultural norms, or under different temperature or weather conditions.

That is why a well thought out project management process will allow multiple variations to be applied as conditions such as project size, the sophistication of stakeholders and other factors vary. That is why the people doing the work need sufficient flexibility to adapt, moment to moment, but in the context of process constraints.

Attempting to apply a “one size fits all” approach in complex situations is a recipe for failure. Forcing people to follow an inappropriate process is a recipe for failure.

Documented and Standardized Processes

Most processes are neither documented nor standardized. A documented process is one that has been explicitly described graphically or in text. A standardized process is one that has been made common across a number of performers; doing the same thing ion a common way.

People can work towards a common outcome in any number of ways. For example, the members of one department responsible for sales and service in one district may do their job following different procedures than another department doing the same thing in another district. Two teams may achieve their similar project outcomes using different tools and approaches.

The process can be made common so that everyone does their work in the same way, using the same tools and templates, following the same steps.

Why Document and Standardize Processes

Processes are any set of steps, documented, standardized or not. Documented and standardized processes are quite desirable. They are necessary parts of achieving high-quality results.

Documented processes can be analyzed, evaluated, refined, standardized and made repeatable.

According to W. Edwards Deming “If you cannot define what you are doing as a process, you do not understand what you are doing.” If you do not understand what you are doing, you are more likely to do it poorly – inefficiently and ineffectively.

At the same time, the documentation is not the process. The documentation describes the process; it is not the process itself. Knowing this helps performers in complex processes to expect that they should and must not stop thinking, following the process blindly. At the same, time there are situations in which the process documentation should be followed exactly as written. Process documentation should clearly state the risks of following and not following the process as it is written.

Standardized and Repeatable Proceseses

Standardized processes, ones that are used across multiple departments or by many people, make training more efficient, are easier to control and improve and enable easy transfer of people between departments or projects. Standardized processes are repeatable. They can be done the same way over and over again.

Standardization and repeatability are great, but they come with a warning. Make sure they are good. Clearly, you don’t want to repeat a process that is ineffective or inefficient. You need to bring process quality into the picture. In addition, you must consider the conditions and build in alternative paths to address predictable alternative situations.

As said, the best people can be brought down by a bad process.

Process Analysis and Improvement

Define your process. Break it down the steps into bite sized pieces, define expected outcomes, establish acceptance criteria, test it and continuously refine it as it is performed.

Remember, everything is caused by something – a set of steps under specific conditions; a process.

Processes cut across silos. Step back and focus on the steps and the outcome. Establishing roles, responsibilities, and accountabilities is critical. However, avoid sub-optimization — making one department’s process great at the expense of the effectiveness of the whole.

Stop playing the blame game. Critically evaluate your process to make sure that it is as good it can be and to identify exactly where things go wrong and how to avoid repeating the same mistake over and over again. Remember Juran’s 85/15 rule.

Document and standardize wisely.

Take a process view

From the Archives: The Boss From Hell

Written by George Pitagorsky on . Posted in Articles. 5 Comments on From the Archives: The Boss From Hell

Whether you are a project manager or a person working on projects you have at least one boss. He or she might be a client, a sponsor, a functional manager or an executive anywhere in the chain of commands above you.

More often than not, as a project manager, you have more than one boss.

A boss is simply someone who has the authority to give you orders; someone in charge of a worker or organization.

I’ve been lucky enough in a long career never to have had a boss from hell. But many, I am told, have them so they probably exist.

What is a boss from hell? It is a person with authority over you who exhibits one or more of the following behaviors:

  • Verbally abusive
  • Passive aggressive
  • Unappreciative
  • Demeaning
  • A liar
  • Incompetent
  • Self-serving at the expense of subordinates
  • Non-caring
  • Cowardly – afraid to stand up for his staff and even himself
  • A workaholic who thinks everyone else should be one too.

For example, a person who yells at you when things don’t go as they think they should. Or, someone who regularly says things like, “Stop whining. Just get it done or I’ll get someone else who can do it.” when you try to explain that hitting the deadline, given current circumstances, is virtually impossible.

Related Article: Managing Your Boss

The boss from hell often combines many of these traits and displays them to make the lives of his or her subordinates miserable. This results in suboptimal performance.

If You Are a Boss From Hell (BFH)

If you are a boss from hell, congratulations for getting this far in this article. Acknowledgment is an import first step in changing negative behavior.

Of course you may be a boss from hell and not realize it. If you want to find out the quality of your “boss-ness,” objectively look at your behavior. Does it match items on the list above? Do people who work for you cringe when you come near? Have people who worked for you quit for no other reason than you and your behavior? These last two are not easy to see. Subordinates are often guarded and won’t even say the real reason they are leaving in exit interviews. Even if they do, the HR people will often not pass the sad truth on. So, it is best to rely on your own self-observation. This takes courage and an intention to continuously get better at what you do. If you own up to your faults and take the effort to change, you will remove yourself from the BFH list.

It may all begin with apologizing when you realize that you have exhibited BFH behavior. You can’t expect to change immediately, but you can recognize and acknowledge what you have done and make the intention to not repeat it in the future.

If you Have a Boss From Hell (BFH)

What can you do if you have a boss from hell who is oblivious to the damage he or she is doing to you and the organization; who just doesn’t care?

The answer depends on your situation, the degree and frequency of hellishness, your ability to withstand abuse and your courage. In any case the first step is to self-reflect. Is it your boss or is it you? Generally, if you find yourself with a BFH from job to job, maybe its you and not them.

One possibility is to fire your boss. This is at the extreme but a wonderful thing to remember as an option. Firing your boss means letting go of the security of your current job and moving on. This can be done by requesting a transfer or by quitting. Once I had a boss and mentor who advised me to make sure I had a year’s worth of money in reserve so that I could feel comfortable leaving a boss or job that was not working out. Short of that you can look for a soft landing place before you say goodbye. Further, don’t act out of fear or anger. Take the time to objectively assess the situation and other options before deciding on your next steps. Consider your mental and physical health and what effect staying in an abusive, demeaning situation will have.

Before you fire your boss you might appeal to your HR group or to someone with some influence over your boss. This is dangerous in organizations where the culture doesn’t vale healthy working relationships. I have seen many organizations in which the person who complains about abuses is considered the problem, even when there is a history of complaints. Sometimes the BFH is well connected and well thought of by his or her superiors – “they deliver the goods” and no one above really cares about how they do it. If the BFH is a client, then there is little chance that this approach will work.

However, if you are in a relatively caring organization you might find that this approach can work. Though, it might take months or even years until some positive change is made.

Before you take these two options, consider the possibility of talking to the boss. A direct, though respectful, confrontation, free from anger and fear, perhaps driven by an understanding that the boss’s behavior is not deliberate, might work. For example, when confronted by an angry or otherwise abusive tirade, you might say “I don’t like to be yelled at. We can discuss this when you can speak to me more respectfully.” This might send the BFH off on an even more violent tirade, or if the BFH is a client a call to yopur boss to have you removed from the project. On the other hand it might result in a calm discussion at a later time. Either way, it will make you feel good to have spoken up for yourself.

Often, what perpetuates BFH behavior is the fear that stops people from speaking up and making their feelings known. That brings us back to the first option – firing your boss. If the worst case scenario is in mind, and it more desirable than taking continued abuse, then you are free.

Project managers are managers. You often have the authority to tell others what to do and how to do it. You are also subject to the authority of your clients, sponsors, and functional managers. The quality of management and leadership has a profound effect on project and organizational performance. Seek to address management style by promoting a servant leadership attitude based on compassion and caring for self and others.