The Community Blog for Business Analysts

Jarett Hailes
Jarett Hailes

Why Business Analysts Should Not Perform Quality Assurance

I seem to find quite a few job postings for Business Analysts that have a couple of lines in the ‘tasks to perform’ description that scare me like:

  • Define test strategy and test plan
  • Develop and execute test cases
  • Perform stress and load test scenarios

It’s not that I don’t believe I am capable of these tasks at some level of competence; after all most BAs have had to perform these activities at some point in their career.  I don’t believe a BA should be expected to do Quality Assurance tasks.  I can understand the temptation to leverage Business Analysts to perform Quality Assurance tasks, namely:

  • BAs already have a good understanding of requirements, use cases, etc. so it should be easy for them to come up with testing approaches and test cases
  • BAs are ‘analytical’ in nature and thus are well suited to QA activities
  • After the requirements are done BAs just typically sit around or are moved to another project, so we might as well give them something to do so they can be with the project for its entire lifecycle (and be held accountable for ensuring in the end user needs are met)

While these arguments all have some level of credibility, I don’t believe that having BAs perform QA tasks should be considered good practice.  Don’t get me wrong, I believe that BAs need to work closely with testers to ensure that requirements are well understood, that requirements can be traced end-to-end, and to help facilitate discussion amongst the team to develop a testing approach.  I don’t even mind having to execute test cases if the team’s in a crunch and need some more people to run through scenarios.  But overall, I believe that having a Business Analyst being in charge of testing activities (especially if it’s on the same project as doing BA tasks) is not a good idea for the reasons I discuss below.

Quality Assurance is a Separate Role

As the BABOK V2.0 has so eloquently stated, Business Analysis is about working with stakeholders within an organization to identify solutions that will help the organization meet its goals.  The BABOK barely mentions testing, only to indicate that a Tester is “response for determining how to verify that the solution meets the requirements defined by the Business Analyst.”  These are two distinct roles that while they involve leveraging common knowledge and artefacts (e.g. requirements) they definitively involve disparate activities, techniques, and tools.

Quality Assurance is its Own Profession

Not only is QA its own role, there are organizations that promote the tasks performed by testers as its own profession.  There are even separate bodies of knowledge, designations and certifications that have been developed around QA activities.  Like any profession it takes time to become adept at performing QA tasks, just as it does to become proficient at BA tasks.  

While individuals may develop expertise in both Business Analysis and Quality Assurance over several years (in which case they can perform either role) it is unlikely that most BAs have the level of knowledge to adequately perform QA tasks.

Bias Inherent in Performing Both Roles

For me this is the most important consideration – if you are the Business Analyst (or one of the BAs) involved in the gathering of requirements, you end up developing certain biases based on your knowledge of the business and the problem(s) that are to be solved by the solution being developed.  Such biases are rarely at a conscious level, but do occur frequently. 

The BA can become so intimate with the requirements that they may not realize when certain assumptions are undocumented, or may unwittingly ignore certain paths or scenarios that need to be tested because they understand the recourses that can occur in those circumstances.   In essence the BA may become so ‘in tune’ with the requirements as documented that they may omit or neglect circumstances or exceptions in testing plans that need to be considered.  An unbiased third party without such intimate knowledge would have a much easier time to spot any inconsistencies.

Such biases can impact the veracity of testing activities.  For example, if the BA starts to write test cases based on what’s in their head rather than what is documented, traceability can become an issue.  If the BA omits certain test case scenarios since they know that they are unlikely to occur, are not documented, or the BA already knows how the system will handle the scenario (since they saw it at the last demo), then not only is the current testing phase impacted, regression testing on future changes to the system can become compromised.

Lost Opportunity to Have Another Set of Eyes in the Process

As noted above, a BA can form a biased view of the solution and the project based on their work and job duties.  It never hurts to have another brain in the fold that is tasked with, among other things, finding holes in documented processes, looking for requirements that may be under-developed, and generally ensuring that the solution is free from issues that would cause stakeholders to reject it.  There are few downsides to including another person given the risks inherent with one person performing both sets of duties.

Get a Tester

Overall, if your organization has the capacity to have dedicated Quality Assurance professionals they will pay for themselves in spades (just as Business Analysts do).  Using BAs for testing purposes may seem like a slick thing to do, but in my opinion it is almost never the right choice given the option to go with a separate individual.

What do you think?  Leave a comment and let me know your experiences.  Have you been a BA who has been forced into QA duties?  Do you think there’s no issue with someone doing ‘double duty’?

This entry was published on Jan 05, 2010 / Jarett Hailes. Posted in Testing & Quality Assurance (QA), Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  4 members liked this article

Related Articles

COMMENTS

rajanh posted on Thursday, January 7, 2010 12:03 PM
Article is well written though I may not fully agree with the author. Here is why (in response to the authors argments)

1. Quality Assurance is a Separate Role - to put is simply, I see no reason why a capable person cannot take on multiple roles. Quality assurance is not a complete paradigm shift....

2. Quality Assurance is its Own Profession- maybe ...maybe not.... there are numerous s/w professionals performing both analysis and QA (for that matter development and project management). Although I agree the larger and complex the systems are, it is better to separate this as its own profession

3. Bias Inherent in Performing Both Roles: The argument given by the author "The BA can become so intimate with the requirements that they may not realize when certain assumptions are undocumented" can be solved by having peer reviews by fellow SAs (or Dev or QA) . It doesnt necessarily take a QA person to point out deficiencies in a systems analysts' specifications, it can be done by other people too.

4. Lost Opportunity to Have Another Set of Eyes in the Process: Agreed, but an SA can perform the QA testing for another group hence he/she is the other pair of eye and vice versa.

5.Get a Tester : A tester who simply executes test cases still needs someone to think things thru and develop the test cases.

So overall, re-iterating myself, while it is good to have separate people perform separate functions in the s/w development process, I see no reason why roles cannot be interchanged or overlapped.







Jarett Hailes posted on Thursday, January 7, 2010 9:40 PM
Hi rajanh,

Thanks for your comments, I appreciate the feedback. With respect to your comments:

I agree that an individual can play multiple roles within a project, and often has to on small projects. My issue is that many organizations seem to assume that a Business Analyst is also a de-facto QA person, when this is not the default case. While QA may not be outside of the realm of BAs with a technical background, for other fully qualified Business Analysts with little to no technical training this could be a great stretch, but has nothing to do with their BA skills. If an organization needs a person with both BA and QA skills then the title of the job description should say such.

I agree that if the BA who performed requirements gathering and writes test cases for the same project the bias can be mitigated by having outside reviews and the like, but I would wager that the reason the BA is performing double duty is because there is an insufficient skill set within the project/organization to support having another person work on the testing aspect. Perhaps developers from other projects could assist with this review process, but realistically if they have this type of time available I'd ask them to write the test cases in the first place (after all, a developer role is even closer to a QA role in many respects).

Perhaps my language is incorrect - when I mean execute the test case I mean go through the steps that have been indicated in a fully fleshed out test case verbatim. I often have clients perform this task prior to UAT so they can become familiat with the system and at the same time have feedback. You shouldn't need any special expertise in order to do this step, if the test case is written correctly and the environment is set up properly.

Thanks again for your comment!
David Wright posted on Friday, January 8, 2010 9:47 AM
I have ranted/written on this topic elsewhere, and I am with larimar on this topic. However,some new thoughts have come to mind today...

-Most projects enhance current systems, only a few create brand new systems.
-Testers don't test requirements, they test systems to see if the systems have been enhanced properly to meet the requirements. This does require some knowledge of the systems
-Many projects define requirements that affect multiple systems, which may not be clear until design is done; different testers will do the testing based on system knowledge. A BA without system knowledge would be much less effective than a tester with systems knowledge.

So, the testing role in most companies is associated with the systems they test, not the business area or requirements. I know because I have worked as a BA with good testers, who knew what strategy and test plan/cases would be need based on receiving requirements that affected the systems they test. There was no way I could match that knowledge/expertise just because I had developed the requirements.

My last and consistent point is that if you are doing more than one job, you should get more that one salary...
rajanh posted on Friday, January 8, 2010 7:34 PM
My simple observation is - If a peron is qualified then why shouldnt they do it ?

And I totally agree, if they are doing more than one job then they shud get more than one salary.....
David Wright posted on Friday, January 8, 2010 8:53 PM
"If a person is qualified then why shouldnt they do it ?"

Sure, that is true for such a person.

The point here is: Being a qualified BA does not automatically make you a qualified Tester.
rajanh posted on Friday, January 8, 2010 9:20 PM
"The point here is: Being a qualified BA does not automatically make you a qualified Tester. "

I never said that....

But if a person is qualified to be a BA and QA person then why not...

You cannot generalize things...that BAs shouldnt do QA work or Developers shouldnt do Photography or etc etc...you get the point.
The Cynical BSA posted on Monday, January 11, 2010 2:56 PM
Is it not a reflection of organizational immaturity for an organization to combine such roles?
Jared posted on Tuesday, January 12, 2010 12:27 PM
I couldn't agree more with this blog entry. Best practice is for the Business Analyst not to perform QA testing. That being said, every company doesn't follow best practices and certainly not on every project.

I am capable of performing QA testing but then again, so are many others. Why does it necessarily fall on the Business Analyst to perform the testing? Wouldn't the developers or the solution architects have the necessary skills to do so in addition to me?

"If a person is qualified than why shouldn't they do it" - I think this is a great example of the thought process behind why some projects ask Business Analysts to test. Am I missing out on other Business Analysis activities so that I can test? Is testing the best usage of my time, or am I simply another resource to be leveraged by the PM?

What else am I qualified to do? Where do you draw the line between what one is capable of doing, and what one SHOULD be doing? Testing? Coding? Changing lightbulbs?
David Wright posted on Tuesday, January 12, 2010 3:04 PM
"The point here is: Being a qualified BA does not automatically make you a qualified Tester. "

Sorry for any confusion... This refers back to the original point of the discussion, that some organizations assume this is true, or should be true.
ModernAnalyst.com posted on Thursday, January 14, 2010 4:11 AM
Posted by Eva Grunfeld on LinkedIn:

I read the article, as well as some of the comments associated with it. I do agree with most of your reasoning. However, I think there is at least one good reason for a BA to do testing, and that is to verify that the requirements were correctly interpreted by the programmers. Sometimes a BA is so immersed in a project that she neglects to include some points in the requirements document becasue it does not occur to her that others don't have that knowledge. When a BA tests that particular function, and it does not play as she envisioned, it may well be due to interpretation rather than programming error. So, some testing is a very good check on the requirements.

In addition, while we may all agree that the BA and the QA role are separate, in today's environment, I see BA job postings that require, in addiiton to BA sills, a whole gamut of very specific technical and software knowledge and PM skills as well.
ModernAnalyst.com posted on Thursday, January 14, 2010 4:12 AM
Postd by Otis D on LinkedIn:

Companies are trying to cut corners and save money. That is why they force BAs to do quality assurance as well. Especially in this economy.

A QA-Analysts should do the quality assurance and testing.
Quality assurance being making sure that the BA followed due process and that the requirements are atomic, unique, unambiguous and above all testable.

In essence QA is ensuring that both the developers and Bas follow the rules, to get to a good product.

If the BA is the QA, they tend to slack and cut corners themselves to get to the end.

I teach my BAs to refuse any position where they are required to do testing as well.

Cheers!
ModernAnalyst.com posted on Thursday, January 14, 2010 4:14 AM
Posted by Udai Singh Rathore on LinkedIn:

Hello,
I agree with both of you that a BA should not do QA job. Denise, I can understand your previous job condition because I have seen companies do this to cut cost.

Actually what I believe is BA's should be doing only UAT part not the actual testing.

please guide if any different views
ModernAnalyst.com posted on Thursday, January 14, 2010 4:14 AM
Posted by Mark Troncone, MBA on LinkedIn:

I believe that a BA should be involved in the QA process, but at a high level. By that I mean to assist the QA team in answering any questions that they have about the functionality, measurements, or results of the of the requirements and how they are to be incorporated into the existing system or built as a new system.

The BA should also be invovled at a high level, as a knowledge resource, to assist QA in their testing efforts as far as reviewing issues and any discovered "bugs" and fixes, or answering questions for clarificattion. The goal here is to be viewed as a subject matter expert for the requirements, the system functionality, and data processing.

Working with QA and reviewing their test plan and results makes my job easier for UAT testing and aiding me in developing a user test plan.
ModernAnalyst.com posted on Thursday, January 14, 2010 4:15 AM
Posted by Linda Ros on LinkedIn:

Two comments with regards to BA involvement with QA..

First comes from a best practice perspective (and quoting Deming) "Quality is everyone's responsibility". By the very nature of building effective and robust business solutions the BA and the QA processes are linked and to view them as separate is to forgo a powerful opportunity to deliver a game changing improvement.

Who better to guide the testing efforts then the process expert. The expert who can draw upon his/her knowledge of the entire process not just a particular task or step, the person who knows the exceptions not just the "standard" process and has a solid vision of not only current conditions but also possible future need.

I have found the level of involvement has as much to do with the type of project and the reality of the project time-line as it does with job descriptions.

Second, I agree with the others, postings and hiring managers should make it clear the skill set required for a particular BA position. Hint to those in transition, this is a great topic to discuss during your interview.
ModernAnalyst.com posted on Thursday, January 14, 2010 4:17 AM
Posted by Bill Reister on LinkedIn:

Depending on the size of the team and budget, this is absolutely wrong. No one is likely to have a better understanding of the requirements than the BA.

In these times of 20% real unemployment, the slacker who says, "I don't do QA" is the slacker who will find him/herself on the bench.
ModernAnalyst.com posted on Thursday, January 14, 2010 4:17 AM
Posted by David Medici on LinkedIn:

disagree, Mr. Reister. Of course the BA will have the best understanding of the requirements, but he will not have the best understanding of QA processes. QA and BA are distinct professions that have their own required skillsets, competencies, and methodologies. I am sure an automotive engineer would probably have the best understanding of automobile technology, but I would rather have an automotive mechanic diagnose my auto ills. QA and BA are not mix-n-matchable.

I notice you are the President of Thunder Enterprises. Without meaning to offend, perhaps the reason QA is still generally poor across many industries (IT for sure), and perhaps the reason BA is still often relegated to "writing use cases" or "gathering requirements" is because management still does not understand either profession and continues to think it is six-of-one-half-a-dozen-of-another, a good chance to save money by hiring one person to do two roles. (Same reasoning that often combines BA and PM, to the detriment of both.) Understand and respect both professions and I would be willing to wager large sums of money that you will find your business people conceiving and articulating better business systems and processes, your QA people ensuring quality is built-in from the start and realized when the project ends, better speed to market, and lower costs overall.
ModernAnalyst.com posted on Thursday, January 14, 2010 4:18 AM
Posted by Bill Reister on LinkedIn:

HI David,

You've missed my point entirely. My point was that taking a one-size-fits-nobody approach does a disservice both to yourself and your client/employer.

Does specialization and division of labor make sense in a large organization, or on a large project? Generally, yes. But not always. By thinking of yourself as a "Business Analyst" or a "Project Manager" or a "Tester," you have marginalized yourself and your value to your client / employer. We all have a bag of tricks, and if you want to maximize your own value you need to be willing to jump up and say, "hey, I can do that!" Those who keep silent in such an opportunity or, worse, proclaim that it isn't their job, may find they have no job at all when someone else with a more can-do attitude is readily available. Today, this minute, there are a LOT of highly motivated people with a can-do attitude looking to be that person to "give you a timeout on the bench..." ;)

President of Thunder Enterprises makes me master of exactly me, myself, and I. In 18 years "in the IT industry" I have worn every hat and, yes, sometimes less skillfully than another might have. No one is good at ANY job until they roll up their sleeves and DO IT. However, even if I am not the best possible person to do a job in THEORY, as Johnnie-on-the-Spot I may well be both sufficient for the business and the best in PRACTICE because I already understand the business, the team, the product, and the requirements. Making that decision should involve judgments on risk, time, budget, existing skill sets, and the ability of the individual to know their own limits and compensate accordingly. Part of that judgment and risk assessment is the willingness to stand up to management and say, "No!" when they suggest that you do something that you KNOW is beyond your skill or that will introduce unacceptable risk to a project which "cannot fail." That takes a spine - another skill not automatically granted by graduating from school. But attempting to take the judgment OUT of the process and applying the same rulebook irrespective of circumstances is a losing game - and it only serves to further commoditize our services and our value in the eyes of prospective clients/employers.

The point to all of this is that any project is only going to provide ROI if the cost to undertake it is less than the business benefit. Anything else is FAILURE - no matter that you might set and meet some arbitrary schedule or budget. Knowing this, and knowing that some projects may be running closer to red ink than to black, means that we all need to exercise our professional judgment to prevent "perfect" from becoming the enemy of "good enough." Just as in warfare, the perfect plan executed flawlessly one minute too late means failure, while a "good plan" that "compensates for errors in time" wins the day. The level of detail and specialization necessary to make a plan that "good plan" varies considerably with circumstances, so much so that some very small projects are best accomplished with a single person being BA; PM; Coder; and Tester. Put another way - the general who attempts to fight every engagement with the same plan may win some battles but will ultimately lose the war.

Hope that makes my intended point clearer!

Cheers...
ModernAnalyst.com posted on Thursday, January 14, 2010 4:19 AM
Posted by David Medici on LinkedIn:

Mr. Reister, I do not believe I did misunderstand your point.

The question we were asked was, "Why [shouldn't] Business Analysts ... Perform Quality Assurance?" We were not asked whether one should refuse to do something outside the narrow confines of one's profession. I have, on many occasions, done things that were outside my BA profession, and on many occasions done it better than those whose responsibility it was. In most of my professional engagements I have been Mr. Manyhats, doing many different things simultaneously, swapping hats as the moment required it. That is all part of being professional, of getting the job done in a responsive, resourceful manner.

The question was seeking to understand possible reasons why, on general principle, Business Analysts should not execute Quality Assurance Analysis. It may have had, as a subtext, the idea that the general principle needed to be taken more seriously by management, for generally it is management that determines the responsibilities of a role.

My response addressed what I thought was the question's intent, namely, addressing the general practice of making BAs perform QA functions, and I threw in PM since many BAs are brought in to perform a BA/PM role (what we BAs humorously call a BM role).

Your point was entirely project oriented, in my opinion. You talked about someone willing to jump in at a minute's notice, about someone making themselves readily available, about risk to a project, about ROI on a project, etc.

My response was entirely profession oriented. I addressed why, on general principle, a BA should not be tasked with QA functions. As a rhetorical device I brought in the analogous situation of an automotive engineer diagnosing auto ills, which is properly the function of an automotive mechanic. I could have brought in the analogous situation of a dental hygienist diagnosing tooth decay, the proper function of a dentist. Could an automotive engineer diagnose that odd sound in my car? Sure. Could the dental hygienist look at my x-ray and diagnose a need for a filling or cap? Sure. Should they? No. Why? I answer it is because the entire point of professional differentiation is to produce excellence in specific capacities which, of and by themselves, add value to an organization as a whole. My answer was more concerned with value to the organization, with ROI on a far grander scale than a mere project.

I do understand your point, and there is merit to it. But not at a professional level. That is something that years of observation and experience has convinced me management, by and large, still does not understand with respect to BA, QA and PM. Perhaps that is why I noticed your title.
ModernAnalyst.com posted on Thursday, January 14, 2010 4:19 AM
Posted by Bill Reister on LinkedIn:

Hi David,

No need to call me "Mr." - I wasn't intending to be critical of your position, but rather suggesting that my first answer had been too short and unclear. I'm Bill to everyone....

Ok, I see what you are driving at and I think perhaps it is a case of "violent agreement." What my original post was responding to was not the TITLE of the article, but the author's first line:

"I don’t believe a BA should be expected to do Quality Assurance tasks."

For my part, I believe such blanket statements drive us to build a silo-ed "world view" that both compartmentalizes and (unfortunately) commoditizes us as people.

I absolutely agree that, from an ORGANIZATIONAL perspective, it is best to keep your BAs doing BA work, etc MOST OF THE TIME. However, such an approach flies in the face of three significant counter-challenges: Most organizations are not large enough to support strict functional specialization, keeping any person in a single role narrows their perspective and reduces their opportunities for "broadening" their skill set; and team size is typically tending to hover around the 5-7 "optimal" size identified many decades ago (optimal in terms of human efficiency with respect to geometric expansion of communication as team size increases). If you are lucky enough to be in a corporate environment large enough to support strict role specialization you are among the lucky! Otherwise, welcome to the world populated by the rest of us.

Again referring to the article, job requirements that gave him pause were:
* Define test strategy and test plan
* Develop and execute test cases
* Perform stress and load test scenarios

Like you, as "Mr. Manyhats" I've often done other roles, and if I may say so often better than the "specialists." Well, we all think that don't we? :)

But, looking at those three bullets the first thing I think is, "if this is a large enough organization to have true role specialization, then the first bullet should be boilerplate; the second bullet should be half complete by default if I develop use-cases as I should; the second half of the second bullet I can probably do quicker than I can explain the use-cases; and the third bullet should be mostly accomplished by regression-test scripts created in prior releases, while I should be working with the scriptmasters to develop any NEW load test scripts that new functionality might require."

In other words, as a BA these bullets either fall directly to me or require my direct and full engagement - so I find myself asking, "what's the problem?"

Well, the world is wide and never is one answer right for all situations!

Cheers,

Bill
K Lewis posted on Wednesday, February 3, 2010 10:34 PM
In small shops (read: tiny), the BA, DA, software engineer, programmer, tester, implementer and maintainer are all one person.

There is great merit in having more than one role because it heightens the awareness of the individual to satisfy the user community as completely as possible and to to *get it right* the first time.
Dikeledi posted on Saturday, February 6, 2010 6:01 PM
Hi Bill and the rest of the community,

I appreciate and respect the topic posted and all comments but in particular, I would like to thank Bill. I have always been of the notion that BA's should not test (as per BABOK). Yes, there is reasonable truth to the article but I also like all your comments Bill and they have changed my mentality about work. Every individual has a right to his/her opinion and I thank Larimar for having raised this topic for your comments (Bill) have changed my like for good.

I am strong in both Business Analysis and QA; and have been planning to dump Business Analysis for QA. I have been so indecisive about this and it has been tearing me apart. I just wanted to specialise in one profession. I am more attracted to 'finding fault', hence the QA choice has been consuming my thoughts. You know what, no more stress for me, you have assisted in clearing my head. I love this Blog with a passion! Pardon my excitement!

One last thing, Bill, you can make a good mentor and coach!


Jarett Hailes posted on Saturday, February 6, 2010 7:28 PM
I'm glad to see that this post generated so much discussion - many great points all around. I would like to clarify a couple points however:

- This article was not meant to advocate that individuals should only be a specialist in one area; over the past 12 months I have performed Business Analysis, Project Management, Quality Assurance, heck I even helped code up some functions when one of my teams was in a time crunch. Individuals don't need to be typecast in one role; in fact in most organizations that can be a career limiting move (which is unfortunate but all too often true). Dikeledi I'm glad that you have a passion for two specialties - that is a great asset to have. Don't ever feel like you need to be 'only' one profession.

- I still don't believe that someone who is a dedicated Business Analyst should be expected to do any level of Quality Assurance. If there is a specific job that requires both then it should be clearly stated as such in the job title (i.e. BA/QA, much like the BA/PM positions I often see). Without this descriptor it appears to me that they assume QA is part of the Business Analysis profession, which it is clearly not.

- From a Project Management perspective I see that there's risk to the project is there is only one person who is responsible for both requirements gathering/management and then validating these requirements are met. Some great mitigation strategies were discussed above but for me the ideal mitigation is prevention - if you can have two separate people to do each aspect then that's the way to go. If you have two BA/QA personnel in the organization then have one do BA work for one project and the other do the QA work for the same project.

Again great discussion and I appreciate all the detailed comments!
Mel posted on Tuesday, February 9, 2010 9:05 PM
Larimar (and everyone) - this has been a wonderful discussion on role definition, accountability, and career advice. The only comment I would like to add is for those of you who may not be quite as old as some of us. I am a 20+ years Business Analyst veteran by virtue of being provided opportunities early in my career to explore the Analyst mentality by performing QA, programming, solution design, project management, staff management, etc.

I am fortunate to have been given those opportunities and still take advantage of my background to help out when needed to get a project or product delivered, but I love my role as a Lead/Senior Business Analyst.
Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
12 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC