Conflict Management

 

Othel Rolle

March 2007

Summary: Architects must understand that business leads, project managers, and developers consider them as alien. One of the reasons for this is a conflict of interests. Relationship management and clearly defined and communicated architecture-service offerings are must-have tools in reducing conflict. (4 printed pages)

Contents

Introduction
Landing on Planet Earth
Identifying Areas of Potential Conflict
Captain's Log
Critical-Thinking Questions
Sources

"Seek first to understand, then to be understood." –Stephen R. Covey

Introduction

The first thing that architects must understand is that business leads, project managers, and developers consider them as alien. One of the reasons for this is a conflict of interests. There are two major fronts at which architects provide key influence and, hence, the potential for conflict:

• For business leads and project managers, it's the architecture alignment with business strategy.
• For developers, it's the architecture foundation for application development and execution.

Although the architect can speak the language of the developer, project manager, and business lead, rarely does the developer speak the language of the architect, and the business lead/project manager never does. With this in mind, the architect must build relationships like a foreign ambassador and define architecture-service offerings that complement the developer's service offerings, support the business lead's strategic direction, and fall in line with the project manager's project-management process. This is a major effort for the architect to achieve without encountering conflict from all sides. But with an eye and an ear toward understanding these individuals first, the architect can maneuver around many of these potential conflicts. Relationship management and clearly defined and communicated architecture-service offerings are must-have tools that I use to reduce conflict.

Landing on Planet Earth

When I first landed in corporate America, circa 1991, as a system architect, the idea of an architect was thought of as mostly a fictitious extraterrestrial creature that was discussed only when upper management went on reengineering retreats or when a Big 6 consulting company told stories of these fascinating creatures.

The idea that architecture is spoken in a language that is different from both the business world and the developer world is understood by all. However, because it is our objective as architects to create connections to the business as well as to the developer, what is more critical is our failure to understand the needs and goals of the business lead, project manager, and developer. As soon as you have demonstrated to the team that your desire is first to understand and then to recommend a course of action, the path to success will be in sight.

In the past, the general goal of architects was to get people to understand them. They needed to have their words heard and their charts viewed, even if they were not understood. It was a solo act. Although this is important in creating a leadership position in any organization, it does not necessarily solidify your importance to the business. In fact, maintaining the position that you just want to have your voice heard and your opinions recognized can lead to the anticipation of conflict with the other members of the team. I submit—and my experience dictates—that when your driving objective is truly to seek to understand first, all roads from there on out will lead to smoother management of any conflicts that might arise.

Identifying Areas of Potential Conflict

Architects encounter conflicts with the business lead for the following reasons:

• Filtered requirements, as a result of not being a part of the requirements-gathering process
• Not a clear enough business strategy

Architects encounter conflicts with project managers for the following reasons:

• Predefined architecture defined by consultants hired for the project, without the architect's involvement
• Architecture selected by the business lead, without proper assessment by the architect

Architects encounter conflicts with developers for the following reasons:

• Undefined and/or poorly communicated engagement model
• Undefined and/or poorly executable architecture framework

These points are by no means the only areas of conflict, but they represent the most significant areas of conflict. The significance is compounded when both sides ignore the actual cause of the conflict and, therefore, repeat the conflict in subsequent projects.

Captain's Log

It was a long flight from New Jersey, but I finally arrived in Zurich, Switzerland. The cab ride to the corporate headquarters took 20 minutes. I had two presentations to deliver to two different groups. The first group would be skeptical of what I was going to say—not because they did not believe me, but because they thought that they already had the answers and that they did not need my contributions.

The second group would be more or less indifferent to what I had to say. They would also question the need for my contribution.

Herein lies the first sign of conflict. Knowing this, the best position that the architect can take is one of understanding. Taking this position makes architects present themselves as team players. This is very crucial in curtailing conflict among team members. As members of a project develop the feeling that they are a team, the level of trust among those members increases, which has a positive impact on the project. Improved cooperation among team members is in direct proportion to the level of trust among team members. Trust and cooperation are essential ingredients for a successful project team. To achieve these essential ingredients, a team member must be accepted into the project team's circle of trust. Knowing not just who you are, but also what you can contribute to the success of the project, is an important step to enter this circle. The first step in gaining entry into this circle of trust is being an active and empathetic listener.

At each meeting, my approach was to be an active listener. Active listening required that I held off on giving advice/recommendations until I was able to understand the full picture of the business need. This reduced the risk of developing conflict and enhanced effective communication.

Although this might sound simple, in most cases, this is not done. Many of us come to a project with very little understanding of the business need and begin dishing out solutions. The requirements that are articulated by the business leads most likely are communicated initially to project managers or technical leads. The architect is generally not a part of the live collaborative requirements-gathering process. Hence, the architect receives the written account of this process after the fact. This can lead the architect to make assumptions that are based on these requirements. Being a part of the requirements process allows the architect to hear firsthand what the business needs are and to engage the business in analysis dialogue, which will lead the architect to conceive of a more successful architecture. For me, being a part of the requirements process is a must; it is my first peek inside of the business need. Remember: When you are peeking into anything, you are usually quiet and listening.

The next step to preventing potential conflict is to present the architect's service offering. These are the services that I can offer the developer, project manager, and business lead. The description of the service offerings provides a clear delineation of services—allowing the developer and business lead to understand where I could be of service to the project. The description of the architect's service offering should be in line with the project-management processes. Each of the architect's service offerings provides a noticeable contribution to each phase of the project.

After they are presented, the service offerings of the architect clearly demonstrate the services that can contribute to the success of the project. The issue that continually arises and contributes to conflict is the issue surrounding when to use these services during the project. This is where the architect's engagement model is of immense value to the project manager, business lead, and developer. The architect's engagement model explicitly states when, how, and where to engage the architect's services within a project. Generally, engagement starts in the initiation phase and continues straight through to project closeout. Knowing when and how best to engage architects for any one of several of their services will allow the business lead, project manager, and developer the opportunity to incorporate an architect into the team as a key contributor.

In situations in which the architecture has already been determined, before obtaining the architect's recommendation, the architect should review the architecture-assessment document. If no architecture assessment was done, the architect should do an assessment. This should be done after actively listening during the business requirements-gathering process. The result of this assessment might be a very sensitive topic, because the project might already be underway with that previously chosen architecture. Make sure that you inform and get buy-in from those architecture decision makers who made the call for that architecture. Taking this approach helps you appear to be a team player and not a solo hero. You might want to invite those architecture decision makers to participate in putting together the presentation for your alternative architecture. It is advisable to present realistic examples that are relevant to the current business environment—including issues with the architecture and how they can be mitigated with an alternate architecture. Remember: An architect's role is not only to find issues with an architecture, but to save the day with an architecture that will drive home the needs and wants of the business.

Two initiatives, the Architecture Review Board (ARB) and the architecture governance, can also reduce conflict in an architect's life by providing an executable architecture framework. The executable architecture framework is a key support in the ability of architects to deliver the proposed solution that they recommend, and it provides a working platform for an architect. Within the architecture framework are process steps that are clear and repeatable—allowing architects to complete their work with an effective and efficient method. ARB can provide a place wherein the architecture governance is brought to life. Within the ARB, there sits a team of like-minded architects whose role it is to ensure that the dictates from architecture governance are followed.

Architecture governance should not just be a body of rules and regulations, but also a source of guidelines that ensure that as application services are created for the business, there is uniformity to the implemented architecture. These initiatives are inclusive of the comments and recommendation from business leads, project managers, and developers. Architecture governance ensures that business strategy is supported.

In my work in Zurich, my interactions with the business lead, project manager, and developer were also guided by Architecture governance and supported by the ARB. In the final analysis, my approach to these groups created a win-win situation that resulted in project success that was duplicated over and over again. Incorporating techniques to head-off conflict proved to be successful. Projects in which the architecture has been selected without a critical review from the architect will require that the architect use conflict resolution techniques that seek to resolve an active issue. Remember: As project managers plan to mitigate risk in a project, architects must also plan to mitigate conflict to ensure their success.

Critical-Thinking Questions

• How do you create an ongoing circle of trust?
• How do you include business leads, project managers, and developers effectively in architecture governance?
• How can you drive competition, but also reduce team conflict?

Sources

[Covey, 1989] Covey, Stephen R. The 7 Habits of Highly Effective People. New York, NY: Simon and Schuster, 1989.

 

About the author

Othel Rolle, PhDc, PMP has 18 years of experience in defining and implementing software and data architectures for competitive healthcare IT solutions. He has successfully facilitated strategic partnerships between senior IT management and leading-edge technology companies, and managed cross-organizational workgroups to incorporate business goals and data integration in setting enterprise-architecture standards. Othel has developed application frameworks for real-time data integration and designed semantic software solutions.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.