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

 

Four components to measuring success of your product / release.

Whatever you are working on will eventually end up with a new or updated product being released. Prior to that release date, consideration should be given to how to measure success.

There are four components to measuring success:
1 – Determine what is to be measured.
What is the new or improved product supposed to achieve? Hopefully you already know the answer to this prior to even starting development.
A business should have clearly defined goals as to what is expected via the release of the new or improved product. These goals should be quantifiable in a mathematical way even if you have to hire a PHD mathematician to determine the formula that quantifies it.

Examples:
a – Game averages 1000 downloads per day over a 3 month period.
b – LED Lightbulb increases market share for our brand over others.
c – New website design increases revenue from marketing and attracts more visitors.

2 – Identify Channels to supply the measurement information.
Now that you know what you plan to measure for success, the next question is where to get this information from?
Channels of information can come in many different ways:
a – Data could be collected from social media site such as Facebook to see how many positive comments a new product gets.
b – Sales information could be tracked from online and physical stores.
c – Surveys could be performed on potential and actual customers.
d – Certain key words/phrases could be searched on in the Search Engines.

3 – Integrate and absorb the data from the Channels.
Once the source of the measurements has been identified, the next step is the actual integration of this data into your reporting system so that it can be sliced and diced to provide the measurement of success reports. Your PHD mathematician may also be needed here to weight the data accordingly so that no one channel skews the results unrealistically.

4 – Present the success data to the consumers.
Finally with all the data, reports can be designed / generated or data outputted for consumption by those who will make the determination that the goals have been achieved. At this point knowing who the consumers of the information is becomes critical as you need to present the data in a format that the consumers can understand and consume. You may need to engage UI/UX experts at this point if the presentation is using new technology so that they can help design the presentation.

Do your client’s business protocols match the current physical environment?

October 27, 2014 by · Leave a Comment
Filed under: Business Analyst Skills, Project Management, ROI 

Businesses can spend a lot of time documenting protocols for how certain events are to be handled when they occur. However, these protocols can be left to gather dust until the next event happens.

From a business point of view, the business needs to consider all protocols it currently has defined and weigh them up against priority of use – meaning that just because an event has not happened for a while does not meant that a slow response will work as gaps in protocol are uncovered due to changes in the environment. Protocols that require immediate response will be considered higher priority for review of relevancy versus those that can have a delayed response.

Examples of protocols:
1 – What to do when the stock market crashes?
2 – How to handle regulated products?
3 – Backup locations for offices if the current ones can no longer be used?
4 – Bad weather grounds plane throughout the country, how to get the planes back on schedule?

What usually gets businesses is an event that does not happen very often that has a high priority resolution required. As there is lack of practice some protocol steps may no longer be valid when the event occurs, people may not be trained in their use and the right licensing may not be in place to perform the task. Failure to respond quickly and correctly to the event can lead to significant income loss for the business involved.

Ebola case in Dallas 2014 highlighted several failures of protocol:
Lack of training / proper equipment lead to further infections.
Inability for toxic waste to be carried off site immediately because of transportation license restrictions placed on the waste which the transportation company did not have.
Limited ability for Hospitals to deal with their own sterilization as this has been outsourced in a lot of cases requiring the receiving location to be licensed to transport / handle the waste at a level they may not be used to.

As business analysts, we need to mentor our business clients through the risks of these often ignored protocols and ensure that they get the review they deserve. At the same time we need to limit the effort spent on protocols that do not have high priority resolution associated with them so that we can be good advocates of our business client’s expenses.

Moving to Agile tougher in big IT shops with Offshoring

August 14, 2014 by · Leave a Comment
Filed under: Business Analyst Skills, Project Management, ROI 

This desire or thought that Agile is quicker can put blinders on the people who suggest it.

In a small IT shop of very structured environment it may bring benefit quickly but in larger IT shops it can be a different story.

When implementing Agile as a method of delivery you need to consider:

  1. Does my department need to interface with other departments for either development or testing?
  2. Will systems be available when my offshore resources need them.

 

Point 1 – the other departments.

You may have gone Agile but that does not mean your other departments have. Imagine if they are in the process of implementing a change or you find a bug in their systems. How long will it take them to respond is a question you should ask. Otherwise the expensive Agile team will be sitting around doing nothing while you wait for the other department to resolve the issue.

Point 2 – system availability for offshore resources.

It is not such a big deal when you are waterfalling a project that every now and again a system may be down for a day or two. In the Agile world, down time is measured in hours. Every hour that a system is not available to a resource means lost time in the Sprint window. It will not be long before the whole sprint is impacted.

Remember then the impacts of Agile when working with other departments and offshore resources as it may not bring you the benefits you desire.

Wagile – Pronounced “Waa Gee Lee” – Blended Agile and Waterfall

We all hear a lot about Agile being the new and Waterfall being the old approach to software development.

So tongue firmly in cheek I am going to talk about those Agile projects that don’t quite cut off the ties with the old Waterfall.

What is known in the industry as Wagile.

Looking at Agile, we should have user stories for all the functionality required by the business. However sometimes it is just ends up with focus on one part of the functionality being done in  Agile mode while run of the mill ancillary items are handled in a more waterfall model.

I am not going to try and guess all the possible items that could somehow fall out of Agile into Waterfall but I am sure that you can think of a few. Most likely low risk candidates for Wagile is reporting – assuming that someone somewhere has identified all the fields that need to be captured and made available to the reports as part of the initial Agile development portion of the project.

So why does Wagile come about? Not everything can make it in the sprints so to keep the client happy, items are basically snuck in outside of the sprints using the Waterfall approach sometime under the support budget rather than the development budget.

Is this the wrong approach? No approach is wrong if it keeps the customer happy but don’t try to pass off your shop as 100% Agile if your are doing Wagile.

 

Changing project approach does not mean a quicker delivery

Sometime clients are concerned about the progress of a project and look at ways to speed things up.

One way I would recommend extreme caution with, is changing project process after a project has started. Now don’t get me wrong in that this rule does not apply in all cases, as sometimes it does make sense to change. However, if the project is only for a few months, valuable weeks can be lost in the adjustment.

How do you know when to change?

Ask yourself the following questions:

  1. Is the current process so flawed that it will not meet the end of project objectives / goals?
  2. Is the project of long enough duration to allow for the ramp up time to adjust to the new process?
  3. Are my staff familiar with the new project approach?
  4. Has there been other projects that have used this approach in the past within my department?
  5. Are standards and training materials in place that will allow my staff to quickly adjust?

If you answer NO to any of the above questions, understand that this change in process may have a more negative impact than you allowed for.

Reminding Business to focus on the business need and not on the solution

A few years ago I was asked by a client to get on a plane to Florida to meet with some business partners and do a final business review of a requirements document that someone had put together.

When I arrived, the business partners present thought that in a few hours we would all be done reviewing the requirements document and then we could then spend time over the next 2.5 days discussing other items. After all they had spent several other sessions over the past few years developing the document so as far as they were concerned it was in a final state. That was until I came along.

The requirements document I had been asked to review had been written in the format of making business work around perceived constraints of IT. It had a good explanation of what the business were trying to do but not the actual business rules behind them. Instead the business had adjusted their rules to meet what they thought the IT department would require.

Two days after I arrived, we finally had a good working document that focused on the business rules and left it up to the IT experts to work out how to implement. Dozens of perceived technology constraints were removed from the document and the business eyes were opened up as to how an IT solution can help rather than hinder their business.

I see this time and time again, where less experienced Business Analysts allow focus of a requirements gathering session to end up bogged down into making Business Rules that tie in with supposed constraints on IT solutions. In turn this leads business to expect little out of IT because they don’t expect them to deliver a great solution. Worse still, the self imposed constraints mean that items that are not delivered from the bad requirements are considered of higher failure because the business compromised so much in writing the requirements.

As Business Analysts there are times when the focus of the solution should be constrained by IT up front but those situations should be clearly defined in the scope statement. When it comes to large Business opportunities, IT constraints should be limited, as the whole purpose is to enable the business to move forward and not hold them back by using out of date solutions.

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.

 

Next Page »