Tag: Learning

Best of BATimes: How To Level Up Your Business Analyst Career

Written by Shanif Dhanani on July 6, 2022. Posted in Articles.

As a forward-thinking Business Analyst, this question is probably crossing your mind frequently.

You’ve established yourself in your career, but you may feel stagnant, eager for a change of scenery or simply ready to learn something new. In a competitive job market, Business Analysts need career know-how to navigate their next steps to keep their work fulfilling. Read on for simple steps you can take to take your Business Analyst career to the next level.

Understand Which Career Path You Want

To get an edge on advancing your career, you need to know where you want to end up. Business Analysts can take their careers in any one of a variety of directions. It all depends on your interests, strengths and opportunities.

As you move through your career, you’ll see that job titles and descriptions become more specialized and specific based on industry and skills. If you’re interested in the tech industry and you’re good at bridging technical work with communicating specialized ideas, a role as an IT Business Analyst could be a great fit. If you’d prefer to work in a variety of industries doing C-level consulting, you may consider a path into a Management Analyst position.

These are just a couple of examples of advanced and in-demand career paths for Business Analysts. Collabera and New Horizons Computer Learning Centers have detailed descriptions of directions that Business Analysts may take as they move throughout their careers.

Find A Mentor

A mentor is a great industry-specific resource for everything from day-to-day questions to giving insight into career decisions. Mentor-mentee relationships can begin organically, like with a trusted superior at work, or you can seek one out with a networking program. The International Institute of Business Analysts (IIBA) hosts local chapters where you can meet other analysts at different points in their careers, and they are forming a mentorship program for members.

A mentor should be someone you can see regularly, perhaps daily or weekly, and who can get to know you and your work habits well. Ideally your mentor is someone at your company, but a former colleague or even a professor can make a great mentor too. With a mentor, you’ll form an ongoing bond that will evolve as your career goals change.

Get A Career Coach

While mentors are typically fellow Business Analysts, career coaches are professionals who operate from a higher level as they help you seek out new opportunities. They may not be Business Analysts themselves, like a mentor would be, but they have plentiful resources for networking, optimizing your soft skills, and helping with resumes and cover letters.

Career coaches often focus on a local region where they have expertise on the job market. They meet with their clients for sessions lasting up to a couple of hours for a flat fee. Virtual and nationwide services are also available through organizations like TheMuse. If you plan on meeting with a career coach, make sure you have an idea of what you want to accomplish during your session and have documents like your resume and work history handy.

Take Classes

Your experience as a Business Analyst doesn’t have to come solely from formal education or on-the-job projects. Taking classes allows you to improve existing skills or add new skills to your resume through cheap and accessible means.

Business Analyst networking groups, like the IIBA, hold specialized workshops to help you hone your skills and learn from other Business Analysts. If you prefer self-directed learning, there are free online resources with high-quality trainings for Business Analysts, like LinkedIn Learning, where you can earn certificates to display on your profile. Coursera also has a free curriculum that specializes in business analytics with courses designed by The Wharton School of the University of Pennsylvania. These courses are great if you have a specialty field in mind where you may be lacking competencies.

Volunteer For Challenging Projects

If you feel stagnated in your current role, be on the lookout for opportunities to challenge yourself. Offer your input in projects that may be out of your usual comfort zone so that you can learn with skilled colleagues or step forward to tackle an issue you found in day-to-day processes. No matter the project, be sure to ask for help when you need it—that’s one of the best ways to grasp new concepts and skills. By taking on challenging projects, you’ll not only gain experience, but you’ll also establish yourself as someone who takes initiative.

Invest In Soft Skills

While it makes sense to devote your time to expanding your technical skills, don’t let soft skills fall by the wayside. Soft skills are qualities and interpersonal skills that are less “trainable” than hard skills, but translate to every role in every industry. Soft skills include conflict resolution, negotiation, communication skills and more. Usman Haq details important soft skills for Business Analysts in his article in BATimes. These skills are acquired and practiced daily, so be mindful of opportunities to hone them. LinkedIn Learning also has courses on soft skills so you can study at your leisure.

Are You Ready To Take Your Career To The Next Level?

Being a business analyst entails wearing a lot of hats. Conquer your career path by understanding your long term career goals, find a mentor and a career coach to help you reach those goals, take classes for both hard and soft skills and don’t be afraid to raise your hand for big projects. As you take these small steps, your future in Business Analytics will unfold.

Making the Most of BA Training

Written by Adrian Reed on January 24, 2019. Posted in Articles.

One topic that is relevant for us as BAs wherever we are in our career is the topic of professional development.

Professional development is relevant for those joining the profession, who need to get to grips with the core skills, as well as those who are experienced who need to refresh their knowledge or keep up to speed with new techniques or developments. Business analysis is an evolving field, and staying up to date is absolutely crucial. Continuing professional development takes a number of forms, both formal and informal, can include anything from reading blogs and articles (on sites such as BATimes.com), attending IIBA chapter events, participating in webinars, mentoring, running or attending ‘lunch and learn’ sessions and of course attending a specific BA training course.

At this point, those of us that have been around for a while will probably be rolling our eyes. I’m sure we’ve all attended or have been sent on the occasional training course that hasn’t been effective. It’s very easy to attend a training session that is logically designed, fun to participate in, but that makes absolutely no difference to our day-to-day practice. You might have even been on courses where the only highlight was the coffee and doughnuts.

It absolutely doesn’t have to be this way! Training, alongside other professional development activities, can be useful and effective, if we plan effectively. Here are some points worth considering.

Use BA techniques to establish the need: We have a whole range of BA techniques that can help us establish needs and requirements in an organizational setting. These same ideas can be used for an individual or team too. We can turn our analysis on ourselves and carry out a SWOT analysis, understand key skills gaps, and then translate these into requirements. If we notice a particular skills gap in our team we can then research, assess and decide amongst multiple options for plugging that gap.
Training isn’t the only solution: As discussed above, training is by no means the only ‘solution’ to a skills gap. It’s easy to overlook the wide range of resources at our disposal, and often there’s a wealth of experience that exists within organizations. If you are lucky enough to be part of a Community of Practice, it may be that you can use Community of Practice meetings to exchange knowledge and build skills in a safe environment. Training is absolutely useful, but it is most useful when blended with other techniques that support it.
Own the plan: As BAs we need to own our own professional development. Even if you are lucky enough to work for a company that will send you on training, it is still worth having your own (personal) development plan, based on your own goals. Of course, like all plans, it should be malleable and fluid—but it shows the broad direction of travel at any point in time, and this can help figure out immediate next steps.
Choose the provider carefully: If you are booking external training, be selective with the provider you choose. Ask questions like “will the trainer be an experienced BA?”, “When was the last time they worked on a project assignment?”. If you are running the course on-site for your team you might want to ask “Can you customize this course so that it is relevant for our context?”. Ask around your colleagues and network to find out which training providers they would recommend.
Training starts before the day itself: Training is likely to be even more effective if we are able to come prepared with ideas, questions and ‘real life’ dilemmas and situations to discuss. Keeping why we’re attending the training in mind, and assembling these ideas in advance can be very helpful.
Commit to action: During the training, after each technique or concept is covered, it is worth consciously considering aspects such as:
- In what situations can I use this?
- When is my next opportunity to use/practice this technique?
- What are my next steps?
  Using a brand new technique in a radically different way for the first time is sometimes tricky, so you might choose to use it in a team meeting, or some other ‘safe environment’ first. More routine techniques can be picked up straight away.
Ask ‘when will I revisit or re-read my notes’?: Learning can be great fun, and revisiting old training material can help us to refresh, reflect and jog our memories.

Training can be a useful professional development tool when chosen carefully and executed well. Questions such as the ones above can help us in choosing the right course and getting the most from it. I hope that you have found this useful, please do get in touch with any other tips that you have—I’d love to hear them!

5 Project communication mistakes.

Written by Matthew Pountney on June 28, 2018. Posted in Articles. 3 Comments on 5 Project communication mistakes.

Business analysts can get so lost in the details of the projects that we forget to tell the people who are most affected.

Or, we try to tell them but they don’t quite understand. Or we just talk to senior stakeholders and ignore the rest.

Here are five ways communications can go wrong.

1. Treating communications like a luxury

The change manager – or dedicated communications officer on big programmes – is often the first to be cut, if indeed the investment has been made in hiring one to start with. The logic here is that running a good communications operation is secondary to delivery activities and, in one memorable case, I’ve heard clients refer to such roles as ‘walking headcount’, meaning their days are numbered.
However, as many teams quickly find out, there is very little on a project that does not fall within a communications officer’s remit: obvious work such as keeping end users informed of a project’s progress and probable impact but also vital but more subtle work like managing different types of stakeholder, creating alignment in messaging, getting buy-in and support. Without this, most BAs managers quickly find themselves sinking and having to dedicate much of their time to this work – taking it away from ‘delivery’.

2. Failing to manage tricky customers effectively

As every contractor, consultant or internal BA knows, stakeholders can be a difficult crowd. Personalities vary, irrespective of seniority: one likes detail and weekly updates, one just wants the headlines and a quarterly steer co; another refuses to read emails but claims to have not been informed; others vie for political advantage over their colleagues at the expense of all other agendas.
Ineffective strategies for dealing with these situations include ignoring difference, trying to pander to everyone or taking the situation personally rather than seeing it as a communications challenge. Through this lens, all inter-personal friction can be mitigated and every stakeholder can be managed; indeed, the only failure is to give up and stop trying new approaches.

3. Creating an information vacuum, allowing gossip

Many projects become their own worlds, often seeing the multitudes of stakeholders who will ultimately be affected by the project’s outcome as an afterthought. Well, people talk and a lack of information will be addressed through gossip. Before you know it, stakeholders will believe your project has nefarious goals or – perhaps worse – that you are going to make all of the organisation’s problems go away.
Clear communications are the only way to manage this, ideally presented by a client stakeholder with good rapport with the affected groups.

4. Being boring

We go to work and – for whatever reason – we think everyone else suddenly wants to be bored out of their minds. So we fill our emails with tired jargon or we inflict long PowerPoint presentations on our colleagues or we feign enthusiasm in the hope our project team will feel motivated. But, our brains in the office are the same as they are outside the office: same attention span, same interests, same intelligence. Not using this fact and communicating in a similar way to how we are accustomed outside the office is a mistake that is sure to see your message being lost or ignored.
Business analysts are particularly culpable. Sometimes, we manage to be both dull and over-bearing to our stakeholders – or try to inject ‘fun’ that numbs the mind of on-lookers. The best approach here tends to be to deliver simple messages, ideally with no more than one or two slides in support. With so many free third party tools available, many of us could also consider playing with well-formatted html emails, infographics, video presentations; but it is rare such media replace the strength of a solid and impactful presentation.

5. Being slow

Many projects that do have a dedicated change officer responsible for communications spend a long time devising a strategy, defining which communications go to which people at which times. This is useful in principle but often they are encumbered by having to get approval for the plan – or individual communications – from unavailable stakeholders or of over-ambitious and costly strategies that end up either never being implemented or rushed at the last minute. Communications are, by their nature, newsworthy – and news must be delivered while it is still new.
Business analysts on projects of all sizes need fixes for these issues to allow them to focus more on the day-to-day running of their projects. If you want to explore ways to address these issues and manage your communications allowing more time for higher-value project activities, please feel free to reach out to the writer of this article.

Top 3 Activities for a Business Analyst in a Discovery Phase

Written by Nick Stowers on April 19, 2018. Posted in Articles. 92 Comments on Top 3 Activities for a Business Analyst in a Discovery Phase

In at the deep end

So, you’ve just heard you’re going to be the Business Analyst on an Agile team that’s going in to a Discovery and it’s your first one.
For my first Discovery, it was daunting let me tell you. I already knew quite a few tools and techniques a BA should use during the lifecycle of a project, but what ones do I use that are particular to a Discovery phase?
For this blog, I interviewed other Business Analysts, Scrum Masters, Product Owners and Developers to get their view on what the role of the BA is in Discovery and I will use their opinions (along with mine) to provide what I think are the top 3 tasks a BA should carry out.

Time is of the essence

You may be thinking, ‘surely you just apply the right tool or technique for the situation?’ Good question and I would say this is true. However. Unlike a traditional project where the BA would investigate, analyse and document literally everything, in Agile, Discovery phases are given quite a short amount of time before moving to Alpha and this is where as a BA (along with the rest of the team), you need to use your time wisely as you just won’t have the time to do all those ‘traditional’ BA activities.

Now, there is a process to follow in that you can’t start to create a backlog until you know what the user and business needs are, and you can’t find out those needs until you identify your users and stakeholders. So, this is where we’ll start.

Stakeholders: Don’t just identify, analyse

The top activity the other roles identified as a key role of the BA was to understand and define the problem. However, before we get to that stage, we need to identify our stakeholders and users. And perhaps more importantly, understand the stakeholder’s interest and their influence in your project.

For me, this is a critical exercise that I don’t feel is given the importance it should at the start of a project. They either get done and are left static throughout the project or not done at all.

While the BA might lead on this activity, it’s most definitely an exercise the whole team need to be part of. My tip here is to put a stakeholder interest/influence matrix on the team wall (hopefully you have one, if not, get some whiteboards!) and give yourself and the team a couple of hours for the session. There are plenty of templates online you can use or if not, just draw it on some flipchart. Give the team around 10-15 minutes to identify who they think are stakeholders and begin to plot them on the matrix.

There may be some conflict where these people sit on the matrix but as long as you agree on who are the highly influential or clearly fit in to a category, the borderline ones you can leave for now.

In terms of analysis and potential time constraints you have, don’t go in to any particular detail and spend time creating stakeholder wheels or stakeholder management plans, the interest/influence grid is sufficient. In addition, use the matrix to create your communication strategy to define what methods you will use to show progress of the Discovery to stakeholders and how often you will communicate with them.

For identifying users, this will be something the User Researcher will lead on as they will be interviewing them but you as the BA should be involved in those sessions. After all, if you are going to be writing the user stories based on their needs, you need to get this first hand. You will also pick up good interview techniques from the UR.

Framing the problem to define scope

Ok, so we now have a list of stakeholders and users and it’s time to start engaging them. Before you start looking at things like defining ‘as is’ processes, pain points and setting up interviews with stakeholders to get this information, you need to have an understanding of what the actual problem is the team has been put together to fix.

You may have been given a mandate as to what the issues are but until you engage the people ‘at the coal face’, they are just perceived issues. The quickest way to get to the root causes is to get those key stakeholders in a workshop and identify the following:

• Why are we doing this work?
• Who are our users, clients and stakeholders?
• What outcomes might users get from this?
• What outcomes might the organisation get from this?
• What are our key metrics?

Now, a lot of information will come out of this session and I see the key role of the BA is to deconstruct all these thoughts and views and turn it into something meaningful……like a problem and a product vision statement.

These statements are short and provide an overview of the vision, problems and methods the team will use to address them. It should be no more than a few sentences which is a difficult task and one I suggest should be collaborated and created with the rest of the team.

Once you are all happy with it, you need to share it with the stakeholders. Not to get agreement or for endless reviews, but to ensure everyone is on board with what the team are trying to achieve.

As some (maybe most) stakeholders may not be aware what a problem and vision statement is, you may have to spend some time explaining its purpose to them. Point out it’s not a personal view, but a collective interpretation of perceived issues that need addressing.

The backlog

As with defining scope, starting a backlog of user stories is not solely the responsibility of the Business Analyst but is something the team are responsible for and should contribute to. That said, the BA does play a critical role in the creation of a backlog. And that is to ensure that what goes in to it is of an acceptable standard. After all, rubbish in, rubbish out right?

I’ve seen this so many times whether it be on a new product or one that has progressed in to Alpha and Beta where the backlog has become a bit of a dumping ground for every idea, whim or ‘wouldn’t it be good if’ thought.

For a start, everything in the backlog should either be related to a user need or part of the product roadmap. If it doesn’t, it shouldn’t be there. If someone does have an idea worth further exploration, put it on the user research/UX hypothesis board so they can establish whether there is an actual need for it.

Before you start creating a backlog, get the team together to agree ground rules. I suggest you hold a user story writing workshop with the team where you can begin outlining the backlog. This ensures the team are involved from the start and you can agree principles with them to stay clear of the ‘bloated backlog’.

Who might I be working with in a Discovery team?

Discovery teams can be made up of several roles, most commonly; a Product Owner, User Researcher, Business Analyst(s), Subject Matter Experts (SMEs) and a Scrum Master/Delivery Manager

I’ve worked on Discoveries where a Scrum Master/Delivery Manager wasn’t part of the initial team and I found the focus and cohesion of the team became lost at times due to a lack of discipline in setting and achieving targets (i.e. sprint planning). When time is the key factor, the team needs to stay focused on its goals which I think the Scrum Master brings.

You’ll start to get the impression now that the Business Analyst is not really ‘solely’ responsible for the outputs of a Discovery but is involved in all of them. One of the people I interviewed for this blog explained his view of the role of the BA in a great way. He said they are ‘decoders’. By this he meant they translate all the information gathered (and there will be a lot of it) in to outputs that not only the team understand, but any stakeholders.

I believe this is the primary role of the BA however in an Agile Discovery, you should be able to evaluate what you are doing is of value and that you’re not just ‘going through the motions’ because of pre-defined duties of the Business Analyst.

I hope this has been helpful and that if you are asked to join a Discovery team, you are equipped to get engaged in those top key deliverables to make the Discovery a success.

5 Myths About PMI’s Business Analysis Certification

Written by Laura Paton on September 19, 2017. Posted in Articles.

In this article I aim to debunk some of the misinformation I often hear surrounding PMI’s Professional in Business Analysis (PMI-PBA) certification in hopes of providing better clarity to support improved decision making.

Background: The PMI-PBA certification hit the market in late 2014. It’s not quite three years since its launch, but it is doing well; having now attained credential holders in 82 countries. The idea that PMI was developing products in the business analysis space was shocking to some, but PMI has been recognizing the importance that requirements play in achieving program and project objectives for years. For those who are familiar with “A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition” (PMI, 2017), it’s no surprise to hear that successful projects require the effective use of business analysis. It makes complete sense why PMI would be investing heavily to raise awareness about the relationship between mature business analysis practices and organizational performance. In “Business Analysis Leading Organizations to Better Outcomes” (2017), PMI reported that organizations with high business analysis maturity, demonstrate above average performance across all key organizational success metrics—including:

Financial performance (69% versus 45%),
Strategy implementation (66% versus 21%),
Organizational agility (40% versus 14%), and
Management of individual projects (62% versus 29%).

So there should be no question on why PMI cares about business analysis and has set out to develop a top-notch professional credential to help organizations improve their capabilities to deliver on their strategic objectives.

Despite approaching its 3-year anniversary, there is still confusion about what the PMI-PBA is all about. As with many new products, there are early adopters and there are those that take a wait and see approach; certification is no different. For those who adopt later – there may be weeks or months spent researching, discussing, or listening to others share their experience and knowledge. This is the time where there should be sufficient and accurate information to base discussions and decisions on; and there is – on PMI.org! Unfortunately, (as I have found firsthand) there are some postings, presentations, and conversations on social media that are perpetuating a misunderstanding about the scope, structure, and value of the PMI-PBA. I don’t believe it is being done on purpose or maliciously—I think it is a byproduct of the community misunderstanding PMI’s objectives and the product characteristics. I hopefully clarified PMIs objectives above—so let’s set the record straight on the PMI-PBA product.

5 PMI-PBA Myths

I have assembled a short-list of the top five misguided statements I have heard about the PMI-PBA. Hopefully this article provides you better information and helps to dispel the misinformation. If you are considering a PMI-PBA, hopefully this information helps you further your discussions with your manager and professional contacts. At the end of the day, the decision to pursue a PMI-PBA or not, is owned by those who must make the investment. Be wary of taking the advice of consultants and peer business analysts who convince you that a certification is right or wrong for you. Everyone needs to perform their own analysis, because each person’s situation is different. This article isn’t about convincing you one way or the other, it’s simply intended to provide you factual information to assist you in your decision making process.

Here we go…the top five myths about the PMI-PBA:

Myth #1: The PMI-PBA is an entry level credential.

This is absolutely false! You can debunk this misinformation by taking a look at the eligibility requirements in the PMI-PBA Handbook downloadable from PMI’s website. To be eligible to take the exam, you must demonstrate either 7,500 or 4,500 hours of business analysis work experience and 2000 hours of business analysis experience working on projects. The 7,500 or 4,500-hour requirement is determined based upon your educational background. Further details are listed in the PMI-PBA Handbook. These hours were not randomly selected. An extensive role delineation study was performed by an external third party and the results indicated that these were the hours required in order to demonstrate competency in business analysis. The PBA exam is also structured to include scenario-based questions which rely heavily on experience not book knowledge to answer. From my personal experience taking the exam, I can attest to the fact that the PMI-PBA is clearly developed for experienced professionals.

Myth #2: The certification confines business analysis to projects and programs.

Completely false! PMI research has shown that 83% of business analysis is performed on programs and projects in highly mature organizations, but this does not mean that PMI defined business analysis only to this context. You can debunk this misinformation by taking a look at PMI’s definition of the term portfolio which states it consists of “projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.” “The Standard for Portfolio Management Fourth Edition” (PMI, 2017) is more than managing projects; hence PMI’s business analysis standards do the same because business analysis is discussed in the context of how it is performed in support of portfolio, program, project management and operations. The “Business Analysis for Practitioners: A Practice Guide” (PMI, 2015) provides an entire chapter, Needs Assessment, that discusses pre-project business analysis activities. Later this year you can take hold of “The PMI Guide to Business Analysis” (PMI, 2017) which goes further than the practice guide in explaining how business analysis supports portfolio, programs, projects and operations. Keep in mind that how business analysis is defined is based on extensive research, not any one person’s idea of how it should be defined.

Myth #3: The PMI-PBA was developed by a group of project managers.

No, sorry this is false too! I can see where some people might think this is the case, but PMI definitely used a team of experienced business analysis professionals from around the world and across industries to develop the PBA exam questions. PMI continues to do so too, because the test bank is refreshed on an ongoing basis. New exam writing initiatives ensure that the PMI-PBA exam questions remain relevant and reflect the latest thinking as presented in PMI’s standards and confirmed across the profession. Those assisting in writing new exam questions are just as experienced as the original development team. I think I should also mention that all PMI-PBA exam questions once written, are also reviewed by experienced business analysis professionals. Additionally, each exam question is required to be backed by at least two independent business analysis references. I don’t want to forget to mention that exam writing teams also have access to extensive PMI research. This credential is absolutely developed by business analysis professionals for business analysis professionals.

Myth #4: The certification is for project managers or PM/BA hybrids.

I can’t say this statement is completely false, because there are some PM/BA hybrids or project managers who qualify to sit for the PMI-PBA exam BUT not all project managers and not all PM/BA hybrids are eligible. In fact, not all business analysts are eligible! In my response to myth #1, I indicated the work experience requirements. It is these requirements that dictate eligibility, not your job title. Product owners, business analysts, project, program, portfolio managers, requirement managers, IT analysts and numerous other titles may be included because it’s not the job title that matters. What does matter is the number hours of ‘business analysis’ experience you possess. You demonstrate your experience on the PMI-PBA application. Therefore, if you are doing any of the work discussed in PMI’s business analysis standards, you are performing business analysis and may qualify to sit for the exam. It’s worth checking out the eligibility requirements to see if you qualify – regardless of your job title!

Myth #5: PMI has defined business analysis as a subservient role to project management.

Oh gosh no! I think it’s time we debunk this PM/BA subservient concept, it’s been around a long time and it’s not how we operate at all if we want to be successful. PMI research shows that highly mature organizations encourage high levels of collaboration between their portfolio, program, project management, and business analysis professionals (“Business Analysis: Leading Organizations to Better Outcomes” [PMI, 2017]). We are all part of the same team and we will jeopardize our success if we fail to collaborate. PMI has not defined business analysis as a subservient role. In fact, the “PMI Guide to Business Analysis” and “The Standard for Business Analysis” publishing this year will sit among some of PMI’s most prestigious standards” – the “PMBOK® Guide,” “The Standard for Portfolio Management” and “The Standard for Program Management.” Business analysis is no less important, but equally important for organizations and individuals to understand and embrace.

I hope my responses to the top 5 myths about the PMI-PBA helps to dispel some rumors, reduce confusion, and allows for improved decision making when it comes to researching a professional certification in business analysis. Remember, PMI may be the Project Management Institute, but this doesn’t mean PMI only serves project managers. It’s not practical to think this way. Those who have experience working on ‘successful’ change initiatives within their organizations can attest to the fact that it’s a collaborative effort. We can’t succeed by separating our business analysis professionals from our project management professionals! This is one of the reasons I am encouraged by the contributions PMI is making to the business analysis profession and even more encouraged to see that CIO.com recently ranked the PMI-PBA as the highest paying business analysis certification on their list.