Skip to main content

Tag: Career

Why I Love Being the Vendor

There are two sides to the business analysis community:  The internal business analyst and the external consulting companies or contractors … “Vendors”.  Being the internal BA just isn’t much fun sometimes and often, the internal policies and practices can work against your success.  Sometimes it’s the company itself that has created a requirements analysis gap and the individuals – however strong they might be – just can’t be successful.  Entrenched, hierarchical, corporate cultures will always work against the internal BA unless a company has made the leap to reset the value and position of BAs within this hierarchy.  In spite of all these challenges, I’ve also seen internal organizations transform themselves from being order-takers, to being considered highly valued business drivers.  So often the difference in mindset for those that succeed is they’ve started to think like vendors.

As a vendor, I get to dictate the process or our company does not do the engagement.  This is a strong position – we’ll only do engagements we know will be successful, or we (subtly) take a pass on working together.  Vendors work from a position of strength and build up our “referenceability.”  If I can say “we’ve done over 1,000 of these” and give specific examples, people generally listen when you tell them “this is the way it gets done if you want success.”  Sure, the vendor has to tune the process around the edges to improve the fit with existing internal processes and issues, but the essence of how the work will get done stays the same on every engagement.  By negotiating the process of requirements discovery up-front, by identifying precisely where additional costs might exist, or how to tune their process to meet their specific business objectives, a vendor walks into an engagement with a higher level of commitment to the process than you would see on most internal projects.  A good vendor pre-loads the deck for success by setting out process, roles, and the minimum involvement needed from stakeholders before they take the engagement.  A vendor’s project intake process is far more structured – even where we’re outsourcing and doing 20 large projects for the same client in a quarter.  A vendor can’t deviate from working this front-end because we know that eventually, if we don’t scrutinize it closely, we’re risking failure on an engagement.

Vendors have done their homework on the value they bring.  We also dedicate about 25% of our corporate resources to ensuring that people understand our value in communications and direct sales cost.  Since a decent vendor has done the research, they can prove to management what will happen in time and cost if their process is not followed.  For example, I can show someone hard data from live projects on the reductions in requirements change we bring, the timetable improvements we achieve, and how our process brings value to larger, more strategic projects.  Because a successful vendor has thought long and hard about what it does, they can be more concise and quantified about the value we intend to bring to a specific situation.  We also separate organizational value management (sales role) from value delivery (consulting function) to more deliberately manage client expectations and satisfaction.  For the vendor, high satisfaction is only achieved by a specific path, that starts with setting the right expectations on the value we bring, and ends with help people both see and showcase that they were successful in achieving their objectives.  The thinking is different: Internal analysts tend to focus on task achievement; good vendors think about value management.

A successful vendor’s delivery team has conviction.  Conviction is that deep-seated belief that a process is going to be successful IF an engagement is conducted a certain way.  You can have business analyst training until you are blue in the face, but unless there is the absolute belief that the new techniques will be successful, these techniques will not used.  Vendors make people document the success stories and show these to the new consultants.  At our organization, we make sure that people know that the process has worked over 1,000 times successfully, and we take the cost hit to put our new people on airplanes to observe an engagement done by an experienced team, so that they can success for themselves.  We also get them to co-pilot an engagement with a successful user of the methods before we ever let them go solo.  All this effort is part of building both competence and conviction.  At the end of the day, a vendor can only be successful if every person on the delivery team is able to do the methodology in EXACTLY the same way and get a consistent result.  In our world, there really isn’t a second chance – we do exceptionally well, or we get fired.  Analysts follow the process a vendor dictates not simply because they understand it, but because they absolutely believe that they will be more successful if they follow it.  The path to developing skills is fairly straightforward.  The path to getting consistent execution is much more complex and relies on first building conviction.

I like to relate success and momentum in general within organizations to a big, heavy, flywheel.  A big success gets the flywheel turning a little.  Get a bunch of successes… and the wheel turns a little faster.  The flywheel is an analogy for a cycle of positive change where small, incremental steps lead to momentous change.  If I go back 10 years, our company tended to do smaller engagements of one or two weeks and we really did not pursue large-scale engagements.  Today, it’s the inverse – our teams tend to be engaged on extremely large and complex projects, and the smaller one- or two- week engagements are a smaller proportion of our revenue.   Vendors must deliberately manage momentum.  With positive momentum, the strategic focus of the organization shifts over time.  An organization with no positive momentum offers basically the same value to the organization year-after-year.  A vendor can’t simply say “our strategy this year is to do more BA stuff”.  In the vendor world, clients can be a bit ruthless, so vendors must either show momentum and continuously strengthen the value proposition, or wane in importance as service providers.

A vendor as specialized as we are (we only do business requirements) lives or dies by how we scope and size an opportunity, and how we determine the optimal process, plan and strategy to recommend for a requirements engagement.  We simply cannot miss when doing estimation – ever.  In fact, in the last bunch of years, I can’t remember sliding over-budget on an assignment.  We have to closely manage the number of client days used on an assignment and commit in a statement of work that we are going to produce “X” deliverable in “Y” days.  Most analyst organizations really do not manage client expectations on the number of days required to do requirements.  In fact, a mere 25% of organizations we recently surveyed accurately estimated the amount of time needed from the stakeholders. The rest underestimated by an average of 192% (get the results from http://www.iag.biz/).   How do you expect to maintain stakeholder involvement over time if the team consistently overruns expectations by almost 200%?

Finally, vendors get access to all the neat toys.  It is perhaps one of the bi-products of working with so many clients that you see what is working and what’s not, but more importantly, a vendor has a deliberate R&D focus to continuously look at new methods or technologies and see what makes them tick.  It’s neat to get a freebie copy of the latest and greatest from a tools vendor like RavenFlow and fiddle with it on an engagement.  Having a substantial R&D budget for BA best practices and technologies development means the vendor is able to get ahead of changes in client demands and talk to them about how, for example, agile methods can be made to work well on very large scale engagements.  Having an R&D sandbox in which to play with new technologies and methods may be fun, but candidly, it’s the only way to determine the practical application of these technologies and methods, and help the organization develop the value it brings to clients.  In fact, internal business analysts and vendor organizations both have access to the toys, the question is, is there a managed process to turn that access into value?

Are these lessons from the vendors well implemented in internal business analyst organizations?  Take a little test:

  • Do your BAs take enough time negotiating the process of requirements discovery – especially on strategic projects – to ensure success? 
  • How good is your organization at selling your process internally?  Do you measure or manage the value delivered to the organization?
  • Do you have consistently high quality requirements from all BAs?  Do your people have conviction that they’ll be successful if they follow your internal process?
  • Do you have strong momentum?  Consistently enhancing value brought to the organization – and an expanding budget/mandate?
  • Can you accurately forecast (+/-10%) the number of days needed for conducting business analysis and in creating business requirements?
  • Do you have a practical, managed process for BA process and technology R&D? 

If any of the answers are “No”, ask yourself, “why not.”  Why not force your BAs to do better elicitation planning, or publish your success stories, or benchmark your team against best of breed performance to showcase their strength?  Maybe you already have strong momentum.  But, maybe, you’re looking for ways to build that momentum and acting more like an external vendor is the path to help get you there.


Keith Ellis is the Vice President, Marketing at IAG Consulting (http://www.iag.biz/) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007.  Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the market strategy of the global outsourcer CGI in the financial services sector.  Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

The Strategic Role of the Business Analyst

The new role of the BA is far more strategic in both the organizational sense as well as at the project level.  In fact, I would go as far as to say that the BA, when appropriately leveraged, represents a liaison between business, project and customer teams.  This shift in responsibilities identifies two areas that need to be addressed by any organization seeking to expand this role:

  • The organizational structure must support the actions of a “strategic” BA position
  • The BA candidate must have wide skill sets, encompassing many general management competencies

As organizations shift to become “projectized,” the roles and responsibilities that have supported projects within a traditional matrix structure must shift as well.  Over the years we have seen organizations struggle with the following challenges related to shifts in both structure and culture:

  • Broken or disjointed cross-functional communication channels
  • Uncertainty around roles and responsibilities within the project structure and beyond
  • Quality concerns at the point of project delivery
  • Skewed scope statements and thus implementation plans due to early stage breakdown
  • Overall loss of productivity on project teams due to lack of continuity and methods

The items noted above are telltale signs that several strategic components of a best practice project management environment are missing.

Forward looking or “best in class” organizations have aggressively embraced the concept of the BA role.  And, what sets them apart from the old school thinking associated with this job title is the escalation and expansion of the roles, definition and responsibilities.  Not too many years ago a BA may have been confined to a very technical role within an IT environment working on specifications, functionality and even some quality and testing related to one or more project life cycles.  Today, we are seeing BA positions filled from across the organization and expect that this trend will continue, as it should.

Let’s address these points built in the context of how they can be leveraged to meet the challenges:

Broken or disjointed cross-functional communication channels
A BA should be in front of any project communication produced from the point of team inception to the close-out phase.  This interaction does not mean that the BA takes on the role of project manager (although we have seen organizations combine the two roles), as it is not effective on larger and longer term initiatives.  Our experience shows that an independent BA position can help to promote better communication, align protocol and help the project manager to extend his/her reach into the project teams.

Uncertainty around roles and responsibilities within the project structure and beyond
The BA functions as a tour guide through the project plan ensuring that all of the moving pieces are touching at the right points.  We call these critical communication points and they can be built around time, budget or deliverable expectations.  The BA will be assigned a protocol map within the project structure to enable them better access to expectations and provide for a proactive way to reach team members.

Quality concerns at the point of project delivery
In reality, the BA is monitoring quality points through the project life cycle thus producing a quality product at the close of the project.  Very much like the thinking around proactive quality control, the BA is in front of each deliverable and monitors the progress against the project plan. This allows for immediate communication between the project manager, customer and associated teams.

Skewed scope statements and thus implementation plans due to early stage breakdown
The planning stages of a project are obviously critical to the implementation plan and ultimate quality.  A BA should be assigned early in the process and work hand in hand with the project manager to ensure the highest level of intimacy with the plan.  And, just as importantly they need to have a direct connection to the internal and external customers in order to ensure collaboration and proactive attention to emerging issues.

Overall loss of productivity on project teams due to lack of continuity and methods
A strategic BA assists the project manger and PMO with the execution of best practice within an organization’s project management structure.  The BA has a unique opportunity to guide the process through an existing methodology and essentially help the project to operate in better alignment.  This is accomplished by having a dedicated individual who is consistently working against the deliverables and is not distracted by the operations management associated with the project manager’s job.

By taking the above steps you have begun the shift toward the organizational structure needed to take advantage of the BA position.  With that said, we still have one more change to make in order to secure success.

It is obvious that the BA role as defined in this article will require wider skill sets than the more traditional BA position still driven from the IT departments of yester year.  To that point we have begun to see a trend where the BA position can spawn from either business or IT.  This is an interesting point as it speaks volumes to an organization’s maturity around project management.  Imagine, for just a moment, an organization that has no boundaries within in its functions and everyone on the team collaborates against a common goal.  I like to call this organizational desegregation and cultural morphing.  As we begin the next phase of benchmarking the project management industry and clients, we are beginning to see this shift as a representative of the next wave of advancing thought in the project management space.  It was not too many years ago that I published an article on the emerging role of the project manager as the CEO of his/her project.   I am confident that the BA role will take a firmly positioned spot in the upper hierarchy of any world class project organization within the next few years.

In order to succeed the BA will need to have a competency profile that meets the following criteria:

  • Excellent understanding of both business and technology within the project environment.
  • Be a leader, communicator and professional.
  • Understand the skills associated with internal consulting techniques.
  • Be proficient in project management skills as well as complete understanding of the internal process.
  • Epitomize the essence of a collaborator and team player.
  • Understand and be able to navigate your organization’s politics and structure.
  • Be able to manage, without having authority, via negotiation.
  • Understand true stewardship-based service.

So, the BA role probably looks a little different than a traditional structure may have dictated.  Yet, this is the trend and I believe will become the norm.  As organizations look to enhance productivity and quality while reducing cost they are finding this role to be ultimately important.  Additionally, project managers we spoke to during the research for this article all stated that having a BA on the team made their job easier and allowed them to focus on deliverable based activity.

It is important to note that this type of structure is recommended for mid to large size projects, but on the smaller initiatives we found that these attributes were part of the project manager’s role.


Phil Ventresca, MBA is Founder, CEO and President of Advanced Management Services, Inc. (AMS), http://www.amsconsulting.com/, a full service management consultancy servicing an international client base.  Phil has utilized his extensive background in management and consulting to lead AMS to its current status as a multi-million dollar enterprise with an international customer base.  He has led the organization to recognize several strategic breakthroughs such as developing partnerships with distance education providers, software developers and publishers.  Through these efforts, AMS has emerged as a leader in consulting, training and assessment services.

His entrepreneurial spirit and keen business insight has benefited many organizations through his consultive engagements with clients such as Boston Edison, ADP, State Street Bank, Cabot Corporation, Merisel, Data General, Simplex, AT&T, BIC, Bank of Montreal, Kronos and others. Phil is an adjunct faculty member at Boston University’s Division of Extended Education. He is responsible for the development and delivery of a project management curriculum to varied international client base as well as a contributor to a unique leadership development program. Phil can be reached at [email protected] or 781-828-8210.

BA Rising

So, last month I covered Business Analysis, and How I Came to Realize What It Was And What It Meant. This month, I want to go more into what it means, and why the increased influence of BA (and the CBAP certification) is so important.

The short version is this: Systems are increasingly important in our quality of life (are you on the no-fly list yet?), and good BA leads to good systems, bad BA leads to Gartner and Standish Group negative statistics (if you don’t know what these groups do, Google them). BAs don’t always have the influence it takes to prevent these bad outcomes, but they should, and they will, now that the IIBA has established some neutral standards.

So, why BA – why can’t we build good systems without it? PMs are trained to deliver on time and under budget, so what’s the problem? (Hint – How hard is it to deliver on time and under budget? How much have you got to spend by when?) If you read the literature, you will see that MOST causes of project failure are related to stakeholders and requirements. These are failures of BA, by definition of the profession, and by default since they are not key to PMI.

I want to make the statement that the techniques of BA work because they are exactly those of due diligence. Sometimes we say that BA is just common sense, then laugh when we realize how uncommon it is. Due diligence IS common sense. Surely no one objects to due diligence? Indeed, why should anyone be concerned about the rise of due diligence? Isn’t that for dullards?

Before anyone spends millions of dollars (or even thousands), or takes any risk of consequence, it pays to do some amount of homework. If the homework seems overwhelming, expensive, or incomprehensible, that just means that the first 10 hours of homework are VERY important. They may be even MORE important than the next 100, or even 1000 hours. There is a LOT of earned value in doing ANY thinking versus none. Once thinking gets to thousands of hours, there is increasing risk of ossification, and the benefits diminish. In spite of this, a common complaint is “We don’t have time for analysis,” as if none were better than too little.

A common project mistake is to assign too much earned value to development, and not enough to analysis. Million dollar mistakes rarely happen at the field definition level, and are typically easy to explain and correct. This is true in spite of the fact that a significant percentage of labor and time may be spent on field level issues, or other technical concerns. Most of the value and risk control in the project may go to the first hours of analysis, with the development being quite low risk, as the “big” problems are actually resolved. It pays to control costs with analysis, and does NOT pay to control it with code change control.

This seems obvious enough, but analysis is overlooked and under-respected on more than a few projects – witness the 35% success rate of projects!t is, in fact, overlooked by the society in general. My father was once a Quality Analyst for a bank. “What do you do?”, I asked? “I make people think.”, he said. “Thinking is painful, and left to themselves, many won’t do it.”

Hmmm. The problem is, that the lax attitude about thinking is due to the illusion that we understand something is so strong. “I’ve been doing this for years, I know what to do!” In effect, EVERYONE thinks they understand, therefore, there is no need for an analyst – no one is (admits to being) confused – that would be awkward, scary even. In my experience, EVERYONE thinks they are THE analyst. It is, apparently, a strong hero role, even if we are only legends in our own minds.

Think about George Washington, fighting a desperate and losing war with England. In the midst of his desperation, he invented enterprise analysis, from a sheer common sense need – “What does the continental army consist of, what is it not, and what can we do about it?” That is bravery, true action, in the face of seemingly insoluble problems.

Imagine making these decisions without a sense of the whole enterprise. Imagine making these decisions under illusions of how coherent the enterprise was, instead of basing them on the best intelligence available.

Imagine pushing resources around “just because you can”.

And if you want to imagine those things, just imagine working on any project for the last 100,000 years, because human nature is such that it prefers illusion to facts, egos to inventories and simplistic principles to problem solving. Our progress comes in spite of ourselves, because nature supports common sense, and punishes lack of care.

The saying that ” common sense is none too common,” applies especially to BA. BA is the refined, professional level, experience based, highly predictive form of common sense. BAs don’t cite common sense; they practice it. They practice it because they are willing to learn, and think, in spite of the petty discomforts.

An example of how rare common sense actually is: Everyone knows you have to think of your customers to have a successful product (at least everyone would select it correctly on a multiple choice test). In spite of this fact, IBM was able to release the PCjr, with no applications that anyone cared about. IBM followed this up by dissing any employees who pointed out the problem. IBM’s slow decline in the late 80s and early 90s was inevitable, and that IBM no longer exists.

Professional BAs really believe in practicing due diligence, because they have seen what happens when you don’t. They are not in denial, and not afraid of the truth. They believe it, and live it, where others don’t, for whatever reasons. YES, they can see the future, because they remember the past.

In a world where “doing it because you can” is the message from the top, it’s easy to abandon due diligence – the paychecks can flow for years sometimes. It is much harder to adopt the Quixotic position – things are worth saving, improving; the world deserves to be a better place.

Given the importance of systems to the state of the future world (identity systems, micro-cash, medical imaging, health management, internet security, etc.), does anyone doubt that they want BA to rise?

This is an important question, for the following critical, political reason: If BA represents stakeholder value, doesn’t that mean that the Project Manager actually reports to the BA, instead of the other way around? Why or why not? Don’t most PMs wish they had a better handle on the requirements before the deadlines and budgets are set? Stay tuned.

Our society has hardly started building systems. We have traffic managements systems to build that will save lives, medical management systems that will empower patients, and identity systems that benefit the users (us) as well as the implementors (them?).

If anyone is against BA, they are against common sense, stakeholder interests, due diligence, and successful outcomes for a democratic society. If you are out there, and don’t want to play, please stand up, so the rest of us can work around you.

BA Rising

This is the first entry in Marcos Ferrer’s blog, BA Rising, an an ongoing series where Marcos shares his views, observations and thoughts on business analysis – and would like you to share yours.

When I was young, I asked my dad what he did at work. “I’m an analyst”, he responded.

In the course of my career I have run into (and sometimes been grouped with) systems analysts, financial analysts, organizational analysts, sales analysts, marketing analysts, computer analysts, network analysts, security analysts, user interface analysts, software analysts, investment analysts, business analysts, enterprise analysts, quality assurance, analysts who analyze analysis, psycho-analysts, and probably others.

Needless to say, my father’s answer, back then, didn’t provide much insight as to what he did to keep the family going. In fact, at the time, I didn’t give it any thought at all. Most of the analysts seemed like people who knew some stuff about some specialty, that’s all. Most were pretty smart, but not all.

Nor did it make sense that in my time there, IBM called me a Systems Engineer. Yet, It didn’t bother me; I figured they knew what to call it. Still, it didn’t feel like engineering. To me if just seemed like a bunch of things to know about computers – and the world – that let you help your customers. Some of it was just knowing that large inventories at year-end were financially punishing to businesses that had them. Some of it (e.g., correct balanced systems and network configuration) was stuff that customers could have figured out for themselves, if IBM had provided the means on-line. Instead, IBM’s engineering support systems gave me information power with my customers, and I used it to leverage information out of them concerning their business interests, becoming an analyst without knowing it.

When Mendes Worldwide (high tech bowling company) called me an Industry Rep, again, it didn’t bother me. They must know! When a client of mine installed the world’s first fully automated duckpin bowling center, after a year of negotiations and Excel “what ifs” with Duckpin industry officials, Duckpin Bowling Center proprietors and potential investors, someone said to me that I must really know the business. Again, I was operating as an analyst, without even knowing to call it that.

What I figured out later (when I found IIBA) was that I was practicing business analysis the whole time. I just didn’t know it was business analysis. I know I didn’t know, because every boss I ever had (except one) challenged me by spluttering “What are you doing, why are you doing that?” And with comments like, “don’t let me catch you doing that ever again!” And I never knew what to say except “But, it’s working!” and “I promise you‘ll never catch me doing that again!”

Over time, I met other people who made things work. They made them work well. They were different from the ones who made things look good. The “look-gooders” made things look good just long enough to get promoted, so someone else would actually have to fix the mess. A small number of people seemed to be able to make things look good AND make them work. All these people seemed to be CEOs; high-level executives, but certainly not business analysts.

What the “make things work” people did, always made sense, got results, and allowed energy time and resources to complete tasks and quickly focus on new opportunities,

In a word, these people left things better than they found them.

That was not easy at IBM, nor is it easy in organizations of any size larger than, say, one person. None of this was identified with business analysis, or analysis of any kind – at least not by my bosses at IBM in 1983 – this changed later.

The Eureka moment for me came while I was consulting with DOL as a client/server analyst. Peter Gordon introduced me to the International Institute of Business Analysis (IIBA, www.theiiba.org). I read their material, and then their Book of Knowledge (if that sounds pretentious, remember that it is really the Business Analysis Book of Knowledge – BABOK – the name adds a little humility, in my opinion, and all to the good).

The IIBA BABOK had summarized (it is still a work in progress) all my knowledge and more techniques than I had ever heard of, but it all made sense – anyone trying to “git ‘er to work” instead of just “git ‘er done”, might do exactly the things listed in the BABOK.

Business analysis meant thinking/being thoughtful! That’s what first attracted me to IBM – the motto – “Think” – and what chased me away later – the lack of actual thinking. Business analysis is what one does, if one really cares about achieving the outcome! Risk analysis doesn’t pay if you will get promoted regardless of project outcome. It only pays if you care, AND if you use it wisely, for issues that the project can truly affect. Anyone with major meteor (>50km diameter) strikes in their risk plan is obsessive, not thorough, and not to be admired, as they have no concept of risk vs. cost. Anyone considering small (<.0.1m diameter) micrometeor strikes, is working on space travel, or is also (frankly) screwy.

Now that I realize my “common sense” skills, that I took for granted and have used during my career, really consisted of BA practices and CBAP standards, I’m hooked. Stay tuned. It will hook you too. Imagine a world where stuff worked better – stuff like medical care, flight safety, telecommuting, war plans, credit protection, law enforcement, more.

Remember, there is strength in numbers – the more CBAPs there are, the better our chances of being heard, and making the difference that is so needed. Join us, or give up and be a spectator. I know you will join, because if you could help it, you would have quit this complex and difficult career long ago.

Again, welcome, and please share your thoughts with us.

, is an experienced teacher, public speaker, and instructor with ESI International. He has over 20 years of experience in the practice of business analysis and the application of Information Technology for process improvement. Mr. Ferrer began his BA career in 1982, while still a student at the University of Chicago, when he developed a consulting practice (he didn’t know it was BA then) with local property management and accounting firms. After graduating in 1983, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in a number of different fields. In 1990 Mr. Ferrer became an independent consultant, again working with a variety of customers, most notably in the Family Entertainment industry. He has also worked on multiple government systems projects and “business” projects, including A-76 work.

In November of 2006 Mr. Ferrer became one of the first 16 CBAPs certified by the IIBA. He has served as VP for Certification at theDC-Metro chapter of the IIBA, and is speaking publicly and promoting certification (CBAP) on behalf of that chapter (www.iibadc.org).

Copyright 2007, Marcos Ferrer. All rights reserved.
07/27/07 


Marcos Ferrer, CBAP

How to Become (or Manage) a Successful Business Analyst

Completing information technology projects on time and on budget is both essential and a struggle for most organizations. Business analysts can help shepherd projects through to successful results by gathering requirements from a business area and presenting them in ways that are understandable and actionable by the organization. Unfortunately, the business analyst’s job description is often vague. While many organizations know what needs to be done, they don’t know how to identify and develop the skills necessary to meet these needs.

As such, we’ve outlined here eight essential competencies necessary for success in this job. For each competency below, we explore the skills, knowledge and abilities inherent to each competency and provide practical tips for using these competencies as guidelines for improving the efficiency of business analysts within any organization. By definition, a competency is made up of three components: knowledge, skill and ability. Knowledge considers “what is being measured?” Skill looks at “how is it done?” Ability examines “to what degree can it be done?” 

Competency #1: Eliciting Requirements On the most basic level, the business analyst’s job is to gather and document user requirements. Requirements are needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of business, rather than the constraints imposed by technology. This means that the business analyst’s job has more to do with identifying the desired results than the actions or resources required to reach these results. The purpose of gathering requirements is to provide an understanding of the problem or opportunity before trying to propose the solution. 

Competency #2: Creating the Business Requirements Document A Business Requirements Document (BRD) is an exhaustive, written study of all facets of regulatory, business, user, functional or non-functional requirements. It is a detailed profile of primary and secondary users and comes directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD should be written by the business analyst. After the document is completed, the business analyst and the client, or user, meet for a formal review and to formally approve the BRD. The document is then shared with the rest of the development team, including the project manager. In creating the BRD, a business analyst should define the various sources for requirements and the placement and relevancy of these requirements. 

 

The Essential Business Analysis SkillsAnalyze & solve problemsUnderstand the businessCommunicate effectively (write & speak)Manage client relationshipsFacilitate discussionsNegotiate & build consensusModel data & processesPlan & manage activitiesFacilitate & develop business strategyUnderstand & manage organizational change

 

For example, senior business analysts may identify such items as the project charter and vision, business case, requirements work plan, vendor request documents and business contract documents. They may also work with the project manager to define the project and product scope. Any requested changes to any area of the BRD, before or after work has begun, must be carefully reviewed by the business analyst who would then work with the client or user to make the necessary changes. 

Competency #3: Modeling Modeling refers to the ability to conduct structured analysis. In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organize information into coherent ideas. The most common types of business analysis models include business models, process models, data models and workflow models. Experienced business analysts develop models such as business interaction charts or entity relationship diagrams and examine how the business process works now, in order to develop improved charts and help troubleshoot in the future. When looking at models, the business analyst is looking for problems and opportunities that will change the process or the deliverable. 

Competency #4: Object-Oriented Analysis An object model is an abstract representation of the process and data requirements of a system, based on separating the system into units called objects. Each object includes the data and operational characteristics of one business item. Object-oriented analysis is particularly important to business analysts as a business planning tool to depict the hierarchy of business functions, processes and sub-processes within an organization. Generally speaking, individuals working on object-oriented analysis should be competent in structured analysis.Object-oriented analysis requires a clear understanding of both the process and data modeling techniques, including the ability to separate systems into objects. Junior business analysts may get involved in the functional separation of the as-is state of a project, including forming a simple model of this state. From this model, an intermediate business analyst may consider developing activity diagrams to further clarify requirements. With diagrams in hand, a senior business analyst is likely to begin designing the to-be state during one-on-one interviews, group interviews and the documentation process. Essentially, each of the processes involved in object-oriented modeling ensures that the requirements are properly communicated to the developers and administrators. 

Competency #5: Testing When it comes to testing in business analysis, the first thing to understand is that the term applies to several different levels of work. First, business analysts are looking to test the products to validate whether the requirements have been met. They develop test scripts, test plans and test scenarios based on the as-is state as well as the to-be models. Testing requirements should be done in recurring stages to ensure that, by following the requirements, the desired deliverables will be met. The second level of testing is more familiar. This is testing the functionality of the physical product – testing lines of code and user testing of graphical appeal, speed and functionality. Black box testing and glass box testing fall into this category. As with the first type of testing, this testing also makes sure we reach the desired state, but it is based on user acceptance. In testing situations, business analysts design test cases and review the results from these scenarios. 

Competency #6: End-User Support It’s a common misconception among project teams that the project ends when the deliverable is completed. This isn’t true. Business analysts should be aware that end-user support after the product is delivered is almost as important. The role of the business analyst is not to act on behalf of the training team, but to complement the training team’s efforts with their knowledge of the business requirements. Much of the documentation created in the process of identifying the deliverables is invaluable to the development of training needs and end user support, including user manuals and reference materials. Business analysts work with end-users after deployment to clarify any high-level questions that need to be addressed. They also work closely with training managers and facilitators to define requirements to deliver the training supporting the business needs. Finally, business analysts assess and evaluate all feedback from team members, those individuals involved in the deployment of the product and any pilot or “test” groups, to ensure that the requirements necessary to correct any issues are addressed in future releases, iterations or versions of the product.   

Competency #7: IT Fluency How much IT knowledge is enough for a business analyst? The IT background for a competent business analyst depends entirely on the environment and possibly the industry vertical within which he or she works. It’s important to remember that IT fluency is just one of eight competencies that a successful business analyst must have. Also, just because an individual is fluent in a given technology does not automatically qualify him or her as a business analyst. This is a mistake made by many organizations. In theory, a great business analyst should have the wherewithal to understand which resources would be appropriate to help define and validate both requirements and specifications within a given project and product scope. In examining the different stages of a business analyst, a person at the junior level would need to have a clear understanding of the IT products and tools necessary for the business to function. An intermediate business analyst may understand interconnectivity and relationships between the tools and, perhaps, system architecture and information architecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical. He or she may also have a very clear understanding of how different IT products are related, interface with and connect to each other, as well as the positive or negative impact they may have in a given situation. 

Competency #8: Business Process Re-Engineering Considered the “big-picture thinking” of business analysis, Business Process Re-engineering (BPR) is a rapidly growing part of business analysis. In fact, lately many companies have been grouping business analysts around this specialty and developing teams of process analysts. This is the phase in which business analysts seek out both problems and opportunities. BPR uses a variety of modeling techniques in order to look at the bigger picture, while still thinking tactically. Business analysts’ responsibilities are often to identify, using various modeling techniques, possible areas of improvement to walk the client or user through each step of the process, examining individual tasks that could potentially be improved and then to actually make suggestions for improvements. 

You’ve Defined the Competencies . . . What Next? Now that the competencies have been spelled out, how do companies go about developing business analysts? First, they must develop and document specific job functions, and the task or tasks related to a particular level of competency. Next, they should assess existing knowledge. Finally, they must provide the training needed to develop the competencies outlined above. The first step in ensuring that an organization’s business analysts have the knowledge, skills and abilities necessary for success is to develop job functions, associated tasks and activities, and expected inputs and outputs, that would in turn support an organizations defined competency. When job descriptions have been determined and approved, it’s essential that organizations “take inventory” of the competencies their business analysts already possess. There are specific assessments to test these competencies. Such tools will establish the knowledge level of individuals in each competency area and of the team as a whole. If knowledge isn’t base-lined, improved cannot be observed, and overall performance for the individual and the organization. After establishing the business analysis knowledge and ability levels within an organization, the next step is to implement training to improve any competencies that may be lacking. The competencies above can also serve as a validation tool for such training. They can be used to ensure that the performance improvement program is comprehensive, that no behaviors or competencies are missed, through proper training, on the job experience as well as the appropriate coaching and mentoring. Keeping in mind the eight competencies, as well as the necessary people, processes, tools and technology, will put an organization on the path to better business analysis and, ultimately, to more successful projects.