Become more hireable – use project specific examples in resume

The business analyst role in its various forms has been around for more than 25 years. This means that there are a lot of business analysts out on the market looking for work.

Employers are no longer turned on to a candidate just by the fact they have lead JAD sessions, captured requirements etc. This is so common place I think everybody has it on their resume in some form or other.

In some ways Business Analysts roles has become like programming roles where the details of what you have experienced get you hired.

To this end, employers are now looking for a dovetail like fit into their open vacancies.

What this means is that Employers look at:

1 – Industries you have worked on. Being able to leverage your experience in one industry to translate into others is important here. Here are some examples of industries:

  • Insurance
  • Finance
  • Health Care
  • Telecommunication
  • Capital Markets
  • Retail
  • Transportation
  • Consumer Goods
  • Energy

2 – Specific projects you worked on. As I mentioned in a previous post, there are at least 5 types of business analysts out there and depending on what role the employer is trying to fill you may or may not be a fit.

All is not bad news. Because an employer is being picky about their candidates, they may be willing to overlook what Industry you worked in if you have the right projects under your belt and vice versa be willing to look at you if you have been in their Industry.

So when you are looking at opportunities for your next gig, think about how it will boost your resume and also be sure to mention the experience in detail once completed.

UI Designers need to understand limits of Project Team

Back to my football analogy again.

In this case we have a Quarter Back calling his dream plays but not taking into consideration the qualities or experience of his team.

So what am I getting at here?

Imagine you are working on a Customer Facing application and you call in a User Interface company (the Quarterback) to design the Front End and it’s their first time working with the Development team (rest of the players). Quarterback keeps throwing the ball but nobody is catching it because they don’t know the plays or signals.

It is important for the success of a project that the team gets onboard to understand each others strengths and weaknesses early on in the lifecycle of a project. If this team relationship is postponed till later then everybody ends up playing catch up as they try to resolve the issues. In Football terms, this means the opposition wipes the mat with them.

So imagine if your UI designer is designing screens that the Development Team is not comfortable to implement for various reasons – stability, development effort etc. It is better for the sake of the project that the UI designer knows and understands what he has to work with so that efficiency in design can be achieved.

Some of you will argue that the Development team should work to the level of the UI designer because his word is the rule. Unfortunately that approach is short sighted. We don’t live in a perfect world and at the end of the day there needs to be a little give and take between both sides. A team full of individual stars usually does not win a game over a mediocre team that plays well together.

Certainly a badly designed site will fail but most UI needs can be met with various solutions and the UI designer needs to be flexible to understand which solution can be implemented within the constraints of the project.

Some may ask how all of the above affects the Business Analyst. In simple terms, the amount of rework required to manage the changes Development bring about leads to inefficient use of the Business Analyst as they continue to rework their documents to meet the new design.

Increased Requirement Cost – Off shore Development and Testing

It has long been said that Off Shore reduces cost and if planned well it can. No longer are companies competing for the few local resources because they can pull from a larger pool. So why then am I jumping on the band wagon on another negative cost to Off Shoring? Simple, the team relationship no longer exists and the benefits that go with that are lost as well.

When your development and testing team are local then the information shared with them is local as well. As time goes by, the team works and plays well together.

Imagine if you were coach of a football team but your quarterback was based in the US, your offensive line was based in another country and your defensive line in yet another. What would game day be like when that team meets for the first time on that day.

It takes time for a team to get to know each other and understand their weakness and strengths. That is what makes a team.

Some companies to counteract the parts of the team being in different locations have started to put resources on shore to dive deep into requirements to clarify questions before the requirements are sent off shore to be developed and tested. Seems like it would solve the problem but in all reality it has just highlighted the problem that was known all along.

Off shore teams are not in the game. They have no feel for the strategy as they are not living it every day. Instead they must be given detailed instructions as to what to do when. The on shore resources are now enforcing that these detailed instructions be delivered. Ambiguity is not tolerated in even the smallest of requirements. Certainly there is less lost in translation and the work delivered back from Development and Testing is closer to what is needed but still the team is not a team but rather a programmed response to a set of plays. If the opposition play a move that was not documented then the team falls apart.

So where is the increased cost? Increased cost comes in two ways:

  1. Not every requirement is worth the cost to document in detail.
  2. Flexibility is costly.

If a requirement is simple (such as a label change), in the team days a simple email would suffice. Now however, it must be documented over several pages since the receiver of the document may have no clue about the application that is being modified – never played on the team before. Multiply up the number of simple requirements by the additional documentation cost and the expense soon adds up.

In regards to flexibility, since everything is documented to the Nth degree that means changes also have to be documented to the Nth degree as well. Yet again, like the simple requirement example up above, changes to requirements can be costly.

In conclusion, the next time you are estimating for a large project with off shore resource, remember to include the increased detail cost that comes along with that.

 

 

5 Common Types of Business Analyst

November 11, 2013 by · 1 Comment
Filed under: Business Analyst Skills 

A lot of people these days call themselves Business Analyst (BA) but put them in a room to talk and you will soon see they are quite different.

This difference also creates problems for employers as they need to find the right BA for their role.

For this post I have broken the types of BA’s into 5 distinct groups that require unique talents to be successful. I am sure that there is more and feel free to comment with your suggestions. It is quite possible for a BA to have been in all 5 roles but the longer they are in one role, the weaker their skill become in the others. In later posts I will go into depth on each role so you can gain an understanding of what the pro’s and cons are.

1 – Business Process Analyst

The focus of the Business Process Analyst is to look at Business Process and see opportunities for improvement beyond the limitation of IT. They may suggest hiring additional people in a role, timing changes of process events and even communication methods. May even suggest IT solutions. Note however that they are not limited to just Information Technology. Generally a Business Process Analyst is knowledgeable about the business to the point that they could perform tasks within the business realm. In fact a lot of Business Process Analysts once worked on the business side, even gaining licenses in the chosen field. Think about Nurses or Doctors advising on business process because they know the role very well. It is unusual for an IT Business Analyst to end up in this role for they do not know the business from not having worked in it. Business Process Analysts, generally are the highest paid of the Business Analyst roles.

2 – Business Data Warehousing Analyst

Data Warehousing is all about data and to be in this role, you need to be comfortable spending you days looking at data elements, tables and database structures. This is a great role if you don’t like interviewing people to understand their job so that you can capture requirements. Most of the focus of this job is gathering data to store in the Data Warehouse and responding to request for data from the Data Warehouse. My friends in this role like it because it does not change much and they don’t have to deal with business users as much.

3 – Business Reporting Analyst

Sometimes this role is included with the Data Warehousing role but other times it is not. These BA’s spend their time pulling data and formatting it for report generation. Knowledge of databases, reporting tools and ways to slice and dice data is usually a requirement for this job. As well as a keen understanding of the requirements that go along with reports – summary fields, paging, sort order etc.

4 – Business Infrastructure Analyst

They gather the requirements around IT infrastructure upgrades. It is a technical role (at least you have to understand technical jargon relating to networks, servers and software upgrades) and rarely involves direct business involvement. Focus is more about making sure IT projects have their infrastructure requirements documented and met. Think along the lines of a Windows Upgrade project and you will get the idea.

5 – Business Application Analyst

Consider this role the more traditional IT BA role however it is going through some changes which I will discuss in a later post. These BA’s work closely with the business to provide IT solutions that tie in with their business process. Generally they are approached by the Business to provide an IT solution or enhancement to their existing business process.

So there you have it, 5 possible BA roles that you may end up in. Each role requires different skills to be successful in and I look forward to discussing them with you at a later date.