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

Unsure about Seeking a Mentor? Read this…

Seeking a mentor can come as advice from a peer or through recognition of need to get assistance in immediate and future career growth. The value of a productive mentoring relationship for the individuals involved cannot be understated for many reasons.

Read More

Mentoring....

  • Builds skills and capability
  • Facilitates problem solving on a personal level
  • Builds confidence
  • Provides a learning "safe zone" protected  judgment or far of retribution for failure
  • Promotes failure as a learning and correction opportunity
  • Helps remove self-imposed obstacles
  • Accelerates career growth
  • Exposes the mentee to examples, people, content and knowledge that the mentee has
  • ...and more!

Finding a mentor is not always easy, and finding a really good one even harder. Take a look at this excellent article from Lolly Daskal on finding a mentor that suits your specific needs.

7 Important Qualities Your Next Mentor Needs to Have

Part of the equation, though, is the mentee's understanding of and commitment to the mentoring process, which can be ill informed at this stage. The expectations of the mentoring Its-still-puzzling-meexperience cannot be formed for the unititiated, because the hasn't occurred yet, because the initial meeting between mentor and mentee hasn't happened. Unfortunately, there isn't a lot of written and easily accessible information for new potential mentees about what they should expect. The following should help those wondering if mentoring is right for you to make some intelligence decisions on next steps.

Purpose of Mentoring

The purpose of the mentoring relationship, which is closely tied to its actual definition, is to provide a safe ad productive learning capability and forum to a person of less experienced by a person of more experience. This typically occurs around a common element, like a shared profession. Done well, the mentee becomes confidently empowered in his or her ability to tackle difficult problems or perform new tasks. Equally important is understanding what mentoring is not about. Mentoring should not be viewed as staff augmentation, in which the mentor is asked to perform or complete tasks on behalf of the mentee. Nor should there be expectation of surrogate problem solving with customers, peers, or supervisors. The mentor is there to guide and enable new behaviors from the mentee, but it is critical that the mentee have accountability for execution.

Working Relationship vs. Friendship

The mentoring relationship is built on trust and trust is built on both observed action and emotion. Therefore, what emerges is an emotional bond between mentor and mentee that can blur healthy boundaries required to provide separation. The mentor should not be viewed as a friend and should not take this role on. Often, tough truths and decisions must be discovered, discussed and made. It's hard enough emotionally to bridge these topics without friendship-based emotions clouding judgement and ability to accept criticism.

Exposure of Personal Psychological Obstacles

When working through obstacles at work or surrounding overall career issues, it isn't uncommon to stumble into territory that has more to do with personal barriers that are actually the root causes of work issues. For instance, if a business analyst tasked with facilitating elicitation sessions or morning stand-ups has fears of public speaking or conflict resolution, he or she might be prone to steer away from these situations while wondering why there is slow growth in career progression. Confronting fears in a mentoring relationship, and in a safe place, can be an unpleasant and very personal affair.

Truth

Few people like to hear the truth about themselves, good or bad. The good stuff can embarrass the modest and the bad stuff is just plain tough to swallow. The mentee who seeks a mentor should take heed that truths will arise and need to be confronted. The willingness to do so is a key sign for a mentor that a mentee is committed to change and progress. It should also serve as a great marker for the mentee that he or she is turning the corner and moving forward. These moments are actually acceleration outings in the mentoring process, in which the mentee can break through obstacles.

The great thing is that mentoring begins to produce benefit for the mentee immediately and in direct proportion to the effort expended. 

Doug Goldberg

Work

The old adage that work isn't easy could not be more true of a mentoring relationship. Beside the difficulty of the personal boundaries that are opened to criticism and the mental effort to protect and repair them, there should be significant tangible exercises that are part of the overall effort. Only so much can be accomplished in the short time the active mentoring session occurs, and this should include the discussion and example instruction. The real learning occurs when the mentee is able to try applying the lessons in between mentoring sessions. This is, and should be, bolstered by homework assignments designed to reinforce the lessons with other information, practical application, mental repetition and reflection. It takes effort on the part of the mentee to add this to the current daily life-load and workload. Expect it to occur and be ready to dig in.

Commitment to Greatness

It sounds like a great thing to many, but when the realization occurs of the emotional impacts and additional work, there is often a tendency to head for the hills. You can avoid this by first know what the mentoring relationship will being to your life and then actively decide whether or not you are in a place to be able to cope with the effects and additional effort. The great thing is that mentoring begins to produce benefit for the mentee immediately and in direct proportion to the effort expended. Unlike a course of study in which the student only obtains the certificate of completion at the end, the mentee is immediately able to begin application of lessons learned to the issue at hand. Better yet, the early lessons build on one another to provide foundation for new obstacles and serve to cement early layers of much needed confidence.

Walk Away with This

Mentoring is not for everyone, because its a very personal experience that has big impact. You have to be in the right place to be ready to accept everything it has to offer. Do your homework about finding your new mentor when you are ready, and be sure to do your homework about what it is really going to bring as an experience.

TIP: The first meeting with a potential mentor is used by both parties to size each other up. Take the opportunity to ask pointed questions about what your mentor thinks you should expect as experiences and benefits.

If you are interested in learning more, contact me at doug@douggtheba.com for more information and a free, 30-minute consult.

 

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