View source for Charter for conflict resolution in BPM

== Executive Summary ==
A BPM program encompasses many parts of an organization, crossing functional and operational boundaries.  In such a setting, conflict situations are bound to occur.  These conflicts can arise between parts of the program or between the program and other organizational bodies.

An organization that is employing BPM to achieve its objectives must have a structured way to resolve conflicts.  Without such structure conflicts can quickly delay and hinder the speed through which BPM can be most effective.

Conflict management and resolution entails identifying, assessing, and mitigating conflicts.  Further, the program must incorporate lessons learned into the body of knowledge to reduce the likelihood that similar conflicts occur again.


== Objectives ==
This Charter focuses on an approach for evaluating and resolving conflicts.


== Scope ==
Conflict situations arise when there is disagreement over resources or beliefs.  This disagreement can be real and manifest, or it could be perceived.  This Charter focuses on the analysis of conflict situations and the resolutions that best benefit the strategic objectives established by the organization.

Conflict types include those internal to the BPM program and those between the program and other bodies.  This Charter addresses both types and outlines a set of activities to address them.


== Plan ==
This Charter approaches conflicts with a four-stage plan.  The stages are as follows and discussed below.

*Problem Identification,
*Impact Analysis,
*Prioritization, and
*Activation and Assimilation.


=== Problem Identification ===
The conflict must first be identified before it can be addressed.  An attentive program team will be able to spot symptoms across the program's activities.  More often than not, this detection is possible because of the cumulative experience of the team members involved.

Additionally, program participants at all levels must be encouraged to voice their concerns sooner rather than later should they suspect that a conflict situation is developing or has already arrived.

In both approaches, program monitoring and individual reporting there are some basic behaviors to maximize the signal-to-noise ratio of the issues being identified.

#<u>Defined Structure</u> - Ensure that there is a clearly defined and understood hierarchical structure for reporting issues.  At the project-level, this might begin with team members reporting to the project manager or to the business sponsor.  At the program level, this might culminate with the program's executive sponsor.
#<u>Require Data</u> - Require that issues are reported with sufficient and relevant data.  The data should be substantiated and validated.  The data should also help explain where the conflict lies.  Often conflicts arise because of misunderstandings or misaligned expectations.

In an active program there will be numerous conflicts being raised at any given moment.  It is imperative that the issues are identified in a timely fashion and can be analyzed quickly.  The suggestions above are made to streamline the problem identification and to advance the conflict quickly in the next stages.

Options should be generated during this stage.  The potential impact should be understood and be ready for discussion.  Encourage those raising issues to also understand the impact of any options that might be exercised rather than to simply raise the issue and defer the resolution to others.

In generating options, remember that BPM is a dynamic environment rather than a static one.  An option might solve the problem for today and expedite conflict resolution.  The solution will need to be revisited in the future, but at least long delays with trying to find the perfect solution are avoided.


=== Impact Analysis ===
Conflict review requires an understanding of potential impacts.  The potential impacts include those from possible actions and those that result from letting the conflict reach its natural conclusion.  All impacts should be discussed and compared.

Two practical challenges present themselves in this stage.  The first is whether a comprehensive set of options is generated.  The second is whether the potential impacts are accurately analyzed.

In the first case, the '''best''' option or course of action is a relative ranking.  The chances are high that not all possible options will be identified, especially if the conflict is reasonably complex.  However, amongst those suggested, it should be possible to pick the _most reasonable_ option.  Prioritization is further discussed in the next section.

In the second case, for those options identified, it is a predictive exercise to determine the impact.  Without actually picking and exercising an option, it is not possible to know all of the effects.  One can only make an educated guess.

The following suggestions are made to offset these challenges.

*<u>Veteran Staff</u>- Start with a group of people who can more easily pattern match the given circumstances with historical experience.
*<u>Add Newcomers</u> - Temper the veteran staff with new resources to distribute the experience and to also encourage creative ideas.
*<u>Group Discussion</u> - Encourage discussion and brainstorming in the generation of options and analysis of the impacts.
*<u>Look Externally</u> - Industry analysts and benchmarks can provide a repository of tried and tested options.

Take the information gathered in this stage to the prioritization stage.


=== Prioritization ===
As with all scenarios where resources are limited, prioritization is essential to addressing the critical items without getting overwhelmed.  For conflict situations, the prioritization stage involves two areas.

First, the conflicts themselves should be prioritized.  In the [[Charter for alignment|Charter for Alignment]], a structure is presented for prioritizing opportunities based on benefit back to the business.  Similarly, conflicts should be prioritized based on their impacts to the projects, to the programs, and to the business.

Second, the potential options must be prioritized.  The impact analysis exercise for each conflict situation will feed into a ranking exercise, where a specific solution will be selected.  As the costs associated with a solution will be borne by either the project teams or the program team, a structured selection mechanism is critical.

In all cases, the prioritization scheme should be systematic.  It should be clear how selections are made.  The objectives should be clear, and the scoring system should align towards them.  High frequency and high impact conflicts should be addressed first as these generally incur the highest cost if left unattended.


=== Activation and Assimilation ===
Implement the selected resolution options in a structured fashion.  There should be checkpoints where progress is evaluated.  These checkpoints offer a chance to re-evaluate the chosen solution if new data is uncovered or the solution simply is not working as expected.

Collect the lessons as the options are exercised.  Validate whether the symptoms correctly identified the conflict and whether the resolution options work.  It should be possible to link causality of adjusted impacts to the major decisions that were made in this conflict resolution plan.

The historical data will prove invaluable for future pattern matching of conflict situations, and it should be captured in a manner that will encourage review and leverage later.  Regular post-conflict reviews should occur to disseminate the knowledge and to build up a set of best practices within the organization.


=== People ===
It is important to recognize that the conflict resolution stages are being enacted at all levels of a program.  Not all conflicts require the attention of the Leadership team.  Some will affect smaller subsets of the program.  These still need speedy resolution to maintain forward momentum, but it would be overkill to put the entire weight of a program behind some conflicts.

This type of resolution at the appropriate level should be encouraged.  Decision-making authority should be granted at different levels of the program team.  Allow selected individuals to make decisions on bounded conflicts.  When those boundaries are exceeded the conflicts should be escalated.

As speed is typically of the essence, the recommendation is to select individuals rather than committees.  While the individuals should take input from the program participants, deferring the decision to committees tends to delay and to hinder resolution options from being fully effective.


== Assumptions ==
*Sometimes a conflict arises because one party misunderstands what is expected of them.  Developing a trial or light version of a feature may be all that is required in the short-term, with a chance to revisit that functionality at a later date.  This includes interfaces on a roadmap, where early versions of solutions might only require an immature version of the service while later, they will require robust and redundant capabilities.  Options for resolving a conflict need not be implemented and then forgotten.  They can be addressed in a series of actions.


== (Anti-)Behaviors ==

=== Behaviors ===
*[[Internal dependencies - simultaneous upgrades]]

=== Anti-behaviors ===
*[[External dependencies - the five-year plan]]
*[[Internal dependencies - identifying shared assets]]


== Conclusions ==
Conflict situations, while inevitable, are manageable.  Proper evaluation of the conflicts and their possible resolutions should occur at all levels of the program.  Escalations should be encouraged when the impact is larger than a single individual's remit.

A structure for conflict resolution provides more than the means to solve a specific conflict situation.  It also allows the lessons learned to be assimilated back into the program's collective knowledge.  That collective experience can help either to avoid the conflicts entirely or to minimize their impact should they occur again in the future.


== Lesson exercises ==