META Trend: In 2004/05, IT organizations (ITOs) will continue to refine their infrastructure planning processes while linking them more explicitly with other IT constituencies: application development, project management, operations, and architecture. Gradually (2004-09), project delivery will become more integrated; different groups will work with standardized deliverables, while further integrating with operations service request management, change management, and other activities. As this refinement takes place, more ITOs will establish center-of-excellence or organizational groupings to distinguish the infrastructure planning discipline (particularly per-project design) and the infrastructure planner role as separate from, yet related to, architecture and engineering.
The enterprise architecture (EA) process is inherently about driving strategic change in organizations. It is human to resist change, especially when a proposed change was not self-conceived. Most organizations suffer from the “not invented here” syndrome to some degree. As change agents, enterprise architects often find themselves in situations of disagreement or outright conflict, at times with a substantial emotional component. The success of individual architects and the EA program is in large measure determined by how effective these situations are handled in a manner that yields the best decisions for the enterprise while preserving and even enhancing co-worker relationships. Like it or not, everyone is a negotiator. However, enterprise architects, in the course of their work as facilitators of the EA process, frequently have the opportunity to serve as a negotiator in unique situations. EA negotiators help people reach wise agreements about the use of technology that will best serve the enterprise. These agreements are win-win solutions that drive progress.
The implications are simple. If an architect is a poor negotiator, he or she will be an ineffective architect. Conversely, the individual, all others with a stake in an issue, and the enterprise will benefit from the good work of architects who negotiate successful agreements. Currently, negotiation proficiency among enterprise architects is largely lacking. By 2008, we expect training in skilled negotiation to be on the shortlist of personal development priorities in 70% of organizations with an EA program.
When should an architect apply negotiation skills?
It is easy and tempting for architects to take a side on an issue and get caught up in a spirited debate. Although forming an opinion on an issue is virtually unavoidable as a human being, architects can and must be careful about choosing when and how to voice that opinion, balancing it against the recognized opportunity to serve as negotiator of an agreement.
Architects must be aware of several common situations throughout the EA process that present negotiation opportunities and be willing to lead by serving in this important role:
- Staffing the EA team: The best people are always in demand and difficult to get. Managers must be convinced.
- EA priorities: Personal/group agendas combined with near-term, tactical focus and pressures must be balanced against the enterprise-strategic drivers the architect would ideally like to be the dominant force for EA.
- EA staff time allocation on EA versus project work: Quality architects are in demand by project managers as project designers, technical team leaders, and other roles. This keeps them grounded in reality, but it must be balanced against doing EA outside a project context across the organization.
Future-state EA content creation: This is where emotional battles occur among passionate, biased technologists. Even in the calmer cases, reaching agreement on a target architecture in any particular domain is difficult, because people are involved.
- Project EA reviews: When a project proposes an approach inconsistent with the future-state EA, the discussion can get interesting, and such meetings can quickly lose control.
- EA exception/waiver request meetings: The prior example can reach a boiling point at this formal hearing. The project team always comes with an entrenched position staked out, which should be handled diplomatically as described below.
A Crash Course in Principled Negotiation Technique
Once an enterprise architect determines there is a situation that would benefit from negotiation, how does one go about doing it? The traditional, de facto approach goes something like this: People take sides on the issue, stake out a position on it, argue for their position (often quite emotionally), then make a series of concessions to reach a compromise (e.g., the emotional battle over selection of Lotus Notes versus Microsoft Exchange as an e-mail standard). Too often, the process stalls in a heated stalemate with no agreement/decision, delaying business progress while damaging professional and personal relationships. This negotiation style, called positional bargaining, produces unwise agreements, is inefficient, often damages relationships, and gets worse when more than two parties are involved. Regardless of whether a hard or soft approach is taken, the results are most often undesirable.
Fortunately, there is a proven, much more effective negotiating style alternative. Ideally, effective negotiations will efficiently produce wise agreements (assuming agreement is possible) between parties, taking community interests into account while maintaining or even improving relationships. Although all negotiations are different, the basic elements do not change. Principled negotiation or negotiation on the merits is a negotiation method born out of research conducted by the Harvard Negotiation Project (see Getting to Yes: Negotiating Agreement Without Giving In by Roger Fisher and William Ury). Unlike most other strategies, if the other parties involved learn this one, it does not harm the process. Rather, it becomes easier and faster to conduct. There are four key elements to the principled-negotiation method that can be used in virtually all circumstances:
- People: The architect must separate the people from the issue. Human emotions tend to get mixed in with the more objective merits of the matter. Egos become attached to the positions taken by individuals. Often, people attack each other rather than the problem, which happens before the parties even realize it. The architect negotiator must set the stage such that the stakeholders see themselves as working side-by-side on the problem – not on each other.
- Interests: The architect should focus on the interests of the parties, not their positions. A person’s stated position on an issue can often mask what he or she really wants. The situation is akin to software developers who go after implementing what users ask for without first understanding their real, underlying problem. Such users often get what they asked for, but not what they need. The object of a negotiation is to satisfy underlying interests.
- Options: Before trying to reach agreement, the architect should encourage brainstorming to produce multiple options for achieving mutual gain. When “on the spot” in a pressure situation, it is difficult to envision an optimal solution because creativity is stifled. Therefore, the architect should arrange a time in which to brainstorm (with the appropriate parties) a wide range of possible solutions that could address the interests of all parties involved.
- Criteria: The negotiating architect must insist on objective criteria. Wise agreements are based not solely on the “say so” of any one person with a point of view, but rather on some fair, mutually agreed-on decision-making standard such as market value, expert opinion, custom, or law. Discussion should be focused on the criteria. When agreement is reached on the objective criteria first, the parties are well on their way to a mutually agreeable outcome.
Bottom Line: Enterprise architects must develop stronger negotiation skills to improve their performance.
Business Impact: When architects negotiate effectively, win-win agreements result in better business decisions to drive higher value from IT investments.
