Performance Issues – Conflict Outside the Team

Conflict that extends outside the project team brings an additional layer of complexity to the problem. Given that the conflict is negatively impacting project performance, or will impact it in the near future, you will still want to take some action to remedy the situation, but now you have an additional objective to meet: preserving stakeholder relationships. Meeting this objective becomes even more important when the stakeholder is an external customer or client. This doesn’t mean that all the remedies described in my article about handling conflict within the team are useless, it just means that you need to use them differently and in some cases this objective may influence which remedy you choose.

This article is not meant to be a comprehensive manual on the subject of conflict resolution, it is meant to provide you with some tips and tricks which may help to solve the problem. You should avail yourself of the multitude of training products in this area if you want to become an expert in the area of conflict resolution. There are also many consultants who specialize in the field of conflict resolution where the situation demands immediate outside help. This article does not address the area of contractual disputes. Contract disputes should be handled by the resolution mechanisms specified in the contract.

I discussed the circumstances under which a conflict between two team members should be addressed and the circumstances under which they should not. Conflicts between a member of your team and an external stakeholder should meet the same criteria and one additional criteria: the conflict is harming, or is likely to harm, stakeholder relationships. This criteria is particularly important when the stakeholder is a customer or client. Communicating the project’s goals and objectives is still important and a preventive measure that will avoid conflicts.

Conflicts with an External Customer or Client

This is perhaps the most sensitive situation and the most difficult to handle because now it is very important to preserve a good relationship with your organization’s client or customer. The benefits of preserving a good relationship will likely extend beyond this project whereas destroying the relationship may mean the end of your project! Meet with the team member involved in the conflict to hear their side of the story. You’re not doing this because you’re taking sides in the conflict, but because you’re preserving the morale of the team. You may have very limited ability to take their interests into account and you should communicate this to your team member. Asking to hear their side of the conflict as a first step will at least convey the impression that you are supportive of their interests. The best remedy for the resolution of the conflict may be a face to face meeting, if the cause of the conflict is a technical disagreement, but you may not be able to approach the stakeholder directly. Treat the situation exactly like a technical dispute between two team members if you can deal with the stakeholder involved directly. I describe how to arrange, conduct, and get the greatest possible benefit from the meeting in a companion article to this one: Performance Issues: Conflict Within the Team.

You’ll need to consult with the stakeholder’s manager where your political environment prevents you from dealing with the stakeholder directly. Don’t get into the technical details of the dispute at this point, but do explain the the detrimental affect the dispute is having, or is likely to have, on the projects goals and objectives. Suggest a face to face meeting facilitated by you, the stakeholders manager and you, or a 3^rdparty. At this point, you’ve only gathered information from your team member. They may offer an opinion on the stakeholders position, or repeat what they believe the stakeholder to have said but you should avoid repeating this information to the stakeholder’s manager. You need to be as neutral as possible when stating the information your team member has provided you with. Avoid using personal pronouns (e.g. "he said……”, "she said….”, etc.) when describing the conflict and keep you problem statement brief and to the point. You’re ready to arrange your face-to-face meeting if the stakeholder manager has agreed upon this approach. If the stakeholder offers another approach that you’re comfortable with and wants to handle the approach, lend your support.

You may need to ask for help from your Project Sponsor, if the stakeholder or their manager is unwilling to engage in any conflict resolution activities. Don’t take this step lightly. Escalating the issue to your Project Sponsor implies that you cannot handle the situation yourself. That’s OK if your Project Sponsor views the situation the same way, but not a wise career move if they believe you should be capable of resolving the conflict on your own.

You will need to take additional steps when the stakeholder is an external customer or client. You have two objectives to meet which may not be compatible: preserve the goals and objectives of the project and preserve your organization’s relationship with the customer and each is equally important. Again, you may be in a position of trust which allows you to approach the stakeholder directly, in which case you can handle to situation as described above. Where your position doesn’t allow you to interface directly with the stakeholder you should deal with the project manager on the customer side, or the person in the customer’s organization who is responsible for overseeing the project for them. You won’t be able to escalate to your project sponsor in case your customer is unwilling to engage in conflict resolution with you. Review the conflict with your team member and assess the possibility of conceding the point. What will the impact be if the point is conceded? Can the negative impact be absorbed in the budget and schedule? If the answer to these questions is yes then concede the point. It is important when conceding the point that the customer be pleased with the outcome. Go that extra mile to ensure this happens. There is no worse outcome than to make the concession, pay the price, and still have an unhappy customer!

There will be some conflicts that arise from technical issues which will be impossible to concede. You hope that in such a case, the customer can be made to see that
”doing it their way” may be good customer relations policy but is not possible in this case. If you cannot make them see this, you will be forced to trigger the conflict resolution actions that the contract calls for.

Perhaps the most common cause of conflict in the area of customer/vendor relationships are requirements in projects that involve the development of software systems. The Statement of Work (SOW) and contract will never contain the specificity required to prevent all differences of opinion on whether a specific feature or function is supported by them or not. The dispute will start when a functional specification or design document is reviewed, or the software is tested and will go something like this:

Customer: "This design/software system doesn’t do x when I do y and it should”

Your team member: "That feature/function isn’t anywhere in the SOW or contract. That’s why it isn’t in design/software system. If you want that feature/function you’ll have to author a change request.”

Customer: "That feature is implied in requirement x in the SOW, so you don’t need a change request from me, just fix the design/software system”

This is the point at which you’ll become involved. Your team member should bring the dispute to you as soon as they have this conversation, but if not you’ll be informed of it at some point when either the customer or your team member escalates the issue. You can avoid some of these conflicts by ensuring that requirements are all supported by an item in the SOW and all features or functions are supported by a requirement (see the articles entitled "Requirements Gathering”) but you can never guarantee there will be no disagreements. It’s even unlikely that you’ll get through a project without a dispute.

Your first step is to get the technical details of the conflict from the analyst or programmer on your team. Have them provide you with a rough order of magnitude estimate of the cost of the feature or function the customer is asking for and why your team member does not believe the SOW does not support it. Be certain you investigate all the way back to the SOW because the cause of the conflict may be a requirement that was missed that is supported by the SOW and wasn’t detected until the functional specification was written or the software system was built. If your team member is correct and the feature or function is not covered in the SOW or contract, assess the impact of giving the customer the feature they are asking for.

Go ahead and give the customer the feature if your assessment indicates your project can absorb the cost and time required to deliver. You may want to reach this decision in the face-to-face conflict resolution meeting described elsewhere in these articles and this is one way of giving this issue a higher profile so your customer appreciates your contribution to the relationship. Another way of emphasizing the contribution is to manage the change through the change management process. Have the customer author the change request (or author it yourself), and track the addition cost and time. Should these steps fail, you’ve reached an impasse and you’ll have to resort to the conflict resolution remedies stipulated in your contract.

You should be able to achieve your twin goals of preserving the project’s goals and objectives and preserving your relationship with your customers. You have control over the means to accomplish both these goals in every case except when the conflict must be resolved using the contract’s conflict resolution tool. Ask yourself the question: "Will this resolution allow me to meet the schedule deadline?” "Will it allow me to meet the budget?” and "Will I be able to deliver a product that meets customer requirements at an acceptable level of quality?” If the answer to any of these questions is "No”, you have more work to do. Ask your customer: "Are you happy with the resolution we’ve agreed upon?” If the answer to that question is "No”, you have more work to do. This work may not be finding a better solution, it may be just be better communication of the benefits the solution provides your customer.