Skip to main content

Tag: Business Analysis

An IT BA on a Cross-Functional Technology Team

Written by Janet Walker on . Posted in Articles. 1 Comment on An IT BA on a Cross-Functional Technology Team

If you, like me, have spent most of your BA life sitting amongst other BAs or inside a cluster of business partners, you can appreciate the “shock and awe” I experienced moving into a workspace filled with engineers and QAs.

Half of our IT team re-orged into system-specific cross-functional teams. The business analysts combined with the QAs, system engineers and even a database engineer (DBE) or two to form a cohesive group of support, brainstorming and execution. I went through this transformation last year and can say the experience has been nothing less than eye-opening.
Keeping the engineering side of your business in focus is important for any BA, but when our business wants to turn left and our engineers – developer, programmers, DBEs, etc. – are diligently working on how to use the latest technology to turn right, we find out how painful it can be!

The engineers (I lovingly refer to them as my Geeks) are as committed to driving our business as I am and are always looking for the inches of improvement around us. Suddenly, the total commitment to our business partners involves some tough choices for me, the BA.

One day I’m in a devoted business partnership, the next day I’m in a devoted partnership of driving the business during system upgrades and failovers!

The first thing that shocked me on the Geek-filled team was finding out I was actually skating on thin ice all those years as I was driving our business forward on top of new technology. Yes, I understood how the system worked and what some of the possibilities were, but all that time the engineers were looking for better ways and innovating like crazy. Suddenly, I understand why the engineering response to my change requests was often “WHAT?”, “WHEN?”, “WHY?” and sometimes “Wait!” I was driving the business on top of a system or systems the Geeks were constantly improving. Understand, our company culture is deeply ingrained in all team members, but sometimes during those days as a business BA I wondered if the Geeks and I worked at the same place. Getting on the same page, or not colliding on the same page, was the source for a LOT of discussions, but, the real challenge had been making the business better on top of the ice and how to make the system better below.

{module ad 300×100 Large mobile}

The second “wake up” moment was when I spent the first month with my Geek team and realized we had been meeting and making decisions over the years while saying the same words and meaning completely different things. For example, I have used the term Doc Type for about 14 years and never knew the engineers supporting my system have been mentally translating it to Doc Type Number. Only when I physically joined their world did I hear the comment from one to another “She means the number.” A simple difference, but really got me thinking. Geeks talk differently. In my part of the world, they speak English, but a different kind of English. There I was, thinking I was an expert at translating technical changes into business-speak, and I found myself needing to come up to speed on translating geek-speak to technical changes to business-speak.

Thankfully, I landed on a team with patient engineers and QAs. I think this patient Geek may be few and far between, but if you find one – listen and learn! My experience with Geeks is that they run fast and when they get an idea – watch out! A discussion can go from clear and orderly to “Wait, what if we do ….” and “No, I heard about something that ….” REAL fast. Your BA skills are needed like no time before. Remember how you led that meeting with business big shots and their conflicting agendas? Child’s play. Now you need your special skills, as I like to say, to herd cats. You are dealing with super-smart, ready-to-execute, get-it-done individuals and what we don’t EVER want to do is stop that innovation and passion for execution.

You just want to figure out how to do what our business needs us to do and make it to your next meeting (or lunch) on time. Remember how I mentioned I work with patient engineers? Well, even their patience is limited when it comes to asking them to remind me (again) what a thread is. You will want to decide what questions you need to ask during a meeting like this and what questions can wait.

My suggestions, if you find yourself gifted with an opportunity to work on a cross-functional technology team:

  1. Concentrate on just listening during your first few team meetings. Ask an engineer or QA afterwards to translate what you didn’t quite “get”.
  2. Slowly start asking questions to find out if anything on the agenda will affect your business partners. This is a way to bring the business closer to your engineers, QAs and DBEs.
  3. Add something to the agenda that is pure BA, pure business. Get ready for odd looks, questions and maybe even some chuckles. This is where you find out how wide the chasm is between what your Geeks think the company does, and what you know it does.
  4. Make an effort to educate your team members as you get educated yourself. Share your current business meeting challenge, your thoughts on acceptance criteria for a task or other things in your typical BA day. Pretty soon you find the discussions become mutually informative, and the action items have you all on the same page.
  5. “BA” for your engineers! Give them the support and input they probably didn’t know they could ask for. Do the analysis, contact the subject matter experts for any clarifications, and learn to test something from the very bowels of the code. Show your cross-functional team what they have been missing all this time and why they need you in their lives!
  6. Lastly, enjoy the most exciting team experience you have ever experienced. Dive deep, sweat a little and celebrate the big wins as a cross-functional team.

The A in BA

Written by Mani Ramasarma on . Posted in Articles.

According to IIBA, business analysis is defined as “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders”. This is what a BA is and should be. However, in most places the role of a business analyst is confined to just two words in the definition – “defining needs”.

The others are given a short shrift. Whether this is by choice or due to a lack of confidence in the skills of a BA is unknown. Probably we as BA’s are to be blamed partly for this. Many of the candidates I interview for positions in my organization also have a narrow view of what a BA must and should do, and this is confined to eliciting and documenting requirements. Many do not address the most important job of a BA – the “A” in BA. A thorough analysis of a problem statement leads to identification and recommendation of the best solution for an organization, deliver value to stakeholders and thus provide complete justice to the definition of business analysis.

It is extremely difficult to explain analysis in its entirety in this article but let me attempt a synopsis.

{module ad 300×100 Large mobile}

So what is analysis? According to Merriam-Webster dictionary, analysis is “a careful study of something to learn about its parts, what they do, and how they are related to each other”. More importantly the plural of analysis, analyses, is defined as the “separation of a whole into its component parts”.

Now, that looks familiar. As applied to business analysis, it is the separation of requirements into their functional component parts aka functional decomposition. Besides being part of a BA’s job, why is it necessary for us to analyze? Why is it necessary for a BA to break down the requirements into their components?

As the saying goes “the devil is in the details”. Not focusing on the details or focusing too much on narrow details without considering the impact on upstream and downstream systems is a sure-fire recipe for disaster. Many projects fail for one or both reasons. Once the time for analysis has passed it is difficult, nay impossible, to analyze at later stages of the project when the focus must be on DDT – Design, Development, and Testing (not dichlorodiphenyltrichloroethane, it is banned). During such crunch situations, people resort to the ‘next best thing’ – assumptions – and it is downhill from there.

Projects typically require large financial investments, and it is important that we do not miss on the material details that could boomerang in the testing phase and blow up in the face. Whether it is waterfall or agile, analyzing requirements is very important, i.e., breaking down the requirements into their components so that the scope is well defined early on in the project lifecycle. This ultimately reduces the need for (often incorrect) assumptions later. The process of breaking down requirements into functional details is called Functional Decomposition.

As with every other thing in this world, there are people who swear by Functional Decomposition (FD) and there are detractors who feel its value is greatly overstated. To each his opinion. I fall in the first category where I believe that functional decomposition, as applied to business analysis, is a fundamental technique that every analyst must not only be aware of but should also use to varying degrees. It provides a logical sequence and a natural flow from the big picture requirement down to its components.
How to decompose requirements into its functional components?

Related Article: Cooking Up Business Analysis Success

This is a standard interview question. Two important things are required to get FD right – visualization and clarity of thought. This must be followed by validation by the business users. The level of visualization needed is a function of the maturity of the business process – the greater the maturity level of the process, the lesser the need for visualization and vice versa. Why? A matured process defines the minutest of tasks very clearly and unless there is a strong need to change it, visualization plays a minor role. The point to be noted here is that even when the processes are well-defined certain amount of visualization is necessary to identify the impact on other upstream, downstream, and peripheral systems.

What is Visualization?

It is the formation of visual mental images. You may have read about visualization in Wallace Wattle’s book “The Science of Getting Rich.” This is slightly different, at least the goals are. Given a requirement you role-play, mentally, the various tasks that a user can perform. Imagine what the end-system must look like.

Further, imagine that you are the user who will be using the system. It is called Receptive Visualization and is akin to watching a movie in your head. Here is a beautiful article on visualization in Huffington Post. The second type of visualization this article mentions, Process Visualization, is similar to Receptive Visualization. Visualization can also be seen as internal brainstorming. You can visualize jointly with others too – external brainstorming. Visualization requires business, process knowledge, and a lot of creativity. Along with visualization, you need clarity of thought.

What is “clarity of thought”?

Clarity of thought is the ability to perceive, understand, and follow a train of thought. Why is this important? Clarity crystallizes the goals that we wish to achieve. It is like writing the script or dialog for a movie. You don’t want to omit sentences that make the dialog non-sensical.

Lack of clarity often results in re-work, increased cost, delayed project delivery and, if you really make a mess of it, making it to the Gartner and Forrester’s survey of failed projects.

How to achieve clarity?

While visualizing adopt a step-by-step approach. At each step try answering the 4W’s (Who, What, When and Why) and the 1H (How). There are 2 H’s – Business and Technical. Focus on the Business How. ‘Who’ defines the actors, ‘What’ is the outcome expected of the step, ‘When’ refers to the timing and ‘Why’ provides the raison d’etre of the step. ‘How’ is used, for example, as in a calculation or formula. Ask, in your mind, the questions and put it down on paper. Revisit the steps as documented (as in the dialog above) and see if it makes sense. Now, this may seem like a lot of hard work. Initially it is, but as you gain experience it becomes second nature, and you should be able to visualize with clarity, edit mentally, and put it on paper all in one go. As you can see visualization and clarity go hand-in-hand.

In a later article I will explain this in detail.

Is it worth the effort to visualize and come up with all those innovative things? I firmly believe so, as otherwise you end up with a system that will probably be antiquated within a year or two. Of course, visualization and clarity do not come easy, and it takes plenty of experience. It is a skill that can be developed.

Realizing Value – The Latest Trend or Here to Stay? Part 1

Written by Elizabeth Larson on . Posted in Articles.

In January we published our annual article about the seven trends in business analysis and project management. If we examine these trends, we see that they have one theme—they are all about value. We see and hear the word “value” in articles, blogs, on videos, and even in the definition of business analysis: “…analyzing business needs and recommending solutions that deliver value…” (BABOK® Guide 3.0).

ith so much emphasis on value, we wonder whether the term “value” is just the latest buzzword, or if there is enduring significance to the word. This article will examine each of the seven trends, discuss its relationship to value, and explore whether the concept of value is simply a trend or here to stay. 

But what is “value?” It means so many different things to different people. Does it have to be quantified or can it be subjective? One of the authors (Elizabeth) has worked with an equal number of sponsors who required value to be measured and those who inherently understood the value of strategic projects. The latter group didn’t want to waste time quantifying something like “competitive advantage” or how much it would cost to upgrade technology, or although it could be done, measure the cost of risk avoidance. 

So first, let’s attempt to define that very ambiguous word. As we said, it means different things depending on the application of the term to the business at hand. For example, in Marketing, the focus is on the customer perception of the goods and services and their willingness to pay for them. In economics, there are two components—utility and power. In Accounting, it has to do with monetary worth.  We suggest that project managers and business analysts consider all these different aspects. 

In 2015, the central theme of our Trends article was Innovation, without addressing whether innovation delivered value. It seemed that every organization wanted to be innovative, and every person wanted to be an entrepreneur. However, we have seen that innovation, disruption, and entrepreneurship for their own sake is not productive. Organizations now realize that a focus on “disruptive” innovation can indeed be, well, very disruptive. More and more of them are finding that disruption is expensive and that entrepreneurship might better be handled by internal people (intrapreneurs) who have organizational history and knowledge. Said another way, there has to be a business case for innovation, and it must provide enough value to outweigh the costs and risks of disruption. 

{module ad 300×100 Large mobile}

With this in mind, let’s look at first two 2016 trends and the ways in which they bring value to organizations.

Trend #1 Proving our value through Business Relationship Management

As we said in the January article, executives have long been interested in getting the greatest value from initiatives. However, they have struggled with how to determine and measure it, as well as what the term actually means. We suggested that the role of the business relationship manager could work with executives and business managers to help them define value for their initiatives (projects, programs, and portfolios), as well as help them measure the value at agreed-upon intervals. We have seen an uptick in the number of articles, conferences, and webinars on this topic, which indicates an increased awareness of the importance of organizational performance and value. 

Trend #2 Agile is gaining wide acceptance but still faces challenges 

We suggested that although Agile is gaining traction and has reached a level of maturity, there are still significant challenges. If we look through the prism of value, it seems that these challenges have arisen because many organizations view “being Agile” as an end in itself, rather than focusing on how Agile projects provide value. 

In his article published in BA Times on February 9, David Shaffer called this out by saying, “The goal of software development is not to be Agile. …Being Agile is a worthless goal.”

Related Article: It’s Time to put Value in the Driver’s Seat

Let’s look at the challenges we listed and how a focus on value would resolve these issues.

  • Is everyone on board?  We have long talked about how common it is to have a mismatch of goals among the executives, mid-level management, business stakeholders, and team members. The result of the mismatch is unmet expectations and disappointment. However, if every group was committed to providing value rather than becoming Agile, there would be a greater alignment of expectations and reduced conflict.
  • Can teams be truly cross-functional? There are many online discussions about having generalists vs. specialists on Agile teams. It seems that there is a great deal of emotion surrounding the discussions, in which some parties say that if there are specialists, it is not real Scrum while others talk about Scrum having outlived its usefulness. 

Perhaps if we changed the conversation from the makeup of the teams to getting products to business stakeholders sooner, thus delivering value sooner, then the emphasis would be on what is the best makeup of the team to add value, rather than on adhering to Agile/Scrum roles. 

  • How much governance should the team follow? Needless to say, the amount of governance depends on how much is needed to ensure the solution delivers value. 

In this article we discussed the importance of value, we defined it, and described value as a central theme for all the project management and business analysis trends. We suggested that innovation for the sake of being innovative and Agile for the sake of being Agile were not only unhelpful but also meaningless as ends in themselves. Finally, we looked at the first two trends through the prism of adding value to the organization. In Part 2 we will discuss value in relation to the other 5 trends. 

1  Business Dictionary http://www.businessdictionary.com/definition/value.html

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

The 4 Chords of Great Business Analysts

Written by Kupe Kupersmith on . Posted in Articles.

In our professional community, there is so much confusion or different perspectives on what analysis is and what makes someone a great business analyst.  With so many different descriptions of the role, it is difficult to look at job descriptions to get the answer.

I talk to a lot of people, attend conferences, and hear thought leaders in our profession talk, and get to observe people doing analysis work. For this post I want to share what I feel are qualities that the best of the best in our field have.

How I will describe these qualities is based on a great video demonstrating how just 4 chords are used in many popular songs.  Check out this funny video by Axis of Awesome to hear all these well-known songs using the same 4 chords.  It is all clear to me now why so many songs sound the same.

So, in a not so quite Axis of Awesome way, I came up with a list of the 4 “chords” all great analysts have. 

Why do so many great business analysis professionals “sound” the same to me? Here they are:

1.      Empathy

The best business analysts have a wave of empathy flowing through them. The way they listen in order to understand. The stakeholders they work with say things like “you really understand my situation. You get my group and me.”

Looking through an empathetic lens they yearn to see how a solution impacts the people, processes, the organization as a whole, and technical impacts.

When people buy a new car, why do they all of sudden see the same car on the road? When someone ends a relationship why does every song on the radio remind them of their lost love and bring them to tears? It’s because it is what is on top of their mind, what they are focused on. A good analyst understands this. They do not assume because everyone says they understand something that that means everyone has the same interpretation. 

There are two things going on here. First, the good analyst cares about all the impacted stakeholder groups.  They want different perspectives to gain a holistic view. They understand there is a customer, the business, and a technology view to everything. This aids in fully analyzing the situation so that the right problem or opportunity is being addressed and that the solution is desirable. Secondly, they always have their eye on the bigger picture. They want to avoid situations that may create a scenario where solving one problem leads to another problem for a different group.

Related Article:  The iTunes Impact on Requirements Analsyis

2.      Yearning for learning

Great analysts always want to learn. They never stop. A great analyst will never be perceived as a know-it-all.  They will be confident in their skills yet humble. They attend webinars, read books, got to training classes, conferences and love reading blogs like this! They are always searching for new techniques or different ways to use old ones. And when it comes to their process of their teams, they are always analyzing what can be improved.

3.      Politely Challenging

This one is easier explained by saying what they are not. They are not note-takers. They are analytical and critical thinkers that search for the facts. They have multiple ways to “roll back” stakeholders to understand the real problem/opportunity that needs to be addressed. They don’t push forward without first making sure there is a shared understanding by the team why a solution was asked to be implemented.

They highlight the elephant in the room. You can sit in a meeting and watch how they gracefully expose the “elephant” to make sure no underlying issue has time to fester. They know it is not about individuals as much it is about results.

That description may sound like a great analyst is a little rough around the edges. A strong person not to be messed with. Actually, they are quite the opposite. They are people everyone wants on their team. They find ways not to put people on the defense. They bring teams along on a journey to uncover the real problem.

{module ad 300×100 Large mobile}

They also know when to move to solutioning when teams are getting stuck. I think sometimes there is almost a black and white view as it relates to problems/opportunities and solutions.  There is a view of no solutioning until we are all on the same page of the problem or opportunity.  This assumes it’s a simple task to get everyone on the same page related to the problem or opportunity. That is not always the case. Instead of getting stuck in analysis paralysis a great analyst will start down the solutioning path to test a hypothesis and see if they can figure out the problem that way.

4.      Value networking

All great business analysts have a knack, a desire, and an understanding of the importance of connecting. Why is connecting with as many individuals important? In this profession you are not paid for what you know, you are paid for who you know and how to find the information. So many people want to find ways to negotiate better,  influence better, and get time with the right people to do their job. The way to do it is by building trusting relationships. 

How often do you go out and connect with people in and out of your organization?  How many new people do you meet a week? How many relationships do you foster in a week? Do you even think of this?

In today’s environment we need to move quickly. When you are working on an initiative, you need to know who the go-to people are. You need to be able to access to them. Just think about your day.  You most likely don’t have enough time to do everything you need to do. You don’t have enough time to meet with everyone that needs to meet with you.  How do you prioritize who you will talk with? Most likely one factor is people you have a relationship with already. 

I’ll end my post now so you can go meet some new people!

All the best,

 

Kupe

How Can You be a Business Analyst without Knowing the ____?

Written by Yaaqub (Yamo) Mohamed on . Posted in Articles. 1 Comment on How Can You be a Business Analyst without Knowing the ____?






This is one of my favorite questions to ask whenever I get a chance to talk to a group of business analysts, be it a study group, class or during a presentation.

After I run through a whole bunch of jargon, best practices and, in some instances, inter-relationships between the different business analysis knowledge areas from the BABOK®, I tell them, “So, I have a simple question to ask you all.” It usually is rephrased as:

What do you absolutely need to know to be a business analyst?

At a fundamental level, what makes a business analyst good, or even great?

What do they need to know well to excel in performing effective analysis?

What is the ‘oomph’ factor that’ll starkly distinguish how a business analyst recommends one solution or approach over another?

After some fast thinking on their feet, I usually get the following responses (with smug smiley faces and brightly lit eyes):

The methodology of the organization?

I utter ‘no’ immediately.

BA Techniques?

I smile and say no.

BABOK®?

I raise my eyebrows and say no.

At this point, I make this a simple fill-in-the-blank question and ask them to amp up the thinking up a notch.

How can you be a BA without knowing the ________?

I get the sponsor, organizational structure, enterprise architecture, domain knowledge (I echo “kinda”), etc.

After dropping my shoulders in a bit of disappointment, I proceed to complete the sentence. (Please don’t expect a magical potion answer here!)

How can you be a BA without knowing the BUSINESS?

{module ad 300×100 Large mobile}

Duh!? Apparently, this is not distilled wisdom extracted after meditating under the supreme BA knowledge tree in the Himalayas.

So, why and how is it important to you as an analyst to know the business well?

How can you learn the “business” better?

In this post, I’ll provide some insight on why this is so essential, even though it’s so simple.

Let’s start with a quote from a great man, Leonardo da Vinci.

“Simplicity is the ultimate sophistication.”

Let’s explore the ‘why’ first.

Related Article: Promoting and Selling the Role of the Business Analyst

Here are the three reasons why knowing the ‘Business’ is necessary for you to be an excellent business analyst.

Knowing the ‘Business’ is Your Business

As a business analyst, you’re entrusted to know how an organization functions in the complex web of people, processes, tools, and technology. A Systems thinking hat is essential and something to be used at all times. Let’s examine the definition of a business analyst based on BABOK® V3:

“Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—to determine underlying issues and causes.”

The responsibility of knowing the ‘business’ is assumed in this definition. This is essentially the glue that holds all of the discovering, synthesizing and analyzing together. If I had to define what it means to know the ‘business’ to be a better BA, I would define it as follows:

“Having superior knowledge of the inner workings of the business (or a business unit), the value propositions (products & services) that are supported, along with how different components interact with one another to create positive outcomes for the business and its key stakeholders. The components could include, industry positioning of the organization, business processes, customer segments, revenue streams, key stakeholder interactions, current challenges, constraints, and opportunities.”

This is the Secret Sauce of Going from Good to Great

After sitting through hundreds of requirements review sessions and JAD sessions, I have seen a pattern of what contributes to excellent analysis. If someone is conducting a requirements discovery session to map out the As-Is process flow, the quality of questions depends on how well they have prepared for elicitation and how well they understand the underpinnings of the process or inner workings of the organizational unit.

Knowing how a department works from end to end, even if it’s peripheral to your area of analysis, can significantly enhance your analysis outcome. It can improve the quality of your questions and thereby create better deliverables.

Pause and Self-Reflect for a Moment

I’d like you to think back and reflect on your journey as a business analyst and evaluate how you were able to perform better analysis if you had a better understanding of what you were dealing with. Did knowing how one department hands off work to another help you ask better questions? Were you more stoked when you understood and were able to trace EXACTLY how your work would or could improve the lives of over a thousand sales reps across the country? Were you able to create better process flows for an update of live software that you were involved with initially? If you can find at least one example of this from your experience, the simplicity, and importance of knowing the ‘business’ will resonate with you.

Now, let me leave you with three simple and effective tips that will help you learn the ‘business’ better.

‘No Curiosity’ Killed the BA

Be curious about the project that you get on. Ask to job shadow a business user and ask them what value their department brings to the organization. Obtain possession of user manuals or policies and procedures library to understand how their unit operates. Aim to become an expert in the realm of your analysis, because you can’t give expert advice without being an expert. As an analyst, you must be galvanized with the prospect of knowing the constituent parts of the organization or a department and learning how it all comes together both at the micro and macro level.

Understand the Business Model Canvas for this Business

Another great way to look at an organization is to see it through the lens of Business Model Canvas – a tool to map, discuss, design and invent new business models. You can start by reading this Wikipedia article on ‘Business Model Canvas’ and watching the following two-minute video:

https://youtu.be/QoAOzMTLP5s

There is also a blank template that you could download and use for mapping out the canvas for the organization that you’re working in. Additionally, you can also zoom in a little bit and create one even for an organizational unit.

Zoom Out and In

In my first book, The Five Pillars of a Great Business Analyst, I underscore the importance of recursive systems thinking. If systems thinking is about having a big picture view of your analysis in the context of the domain, recursive systems thinking is having multiple big picture snapshots, and zooming out each time until you see how it all ties into the overall business. As you go through the analysis of a piece of a problem domain, think of what people are involved, what processes have an impact on their work and workflows, and what systems they use including IT and Non-IT. Repeat this process by zooming out to relate it to the next level up in the organization until you’re able to understand how this aligns with the overall objectives and value propositions offered by the organization (e.g. how a change in billing system to enable online statements impacts the billing department, and then to sales and marketing department and then how it affects the organization’s overall objective to go green).

I wish you luck with your ‘business’!

Please use the space below to provide further comments or questions on the theme of ‘knowing the business’ or to provide more suggestions of how to learn the ‘business’ better.