Skip to main content

Tag: Career

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.

Summary

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 BPMInstitute.org

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.

Are Business Analysts In Danger of Becoming Extinct? Part 2

The response to my article has been overwhelming to say the least.  I was pleased to see the genuine interest and passion in support of the role and profession of the business analyst.  The many differing viewpoints in and of themselves tell a very interesting story, perhaps worthy of another article?

As I reflected on all of the comments, it occurred to me that the forest had been overlooked for the sake of the trees…the technical trees.  Many of you responded with concerns, support and very pragmatic viewpoints where “technical competencies” are concerned.  It’s unfortunate, and a challenge BAs and stakeholders alike face every day.  However, my intended message was clearly lost in translation. When I referred to “technical competencies”, in the context of the article, I was specifically addressing those tasks, activities and techniques referenced in the Business Analysis Body of Knowledge®, as presented by the IIBA, and NOT “technological competencies” as they relate to the information technology world.

I hope this clarification will perhaps give a moment of pause and reflection before reading Part 2 of this article, I’m more curious than ever to hear your thoughts, feedback and input.

In this article, I continue my mission to raise the alarm to the potential extinction of the business analyst by emphasizing that regardless of the BA’s professional level, we need to demonstrate quantifiable impact.  As I wrote in Part 1 of “Are Business Analysts In Danger of Becoming Extinct? A Perspective on Our Evolution,” I explored the context for the reasons BAs need to use a balanced portfolio of technical and business skills in order to demonstrate their value to the organization. In this article, we’ll examine the appropriate mix of skills based on the BA’s level of experience.

When we set out on a career path, whether it’s police officer, writer, painter, etc., we are rich with technical knowledge and competence, doing a lot of work “by the book.”  As we become more experienced and more seasoned, we find our own rhythm, shortcuts and better ways to do things, and come to rely more on our business savvy and skills as we inevitably begin to direct others in performing the technical aspects of a job.

In the beginning of their careers, business analysts start out with the IIBA Body of Knowledge® and any other materials they can get their hands on as reference for drawing diagrams, researching templates and other technical questions.  The new BA relies extensively on skills around requirements analysis and elicitation practices as the core essentials. This requires a high degree of technical fluency; for example, elicitation from a technical perspective requires planning and stakeholder analysis using a variety of different techniques to realize requirements from all perspectives.

In order to conduct elicitation activities with a high degree of accuracy, the BA needs to be aware of which ones, e.g., brainstorming, interview, focus group, survey or questionnaire, are most appropriate.  Knowing which method is right and selecting the most appropriate technique increases the efficiency and effectiveness of that activity.  

For example, using a survey/questionnaire of 300 people in 10 days of effort using 600 hours as opposed to conducting 300 interviews requiring 1,200 hours is an example of creating an efficient solution that can quantifiably show positive impact on the project.  This kind of quantification gives the BA evidence to provide to executives to justify the recommended activity.  It also provides the opportunity to demonstrate the cost of not conducting the activity—and, if done properly—the opportunity to:

1.    Quantify the results of the survey through carefully crafted questions that would ask stakeholders to rate and rank anything from wants and needs to priorities.

2.    Vote on the allocation of requirements based on said data.

The same can be said of requirements analysis—creating the right models, sequences with the right degree of accuracy, plan for activities—these are all technical skills that provide opportunities to show quantifiable impact.

As BAs develop further along they look more at the big picture—how the business runs—and perhaps leave the more technical aspects to another BA or team.  Having a mixed balance of both is critical to enable oversight and examination of the work being done, while being able to practically apply career experience based on business skills.  So, while the more experienced BA is knowledgeable in both, he or she doesn’t necessarily execute both.

Moving beyond junior technical, worker bee-type of activities, the more experienced BA progresses to the intermediate level where he or she puts a toe in the water with activities such as planning and monitoring.  This is where business skills start to come into play to answer questions such as when and what activities need to be done and who are the stakeholders that need to be considered? 

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.

What’s the right mix?

It’s helpful to have an idea of the percentage mix of technical and business skills the BA will use throughout the career spectrum:

Career level

Ratio of technical to business skills

Competencies of focus

Junior 80/20

Elicitation and requirements analysis activities and techniques, ability to practice solution assessment and validation activities

Intermediate 60/40

Planning, monitoring, and management of requirements + junior level competencies

Senior 20/80

Enterprise analysis + a high degree of business skills expertise, e.g., critical thinking, problem solving, change management, high impact communication

Given the range of skills sets practiced at each level of experience, the 80/20 rule using a mix of junior, intermediate and senior levels of BAs in the organization is recommended:  80 percent junior and intermediate level and 20 percent senior level.  This will create a balance of business analysis capability based on experience, not headcount.  It also facilitates a well-rounded BA perspective.  For instance, if an organization is top heavy on the senior BA side, there’s the risk of potentially losing objectivity and creativity without junior or intermediate BAs to question or bring a differing point of view.

The levels of experience align essentially with three layers of the BA’s impacts:

  • Organizational level – This level addresses issues such as key performance indicators, goals and visions, which are typically manifested by a senior BA conducting senior business analysis type activities.  An example would be using enterprise analysis to contribute to the development of a solution that increases profitability by a certain percent. 
  • Practices, standards, methods and approaches – At this level, intermediate and senior BAs are seeking to create efficiencies within their practices and processes. They address issues such as how can we do this faster, better?  How can we refine our approach/methods?
  • Activities – This level is task focused, seeking improvement of junior level practices, asking questions such as “can we be more precise?”, and “can we be more efficient with our technical activities?”

The business analyst profession continues to be a work in progress.  To keep BAs from going the way of the dinosaur before they’ve had a chance to completely mature takes a balance of skills.  With a greater understanding of how BAs can demonstrate their impact and value to the organization with a portfolio of competencies, you’ll better serve your professional development while elevating the business analysis profession too. 

Don’t forget to leave your comments below.


Glenn R. Brûlé, CBAP, CSM, Executive Director of Global Client Solutions, ESI International, brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. A recognized expert in the creation and maturity of BA Centers of Excellence, Glenn has helped clients in the energy, financial services, manufacturing, pharmaceutical, insurance and automotive industries, as well as government agencies across the world. For more information visit www.esi-intl.com.

Are Business Analysts In Danger of Becoming Extinct? Part 1

Sept27thFEATRURE2Most organizations have an understanding of the value of business analysis and what requirements mean to a project.  At the same time, conditions are emerging that have the potential to undermine the position of the business analyst to the point of extinction.  In this first part of a two-part article, we’ll take a closer look at what has brought these circumstances about in order to provide a clear understanding of why BAs need to balance their technical and business skills and demonstrate proof of their value to the organization.

Some historical perspective on the evolution of information technology draws interesting parallels to the story of David and Goliath.  IT essentially began with the Goliath that was the big old, clunky IBM 3480 mainframe.  The David to IBM’s mainframe came along as the new Windows operating system and networks. David won the day and the mainframe went the way of the dinosaur.  New opportunities continued to expand the world of technology with network computer systems and the major emergence of the Internet. With that, the Internet, desktop computers and local area networks became the new Goliath.  The new David was the software developer who was desperately trying to crank out products that could work on networks and the Internet.   As Goliath’s world of technology grew out of control, yet another David in the form of the project manager was introduced in order to gain control over the world of software development. 

Up until that point in time, success was measured with clarity and precision.  To the technology world and software developers, to measure meant answering the questions, “Is it working well and are the lines of code being executed?”  So the project manager was brought in to gain control over what wasn’t working. The result was a clearer definition of success in terms of time, budget and quality.  However, Goliath continued to rage on in the software development vs. project management battle, as failure reports from the Standish Group and other research bears out. 

The project manager began to partner with the business analyst. David now took on the dual roles of the project manager/business analyst and he understood the secret weapon to defeating Goliath was requirements.  Prior to that partnership, the PM was responsible for what could be called requirements activities.  When the additional role of the BA was introduced, there were two disciplines aiming to subdue the mighty Goliath. 

During the time before the BA was introduced, measurements of success and progress were relatively easy.  The introduction of the complementary BA role was as a strong communicator and facilitator, acting as the catalyst to project success.  The overarching problem is that BAs are now selling themselves short in promoting their business skills when they should actually be promoting a balanced portfolio of technical and business skills.  While facilitation and communication are critical, they are difficult to quantify. As a result, BAs risk extinction because by putting all their eggs in the business skills basket, they aren’t exercising their technical skills that demonstrate quantifiable impact.

BAs need to understand their audience when it comes to balancing business skills and technical ones.  The people who grew up in technology—project managers, software developers—are now our leaders—the CIOs and managers of IT teams who are accustomed to black-and-white quantification.  So in order for BAs to adequately sell the value and impact of their contributions, they need to speak the language of their audience, which can only be done through a balanced portfolio of competencies.  For example, as a practitioner of enterprise analysis activities, the BA can identify inefficiencies in the organization and provide direction on how to improve them.  These are activities from which impact can be clearly proven. 

Most critical to practicing a balance of competencies is understanding the BA’s business value and impact.  As an example, about 10 years ago, one of the top five banks in Canada found that its insurance division wasn’t generating nearly the amount of revenue that had been anticipated.  The bank was very progressive in its view of the realm of requirements and business analysis.  It had actually coined the term “SWOT team” for their BAs due to their ability to identify strengths, weaknesses, opportunities and threats. The bank sent in the SWOT team to evaluate all business issues related to its auto insurance business. 

The SWOT team discovered that in order to give a prospect a quote over the phone for auto insurance, it took an average of 17-20 minutes (a quantifiable metric). With further investigation, they began to clearly understand that there were multiple systems with which the call center reps had to deal that slowed them down and prevented them from handling more customers.  

The SWOT team proposed a service-oriented architecture-type system that pulled together all systems and provided access to information through a common interface that put everything on one platform.  This enabled the call center reps to dramatically reduce the time it took to provide a quote.  The resulting increase in revenue was estimated at a cool C$1 million a day. 

This example should resonate loudly with BAs.  The SWOT team didn’t go in with just their communication skills drawn; they

  • identified an inefficiency
  • did their analysis of the people in question, as well as of the entire organization
  • developed a solution that impacted the auto insurance business and drove further change in the divisions for personal, mortgage and homeowners insurance

They accomplished all of this, in addition to making C$1 million more a day.

They did it through enterprise analysis, requirements analysis, creating models, facilitation, solutions assessment and validation: in other words, a very broad portfolio of competencies. 

In Part 2 of “Are Business Analysts in Danger of Becoming Extinct?” we’ll examine the balance of competencies needed along the BA’s career spectrum

Don’t forget to leave your comments below.


Glenn R. Brûlé, CBAP, CSM, Executive Director of Global Client Solutions, ESI International, brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. A recognized expert in the creation and maturity of BA Centers of Excellence, Glenn has helped clients in the energy, financial services, manufacturing, pharmaceutical, insurance and automotive industries, as well as government agencies across the world. 

Business Analyst “Real Jobs” — Define the Problem

Business Analysts are asked to do many things: elicit, document, and manage requirements; facilitate meetings; fit/gap and feasibility studies; act as a bridge or liaison between functional and technical groups. We often look at this mix of activities and think “This is my job”. Through this series of articles, I’m going to talk about the things that a BA needs to do as part of their “Real Job”. Not just the skills and activities we practice on a day to day basis nor the tasks that we are assigned and complete from project to project basis, but the reasons behind those skills and activities; the what and why of delivering value to the business via IT projects.

Charles Kettering said “A problem well stated is a problem half solved” more than half a century ago, and it is still true today. Helping the customer come to an understanding of what they want to do and why is the crucial first step to getting a project going. Without this understanding, the project is off on the wrong foot. Sometimes, though, reaching this understanding is not that easy.

In this article, I address the perception common among BAs that “I [help] solve problems”. While this is partly true, I think that the Real Job of the BA is to help the customer accurately and succinctly define problems (or issues, the preferred term for business-side people).

How many times have you started a project where the customer asks you to implement something, and you realize it is really a solution? Do you forge ahead, holding requirements workshops and putting the documents together?  Or do you stop and ask them why they want the project, only to have them say “Because I said so, that’s why!”?

Be careful. Either approach could get you in trouble, and knowing when and how to do both as appropriate is one of the things that identifies a real BA. Which brings us back to this part of the BA’s “Real  Job”: defining the problem or clarifying the issue.

 Clarifying the issue involves working closely with the customer to understand the rationale for the project and how it fits in to the business. Whatever level you are working at in a given project, from high-level strategy to enhancement of an existing system, help the customer articulate the business value of the project by showing how it will address an issue (solve an existing problem).

There are as many levels of business issues as there are types of requirements, and in fact we can  map them nicely. I’ve created a modified version of the venerable V-diagram to show how business issues map to requirements.

SomeDudeAug30

You‘ll notice the two-headed arrows on the slide; this is because requirements don’t exist in a vacuum. In examining a requirement at any level you can turn it on its head and look at what issue that requirement is intended to address. As you dig in, be sure to ask “are we solving the right problem?” This may lead you to uncover issues at other levels; issues that, when addressed, may make the problem you are currently examining simply disappear.

Carefully articulating the issues or problems when documenting requirements can lead to improved

traceability and provide a common language when discussing matters of scope. It can also help with the all-important prioritization of requirements, that often onerous job of separating the ‘must haves’ from the ‘should haves’ and the ‘like to haves’.  Clearly, if a requirement is related to a core problem that the system is intended to address it is a must-have, while those requirements that don’t actually address an issue probably are not.

CONCLUSION: There is little business value in a solution in search of a problem, sometimes known as “build it and they will come”. On the other hand, even an average solution to a problem shared by many people will be embraced and used. Keep in mind that problems and requirements go hand in hand. Make sure that you work with the customer to understand and clarify the right problem, and you’ll be well on your way to doing your “Real Job”.

Don’t forget to leave your comments below.


Greg Busby, CBAP(R), provides leadership for  Cornell University’s BA practice, which he helped start 5 years ago. With over 25 years experience in IT, including Business Analysis, Product Management, Consulting, and Development. Greg’s focus is on establishing and maintaining the partnership between IT and business units to help ensure that technology projects support and further the institutional strategy and goals. His primary areas of interest are enterprise analysis, portfolio planning and analysis, BA/PM teamwork, and professional development of BAs. 

Celebritize Yourself

I just finished reading a wonderful book by Marsha Freidman, Celebritize Yourself,[1] which describes a three-step method to increase your visibility at work. I feel that after seven years of work in your profession as a business analyst, you should be recognized as an expert and if you are not, this book will help guide you through the process. Celebritize Yourself is about branding yourself as an expert. This book is not about becoming a Hollywood or TV reality celebrity, but about becoming recognized as an expert or leader in your field.

The three-step method to celebritizing yourself is

1. Write,

2. Speak,

3. Sell.

Write as much and as often as well wherever you can. If fact, everyone who is reading this article is invited to contribute to the Business Analyst Times website: http://www.batimes.com/contributing-to-ba-times.html about your own experiences pertaining to business analysis problems and solutions. 

The second step, Speak, is your ability to give presentations to various groups through work-related projects or organizations such as IIBA, Toastmaster, etc. Speaking in front of a group is the number one fear that people have but as a business analyst, you are expected to give presentations about your work so why not take it a little farther by volunteering to give presentations outside of your work environment. The experience will provide you the opportunity to improve your speaking skills.

The third step, Sell, is about selling yourself as a business analyst for future projects or as an authority on business analysis topics so that managers will seek out your opinions. At one company where I worked, I facilitated a weekly brown bag lunch meeting for business analysts where we could share ideas about business analysis topics within actual projects that were currently underway. This proved to be valuable to the newer business analysts and project managers, and also gave me the opportunity to write and speak.

If you look on IIBA’s website, IIBA.org, you will see that IIBA encourages you to give back to your profession by volunteering to write and speak on business analysis topics.

Volunteering activities include:

  • Willing and able to devote two to six hours per week to IIBA calls and volunteer-related work
  • Access to email, the Internet, and a word-processing program
  • Willing and able to attend committee meetings, as scheduled, via conference call or in person.

Before you start, the author recommends that you make a list of your strengths and weaknesses. What are you good at? Is it your organizational and planning skills, your people skills, communications? These are the things that come easy to you and that you thoroughly enjoy. What about your weaknesses? These are the things you struggle with and don’t enjoy and may even try to avoid or pass on to another team member. Do you need to improve on any of these weaknesses? What makes you unique from other project managers when you compare yourself to them?

Next, the author suggests you answer the following questions:

1. What’s Your Vision for Celebrity? Before you can finalize a plan, you must decide where you want the plan to take you. What is your business analysis vision? Make it simple and write it out as to what you want it to be.

2. What is Your Commitment to Your Vision? How determined are you to become a great business analyst? Do you have your CCBA or CBAP certification? Do you attend your local IIBA chapter meetings? Do you communicate with other business analysts? Do you read articles and blogs on Business Analyst Times and respond to what is written there?

3. What is Your Own Unique Message? Defining your message is not always easy nor is it always obvious. But it is important to have a distinctive message about your knowledge, experience and education. What part of it do you enjoy the most and what energizes you to perform the work that you have been assigned?

4. Why Does Your Message Appeal to You? What do you love about being a project manager? Is it the planning, the execution, monitoring and control, or is it the team members or the satisfaction of successfully completing the project that greatly benefits the organization? 

5. Why Will Your Message Appeal to Others? It is meaningless to start this journey unless your message can resonate with others. How can you reach out to others to touch their lives and benefit them regarding business analysis?

6. Who is your Target Audience? Who will benefit from your message? Is it other business analysts, stakeholders or students? Identifying your audience is the foundation for your entire plan. That is your personal marketing plan.

7. What’s Your Plan for Celebrity? The plan should contain a defined goal and specific steps that are necessary to achieve it. You should write this, evaluate it and update it frequently before committing to it.

8. When Will You Start? I assume by now that you are enthusiastic and you are thinking about starting your own celebrity journey. Here is a quote from Amelia Earhart: “The most difficult thing is the decision to act; the rest is merely tenacity.” The author suggests that you start out small and add to it as goals are achieved.

9. Have You Picked the Right Teammates? You are looking for individuals that can help support and constructively criticize you and your work. Choose teammates who clearly want to help you succeed. Embrace them and listen to what they have to say, even when it’s critical of your work.

10. How Will You Measure Success? When you consider the time and effort you will put into this, what will you expect to be your reward? Is it recognition from your peers, management or family? Is it the satisfaction of helping others? Only you can provide the answer to this question.

In summary, celebritizing yourself is not a means to an end, but it’s an ongoing journey. It is a path and not a destination. Don’t let the hard work dishearten you or let obstacles stand in your way. If you apply the principle in this article or from the book, you will find the journey becoming easier and your expectations will be met. To walk the path takes a strong commitment to develop a personal plan that can lead to a successful career while helping others. It can lead to a strong sense of fulfillment in your life.

[1] Celebritize Yourself, Author: Marsha Friedman, ISBN: 978-1-886057-20-3, Warren Publishing, Inc 2009


Steve Blash is an experienced IT professional consultant providing business and technology leadership, mentoring and vision. His areas of experience include project management, I.T. management, business process improvement, business analysis, business intelligence, data analytics and data warehousing.