Description

An architect needs to interact with multiple stakeholders to deliver his commitments. In most cases, the architect’s own deliverable depends directly on the deliverables of her/his peers (other architects, project managers, development teams, etc). It is also likely that the architect’s output affects that of her/his peers as well. Thus, the architect needs to work with or collaborate, with stakeholders to deliver her/his work item. However, not all the stakeholders would necessarily have common priorities, and they may be constrained by their own timelines as well. It is also not necessary that they would share the architect’s vision as well. However, the inputs of all the stakeholders are required in many time-critical situations to deliver the product. It becomes the responsibility of the architect, then, to negotiate with the stakeholders to get their buy-in, to arrive at an optimal solution and to ensure their continuing commitment to the work item in focus.

Overview

Why does an architect need this skill?

The architect’s mission gathers inputs from multiple sources, and this in turn involves working with a wide spectrum of stakeholders, from customers to development teams, to management at different levels, and to peer architects from other teams upon whom the deliverable has a dependency.

The deliverable should meet the following:

  • the customer’s needs.
  • the required and applicable standards
  • the expected performance requirements

Collaboration involves the different disciplines working together towards a common goal. It involves the making of collective decisions at each stage. Problems are analyzed and solutions are iteratively fed back by the entire team of stakeholders. Options from the entire team are evaluated.

In other words, the entire team commits its expertise towards a coherent solution.

The architect is responsible for obtaining the final design solution, through collaboration with stakeholders.

Collaboration involves both working as part of the team or as a facilitator – as the situation might demand.

Collaboration is generally tightly coupled with its complementary skill: negotiation. While collaboration itself involves working with multiple stakeholders, one needs to take into account that the stakeholders themselves, while committing to the architect’s deliverable, may have one or more of the following constraints:

  • Their goals may not be aligned with the architects in entirety
  • They may have higher priority work items, which implies that their inputs may not come in at the desired speed in the architect’s timeframe.
  • The stakeholders’ view of the problem may not be the same as the architect’s.
  • Organizational politics can impede the inputs from an important stakeholder.
  • Personal relationship equations may not be conducive to the goal.

In each of these cases, the architect must talk to the individual stakeholders, and negotiate to arrive at a common understanding. Without this, collaboration will fail. Negotiation is about realizing a common objective through agreement and consultation. Styles of negotiation include creatively including new terms, compromise ( not preferred), working to ‘yes’ etc. Separating the people from the problem is very important, and a sharp focus on the deliverable is essential. A principled negotiation or negotiating based on the merits, is one good way of approaching the problem.

Common tasks involved in this skill?

The common tasks involved are:

  • To Understand each stakeholder and that stakeholder’s requirements and constraints
  • Separating the people from the problem
  • Communicate articulately and effectively with each stakeholder to ensure a common understanding
  • Maintaining the communication in order to ensure iterative feedback towards the goal
  • Understanding Organizational Politics
  • Maintain effective relationships

How an architect would use this in daily activities?

Consider a typical example where an architect needs to deliver the overall design for a project A. His stakeholders are the customer, project manager, development team and the related interdisciplinary teams on whom the deliverable has a dependency.

There must be collaboration between the architect and the development team; indeed, the development will not be of the required quality or on time unless the architect regularly communicates the dependencies and design to the development team, and in turn understands the implementation complexities so that he can design appropriately.

The architect needs to collaborate and negotiate with the related interdisciplinary teams, without whose inputs her/his own design would be blocked.

Collaboration and negotiation with the project management is required in the above case, to communicate the required deadlines and statuses, and provide inputs to development planning.

Last but not the least, the customer needs to be a part of the larger picture, so that changing requirements can be captured accurately and any issues with meeting any of the customer’s technical requirements communicated appropriately.

Proven Practices

The architect is the role/person with the entire high-level picture of the entire deliverable. (S)he is the person who can provide inputs to the to make the project/product a success. The architect also has a working relationship with all the required stakeholders, having worked with and understood the stakeholders. (S)he is the  person providing the “glue” for the larger, virtual team that accomplishes the entire project.

The architect needs emotional intelligence in dealing with different types of stakeholders. Organizational politics form one of the biggest challenges to the architect. The architect needs to be aware of this, so that any risks to his project can be assessed and strategic engagement plans can be made. The individual personality types and conflicts arising therein needs to be considered another challenge too, since wrong handling can result in a loss of support to the architect’s cause.

One of the main psychological challenges that an architect faces, is acknowledging the fact that each collaborator brings value to the project and that their combine effort is likely to yield better and faster results, than without collaboration. The natural tendency for an architect is to take great pride in individual authorship.

Sub-Capabilities

Understanding the Stakeholder

This sub-capability deals with knowing the different types of stakeholders, and each stakeholder’s characteristics vis-à-vis contributions, and their own take-aways.

Iasa Certification Level Learning Objective
CITA- Foundation
  • The Learner will be able to list the different kinds of stakeholders
CITA – Associate
  • The Learner will be able to list the needs of different kinds of stakeholders
CITA – Specialist
  • The Learner will be able to identify the contributions that each stakeholder can bring to the project
CITA – Professional
  • The Learner will be able to identify means to engage the stakeholder positively
  • The Learner will be able to estimate the impact of the stakeholder’s personality on the collaboration

Effective Communication

Effective communication requires understanding the needs of the stakeholders, and how to communicate with them to ensure the delivery of the project.

Iasa Certification Level Learning Objective
CITA- Foundation
  • The Learner will learn to identify views and viewpoints of the stakeholders
CITA – Associate
  • The Learner will be able to identify the objectives of his stakeholders
CITA – Specialist
  • The Learner will be able to communicate his requirements to the stakeholders effectively
  • The Learner will be able to identify what is required to engage the stakeholder in order to ensure continuous commitment
CITA – Professional
  • The Learner will be able to communicate and negotiate with the stakeholders to achieve results
  • The Learner will be able to understand the constraints of the stakeholders and appropriately engage them

Resources

Articles:

http://www.cutter.com/offers/greatarchitect.html (“What Makes a Great Enterprise Architect”)

Blogs/Webcasts/News/Reference Resources:

http://www.ipenz.org.nz/ipenz/forms/pdfs/Improving_Collaboration-Architects_EngineersOct2014.pdf
Fisher, R., Ury, W. and Patton, B. (1991). Getting to Yes: negotiating Agreement Without Giving In. Second Edition. New York: Penguin Books.