Skip to main content

Author: Cecilie Hoffman

Passing the Bad Ass BA Baton

In 2009 I started writing the Bad Ass BA articles (2009-2012) as a way to channel my frustration at work. With all the interesting problems and all the intelligent professionals, my impatience with mediocrity drove me to speak out about what we could better. I should say, speak out and act out; writing the Bad Ass BA articles was simply a chronicle of my constructively disruptive, actively resistant activities at work. Each article ended with short bio line about my professional passion, “ … to educate technical and business teams about the role of the business analyst, empower the business analysts themselves with tools, methods, strategies and confidence.” There’s no bad assery in that statement, in fact, as I re-read it now, I wonder, so what’s the big deal?

The big deal is how the passion manifests. It is one thing to recognize mediocrity and not be satisfied, it is another to speak truth to power, hold people accountable for their responsibilities and do the heavy lifting to generate alternatives. And it isn’t enough to do this by yourself. The big deal is getting other people involved to help, to do their work differently, to not be afraid to do what needs to be done. The big deal is, to manifest your core BA-ness, your agent of change-ness, and make the world a better place – you have to take a risk.

I haven’t been able to write Bad Ass BA columns for a couple of years primarily due to health. Discovering in middle age that one is allergic to gluten, soy and, because I’m lucky, dairy too, stands your life on its ear. I’m getting better but I need to focus on other things before I can write regularly again. At the 2013 Building Business Capability Conference, Adam Kahn, introduced me to a fellow badass – Bob Prentiss. You may know him as Bob-the-BA, teacher of hundreds of proud CBAPs, and bring-down-the-house conference speaker. What you need to know is, a mutual friend, gave both Bob and me our start speaking at regional conferences back in ancient history. I had been feeling guilty that I wasn’t doing anything with the Bad Ass BA platform, and now here was someone who had a burning flame in his heart to do what I could not. The “Bad Ass BA” moniker needed a new home. 

Over the past few months, Bob and I have been comparing notes on why it is important to us to be a Bad Ass BA. Bob says it beautifully, “give a name to cause, create a purpose in life, give opportunities to people who aren’t quite ready to seize it for themselves”. And what does a bad ass do? “Challenge for the right reasons, call bullshit on entitlement, question doing it because we’ve always done that way, get people to focus on the facts and the objective, set aside their fear-uncertainty and doubt (FUD).” Standing up to mediocrity means taking on risk, and that’s a scary thing to do if you’re a professional person who might be supporting a mortgage and a family. No one wants to find themself suddenly out of a job. Even so, for both Bob and me, because of who we are and how our brains are wired, the drive to make things better is so strong that we will speak out and act out. Bob and I were lime and tequila as we talked about the importance of knowing yourself, being aware of what makes you willing to explore the opportunities for a company, being willing to go where others fear to tread, being conscious of taking calculated risk, being willing and able to take on the big challenge and being determined to get people to walk along side with you. Time to pass the Bad Ass BA “baton”.

So, what is Bob going to do with the badass baton? Bob will be writing, blogging and presenting at conferences, small slices of big truths that represent the characteristics of a Bad Ass BA, and the journey that one can take on their way to becoming one. His message is for all levels of business analysis professionals; “find a better way” applies no matter how many years of experience you have. It is about the journey you take, the skills you acquire, and what you do with them along the way to make a difference. If you are a bad ass wanna-be you’ll find guidance and inspiration. If you are a bad ass already, and ready to take it to the next level, you’ll find validation and encouragement. If you are a kick butt consulting bad ass, you’ll have a reference to give others that will make you look even more brilliant.

Cecilie hopes to be back to writing soon with stories of making a difference in the realm of business analysis and business architecture. Meanwhile it is time to pour gasoline on the fire and give a fireproof cape to Bob Prentiss.

Bob: “Thank you Cecilie! So was I the lime or the tequila? I often think I am the lime, that sour, and sometimes bitter taste that compliments the salt, savory, and sweet. When these ingredients are left on their own, they are disconnected and lack harmony, but when combined together, complete the ingredients for that perfect margarita. One of my favorite Chinese proverbs actually explains my badass BA approach to life: “Eat bitter, taste sweet.” It is a road less traveled for the badass BA; a road of challenge, resiliency, adaptability, and a tenacious drive to make things better. We eat the bitter, taste the sour, we fight resistance, we speak truths, we influence and influence again, and we eventually add the salt, sweet and savory to push projects and organizations in the right direction for the right reasons. As I take up the baton of the bad ass BA from Cecilie’s very capable bad ass hands, I look to share the bitter and sour, share my experiences, failures and successes to help you on your journey to bad ass extraordinaire and of course, your perfect margarita! “

Bob and Cecilie send a beer and a chocolate-covered “thank you” to Adam Kahn.

Don’t forget to leave your comments below.

About the Authors

Cecilie Hoffman is a Business Architect / Analyst working for a Fortune 100 company in the San Francisco Bay area. Her professional passion is to educate technical and business teams about the power and value of the business analyst role, and empower business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the IIBA Bay Area (formerly Silicon Valley) chapter. LinkedIn Profile:

Bob the BA provides badass business analysis training, consulting and mentoring services. Bob is passionate about helping you learn differently; so that you can learn new things faster, and put into practice immediately. Bob is CBAP® certified with 25+ years of experience in corporate America; with a background in managing BA centers of excellence, assessing and managing BA maturity, quality, and competency. Bob is the developer of the PMI® 2011 Product of the Year – Project R.E.A.L. (Real Experience; Applied Learning). Bob has presented numerous keynote, workshops, seminars, conferences, and training sessions across North America. Bob is a founding member and past President of the IIBA® MSP Chapter.

The Bad Ass BA: How Do You Know When Business Analysis is Being Done Well?

FEATUREOct15thA senior manager posed this question at the end of an all-hands meeting: “How do we know when business analysis is being done well?”

If you are a business analyst, it is easy to answer the question, “How do you know when business analysis is being done poorly?” While it is likely that what this senior manager wants is success criteria, there’s a useful intermediate step, which is to identify the symptoms of success. Let’s assume this manager is getting ready to make changes in his organization so that defining business needs and recommending solutions that deliver value to stakeholders enable the desired organizational change. Moreover, the activities leading to and following from the change will happen in a predictable, efficient and, dare we say it, a manner that makes people proud to be part of the organization? Yes, we dare.

Try the following exercise for yourself. Fill in the blank: “You know that business analysis is being done well when _______________________.” Here’s what we came up with. We have included the perspectives of many different organizational levels.

  • The business’s “vision” is expressed in terms of a vision statement and a roadmap for how it is going to get there. The roadmap is updated frequently to reflect the progress of development programs and projects, and changes to the business vision as the market changes.
  • Product management teams understand the difference between a vision, a roadmap, a portfolio and a project pipeline.
  • After the agony of elicitation, modeling and analysis, the answer/solution/approach is obvious to all stakeholders (and they agree on which one it is).
  • Successful approaches are repeatable and results are reproducible.
  • An organization’s ability to identify the success criteria for a proposed new program or project includes meaningful metrics.
  • The enterprise has the habit of building in baseline measurement and trend analysis.
  • There is no resistance to measuring/monitoring the effect of change.
  • Time to create quality documentation is protected; historical documentation is valued for potential re-use and for use as a reference.
  • Junior and mid-level business analysts can connect their tactical work to their organization’s strategic goals and the enterprise’s strategic goals.
  • Senior business analysts know what their business customer’s 5-year business roadmap is and how that roadmap is supported by IT’s 5-10 year technology roadmap.
  • New-hire business analysts are given ready-for-them-on-day-1 materials, organizational charts, process map repositories, and BA best practices/templates repositories.
  • HR, product managers, project managers and line (organizational) managers understand the difference between the following roles: business analyst, application analyst, quality assurance analyst, UI designer, database analyst, developer.
  • Entry-level new hires are not given the business analyst title until they have demonstrated some if not all of the fundamental skills of a business analyst. This common practice devalues the role of the business analyst.

“But wait,” you say, “there’s more!” You are right, there’s much more, but let’s press forward past the symptoms. Let’s take an organizational perspective. First, we need some context.

Here’s the conundrum that line managers of business analysts face: business partners/clients/customers want a business analysis service that provides both a strategic partner and a faster-than-light order-taker. Many BAs begin their professional lives in order-taker roles. Over time, they develop their skills and chance upon a situation where their insight, experience and knowledge enable them to contribute at the level of strategic partner.  After the head rush and deep sense of professional fulfillment from receiving the first “Your contribution as our strategic partner delivered results far beyond our expectations” comment, few business analysts will be content returning to the role of an order-taker. A good manager understands that the BA as strategic partner vs. order-taker isn’t an either/or question, but is a question of organizational maturity.

Regarding organizational maturity, we need to remember the late 1980s when Watts Humphrey first published his Capability Maturity Model (CMM) as a paper, then as a book, Managing the Software Process. The 1989 model defined five levels that were points on a continuum:

  1. Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process.
  2. Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
  3. Defined – the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being work Instructions).
  4. Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
  5. Optimizing – process management includes a deliberate process of optimization/improvement.

According to the Software Engineering Institute, which sponsored the development of the Capability Maturity Model, “Predictability, effectiveness, and control of an organization’s software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief.” That was the perception back in the late 1980s. Fast forward to 2012. We now have a variety of rapid iteration software development methodologies that have the intent of optimizing the software development process but, well, let’s be honest, are often misused to avoid doing the hard work up front of defining goals and success criteria.

As a result, we have this notion of “quick hits.” A quick hit is often a solution to a problem that everyone wants solved yesterday. Getting any form of relief to the problem is so urgently demanded that people adopt a just-get-it-done attitude and throw money at it. Quite often the quick hit is a short-term success, not because the effort in the spotlight and a few individuals’ careers are riding on a good outcome, but because the business analyst defined the problem so well that the solution’s objectives were highly constrained so that the requirements could be met with a minimum of design, which would mean that development was low risk so functionality could go into production like an arrow to the target.

While the quick hit model for projects delivers immediate gratification, anyone taking the long view realizes that the success of a quick hit is often counter-intuitive. Sure, the quick hit solution was speedy, and it met the letter of technical requirements but it isn’t extensible and it has few “-ilities,” namely, scalability, reliability, compatibility, manageability (four of the many “non-functional,” requirements for readers who aren’t business analysts).

Moreover, the more emphasis placed on quick hits, the less focus there is on strategic planning and understanding the big picture, that is, the business model and business architecture view of the business’s needs. People who are rewarded for putting out fires with quick hits are not receiving incentive for thinking about the long-term ramifications, nor do they feel at liberty to think strategically.

In 2010, Alexander and Osterwalder and Yves Pigneur published their handbook for visionaries, game changers, challengers and empowered business analysts called Business Model Generation. When there is no business model, an organization is low on the capability maturity model; development is chaotic, quick hits are the norm rather than the exception, and innovation is haphazard at best.

In 2011, Robert Strohmayer identified the business architect at the top of the list of the six hottest jobs in IT (“The 6 Hottest New Jobs in IT”, Infoworld, June 2011). Strohmayer quotes Alex Cullen, a VP at Forrester Research and the Research Director for Enterprise, Business, Application and Development and Technical Architectures, “Business architecture is about making sure the whole business holds together . . . it’s a role built around business planning, pointing out opportunities to utilize IT more effectively.” Simply put, business architecture model is a blueprint of the enterprise that provides a common understanding of the enterprise and is used to align strategic objectives and tactical demands.

When business analysis is being done well, the practice of creating and maintaining the business model and the business architecture is as deeply ingrained in the organizational practices as the tradition of the quarterly all-hands meeting. Not having the business model and the business architecture model as references would be unthinkable. After all, how will an organization know what it is doing and how things will affect it in the long term?

When business analysis is being done well, the organization values having the solution to a problem defined along the dimensions of the users, the interface, the capabilities that the users and the business will have, the data, the controls, the environment that the solution will deployed into, and the quality (those “-ilities”). If you want to know more about these seven dimensions, take a look at Discover to Deliver, just published by Ellen Gottesdiener and Mary Gorman.  Discover to Deliver articulates a methodology based on rapid iteration for ensuring that what gets built has long-term value and can be linked directly to an organization’s strategic goals.

When business analysis is being done well, business customers see their business analyst as a strategic partner, and they see an empowered business analyst who knows the business’s 5-year roadmap, not just their program portfolio, not just a project pipeline and not just the project in front of their nose. In our experience, business analysts who work in organizations that are not mature in the CMM sense are only as good as the managers who protect them. No business analyst who consistently takes initiative, challenges the conventional perspective, raises uncomfortable issues and brings transformational (disruptive) ideas to the table will survive without at least one manager watching their back and providing them with information about the political climate and budget sensitivities.

When business analysis is being done well, executives see the product managers as entrepreneurs, the enterprise architects as intrapreneurs, and everyone sees senior business analysts as brilliant strategic partners.

Don’t forget to leave your comments below.

Cecilie Hoffman‘s professional passion is to educate technical and business teams about the role of the business analyst, and to empower business analysts themselves with tools, methods, strategies and confidence. She works for a Fortune 100 company that is asking the right questions. [email protected].

Rebecca Burgess is a certified Six Sigma Black Belt and a business process analyst at Academy of Art University in San Francisco, California. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement.  [email protected]

The Bad Ass BA: “Business Architect”?

FEATURENov1stWhat the heck is a Business Architect? 

I have had the title Business Architect for almost a year now — I’m loving it. With about thirty years’ working experience in software and the last ten years in the role of business analyst, the next step for me was business architecture, but if you asked me a year ago what that meant, I wouldn’t have been able to give you a succinct answer, or tell you the elements of the discipline. It was something about the connotations of the word “architecture” that attracted me. The notion of integrating all the functionality together, having hierarchies of taxonomies in your head, ooh, ooh! But thinking and doing take more than a little effort to link. Sometimes stubborn people like me need a kick in the rear from the universe to get moving. So while I didn’t like getting laid off last year, because as much as I was relieved to be out of there, my pride was hurt, it was time to go and it forced me to recalibrate myself professionally and make the leap.

The trouble was, there was so much conflicting information about the role of the Business Architect. There’s lots of conflicting opinions on the differences in focus between an Enterprise Architect, a Business Architect, an Information Architect and a Process Architect.

Being intuitive and somewhat reckless, when the interview question came up from the Enterprise Architects about what technologies I would recommend, I heard these words coming out of my mouth, “Gentlemen, you shouldn’t be hiring a business architect to advise you on technologies. I may have my opinions, but there are far better qualified people out there for that. I would be bringing you information about business needs and business processes, not on technologies or solutions.” This was a phone screening. There was dead silence on their end of the line. Darn it, Cecilie, you’ve stuck your foot in your mouth again, I thought to myself. Then, I hear, “Okay! Would you tell us about a situation in which…” Whew, they were still talking to me.

I knew I could do the tasks identified in the job description, but I knew I had to get ahead of the professional development curve if I was going to succeed in this role in the long term. After a few months on the job, there was an opportunity to take the equivalent of Business Architecture 101 at a conference, so I signed up for two 1-day seminars. One of the seminars was just okay. The second one was mind blowing — one of those experiences where every synapse in your brain is pulsating and your neural matter hurts for days afterwards because new neural pathways are forming, and old, deep patterns that have never been challenged before have been cauterized out. I walked around for a week after that seminar like a grinning fool.

I needed definitions and I got ‘em. After keeping these definitions in the back of my mind for the past six months, I’m ready to share — they are valid and I hope you find them useful for your career development and for your endeavors in the Enterprise Analysis knowledge area of the Business Analysis Body of Knowledge.

What is Business Architecture?

First, a business architecture is not a business function/process model. Most business process models show an inventory of processes, but not an integrated model of the information used by those processes. Most business function/process models do not show the customer/consumer/end user or how that customer perceives the touch-points between the business processes and functions.

Business Architecture occurs when you integrate two or three or more different core cross-functional business processes in an engineering type of model, and as a result, make things more clean and efficient. This model is the beginning of an enterprise business architecture. The definition I use is a model of an enterprise (single company or industry) that shows the integration points of all the information that enables the enterprise to function. The model shows information sources, destinations and transformations.

Furthermore, for a single company, a business architecture is just one element of an integrated enterprise architecture. The integrated enterprise architecture includes business, technology, security and organizational architectural components to create a complete model. In addition to all the modeling techniques I have used as a business analyst, I have added capabilities, value streams and value chains to my bag of modeling techniques.

No discipline is without its controversies and the usefulness of basing an architecture on capabilities is one of those controversies. Here’s a definition of capability: the ability of an organization to use its assets to accomplish an activity that delivers business value or competitive value. I have memorized that phrase and can spout in out in my sleep. I can’t build a model of a capability that would stand up to a spring rain. Still, I see long threads on the business architecture discussion sites focused on how best to model “our unique ability to do ”. When the focus shifts solely to a linear process without a view of the integration points, I get worried.

A value stream is an end-to-end collection of activities that creates a result for a customer. The value stream has a clear goal: to satisfy or to delight the customer. “Delighting the customer” is a well-known phrase that comes to us from the Six Sigma and Lean Manufacturing disciplines.  

Some examples of strategic visioning value streams are “insight to strategy,” “vision to eBusiness enterprise,” “concept to development,” “initiative to results,” and “relationship to partnership.” At Railinc, because the business architecture function is new, one of the first things my team had to do was define an “initiative to results” value stream and integrate it with the product management team activities.

You may be familiar with some customer-centric value streams such as “prospect to customer,” “lead to cash,” manufacturing to distribution,” and “request to service.”  Business analysts are also typically deeply involved with business-enabling value streams such as, “forecast to plan,” “requisition to payables,” “resource availability to consumption,” “acquisition to obsolescence,” and “financial close to reporting.” People caring is another category of value streams, “recruitment to retirement” (less politically correctly known as “hire to fire”) and “awareness to prevention.”

I’ll go into value chains in a future article, but for now I just want to say that value chains are part of what a business architect builds. A value chain is a sequence of activities followed by a company in a specific industry. The chain of activities gives the product more added value than the sum of the independent activity’s value. As a simple example, take a master chocolatier as a profession. Cocoa mass, sugar, cocoa butter and dark chocolate nibs are low-cost ingredients by themselves. In the hands of a master chocolatier, the result can earn you forgiveness for leaving dirty socks on the living room floor, show appreciation to that analyst who went the extra mile for your study, or, eaten in private, could get you lucky on a date. The making of a chocolate confection may have a low cost, but the activity adds much of the value to the end product since the ingredients are significantly less valuable than a box of Recchiuti Confections. 

So, what do you do with a value chain? Once you have the value chain, in order to understand the behavior of costs for the product you can disaggregate a company (don’t be distracted by the divisions) into its strategically relevant activities. And you can examine the existing and potential sources of differentiation between your company and your competitors. Does your competitor have the ability to deliver a service in the same end-to-end capacity as your company can? Does that make you more interesting to potential customers? Understanding the value chains enables a company to gain a competitive advantage by performing these strategic activities more cheaply or better than its competitors.

What is the goal of Business Architecture?

In my opinion, the goal of a business architecture is to enable a company to focus its services on its customers. If you don’t know how the information in your company is integrated to enable delivery of services and customer satisfaction as well as being able to bill and collect for those services, then your company is in trouble. 

Case in point, what happens when you have multiple customer master databases? It is easy for this to happen. In my previous company, we grew by acquisition. With each new acquisition came at least three customer master files, one from the sales group, one from marketing and one from customer service. In my current company, we are in the process of integrating the customer master files associated with siloed products. One of the driving issues is data quality; when you have multiple sources of the same data, but no process for “single source of truth,” it can be impossible to know what is the most current data set for a customer. To achieve the goal of a single customer master file a company has to have an integrated model of customer touch-points. I don’t know about you, but I hate getting “exceptional offer for new customer” announcements from a service provider that I already have a contract with, especially when I see what good deal I would get if I weren’t already a customer. Makes me wonder if a competitor might match that new customer offer.

Rethinking “The Customer is #1” idea

A short tangent, indulge me. I’ve never liked the idea of the Customer being #1. In my mind, the employees should be #1 because if the employees are treated well they will perform well and treat the customer well and make the customer feel like they are #1.

In a previous company that I’ve worked for, if a customer became difficult to work with, one question that was always on the table was, are they worth doing business with? We could quantify that answer in terms of revenue versus lost productivity dealing with them and low employee job satisfaction. There’s a ceramic urn on top of the refrigerator in the employee break room at that company labeled “ashes of former customers.” I can’t tell you how much employee loyalty that urn evokes; I can tell you that in that urn are the names of companies we stopped doing business with because management decided it was bad business.

My employer, Railinc, is a subsidiary company of the American Association of Railroads. Having never worked for a subsidiary company before, I was surprised when I realized that one piece of advice that has been in my toolkit is no longer applicable — Railinc cannot fire any of its customers. We can’t single out a particular railroad and say, “We won’t do business with you.” A new twist in the life of an information worker.

Does making the employee “#1” conflict with the goal of a customer-centric business architecture? Not at all. It just means that a company needs to examine its business goals and determine the different aspects of “the customer,” i.e., revenue source and cost-center if it wants to broaden its definition of “customer.” Customers aren’t just revenue sources; they are also sources for cost, as in customer-retention. Employee-retention is also a quantifiable asset. Revamping the definition of customer is one example of how thinking at the enterprise level changes the scope of a business analyst to business architect.

What does a Business Architect do?

Like the job description for a business analyst, the answer to that question seems to be dependent on the hiring manager. There’s lots of confusion between the role of the enterprise IT architect and the business architect. I can only tell you what I am and am not doing.

Currently my focus is on core elements of the industry, specifically railcar health and railcar utilization. My days are spent as follows:

  • Formulating frameworks and building models — by the bucket load
  • Writing concept documents
  • Critiquing project proposals
  • Preparing for and conducting knowledge elicitation meetings
  • Asking a lot of questions
  • Collaborating, facilitating, more collaborating
  • Identifying “services” in product offering visions
  • Tending an organic (constantly changing) ten-year roadmap

I do not research or recommend technologies. That’s doesn’t mean I can be ignorant of past or current technologies. In fact, being older and having been around when some of the legacy systems were built and understanding how difficult it is to migrate off those platforms has been beneficial. I leave the “how” of the solution to the enterprise architects. They come to the business architecture team for the “what do they need to do and why do they need to do it.”

In my current position, my scope of work isn’t a single company. Railinc provides information services to the railroad industry. The business architecture model that my team is building focuses not on a single enterprise but on the entire railroad industry.

What I don’t do is spend any time with UML, write formal requirements and work directly with the product developers. That experience prepared me for how I spend time now — working with people at the railroads, with Railinc business analysts, product managers, program managers, Railinc enterprise and data architects, and external industry subject-matter experts. 

I help articulate our products, current and future, in terms of services and value streams. In particular, I analyze railcar health and utilization information and integration points in terms of relationships to all external entities, other enterprise value streams and the events that trigger instantiation. I look at railcar health and utilization information from the perspective of what my company must produce to satisfy its industry partners, compete in a market and deal with its information suppliers.


If you can’t help but perceive the world around you in terms of business information needs and process and connections; if you can hold multiple points of view simultaneously; if the meta-modeling is part of your consciousness and you’ve had a blast being a business analyst and are looking for something more, then I strongly encourage you to start aiming your career at business architecture.

Recommended Reading

Google these:

  • The Outside-In Approach to Customer Service, Sarah Jane Gilbert
  • “You Can’t Cost-Justify Architecture,” John Zachman
  • “Converging Business Architecture Approaches,” article on

This book was published this year: Enterprise Business Architecture, by Ralph Whittle , Conrad B. Myrick 

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the roles of the business analyst and business architect, and to empower business analysts with tools, methods, strategies and confidence. A motorcycle enthusiast, she’s riding out the downturn in the economy by living a bicoastal life, living in California and working as a business architect at Railinc in North Carolina. Her friends have disqualified her from the “how far do you commute to work” contest on the grounds that she’s nuts.

The Bad Ass BA Crampons up the Learning Curve of a New Position

BA_March8_CecilieMAINFollowing through from the previous articles on changing jobs (see Part 1 and Part 2), what happens when the universe gives you what you asked for, the job you have been hoping for, holding out for? Whether your new position is a small change, such as moving from one group to another in the same department in the same company, or a major change, such as moving across the country to take a position with a different company, along with the new job comes a learning curve. This learning curve can be anywhere between a gentle slope to a climb up a nearly vertical wall. “Learning” – that’s such genteel term; so analytical, so detached; it conveys none of the spine-tingling, ear-ear-to-ear grinning excitement that I feel when it is time to “suck up a new domain”.

How do we business analysts build the connections from our knowledge and experience to incorporate a new domain? For example, I have previous work experience in shipping, as in ocean transport of those big thirty-foot containers, and in expedited freight, which you know as DHL, FedEx, and UPS. My new position is with a company that provides information management services to the rail industry. I know nothing about the railroad business, but I do know that the fundamental business activity in transportation is to be able to move something from point A to point B and bill for all the services involved in that movement.

My learning curve isn’t a vertical wall, but it is pretty darn steep. The stakeholder community is fascinating. There are hundreds of railroad companies in Canada, the United States and Mexico, but there are the “Class 1” railroads that dominate the business landscape. In addition, there are railroad car owners who lease cars (a train is an assembly of cars and at least one locomotive) to the railroads. There are also component manufacturers who manufacture parts; suppliers who are distribute those parts, and car shops who consume those parts as part of performing maintenance and repair on the cars. There is also government involvement at the federal, state and local levels – just think about it, transportation is essentially a leading indicator of the health of the economy. If trains are moving, that means goods are moving. In order to be able to map the railway industry equivalent of the Quote to Cash business process, I will be inhaling noun phrases, absorbing relationships and concepts through my pores and trying to map all this new information onto my previous experience so that I can make sense of it as fast as I can. As each of us grow in our careers, we will all experience this terror and joy of having to perform while incorporating new knowledge on the fly.

Have you ever wondered how you do it? Is there a model? You betcha! There’s a nifty, keen learning model called Bloom’s Taxonomy, published by Benjamin Bloom in 1956. Below is the graphic model, called Bloom’s Rose, a nice play on his name as well as the shape of the representation. Do click on the graphic to see a readable version on Wikipedia.


In the center of the diagram above are six numbered skills; the numbers represent their position in the hierarchy where 1 is the most fundamental skill and 6 is the most sophisticated. The spiral in the center of the diagram indicates to me that Benjamin Bloom understood that the sequence was not strict; there was a lot of iteration.


A lot of research and discussion has been done on Bloom’s model since 1956 to reflect changes to an information-processing focus of modern Western education. Below is what the current model looks like. As you might guess, this model is still being discussed.


What does this model mean for a business analyst who is on a rapid learning curve? Think about the skills you need for knowledge of, comprehension of, and critical thinking about a particular topic. Let’s walk up from the bottom of the hierarchy. The titles of each section have old skill name in parentheses.

Remember (Knowledge)

The BA shows memory of previously-learned materials by recalling facts, terms, basic concepts and answers:

  • Knowledge of specifics – terminology, specific facts
  • Knowledge of ways and means of dealing with specifics – conventions, trends and sequences, classifications and categories, criteria, methodology
  • Knowledge of the universals and abstractions in a field – principles and generalizations, theories and structures

After studying about eating a healthy diet, the BA can respond to questions like: “What are the health benefits of eating apples?”

Understand (Comprehension)

The BA demonstrates understanding of facts and ideas by organizing, comparing, translating, interpreting, giving descriptions, and stating main ideas:

  • Translation
  • Interpretation
  • Extrapolation

The BA can respond to requests for information such as, “Send me a summary of your comparison of the health benefits of eating apples vs. oranges.”

Apply (Application)

The BA demonstrates the ability to use the new knowledge, solving problems to new situations by applying acquired knowledge, facts, techniques and rules in a different way.

The BA can respond to requests for information, such as, “Which kinds of apples are best for baking a pie, and why?”

Analyze (Analysis)

The BA examines and breaks information into parts by identifying motives or causes. The BA can make inferences and find evidence to support generalizations:

  • Analyze elements, e.g., of a community or system
  • Analyze relationships among those elements
  • Analyze organizational principles

The BA can respond to requests for information such as, “List four ways of serving foods made with apples and explain which ones have the highest health benefits. Provide references to support your statements.”

Create (Synthesis)

The BA can compile information together in a different way by combining elements in a new pattern or proposing alternative solutions:

  • Produce a unique communication
  • Produce a plan, or proposed set of operations
  • Derive a set of abstract relations

The BA can respond to a request to provide alternatives such as, “How can we convert this “unhealthy” recipe for apple pie to a “healthy” recipe by replacing the objectionable ingredients? Explain the health benefits of using the ingredients you chose vs. the original ones.”

Evaluate (Evaluation)

The BA can present and defend opinions by making judgments about information, validity of ideas or quality of work based on a set of criteria:

  • Judge / Assess in terms of internal evidence
  • Judge / Assess in terms of external criteria

The BA can evaluate a set of alternatives and make a recommendation, such as, “We want to serve apple pie as a snack to the kids in our after-school science program. We are trying to decide whether to serve freshly-baked apple pie using organic apples from a local farm, or pre-frozen apple pies, also made from organic apples but come from sources more than 100 miles away. The issues are cost, ease of delivery, and the community’s desire to support local businesses.  Please advise.”


Remembering, understanding, applying, analyzing, synthesizing/creating and evaluating – do these six terms resonate with you? When you learn something, did you realize you were doing all this work? I think this is why our brains hurt when we are on a steep learning curve; we can almost feel new synapses forming in our brain as the new connections form. What is even cooler is that by the very nature of the work we do, the opportunities to learn, both breadth and depth, are nearly without limit. We just have to seek out those opportunities and make them happen.

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. She is a business architect at Railinc in North Carolina. See her blog on her personal passion, motorcycle riding, at
 [email protected].


Rethinking Asking the Stupid Question

Business Analysts ask questions; that’s what we are paid to do. We are encouraged to be inquisitive, “there are no stupid questions.” We are taught to ask “why” five times to get to the root of the motivation. Most of the time we feel good about asking questions – we’re prepared, we know what topics we want to cover and we know we are talking to the right person. And yet sometimes we realize that no matter how we twist our brain around, what we are hearing doesn’t make sense. It could be as simple as an acronym we haven’t heard before, or as complex as a decision that is so wrong-headed we can’t believe everyone just agreed to it.

What do you do when you have to ask a question you wish you didn’t have to ask? I have seen good business analysts unwittingly shoot themselves in the foot by using this common wishy washy preface.

“This might sound stupid, but…”, or “This might be a stupid question, but …”

Why do we undermine ourselves by prefacing our question or remarks with wishy washy language? The preface says essentially, “I’m insecure about asking this question and I’m expecting you to make me feel bad for asking.” Yes, that’s a harsh assessment – but I’m trying to make a point. You might think that because you are going to interrupt the discussion, the preface is a way of being polite. Is it? Putting the idea into people’s head that you are asking a stupid question nearly guarantees it, which is counterproductive to the importance of your question. Also, you want to save your “stupid” question prefaces for sneak attacks.

There are exceptions to all rules, including the “don’t ever say, “This might sound stupid, but…” rule.  In some situations the clever BA will want to launch a sneak attack by asking “crazy as a fox” question, for example, you perceive that people are going along with a line of thought that doesn’t make sense, and you’re about to bring them to their senses with cogent questions that cut to the heart of the matter. In this case, the wishy-washy preface telegraphs to the group that you’re about to pounce. Telegraphing your intent is a viable strategy to get people to pay attention.

We’ll leave the exception aside, and focus on a better approach to asking clarifying questions that require you to interrupt. In general, say what’s on your mind. It reinforces your credibility to present your ideas with confidence. Instead of flogging ourselves with the idea that “I should know this”, try adopting the Generous Listening attitude. What is a generous listening attitude? It’s the view that we Business Analysts are there to hear the essence of the other person is saying, and to it reflect back so they can hear themselves more clearly. It’s not merely replying “So what I hear you saying is …”, and it’s not asking a bunch of questions to further clarify what they are saying so we understand perfectly what they mean. Generous Listening is listening in a frame of mind that helps a person understand what they have conveyed to you and the group.

On the surface, the Generous Listening paradigm’s advice seems contrary to what we business analysts are told to do; Generous Listening advises us to avoid the questions “How?” and “Why?” questions. Before you dismiss this advice, consider creating a space in your toolkit for new questioning strategies. “How” and “Why” are great questions when appropriate, but they can shut down conversation instantly when you’d rather keep the conversation flowing and growing, and when you are interrupting for a clarifying question, usually all you want to do is get your answer, and let the discussion resume. As we BAs know, asking “How?” when a person does not yet know “What” results in mere speculation.  

Think about your frame of mind when you listen to a discussion. I know I’m listening for flaws in a person’s reasoning, overlooked cause-and-effect scenarios – my mindset is so tuned for critical analysis that I’ve assumed that there’s something wrong before they finish their sentence! Generous listening is the process of getting at the “what” in the other person’s mind and assuming the “what” is there even if they need help articulating it. The question “Why?” tends to spark defensiveness. Even when appropriate, it may be better to say, “Help me understand your thinking on this … “

Generous Listening recommends adding the following phrases to your toolkit to listen generously and expand a conversation:

That’s a great idea!

Please say more about that.

Interesting! What else?

What would that make possible?

What would that allow for?

Tell me more . . .

What would make that possible?

Help me understand . . .

When we ask questions such as, “What would make that possible?” instead of, “What could go wrong?” an entirely different conversation results. Try it! Incorporating these simple phrases will completely change the character of your communications.

Let’s get back to the short interrupt preface phrases.

Not great: “This may sound stupid but, have we assumed that … “

Do you really need the preface? Here are three alternatives.  

Okay: “It sounds like we have assumed that …, is that correct?”

Direct, but could put the person on the defensive: “Why have we assumed that …”

Better: “Would you say more about … , it seems that we have assumed that …”

Here are three additional phrases to use for a quick interrupt:

“I just want to make sure I understand, “DR” in this conversation means “disaster recovery, right?”

“Let me repeat what I just heard, you tell me if I got it right. …”

“Could I just verify what I’m recording for the meeting minutes / for my notes …  “

Tips for asking a question that you wish you did not have to ask:

Keep it simple.
Eliminate the preface, eliminate add-on questions. Phrase the question in words that the group will understand. By keeping questions simple, you avoid inadvertently inserting distractions into the discussion.

When we say “DR” here, are we talking about disaster recovery or a data repository or dead reckoning?”

The form of this question is “A, B or C?” The simplest form of the question is, “A?” Ideally someone will say, “disaster recovery”, you say, “Thanks” and the discussion continues smoothly. Alternatively, if you ask, “A or B”, someone might remember an issue related to the data repository and the discussion will veer off in that direction, leaving loose ends on the disaster recovery topic. Including the ludicrous possibility of dead reckoning adds a touch of humor which could be useful if you are trying to diffuse a tension-laden meeting, but it distracts people from the topic so use that gambit only when needed.

Be relaxed.
When asking a question you wish you didn’t have to ask, don’t make it worse for yourself by telegraphing your unease. Be relaxed, when you ask your question, wait for the answer, then let the discussion carry on. When you are nervous you will increase the anxiety level of the people around you, whether or not they are consciously aware of your discomfort.

Asking questions is our job! When building trust and a shared consensus of reality, making assumptions is the kiss of death. Asking questions, even a question that you are sure everyone knows the answer to except for you, shows that you are paying attention and striving for a solid understanding. Interrupting for clarification can be done without disrupting the flow of discussion and without undermining ourselves.

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times and most recently the poem, A is for Analysis. See her blog on her personal passion, motorcycle riding, at
[email protected].