Learning Series: What Happens When You Have EI Awareness

“Many times we are our worst enemy. If we could learn to conquer ourselves, then we will have a much easier time overcoming the obstacles that are in front of us.” 
― Stephan Labossiere

In the last article in this series, I wrote about the tie-in of emotion to the ability to learn. The point-of-view that emotional obstacles block growth and learning is interesting. They don’t actually stop us from trying to learn; we can still go through the motions of going to a class and listening to discourse and trying to use that information for a particular need.


So, what happens to those students of themselves who learn to become more self-aware? What effect does it have on them and what effect does it have on their ability to learn?

Those who have had, or taken, the opportunity to recognize how they feel about different experiences have also been able to essentially evaluate whether each experience is valuable…either positively or negatively. For example, a person might work up the courage to ask her boss for a raise or promotion, only to be shot down. The rejection of the request and the emotional dejection from the failure to get the promotion is obviously negative. However, there are positive consequences that not everyone can recognize nor attain. Those more attuned to their emotions may be able to walk away with a feeling of pride after conquering the fear to work up enough courage to even ask for the promotion. That success also builds lasting confidence and can lead to larger and great feats to accomplishment. In effect, a negative and positive experience was used to produce a value statement for this person, in order to determine whether the result of the experience was worth the struggle. At this point, the brain has attached actual value to the experience.

“Through the experience of emotions, [we] come to recognize what is cognitively and affectively of value,” helping determine how and why we respond to the world around us
–(Dirkx, 2006)

Continue reading “Learning Series: What Happens When You Have EI Awareness”

How Do I Learn to Become More Aware of Emotion?

As I alluded to in the last article, the learning environment is important and must provide a “safe zone” to allow emotional content to be brought out when the moment is right. At this point trust has ensued and the walls start to come down. The student steps aside and gets out of his or her own way, so solid learning can occur. When you become aware of your awareness, it can truly be an awakening of sorts. It’s at this point, conscious or not, you begin to think about and process things differently. This leads to a different in your approaches with others and with yourself.

Mentoring can help this occur, because it is a different learning platform that provides specific benefits for specific circumstances. It is an alternative learning experience that promotes emotional intelligence improvements (one of many). It is very different than the traditional learning model we’ve all become accustomed to.

  • Individualized, customized, private vs. group classrooms and mass-audience
  • Focused on iterative assessment trust and value vs course completion certificate
  • Life-long behavioral lesson shelf-life vs. diminished value as course version or content changes
  • Transferrable skill into every facet of life and work vs. direct applicability to specific purpose
  • Pay-as-you-go and assess for value attainment vs. pay-up-front for single event

“If people are anxious, uncomfortable, or fearful, they do not learn”
–(Perry, 2006)

I’ve Got My Emotional Awareness…Now What?

Building this type of awareness is a journey, so if you’re holding your hand out for a certificate of completion, don’t bother. The good news is that when you’ve started to build this awareness, it can become a great cycle. A little struggle, a little growth. As it repeats, you as the student start to look at others differently with more recognition of what they are going through based on your own experiences. You are more attuned to their reactions to words and actions, keener to how to best approach a problem or a conversation, more prone to let or help a situation defuse before attempting to “fix” it. This is empathy in action.

If you haven’t read between the lines of the previous paragraphs to recognize what’s happening, here is my perspective on how you are transforming…

  1. You learned about yourself, and you developed an awareness that you did this.
  2. You continued the process, achieving additional awareness, regardless of the presence of negative consequences…thus a net-positive experience.
  3. Your perspectives of others changed as a result of your own growth.

“Experiencing one’s self in a conscious manner–that is, gaining self-knowledge–is an integral part of learning.”
— Joshua M. Freedman

  1. Your change in perspective led to changes in how you work with others, bringing a certain non-intimate closeness to your interactions.
  2. Your closer exchanges brought forth empathy and shared experiences developed
  3. The shared experiences formed bonds that built stronger working relationships.
  4. Those around you received benefit; comfort in your approach and success in results as you worked with them.
  5. Your thought process maturation has accelerated. You’re asking questions that you wouldn’t have thought to ask, factoring in complexities and concerns that never occurred to you before, recognizing potential obstacles before they appear to surprise you and seeking out answers that have new importance.


The last item in the list of benefits is REALLY important. It’s integral and directly aligned to points when people are able to make mental jumps in their lives and careers. It’s also integral to the message this website brings, which is that when you grow in your thought process and the way in which you approach it, you afford yourself the ability to grow in your ability to learn and build personal capability. That is the difference between business analysis and business architecture.


Dirkx, J. (2006). Engaging emotions in adult learning: A Jungian perspective on emotion and transformative learning. New Directions for Adult and Continuing Education, 109, 15-26. San Francisco: Jossey-Bass

Shuck, et al., (2013). Emotions and Their Effect on Adult Learning: A Constructivist Perspective




How Project Analysis Matters to the Larger Architectural Picture

This post seeks to shed some light on the differences between project analysis and enterprise analysis, where business architecture takes on a more important and visible role. As our profession grows and matures, understanding the commonalities and differences in analytical technique will serve to promote the BA role.

Continue reading “How Project Analysis Matters to the Larger Architectural Picture”

Who, What, Where, When, Why, How

The words in the paragraph header above are the simplest terms that we, as business analysts, can focus on to collect information and maintain it during the execution of a project. They provide our view of the project world we will operate in. Without it, we don’t have a clue about what we are doing or where we are going on a project….and the BA plays a key role in setting up the whole team to understand the project and problem domain from the start. Yet even when we get all pertinent project data collected and analyzed, it is still common to get hit with scope expansion due to hidden surprises, and surprises can cause issues with success. Why is that?

Often, projects are more than what is in the SOW in front of us that defines our scope; miss it in the discovery and estimation and it’s too late. Missing the bigger picture is easy when focused on specific aspects of change or solution delivery. There are two really important reasons for this (well probably more, but you only have so much time to read here). First, failure to actively question reality, and; second, myopic views of a solution. Questioning is a primary skill of the business analyst and we are all able to execute this, but ACTIVELY questioning a series of stop gap questions can help avoid scope creep and pitfalls while concurrently building your domain knowledge.

Consider this scenario…..

Assume that you have identified five stakeholder groups and their roles on your project. You understand who they are, what they do in the business, what knowledge they have and what user stories/use cases they are associated with. You also have been able to identify their needs for the current project outcomes (process and software). As you build your process, you are able to tie activities to the stakeholders that have been identified. You then build a context diagram to understand the general system and data architecture for reference, and you are able to also tie your identified stakeholders to the in scope system. However, your research (YOUR QUESTIONING) shows that the system actual sends and receives data with three other systems; none owned or operated by your identified stakeholders. What are these other systems? What do they do? Who uses or relies on them? How do they map to the business?

You have just identified out-of-scope impacts to and from your project and are about to delve into business and enterprise architecture. (Thank gosh this doesn’t happen in real life, right?). Your limited view of your project domain has grown to include other business and/or technical architecture elements that all work together in some way. How a BA addresses these other elements is often the distinguishing characteristic of our profession.


Identify Project Impact to the Larger Enterprise Structure through Questioning

Projects are executed to complete a set of tasks to achieve a goal or objective. When they are estimated, it is not uncommon to have unknown elements, such as the scenario we just encountered. It’s easy to see how a project can quickly get into trouble when encountering surprises that impact scope, ability to complete on-time, and project budgets. The triple-threat at work!

A Technical Solution HAS IMPACTS! Analyze the Total Solution!

Good business analysts think about all the interdependencies that scope creep entails and the inquire about the details. Even when the answer is known, questioning serves as a validation mechanism. The three impacts/systems you identified are there for a reason. This is where the information you have or don’t have can be used to fill in gaps in the larger picture (remember no information is an answer, too). If you’ve ever done a logic puzzle, this is much in the same. You are using a few pieces of information to make assumptions and validate those to lock in as many facts as possible in order to solve the total puzzle.

At this point, knowing that new items have been identified, the most effective BA technique is to refer back to the technical architecture/business architecture/prior project documentation (because we KNOW that was the first thing you pulled together when you came on project. Right? Right!). If not, get your hands on it and start locating the pieces that form the domains that your project application and processes live in.

In the absence of these documents and diagrams, you have in this example the beginnings of at least your local architecture and how your project fits into the bigger elements.

Technical Documents and Diagrams that Are Helpful

There are several primary documents/diagrams that I rely on regularly to help shed light on the technical architecture. Each of these provides a specific view of the technical structure. There are MANY, MANY others.

  • Context Diagram: a simple model that shows a central system and the surrounding system architecture, plus the TYPE of information that gets passed back and forth. Easily consumable by business.
  • Technical Infrastructure Framework/Diagram: a complete model of the technical infrastructure on all levels. Usually very complex but an excellent source for researching technical architecture.
  • Data Dictionary + Data Model or ERD + Data Flow: This data “trifecta” is technical in nature but is built around business and organizational concepts and structures. Knowing what the data is reflects the “conversation” between roles and systems, which allows processes to function.
  • Integration Model: Usually not part of the technical repertoire, but a great addition to show which systems interact with one another and often includes data types for passed information through the integration points.

Business Documents and Diagrams that Are Helpful

There are several primary documents/diagrams that I rely on regularly to help shed light on the business or organizational architecture. Most you’ve heard of before.

  • Glossary of Terms and Acronyms: Cannot stress enough how important this super simple document is to have in place and iteratively built through the life of a project. Common taxonomy and shared understanding is a HUGE issue in achieving success on a project
  • Organization Chart: Another simple document that can help tie pieces together as information builds. It normally serves to identify people, roles, titles and business units, but ad-hoc notation can be added by the BA to includes capability utilization, data types, system utilization and more.
  • Process Flow and/or Use Case Diagram: The de facto form of “what the business does, who does what, when “it” occurs and how people and systems interact together.
  • Capability Model: A business architecture reference that defines what the business does, but not how. It represents the core capabilities for the master organization or the business units within/subsidiaries. The capability model can be used to map every other element of the organization to individual capabilities, which provides a clear line of sight view for people, processes, systems, data and other elements. It is often non-existent in less mature organizations, but the BA can begin to craft it as the project occurs to provide superior value and domain understanding.
  • Context Diagram: While this is a technical artifact, I really like how simple it is and have often used it to illustrate business units and the information and actions that pass back and forth between them.

Take Away

Requirements are often cited as a primary reason for project issues and failure, though I refuse to cite the Standish Chaos Report again. While true in some regards, the root cause is a much stickier issue that can be traced many times to lack of or elimination of proper discovery to clearly identify the complete scope of an effort. The BA encounters a situation in which requirements are essentially needed for an unknown, hence the importance of questioning. When encountering scope surprises…

  • ask the right questions (who, what, where, when, WHY, how) over and over
  • also question what is NOT evident or obvious (are there roles that don’t map to systems? data that doesn’t map to capabilities or process? process that doesn’t map to roles or systems?)
  • revisit the available documentation and interview key SMEs to acquire answers
  • pull the pieces of your problem domain together to build an updated view and define impact
  • document the architectural mappings and alignments as a value add for your customer (and your team’s ability to succeed)
  • learn the general architectural constructs that work best for YOU when trying to craft answers about the bigger pieces


Paradigm Shifts for Business Analysis

We’ve all heard the arguments, and probably started a few as well, about the fact that business analysts are so much more than scribes, requirements clerks, documentation writers and the like. Yet the perception and utilization of BAs in this regard continues to permeate the profession. In looking at the responsibilities and actions of the general BA population, there are signs that may point to why this continues to be a problem. In 2011, Glenn Brule wrote a series of articles that discussed the progress ion of the BA career path and the shifts in focus, as well as skills needed for the changing competencies.

Transitioning into a senior role, the BA is acutely aware and well seasoned in technical skills and begins to flex business skill muscle in enterprise analysis-type activities, e.g., writing a business case, understanding business needs, conducting capability analysis, defining solution scope.

Glenn R Brule, Are Business Analysts in Danger of Becoming Extinct? Part 2

Continue reading “Paradigm Shifts for Business Analysis”

Essentially, Brule was highlighting his foresight into the fact that business analysts had a path to remain relevant in their roles if they understood some basic phases of the BA profession and the general skill sets required for each. He painted a high-level picture that provided a road map for a practitioner to start with, as a basis for moving forward. Concurrently, the proliferation of the popularity of certifications such as ITIL and TOGAF have gained significant momentum while new organizations continue to form up, mature and provide a home to aspiring business architects. This year at the Building Business Capability conference in Las Vegas, there was noticeable on the push to add strategy to the mindset of the BA’s pursuit of excellence through exposure to more strategic process discussion and architecture modeling platforms. In fact, Sparx Systems we quick to espouse a recent partnership with IIBA to cement the importance being placed on the topics. Even more exciting is the increase in volume of blogs and articles peppering the Internet that promote these shifts.

But! There are two major things that I think are missing in the drive to mature the profession. The first is the recognition of the business analyst as a strategic analytical weapon by organizations, key business units in the organization and managers of individual or groups of business analysts.

While Enterprise Architecture is seeing a healthy foothold growing in many organization, that doesn’t always equate to the parallel creation of business architecture capability. Business architecture units are still relatively new ventures in the same organizations as additional focus on the business is added. Therefore, it might not be unreasonable to assume that good visibility in to the solution and technical architecture is present, yet there are holes tracing it back to strategic need and value statements, assessing fully the organization impacts or determining the level of change management.

“The crucial element is how well the Business Architects are integrated with the other architects and with the analysts. In many cases Business Architecture was within the Enterprise Architecture function – as an aside…”
What is Business Architecture?
By Allen Brown, President and CEO,
The Open Group

Additionally, the word “solution” in many instances has somehow come to signify the technical product delivered to the customer in project execution, and I think that is a massive and dangerous proposition. The dumbing down of “solution” (which is not a comment on the high value of technical awareness and delivery) makes it easy to simply forget that the technical product should be assessed against the organization that will install it and turn it on. Without clarity on what will happen to existing process, resources, workload shifts, data flows and the need for communication and training, there is significant failures to occur. Combine the project execution missteps to understand business impacts with lack of business architecture viewpoints, stakeholders and interaction points; the business understanding becomes even muddier. The best thing to resolve this obstacle has already started, and that is the aforementioned increased dialog.

I think the second major point is more problematic. After watching many, many business analysts, reading the content in the BABOK (all three of these fine, fascinating tomes of career non-fiction) and also reading the general flavor of dialog in the community; and managing, mentoring and guiding business analysts, I’m convinced that the younger, less experienced analysts today are short-changed by focus on tactical execution of requirements identification and techniques without realization on the value of those skills in a strategic setting. So, for those of who just choked on hot coffee reading that, I’m NOT espousing that we stop understanding and analyzing content to produce great requirements. Our current jobs are more essential than ever. I am stating that training and cultural awareness that targets our up and coming BAs earlier on the value of their current skills and how to better apply them in different scenarios must gain more traction. The IIBA® has taken a huge step forward in the new BABOKv3 by introducing the Core Concept Model (page 12) to all business analysts. The model applies a framework to every action we will perform and uses it mentally chop up and reframe the work we are doing and the questions we are asking. This is the first piece of the strategic puzzle communication, but it must be followed by reinforcement of more experienced analysts guiding the professionals who will take over in the coming years. While the collaborative dialog HAS increased, I’m hoping that there will be movement, by our own hands, to increase the clarity and applicability of the BA value into enterprise and business architecture.

Let’s start here.

IIBA President and CEO, Stephen Ashworth, in closing remarks at BBC 2015, put out a call to the community to give back and add value. I would like to propose this as one starting point for us to put some focus on. I’d like to also add anything I can to what may be the first major movement of business analysis since the IIBA formed a qualifying body for certifications and standards. This will be a recurring topic in this blog from time to time and part of my mentoring regimen with willing participants.

Interested in everything you wish to add to this conversation, good or bad.