3 Generic Certifications that help you get IT BA interviews!

There is no getting past it that the IT BA market has become saturated. It is no longer enough to be someone who has worked as a BA for years as the market is full of that experience. So the question becomes how do you make it to the interview pile instead of the reject pile?

Today I want to focus on 3 generic IT certifications that are not tied to an industry or solution that can help move your resume into the pile to be interviewed.

#3 Certified Business Analyst Professional or equivalent: This one has been around for quite a few years now. If you have been doing BA work as long as I have, it really does not bring much value in terms of knowledge. If you have less than 10 years of experience, this one is good to add onto your resume. However its value has somewhat diminished with Agile development.

Pros:

  • Shows that you have at least been educated as a BA.
  • Great for when you have limited real world experience.

Cons:

  • Has not become a job requirement like A+ certification (for pc repair).
  • BA roles differ from company to company so some companies add more or less weight to the certification.
  • Does not carry as much weight in the Agile development world.

#2 Certified Scrum Master: You can look on this certification as selling yourself to the client as two for the price of one. For the longest time, clients have liked to put their BA’s in the role of backup Project Manager, being a Scrum Master is the new flavor that Agile development has brought to us.

Pros:

  • Shows that you understand Agile development.
  • Makes you more appealing to the client as you can now fill two roles.
  • Could increase your salary as Scrum Masters can make more money than ordinary BAs.

Cons:

  • You may end up doing more Scrum Master work than BA work.
  • Could make your life busy as you juggle two roles.
  • You may not like being a Scrum Master.
  • Only applicable to Agile development. For non Agile, you could look to taking Project Management certifications instead.

#1 Certified Product Owner: You can look on this certification as being the natural career progression of the BA involved with Agile development. Any BA that wants to stay more in the BA world should look to get this certification sooner or later. It shows a client that you understand Agile and that you understand the BA role through the Product Owner viewpoint. With the advent of the Product Owner role, certain tasks normally performed by the BA have moved to the Product Owner and this is why it is not a large step for a BA to move into this role.

Pros:

  • Shows that you understand Agile development.
  • Makes you more appealing to the client as it shows you should be able to represent what the business wants.
  • Could increase your salary as Product Owners are more involved with the money making side of the business.

Cons:

  • More applicable to Agile development but does carry over into other types of development methods.
  • May not pay as well

In summary, if you are wondering how to get more interviews as an Information Technology BA, getting at least one of these generic certifications can help you move forward. What school or method you choose to get these certifications is not as important as actually having a certification that you can add to your resume.

From a long term perspective with these certifications, you will need to decide if you want to go more on the high paying Scrum Master side (which is more like the old Project Management) or look to move into Product Ownership which is the natural next step for Business Analysts.

Business Analysts who want to become Product Owners should know these two things.

As the market changes for business analysts and more consider the move into the product owner world, the question becomes, what is the difference between the role? Product owners can sometimes just be business analysts with a new job title and in other cases they are really product owners with full authority to make decisions.

Agile development has driven the growth of the product owner role. No longer do business partners have to wait months for development to implement new features / functions, instead they can be delivered in weeks. Since business partners usually have to run the business they don’t have time to spend on agile work so they delegate business representation to the product owner.

Now, let us consider two of the key differences in the product owner role vs business analyst:

  1. Industry knowledge – with the traditional BA role, there is usually time to get up to speed in the industry being worked in (Retail, Utility, Finance, Health, Transportation etc..) as the requirements are gathered. This means that having industry knowledge is not a deal breaker to being hired. In the product owner world, you had better know the industry as decisions have to be made quickly to keep the development moving. For example glass devices are not allowed in food processing plants, so developing a product solution that uses cell phone applications would be a bad decision for any industry that goes inside food processing plants because of the glass touch screen.
  2. Metrics / research – product owners need to make decisions on the priority of features / functions to be developed. As a product owner, you need to know how to justify the decision based on real world facts. This requires an understanding of the research options / data available and metrics desired in new development. Think Google Analytics, combined with any restrictions on data that can be collected / solutions that can be delivered. Business analysts on the other hand normally get this information and direction from their business partners.

How to get the skills needed to be a product owner?

  • Industry knowledge can be gained by either working as a business analyst in the industry for a period of time or getting a job on the business side. Both options will be good to getting the necessary experience.
  • Knowing research options / metrics to justify decisions is not always needed as not all companies expect this of their product owners. However for those product owners that do need to know the information, joining external groups in the industry, reading trade publications, staying on top of trends, working on the business side etc.. can all help to build up the knowledge required to justify decisions.

Are criminals and government fines driving new requirement methods?

We all have had the business partner who never quite tells us all that we need to know when working on a project but spare a thought for those who design solutions to defeat criminals. In their case, the criminal is not sharing what he does and most design is done in reaction mode.

One area that has got recent focus is Money Laundering. Financial Institutions that end up involved with Money Laundering not only risk loss of money and reputation but fines as well imposed by their governments or even other governments. The situation of identifying money laundering has gotten so out of control that nobody really knows how to define the complete requirements to identify money laundering.

Traditional requirement methods basically do not work anymore. With traditional requirement methods, the Business Analysts identify / capture the business rule and then implement it. Unfortunately the people who make the business rules are not the ones sharing it with us.

Criminals don’t tell us that if they do X, Y & Z then they are money laundering. The criminal’s desire is to float under the radar as normal customers. Their methods for appearing as ordinary customers have gotten so good that the people trying to create the rules after the fact to identify Money Laundering can no longer keep up. This puts Financial Organizations in a bit of a pickle.

Governments have made it so that Financial Institutions cannot just ignore the problem of Money Laundering and hope for the best. After all, if a Financial Institution goes belly up, it can affect a whole country. To avoid this worst case scenario, a government may force a Financial Institution out of business if they are not confident that the institution is compliant with laws. If you want to get business owners / board members to do something about a problem, threatening their business is one solid way to go about it and the governments know this.

For Financial Institutions to get round this issue of not knowing the business rules to implement to identify Money Laundering, they are turning to Artificial Intelligence (AI) to fill in the gap of knowledge. AI will scan through large amounts of data to learn, establish, monitor and update the business rules that identify Money Laundering or Potential Money Laundering. Systems will then implement the rules on the fly to freeze accounts, recover laundered money and notify government and law enforcement agencies.

While I am not a liberty to talk about the specific data being worked with, I can discuss what this means from a Business Analyst perspective. Data scientists and AI engineers will take over the role of capturing and implementing the business rules for identification of Money Laundering into the systems. Previously this was handled by the Business Analyst. However, before you cry about the loss of another piece of work for the Business Analyst role, new opportunities will open up:

  • AI needs data and lots of it. Business Analysts will be recruited to provide data interfaces into the AI machine. At least for the next little while. Eventually, the desire is to end up with more of a Web Crawler approach where the AI establishes new sources of data with little to no human intervention.
  • While AI will be good at identifying that an action is needed it will not be good at implementing the action (at least until we build the fictional “Skynet”). Business Analysts will always be involved with ensuring that the action is communicated to where it needs to be communicated and that any automatic response within an organization is performed . With the way Companies, Governments and Law Enforcement Agencies reorganize themselves on a regular basis it is unlikely that this will ever be a static solution. Given that changing environment, this should keep Business Analysts busy for a while.

What I think will be interesting in the future will be for the Data Scientists and AI engineers to be able to explain the reasoning of the AI for its decision that a particular event is Money Laundering. Eventually it could grow beyond their understanding. I can see a future where Business Analysts will be called upon to get the AI systems to pump out human readable reasoning and maybe that will be a new job task for us all.

In summary, criminals and governments are driving the need for AI to step in and generate IT requirements on the fly. This is to ensure that the criminals are kept in check and that businesses are not shut down by governments for not keeping criminals in check. While some BA roles will be lost around business rules capturing and implementing, other new roles will open up in support of the AI infrastructure and especially the output from the AI solutions.

AI will end the need for IT Requirement Business Analysts

Will say up front that this is purely an opinion piece as I don’t plan to provide the textual references to back up the statements. Purpose is just to think about the evolution of technology that had led us to this point and the impact to the IT Requirements Business Analyst.

Historical speaking if we start at the Industrial revolution, machines were used to speed up production. Back then, the equivalent of a software programmer was a mechanical engineer who designed the levers; shafts and cogs etc.. to produce the desired result. More often than not, workers were required to keep the machines fed with raw material and to remove the finished product. You could think of the raw material as being the equivalent of data coming into a modern day data processing software and the end product being the finished use of the data such as reports / dashboards or account updates.

When the electronic computer moved into the office world in the late 40’s we started to see where the processing of data by human clerks was being replaced by the computer. The mission of the computer back in those days was to reduce the number of humans involved in processing data. At this point, businesses are not looking for the computer to give them guidance but just to allow data to be processed quicker and more cheaply. Designers of software could focus on the tasks already done by the human and create software and peripherals such as printers that replaced those tasks. This would be done by job shadowing to understand the process.

Moving into the fifties and sixties, computers became available that could be programmed with complex algorithms to allow data to be processed in a way that predictions could be made from the data. At this point, the designers are no longer thinking about replacing workers but instead leveraging the processing power of the computer to produce decisions related to business. While some of this you could argue was done in WW2 to break codes, those machines were specifically built for the task. What the more modern computers allowed was for programming languages to change the decision task to meet the current need. However the one handicap was the speed of the computer in those days. Decisions generated by the computers were not done in real time and the programming involved was complicated.

With the advent of the more powerful and useful computers that come out of the late sixties, we start to see where computers become part of real-time processing. Computing processing power and storage keeps increasing every year allowing for businesses to look at new way of saving costs / increasing investments by letting the computer streamline their processes beyond replacing people to even including the ability to expand their business. This is achieved by the development of new interfaces beyond the punch card of old. Now terminals are available that allow for direct access to the computer processor allowing for live updates of data – think airline ticket handling. In this period the designer was seeing how new tools available via technology could enhance rather than replace the current process. However even with all these advances, the use of the computer was still dependent on a designer working out the needs of the business and getting it coded. Software solutions were ridged and limited to the design parameters provided.

Even when we go into the turn of the century, the faster computers with more data handling are still moving along with limited software design that involves fixed parameters and limited interfaces for data collection.

Where we seem to make the evolutionary leap towards AI is when the processing power and data handling ability of computers crosses a threshold where it can consume non-human prepped data that is beyond just text. Previously, data processing power limited what a computer could do in real time. Now a computer can process not just plain textual data but also images, sound etc. and determine decisions based on this. It is like we have removed a prisoner from a small cell where the only thing they could see was text and their hearing / touch / sensing was deliberately disabled. Now we are in a scenario where computers can be educated to interface with humans on a natural level. All the designer needs to do is define the data streams (based on the context – driving a car for example) and the measures of success. AI can then learn to process the data.

Now before I talk about the impact of AI on the BA role, I want to break the role into two:

Role 1 is the BA that looks at business processes.

Role 2 is the BA that looks at interfacing IT with business processes.

Business process BAs (Role 1) are already heavily being replaced by the Product Owner role so while this BA will eventually not exist, the role has a chance of living on for a period of time with the advent of AI as a Product Owner. Eventually however even Product Owners will be replaced by more sophisticated AI solutions. Big risk though, is that businesses become clones of each other. An AI analyzing the marketplace may come up with the same opportunities as another business AI thus killing the market opportunity as both deliver the same solution at the same time making neither have an advantage over the other. While this happens with humans today, the occurrence is less as humans cannot deliver ideas at the 24x7x365 speed that AI can. Stock market meltdowns have already been shown to happen when multiple different stock monitoring software trigger sell decisions because a trigger event occurs. This will be the same issue when AI takes over the business Product Ownership.

Role 2 BAs that focus on requirements for IT design are most likely to be impacted in the very near term by the advent of AI. This role has already seen a significant amount of work being moved to UI designers and Data Warehousing Specialists (both of whom are at risk of being replaced by AI as well) that the amount of work left is limited. With the advent of AI, its is conceivably possible for the BA person to be replaced by an AI solution that interfaces directly with the business to produce either IT solutions or output that can be used to create IT solutions. For years this has been a dream of many companies. Easier to use software being the traditional way to limit IT expenses – think about how many business users use Excel for example without ever talking to a BA. AI will make it a reality for everybody to ditch the IT requirements BA. Instead of having to learn an interface specific to a piece of software, the AI will instead provide a sophisticated human interface that replicates what the BA does today. For the business it will be as if they are working with a BA but without the human cost. Certainly it will take time and money to develop this BA replacement AI but once it is developed it can easily be distributed and shared.

In summary, AI will be a great move forward for business but will negatively impact the Business Analyst market as we know it today. Business Analysts who focus on only IT requirements would be well advised to move into Product Owner roles or be involved with the AI development that is happening so that they can be an expert in the field.

VW a lesson in marketing versus regulations

By now you will be very aware of the VW diesel scandal where the software on the car detected when the car was being tested and controlled exhaust emissions to past the test.

Anyone that works in gathering requirements can easily see the problem here. There were two competing requirements Marketing and Regulatory and in the end the marketing side won out.

Big business is a game of cat and mouse. Laws are in place for a lot of things but for business the viewpoint of laws is the risk / cost of being caught and the benefit of not following the law. If the law is not enforced 100%, business will start to think of it as an optional law. There are numerous cases of settlements between car companies and the US government or consumers. The Titanic is a classic example of the law being met but the intent of the law being missed which was to have enough life rafts to save lives – the law had not been written in such a way as to force the life rafts to be enough to meet the number of passengers.

When gathering requirements for a solution, care must be taken to understand the implications of giving one set of requirements higher priority over another. Risk analysis is supposed to be done to ensure the VW, Titanic situation never occurs today. However profit is a powerful master and it will make people blind to that which is obvious.

Double check those requirements that fly in the face of morals to make sure you are not ignoring something that will later make you a headline.

 

The industrial revolution 2.0 – where Jane & John Doe programs make sense

If you ever saw pictures from the original industrial revolution (1790 – 1870) you would have seen machines producing goods that also required humans to keep them supplied with materials. In some cases it was dangerous work as the humans darted under the mechanism of the machine to keep it supplied. One wrong step and the human resource was injured or killed.

These machine in their own way were original pieces of programming. Basically the Steam Punk of code where the internal workings are completely visible. Humans basically made up the shortfall in what could not be replaced easily or affordably by machine.

Step forward into today and while the brass and iron has vanished we still have humans fulfilling the roles where machines have not caught up.

Amazon pickers is an example of the humans still meeting the need.

When do you ask does it make sense to replace the human programs (lets call them Jane & John Doe)?

NOTE: This article is a somewhat tongue in cheek consideration of the removal of humans from the workforce and is not meant to offend anyone who is worried about AI takeover.

Let’s first look at the benefit of our human Jane and John Doe programs:

1 – Easily programmed if task is not too complicated.

2 – Can be programmed by other existing programs.

3 – Adaptable interface – Buttons, levers, switches etc.. are not an issue.

4 – Can be replaced if failing.

5 – Low short term investment costs.

6 – Can be easily reprogrammed as tasks change.

7 – Multiple interface methods for programming – auditory, touch, visual.

 

The cons of Jane and John Doe:

1 – Program can leave of own accord requiring another program to be obtained.

2 – Program can be injured requiring maintenance costs to be paid even if another program replaces it.

3 – Not all programs are of equal ability which can cause quality issues.

4 – Limited amount of transactions per hour can be handled and there is risk of memory leakage if the task is too frequent or repetitive.

 

Now let us consider the attributes of the equation to determine when to replace the Jane and John Doe programs with actual computerized machines :

1 – Cost of your current Jane and John Does + cost to remove them from the role versus the cost of the computerized machine.

2 – Frequency of the transaction – more frequent or increasing frequency raises the number of Jane and John Does programs you require making a computerized alternative more attractive.

3 – Availability of Jane and John Does – if they are getting harder to find, their cost goes up.

4 – Complexity of the task – like point 3, if the complexity of the task is getting higher, the number of Jane and John Does that can do it get less, increasing their cost.

5 – Long term need for Jane and John Doe – if the task is not changing and going to be around a long time, programming a computerized alternative makes sense as the long term return can be seen.

6 – Reliability of the computerized alternatives or level of risk a single failure point can create. When you have a large human set of programs, there is a lot of redundancy built in if one fails. With a computerized machine, when it fails, there is no backup until it is repaired.

There are probably a multitude of other reasons to keep or replace Jane and John Doe. This article is just to make you think about it from a ROI point of view and how history repeats itself 200 years later.

To quote what the head of an IT operations once said to me back in the 1989 “As soon as the cost of the tape system comes down to being cheaper than the staff I will get rid of the operations staff.” By 1992 the operations staff were out of a job as a machine had replaced them – the cost had come down enough. Machines eventually get cheaper than their human counterparts.

 

When software kills due to incomplete requirements

If you are lucky, your software has not been responsible for the death of anyone to date. If you are unlucky then you know it.

When a analyst gathers requirements for a piece of software there is a tendency to focus on the happy path and ignore the surrounding paths that can lead to disaster. Unfortunately events can lead up to the identification of the missing requirements and sometimes death is a result.

To be fair, we humans can still kill ourselves without software such as with the mechanical loaded gun or the speeding car taking a bend too fast. However software seems to give people in some cases a false sense of security that does not exist. In other cases it can give them power to do something that should not have been possible if they were directly engaged with the physical which leads to disaster.

The article below refers to two cases where software enabled a pilot to do something they should not have been allowed to do with death being the end result.

Lessons from spaceship two’s crash

In the above article, the situation was different from my previous article about lack of tactile feedback. In both cases the pilots knew what they were doing, they just did it at the wrong time or too frequently for the specific vehicle to survive.

As an analyst, be it a system’s analyst or business analyst, it is not enough to think of just the happy path. Whenever you are gathering requirements you need to also think of what will keep us on the happy path. Whenever there is an interaction or a key data point, ask yourself if the event that causes this can be triggered at the wrong time or occur too many times.

Look for the ways that one can step off of the path and see if you can build either a metaphorical wall to keep us on the path or ways to get us back on the path before any damage is done.

Testers working for nothing – why you should not go into testing as a career

Often Business Analysts will see in their job description the act of testing. True heavy testing requires special skills that do not tie in well with good Business Analysts skills.

Business Analysts often need to get out and communicate with a variety of people and dig beneath the surface of conversations to find the true requirements / processes.

Testing however relies on the information presented from the Business Analyst along with other documents and  industry standards to validate the work done. Testers effectively thrive in an atmosphere where communicating with a variety of people is not required.

While small amounts of testing such as a minor enhancement can be covered by a BA, care must be taken if the BA role requires more than that as it will weaken your BA skills over time.

Maybe the above is not enough to dissuade you from heading down a testing career path from your BA role but two trends should discourage you from heading into testing as a career:

1 – Outsourcing

Recently I saw a corporation completely outsource their Testing Department. Part of the reason behind this is the theory that the size of a testing department varies according to the work being done. A vendor was considered a better solution to handling the waves of work as opposed to having staff on hand.

2 – Testing for nothing in hope of potential rewards

This is the most worrying concern for anybody involved in testing. It looks like a Silicon Valley startup has ditched paying testers a wage. Testers have to compete to win cash by being the first to identifying bugs / issues that nobody else has identified. If they are not the first then they get nothing for their efforts. The prizes are also so small that only someone living in a country overseas could justify the risk of time and effort for little to no reward.

Data handling – know when to bring the experts on board.

We all know about the Y2K incident with the 2 digit year however there are still examples of data storage length being inappropriate for the data to be stored.

If you are a Business Analyst that deals with data then it is important to always be questioning the data requirements to ensure that they meet the need of the business / application now and especially in the future.

Industries where data is critical to their function will probably leverage Data Modelers / Engineers / Scientists to manage data definition. As a BA we should not be afraid to state when the  data knowledge is beyond us and ask for the project to employ one of these specialists. Do not try and wing it because the end result can be expensive to the company.

To read up on some of the impacts of data, see this article below from the BBC:

Data Handling that led to disasters

PM versus BA – the dead discussion and why being a PM may be better than being a BA

It can be interesting to read articles on the Ideal Way that things should happen. These articles are somewhat like the ones about why all people should be debt free and happy. If you are not debt free and happy, then you personally are doing something wrong.

Focus of this website is in the reality of the workplace which is usually far from Ideal. Politics, Oligarchies, Budgets etc. can all get in the way of achieving the Ideal or “World Peace”.

If you want to read up on the debate around the fact that there is no difference between PMs and BAs but it is all about what you bring to the table (“Ideal Approach”) then check out this link – PM vs BA.

Honestly however, the whole conversation is dead one which is what the author of the article states. The author basically questions why PM versus BA is even a discussion point to which I have to agree (having had a foot in both camps (PM / BA) I see no reason why the right BA cannot do PM work and vice versa). Business Analyst term has become so watered down anyway it means many different things to people in the industry. There is no one definition (outside of the textbooks) for what a BA is. Effectively as the author of the article states, project success is based on collaboration and not on title. However in the real world, project teams (especially in larger companies) are formed based on titles / roles / budgets / deliverable dates and that is where the Ideal is left behind. The company that you are at will dictate your role to you based on their process / procedures / politics etc.. Some companies will be Ideal while others will miss the mark.

From a current trend perspective over the past 20 years, I have seen the companies go from using BAs to manage small projects as they gather requirements to the other scenario of having PMs gather requirements as they manage projects. Talk about territory wars. As the trend continues, the BA starting out might be better off to go into Project Management first since they will get better experience than trying to come up through the BA ranks where they run the risk of being no better off in experience than a secretary.

From a historical perspective (ignoring the above about collaboration approach), let us talk about the facts around the PM being different from a BA.

1 – Project Managers are brought on before Business Analyst so why bother with the BA.

– Pure Business Analysts are seen as an unnecessary expense in a lot of companies – last hire in your small companies. More and more the Project Manager is being looked at to deliver the Business Case / Requirements as part of their role to avoid the expense of having a Business Analyst. Personally I have seen two recent larger clients push to have the PM do most of the work since the rational is that they need to have a PM anyway so they might as well leverage them to do everything with the theory that the project is saving money. In these companies, the BA is getting downgraded to little more than a secretary required to document whatever the PM states and store it in the appropriate software.

2 – Project Managers can always do BA tasks or vice versa

– A project that is on a tight deadline cannot afford to have the resource distracted from requirements gathering with PM paperwork / issues. Try to gather requirements while putting together multiple project status / dashboards (and they all have the same deliverable date) and you will see what I mean. Sure this is not a problem when deadlines are not important.

– Not all BAs can do financial reporting / resource management as they have not been trained nor do they have the experience. After you have sat through a few cost center allocation discussions with Finance, you will enjoy getting back to requirements gathering

– Paperwork / Software used by PMs may be unfamiliar to BAs. MS Project and the latest tools all require some form of training / experience. Dashboards have to be designed / populated for projects which takes time away from requirements. It is the same for PMs trying to capture requirements as they may not be familiar with the software where the requirements are stored.

– Some PMs have no clue about proper requirement writing (ambiguity), business case development (what does the business really want and how to justify it) and it shows when the project moves through the phases. It is kind of like expecting a BA to be able to design databases. Some have it and some don’t.

3 – PM is the natural career progression for a BA

– NO it is not! Pure Project Management is different to Business Analysis. Even the IIBA acknowledges this when they ask you to describe the role you had in the projects you worked on. If you answer too many questions from a PM perspective they will not acknowledge that experience as being BA relevant.

 

Hopefully I got the point across that the BA versus PM debate is dead. To argue it anymore would be to ignore the trend in the industry which is downgrading / killing the Business Analyst job title making this whole discussion pointless.

As Business Analysts, we should be more concerned with making sure the role we are in ties into our skills. Remember, the BA title by itself is pretty much worthless these days as it means so many different things to different companies. Your focus should be on getting the skills / experience to be in the role you desire and not on the job title.

For a list of Business Analyst job titles, see links below:

Job Titles Job Titles

 

Next Page »