Archive for the ‘change-management’ Category

Goal Based Conversations

Wednesday, January 2nd, 2008

I find myself asking my children with great frequency, “What is your goal?” Not in a philisophical “What are you going to do with your life” way, but in a “What could your goal be aside from making your sister cry” way. I want my children to grow up understanding that what they do and what they say will impact those around them, and that should carefully consider what they are trying to achieve and insure that are behaving in such a manner as to achieve it.

Understanding what your goal is and behaving in such a manner to achieve it is a tremendous asset to an Enterprise Architect. I have witnessed countless discussions and meetings spiral off topic and out of control as participants argued to defend the correctness of the details of their own position to the detriment of moving toward the overarching goal. Achieving maximum success in one’s career and in one’s life is about setting goals and behaving in a manner that gets one closer to those goals!

A goal based conversation is nothing more than one of the many interactions we have with stakeholders on the road to ratifying a design. Here are some tips for goal based conversations:

  • Be clear on your goal. If you aren’t clear what you are trying to achieve, you can’t possibly achieve it.
  • Don’t get caught up in winning or being right. It is all about achieving your goal. Anything else is a distraction, including taking a personal stake in the outcome. This is a common mistake. It is easy to get defensive about work you have done. I also discuss this in my article on diplomacy.
  • “Just the facts, maam”. Have a pros and cons discussion based on facts.
  • Know when to accept a minor victory. Not every battle is worth a last stand.

Posted in change-management, project-management | No Comments »

Architect or Diplomat?

Thursday, June 1st, 2006

I was approached by a colleague after a recent architecture design meeting who remarked, “Wow, you are quite the diplomat!”, which made me stop and think. While I believe my technical knowledge and experience enable me to bring significant value to my clients, I rely just as heavily, if not more, on diplomacy to broker architecture designs to conclusion. Creating a great design is just a piece of the architect’s puzzle. This led to some ruminations on an Enterprise Architect’s “soft skills” that are not directly related to core technology capabilities and some thoughts regarding architecture diplomacy.

The cardinal rule of architecture diplomacy is “Include fellow solution stakeholders early and often.”

Solution stakeholders are the group of people that have opinions about how a solution should be architected – most typically they are either technology teams that will play a role in building or supporting the solution or they are owners of technology domains within the enterprise, like information security or database management. There are actually a multitude of reasons to make an extra effort to include these stakeholders:

  1. Engaging people early makes them a part of the solution – people are always more likely to root for your team if they are on your team. Nobody likes being kept out of the loop. You are not an army of one – even if you are Genius #1, you need some help implementing your brilliance, in which case you want the implementors on your team!
  2. If you are unsure about the design, brainstorming with a team with varied opinions and experiences will result in design epiphanies. Draft something to depict the target solution – even if incorrect it will be valuable. People are quick to identify mistakes. Don’t take it personally, but use it as a tool to engage your stakeholders.
  3. If you are sure about the design, reviewing it with a team will undoubtedly result in ample feedback. Some of it will align with the design as you envisioned it. Excellent! There is nothing that ratifies a design as quickly as consensus. Some of the feedback will disagree with the design as you envisioned it or offer refinements to your design. Ask anyone giving only negative feedback on the design to propose changes to fix it. If proposed changes improve the design, you would be a fool not to implement them. If they worsen the design, you would be a fool to implement them. You are a complete fool if you did not seek feedback in the first place!!
  4. Don’t talk at your stakeholders. Talk with them. “Talking with” requires listening and responding as opposed to driving ahead down whatever path you started. It seems obvious, but when you are listening, you will hear others “talking at” and not “talking with”. People don’t like being “talked at” becuase it wastes their time – they could be elsewhere doing valuable work while you talk.

Posted in change-management | 1 Comment »