Business Analysts are a waste of money

Today I wanted to rock the boat a bit and state that Business Analysts are a waste of money and how employers should avoid the waste.

Why you may ask am I saying this?

I am saying this because too often a Business Analyst is seen as the solution to any problem with a project.

Short a project manager or tester, hire a Business Analyst to do the job.

Last release was a mess, hire a Business Analyst to fix it.

Need some documentation done, hire a Business Analyst to write it.

Business strategy not getting implemented quickly enough, hire a Business Analyst to implement.

For centuries, the world existed without the Business Analyst job title. Now the market is flooded with people claiming to be a Business Analyst of some sort along with managers thinking they know what a Business Analyst is.

This has led to employers hiring someone to fill a job because they meet the requirement of the Business Analyst title. In the best case the Business Analyst will adapt to the role. In the worst, they will fail miserably because the role is not a fit for their experience. In other cases the employer keeps the Business Analyst in their position long after the role has changed to something else just because they have a good working relationship.

So how should employers fix it?

Employers have to think about:

  1. What their perceived skills of a Business Analyst are and how does that relate to what the industry thinks a Business Analyst does? For example, Business Analysts can write but they do more than Technical Writing so if the role is purely for writing, hire a writer.
  2. What skills they need in the role?
  3. When do they need the skills and for how long? Take a development project for example, at some point the requirements will be 99% complete and then it is off to testing. So at some point the employer goes from a shortage of Business Analyst skills to QA skills.
  4. How structured and large is the environment? No point in hiring a fortune 500 Business Analyst if you are a mom and pop shop that is looking for someone to maintain your web site.

The above is not an exhaustive list but just rather something to make employers think.

Personally I will be one of the first to tell a client if I feel they don’t need my skill set at the time of hiring or later in a project due to role change and make suggestions as to who they should look for. It is always in my interest to make sure that the relationship between client and consultant is a win win for both parties. I know this is contrary to large consulting practice and has cost me work. I however feel much happier for it and so do my clients.

 

Business Analysts are catalysts to success

People outside of IT often wonder what a Business Analyst does and that includes our business partners who we work with. Their is great concern that we do not provide “Value Add” services.

 in the BA times recently wrote an article about BA’s thinking of themselves as bridges and how that is wrong.

I have seen the bridge thinking BA’s in action, and they are no more than note takers and usually midway through a project nobody is happy with the results.

As Business Analysts, we are there to act as one of the catalysts that make the project successful. However that does not mean a BA that does well in one project will do well in another if they do not have the skills.

If you look at the job search engines you will see that BA skills required for roles can vary from company to company and department to department.

Examples:

  • Data Warehousing BA’s are expected to understand database structures and know SQL.
  • Business intelligence BA’s can need some of the skills of the Data Warehousing BA along with reporting tools and statistics.
  • Front end BA’s are expected to understand UI/UX, use cases.
  • BA’s that specialize in Business Process are expected to understand the business they are working with.

What we can see from the desired experience is that companies want a BA that can mentor and guide. Having the ability to just gather requirements is not enough. There is an expectation that a BA will bring knowledge and experience to the table along with other soft skills such as negotiation.

It should be noted though, that some companies are not prepared to let the BA mentor them because of their thought of the BA being just a bridge between IT and Business. It is up to the Business Analyst to break down this stereotype to make them realize the “Value Add” that a BA can bring to the table.

ui – Tactile feedback – Why BA’s need to consider cost of failure without it.

In this article I want to ask Business Analysts to consider risk cost calculations when it comes to UI that reduces or removes Tactile Feedback from a user interface.

I like to share examples of User Interfaces that seemed good in the lab but not in reality.

In the book  Yeager by General Chuck Yeager / Leo Janos,  the pilot Chuck Yeager makes reference to the one time the F16 airplane had a “Fixed Force” sidearm control. Basically a control stick that did not move but relied on the amount of force the user applied to it to determine what the controls would do.

It was not a success as the lack of tactile feedback made it difficult for the user to know how much force they were applying. In his case, they replaced the fixed with a moveable stick that could move about an inch in two directions.

Even then, moving of a stick by itself may not be enough as witnessed by the crash Air France Flight 447 on June 1st 2009. The article link below explains how lack of Tactile feedback may have led to the crash of the flight. In the article it is suggested that since the co pilot could not see or feel what the other pilot was doing (they were using a sidearm control) he was unable in time to rectify the situation.

http://www.telegraph.co.uk/technology/9231855/Air-France-Flight-447-Damn-it-were-going-to-crash.html

With the advent of more touch screens devices, we are bringing the lack of tactile feedback to the masses. Certainly we can feel a swipe of the screen but when it comes to pressing something, we have no clue by our touch that the event took place. Even with the swipe, it is possible that the screen was dirty and thus did not register our swipe. In not all cases will it be possible to follow our hand / finger movements with a glance by our eyes thus making the Tactile feedback more critical in those situations. We could add sound to each contact but then that can lead to over abundance of sounds which in themselves become a distraction from the task. Military pilots in various recent wars have complained about having cockpits full of various informational sounds all at one time that if they can turn them off they do. This act of silencing the sounds nullifying the benefit the sound was meant to serve.

While we can see the advantage of the flexibility of the touch screen in that we can change the controls displayed to match the task at hand, the risk of the task needs to be considered. As Business Analysts helping business introduce new technology, we must make sure that the risk of limited or no tactile feedback is calculated against the cost if something goes wrong. This information will help fund the UI/UX department in their quest for the best/affordable UI interface for the situation.

 

How fake UX/UI experts impact your Project and Profits

General process for IT visual design in Technology. Web, Mobile, Tablet, Smartphone, UX and UI experience.

General process for IT visual design in Technology. Web, Mobile, Tablet, Smartphone, UX and UI experience.

Why, I question am I still seeing issues with Visual Design projects that affect Web, Tablets and Mobile applications? After all the years we have been doing this, it seems that important steps are getting lost in the mix. The end result is a partial or failed implementation or a project that runs on longer than anyone thought it would.

20 years ago, a company may have been forgiven for issues with their customer facing web site but now that everybody has been doing this for a while, forgiveness is in short supply. You either get it right or face a backlash.

We have learnt that with the ability to quickly present a screen to a large audience there must be some thought as to how well it will be received. Companies have expanded their development groups to include the following roles to improved UX/UI:

  • HCI expert – a person or group of people that look at how the company web site or mobile application will be used and determine the best way to design it from a usability perspective.
  • Graphic Artist (GA) – takes the finding of the HCI expert and produces rich mockups that mimic the end result. In some cases they GA may even provide the actual production code.

Why then are Visual Design projects facing issues? These issues then lead to rework that puts more pressure on the rest of the team to make up the shortfall in quality. For a Business Analyst / Product Owner, this means less time to be working on the next project as they get stuck picking up the pieces of the current one. Budgets are also blown as the project extends its timeline limiting funds that could have been used for more new development.

My experience is that people and companies are claiming they are UX/UI experts but really they are not. They don’t know anything about personas; how to communicate design, how visual design projects work. I am sure they don’t know many other things about UX/UI but the former items are what I will focus on.

PERSONAS

A company needs to know who they are reaching out to with their Visuals on the internet. Personas affects how a user will interact. Some personas may be more computer literate than other. Studies need to be done to determine what works and what does not from a design perspective.

COMMUNICATING DESIGN

This is big one. Anyone can make  a pretty picture of what a screen should look like but can they explain all the possible user interactions that can happen in a way that development and/or graphic designer can understand and implement. Ambiguity here leads to either a failed implementation because of wrong interpretation or delayed implementation as questions on design are resolved. Those delays can lead to the project doubling in length.

VISUAL DESIGN PROJECTS

Many components go into a Visual Design project. On the one hand we have the screen interactions and on the other hand we have the technology to be used. A UX/UI team that silo’s itself from the rest of the project team ends up creating work that may not be applicable to the group. Examples: developing a solution for Android devices when the company plans to only support Apple devices or a Web design company that you hire to work on Mobile Applications.

 

I could go on for several days on the subject of UX/UI impacting project but I wanted to keep this article as a  light weight discussion on how fake UX/UI experts impact projects.

To leave you on a good note, here are some suggestions on how to Identify the fake UX/UI experts:

  1. Request examples of their persona studies. Get them to justify the personas and what they learned. Ask them if they know what 508 compliance is.
  2. Request examples of their design documentation that shows wireframes/mockups and put your developer hat on and see if you can find any ambiguity in what is presented.
  3. Ask what technology they have worked with and see if it ties in with what your company is doing. Too many companies don’t see the difference Technology brings so they assume that because they had success with the Web they can easily do Mobile Applications.

To get a good understanding of UX/UI, I recommend reading the articles presented  by the Nielsen Norman Group.

 

Starbucks Coffee – Two lessons on Business Analysis post Proof of Concept

I was reading Howard Schultz /  Dori Jones Yang book – Pour Your Heart Into It (1997 Hyperion)- when I saw two examples on how missing items during the analysis phase can impact you later.

1 – United Airlines – Coffee. In January 1996, United Airlines started serving Starbucks coffee. United and Starbucks knew that the brewing equipment needed upgraded but not all of the equipment was in place by day one as the equipment supplier could not produce the parts needed by the deadline. It took four months to fix. As Business Analysts we have to consider the impact and risk of a proposed solution to the timeline of the project and raise alarm bells should there be a concern of the solution not being in place on time.

2 – Eggnog flavored syrup. In 1994 a decision was made to save money and speed up handling of Eggnog flavored coffee by using a syrup instead of a carton of eggnog. Proof of concept and quality control was not properly done leading to an implementation that backfired. The end result was a return back to the process of using the eggnog cartons the following year. When working on a solution that is fundamentally changing the product that is sold, great care must be taken by the Business Analyst to:

  • A – Ensure that the proof of concept guarantees that the new product is equal or better than the old in a measurable way.
  • B – Final implementation plan does not cause the quality of the new product to deteriorate below what was shown at the proof of concept.

Business Analysts need to be able to think beyond the obvious to identify the risks and problems that can crop up. There is a tendency to get caught up in the moment by short term success and lose sight of the greater picture.

In both cases above, the team failed to see beyond the initial proof of concept the pits in the road that would cause them trouble.

Where Senior BA’s end up

I am actually going to take it easy this week and refer you to an article written by someone else.

This article is good reading if you are considering a career as a Business Analyst or are at the more junior end for it lets you know what the 10 year career path is.

After reading it, you may want to reflect and consider where you would like to end up and steer your ship in that direction.

What is the future for Senior Business Analysts

Happy reading

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.

 

 

« Previous Page