Business Analysts? Aren’t those the folks in the basement who write documents?

Today I write you having recently returned from the Building Business Capability (BBC) conference in Las Vegas, the premier Business Analysis conference globally. Like most of us going to similar events, I come back energized and full of information, and one such chunk of news strikes a chord with me…so I’m sharing it here.

If you’ve read my posts out in the Internet ether, you’ve read that I believe that we business analysts must collectively STOP referring to ourselves as requirements experts, which connotes one who documents requirements and results in others evaluating us on said requirements that we produce. We must START vocalizing our skills in strategic, system, enterprise and critical thinking which deliver value to our team, our organizations and our customers.

A new study (http://www.iiba.org/Learning-Development/L-D/research-and-study-impact2016.aspx) has just been released that validated a number of things that I have been writing about, and that others have also been espousing about the trends in business analysis and the obstacles related to these trends.

“IIBA engaged KPMG Canada to study how business analysis can continue delivering value to organizations. In conducting this study, we heard from global practitioners and business leaders, and augmented their insights with KPMG’s 2016 CEO Outlook1 and other proprietary research. We heard from many who feel traditional business analysis skill sets and capabilities will no longer be sufficient to add the value that their organizations need to compete.” (1) 

I highly recommmend that we all take a peek at the study results, which are both alarming and right on the mark, in my opinion. The crux of the results point to disparate opinions between practitioners and C-Suite executives about what each group THINKS business analysis is, the value it provides, the purpose of it, the utilization of it and the location of practitioners in organizations. For instance, cited in the report is a comparison of where BA Skill Sets are perceived to be located in organizations. 19% of BA practitioners indicate that these skill sets exist in C-Suite and/or Strategy groups while 68% of C-level executives and 81% of strategists feel that those skills reside in their respective higher level groups. That is an abyssmal gap, but what does it really tell us? To me, it says that the latter combined groups, those who drive innovation, company direction and strategy feel they have the skills do to the job. Conversely, those that are practicing and updating Business and Architect skills daily, getting trained and getting certified see very few practitioners engaged, and little evidence of skill utilization, at this level to proved value.

Another very potent result is the fact that predictions of industry trends for the next three years have organizations, based on responses, looking for more strategic thinking, better leadership skills and enhanced creative thinking and innovation. Today’s skill sets deemed valuable are led by domain knowledge, critical thinking and problem solving and requirements elicitation and documentation.

Finally, a shift in analytical capability that provides VALUE based on outcomes and away from tactical analysis (read requirements analysis) is also taking hold. Business analysts mired in paralyzing granularity will struggle to break out to provide strategic capability wihtout C-level executive recognition that these capabilities exist in this group and understanding on how to first free up these resources and then how to capitalize on it to serve not only customers directly, but also peer teams in the same organization. Analytical capability is crucial in sales, enterprsie and business architecture, strategic planning, financial planning and the like.

While I was at the conference, and before I had a chance to read this study, I had an opportunity to sit down for a short chat with Alain Arseneault – Director, Corporate & Business Development at IIBA. I expressed concerns that I felt IIBA global/corporate must do more to assist lone evangelists in marketing the skills of a profession that I’m very passionate about to organization executives. I also described the difficulty that single persons and groups of practitioners battle when trying to illustrate value and sell BA skills and capabilities to those 68% of executives mentioned above. It is an almost impossible task without the power of a professional industry leader to convey how much we can offer our repsective firms, and I politely encouraged IIBA to give us a hand in the messaging through the power of their corporate aliiances. Thankfully, the study bears this out and there was significant dialog at the conference about efforts underway to make this happen. However, it really is up to each of us to self-promote what we are capable of, and the urgency is never greater!

Speak up and be heard! There is no downside to communicating this message!

(1) 2016 KPMG LLP Business Analysis – Positioning for Success

Facebooktwittergoogle_pluspinterestlinkedinmail

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.

brainbulb

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.

Transferability

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.

 

References
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

 

 

Facebooktwittergoogle_pluspinterestlinkedinmail

Deconstruct Delivery Issues Using an Architecture Mindset

We’ve probably all experienced teams that have struggled to deliver what has been promised, estimated, quoted, sold and talked about. You may have even been on one of those teams. This post is a short one (What? Not everything I write is a novel) about some things that all parties can do to take a step back before it’s too late.

There are a ton of reasons that things can go wrong, but let’s just talk about one. Scope. BORING!

Here’s why it’s important to this post and the general dialog though. SOLUTION. OOOOOO! Exciting word!

Depending on who you are and what you do, you might define solution a bot differently than someone else…..and THERE is the issue.

In a world (<—C’mon, say it like that guy in the movie trailers…) where technology has become very dominant, there are a lot of people who focus on it. There are even a few very specific methodologies devoted to delivering it better. Fine. But when the word solution starts getting thrown around, get it collaboratively defined by all stakeholders.

  • To a technologist (generic term I use for developer, methodologist, enterprise architect, etc.), that might mean the technical solution. That is what they focus on.
  • To a sponsor, they might THINK the solution is the new platform, because that is what is tangible and visible.
  • To a test team, they typically only think about test the platform, usually not the process or information sharing changes.
  • To a UX team, mucho focus on usability and experience and user satisfaction on both.

These four all have a common technology thread. No issues with that from me.

Now think about this….

  • People use processes and information
  • Process and Information interact with technology and data that facilitate processes and information
  • Create new technology or change the existing technology, and you touch the data, processes and those pesky people.

A SOLUTION SCOPE should be all encompassing. Technology. Process. People. Simple as that. Just start asking some basic questions and you will likely find that the answers to at least one of these facets is not nearly thought through enough.

See what just happened here? I didn’t even have to cite the Standish Group Chaos Report on how poor requirements contribute to project failure. I took out whole scope threads to start defining where we can go wrong. Gotta’ have a scope to write a poor requirement, right?

Questions:

  1. How would missing one of the two non-technical facets (process, people) effect a single project outcome?
  2. Same question, yet this time consider impacts to an enterprise platform
  3. How would delivery of value to the customer be impacted without a solid solution that encompassed all three?
  4. How would a process improvement program be stunted by eliminating technical concerns?
  5. How would an organizational restructuring or reduction in force impact processes and information?

Weigh in! Let’s hear what you have experienced! How has this issue manifested into delivery issues?

What questions do you make a part of your due diligence?

 

 

 

 

 

 

Facebooktwittergoogle_pluspinterestlinkedinmail

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.

scopeexpansion

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

Facebooktwittergoogle_pluspinterestlinkedinmail

Already Know the Answer? Think Again…and Listen.

IMG_69541

Walk into a room full of stakeholders and there is no doubt that you will have an earful of opinions and maybe a few decisions.  Walk into  the room with the answer already defined and suddenly silence reigns, even though everyone is talking and offering ideas. Why?  Because in these cases, the practitioner has already preconceived what the end state vision needs to look like. Once that occurs, the need to hear people out immediately diminishes.

Read More

When we arrive at the answer before performing due diligence, there can occur consequences that impede success. This article will discuss a few scenarios that can occur at both the project and enterprise levels. When you complete reading this article, you will:

  • Understand how to spot some situations that require additional work,
  • Understand the issues that "knowing the answer" can cause
  • Understand how to adjust your approach to get back on track

There are two very common scenarios that I encounter, when working as a mentor to guide business analysts. The first occurs when a product vendor has, well, a product to sell. The problem is that when dealing with customers who have specific needs, configuring a product into new forms that address these needs can get in the way of a sale. Think of the old square-peg, round-hole analogy. So, there is often a push to highlight the positive benefits of the product suite while glossing over elements of customer needs that the product doesn't address. That whole sales commission thing can get in the way as well. If the salesperson has stopped listening to those needs, because the end state result exists already as the sold product, the situation can result in  a sold product and dissatisfied customer.

"An essential part of true listening is the discipline of bracketing, the temporary giving up or setting aside of one's own prejudices, frames of reference and desires so as to experience as far as possible the speaker's world from the inside, step in inside his or her shoes...."

- M. Scott Peck, MD

Another scene involves an overly-confident business analyst who has solved a similar problem in the oat and outs about to make the mistake in assuming the two situations require identical answers. stop-sign-1496105Right there, the BA has killed the opportunity to engage in great dialog and obtain insight need to address the problem domain properly. Specific stakeholder feedback takes on the indistinct din of a soccer stadium, lots of chatter but nothing is specific significance.

Don't be the, "Wait, I already know the answer," BA.

A third act in this play occurs when specialists, or experts, in their domain of choice begin to make decisions either investigating or understanding the impact on the larger enterprise. Sometimes, a selection of a system or definition of a target metric seems reasonable but takes on new light when the input, output and processing factors are highlighted.  For instance, a quick decision to increase profitability by 35% by increasing manufacturing output sounds find until one considers the supply chain and manufactured product transporting issues that arise. There is always more to a story.

Fortunately, the capabilities which are part of the Business Analyst's tool belt can help in all situations, and that includes saving the BA from himself or herself!

Big Picture Awareness

Move your mind from the immediate view to the larger picture. Take the opportunity to ask about how the primary domain is interwoven with the larger enterprise technology architecture, organizational capabilities, master business processes and other stakeholder groups. Expansion of your view of the problem domain ensures that there is an ability to identify direct or indirect impacts to actions, needs of other groups using shared processes or technology and alignment to the larger organization instead of only a specific business unit. 

This is one of the best self-training exercises a business analyst can perform. Active validation of questions and theories about topics that are not initially considered in scope increases the value of the business analyst's contributions, builds confidence in understanding enterprise level constructs and let's your customers realize that you have the ability to think through more than just what is on the surface. 

Drop the Ego; Review and Use Lessons Learned

  • You don't know everything, so don't act like you do. EVERY business analyst will get to the point in his or her career where there is finally five minutes of confidence acquired over his or her career. Congratulate yourself, but try not to make decisions during this five-minute period.
  • In all seriousness, confidence can be a great thing while also providing a slippery slope. Use learned lessons and thorough analysis to understand what went well and what didn't, instead of blindly assuming that an effort was ultimately successful overall. This will help you realize:
    • There are often things that could have been done differently or better
    • You need to document both successes and failures individually and together to realize the overall project net results
    • You can both fail on individual tasks while achieving overall success or achieve great task results while failing on the overarching effort
    • The solution for one problem will almost never be identical for another problem...and may actually cause unforeseen problems in other areas (see Big Picture Awareness above)

Listen through Questioning, and Build Dialog

  • Asking questions and listening to answers is what is captured on a tape recorder. Listen to it again, and the same soulless Q&A is repeated. Hidden in the crevices between the dialog is the true essence of the problem statement, the engagement dialog and the solution that will help your customer. Dig in! 
  • The dialog between people is not listed as an official IIBA technique, but there is no doubt that it if a business analyst skilled in building a trust relationship can execute on creating critical dialog, other techniques that are dependent on it can then be employed. Dialog provides the opportunity to listen, short periods to digest and process information and THEN, thoughtfully respond.

Notes Traceability

  • Check the notes that have accrued over time as you have engaged with your customer or groups of stakeholders. Can you find evidence of where the solution options and decisions have come from? Can you find holes in stakeholder coverage or open items that could impact decisions? This simple exercise actually takes little time or overhead, but a quick scan on historical notations can often highlight who provided what options, who had issues, who had solutions, who wasn't represented, who decided on the appropriate solutions, and where those solutions are sourced from. If your investigation begins to look like a sales brochure or swiss cheese, and you are unable to find where your customer is specifically asking for your specific product capabilities, there is cause for concern that might show the solution decision was premature or unduly influenced by preconceived opinion that promoted glossing over key facts. Keep yourself honest by reviewing and publishing minutes of discussions and decisions...and ensure you look at them!

Take Away

Force yourself to discard what you think the answer is by engaging with others, asking questions and validating key items. Prove the answer through diligence! 

Facebooktwittergoogle_pluspinterestlinkedinmail

Agile’s Message on Documentation and Requirements

Today I was listening to a podcast presentation on MasteringBusinessAnalysis.com by Dave Saboe called
MBA045: The Agile BA – Myths and Misconceptions in which he interviewed Bob Woods. In the conversation, there was discussion about the types, volume and value of documentation in Agile and how the differences between Agile BA documentation and more traditional Waterfall output commonly have BAs feeling boxed out of these projects (paraphrasing here).
Continue reading “Agile’s Message on Documentation and Requirements”

The way the dialog was expressed, things suddenly clicked for me, as it reminded me of some messages that I’ve been espousing to the BA in my organization to
21733572474_a56d1c38ba_zeffect a mindset shift away from value placement on deliverables and onto the actual work and analytical thought that is executed to create the content for the deliverables. To make this shift occur, though, there are a number of dimensions that must be considered. I’ll discuss those a  little further into this post.

 

The Good News…

….is that this whole premise of adjusting our perceptions of work around the value we produce has been underway for some time in the Agile community. Bob Woods’ emphasis on the right documentation is the (renewed) starter to bring understanding with other team members to light who don’t really have a great understanding about business analysis. This is important to change perceptions of our involvement on a team, especially an Agile team, from an agility and value enabler instead of a ship anchor dragging bottom. If we start to change how we ourselves place the most valuable aspects of our work, perhaps we will be able to also shift others away from “scribe” and more toward “thinker”, “strategist”, “risk mitigator”, “enterprise collaborator” or “success enabler”. Next time you hear an Agile practitioner say something about “…we don’t document blah blah…”, before you react, think about what they are really saying. They are placing the value on the collaboration and the THINKING (read analysis) that occurs MORE than they are on the output. I’m sure they can elaborate on this better than me. So, I won’t rehash the whole Agile or Scrum manifesto content here. As we continue to struggle to define our professional value to others, it’s important to keep in mind that it doesn’t look the way it used to, and we need to be agents of our own change.

Dimension 1: How Business Analyst View Themselves and Their Work
The maturation of the BA culture has just recently taken more substantial form in the last 10-15 years. Until the IIBA came along, there was no consistent message written down and recognized as a central point-of-view. With our growth came a general understanding of what we do; write requirements and documentation. That is, understandably, what we were taught; told; and learned to do. Therefore, it’s not such a stretch to recognize that many of us still view a lot of our own expertise in those areas. Well word got out, and that is how the rest of the professions that we interact with might also see things. Now think about where we really add the most value and whether it really is in a nicely formatted 16-volume set of documents.

Dimension 2: How non-Business Analysts View the BA Work
If those who are not business analysts only understand that business analysts create requirements and write documents, that perception that takes root and is very difficult to alter or eradicate. So, take that perception now and apply another persona to it…

  • If you are a sales person who is trying to close a deal and costs are at issue, documentation takes time and more time equals more money, cut the costs that produce the least value at the highest costs first.
  • If you are a project manager who is trying to show early value or ensure resource teams are able to work when they on-board, cut the costs that produce the least value at the highest costs first.
    ….and so on…We’ve all seen it or been there. How do you think those two personas might solve the cost issues above if our perceived value as solution discovery, risk discovery, analytical problem solving, etc. was viewed as something that could they could not live without?

Dimension 3: How Business Analysts Value is Measured
The perception that we as business analysts add overhead and not so much value may or may not be prevalent, but it does exist. If those other roles think that “note taking” or “requirements” is all we do, then we are measured by what we do, and that is our document deliverables. We become victims of our own ability to produce great documentation, because to do it properly, it costs money and takes time. To the uninformed, it makes perfect sense to just find a more cost effective way to produce it (let the developers do it). For those who really DO understand the value in a deliverable, they must still battle the cost issue. We must alter the target of where BA value is perceived by others, by helping them to recognize the value of issue discovery, risk discovery, illustrative modeling, mitigation and communication plans, facilitated collaboration output, domain knowledge clarity, business and technical architectural awareness, etc. Essentially, it becomes more about what we are DOING to produce value immediately, rather than where we are CAPTURING what we are doing in a document.

 

Dimension 4: How BA Value is Communicated to Different Audiences
The ability to communicate our output as business analysts resides in the output that we provide in the deliverables we create. The document, the requirement, the model, and so forth are how we express ourselves and they are critical devices to our ability to serve our teams and customers. But is that really where our value is?

Change of Message, Change of Mindset, Change of Self-view

Given the option, I would like to be known as someone who was able to bring domain context, enterprise impact awareness, recognition of risk and alternative ideas based on user-specific needs. I would like to be brought into strategic conversation and planning events because I understand what decisions poorly supported by intelligence can do to an organization. I like that much better than, “Oh, he writes requirements.” I feel better about what I do when I think about my own value this way, and how simple adjusts messaging really make the light go on for my customers. I convey those value-add statements to others when I engage with them; and hopefully we can affect some change in their perceptions of business analyst value, and that isn’t in the document. The value is our analytical thought process and communication skills.

Try correcting the perception in your counterparts next time it comes up, and let others know what you are really capable of. When you get done killing it, you can capture what you need to in a document. Would like to hear your thoughts on this. Drop a comment in!

 

Facebooktwittergoogle_pluspinterestlinkedinmail

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.

 

Facebooktwittergoogle_pluspinterestlinkedinmail