Are you just a glorified factory worker or do you focus on enhancing Skills/Experience?

Times have changed and along with it the expectation of the Business Analyst role.

There was a time when Business Analysts were hard to find and the skills of the role were high. Now however, a lot of roles are getting labeled as Business Analysts which is causing confusion since the people in these roles feel they are Business Analysts. In other cases, skilled Business Analysts are finding their roles not what they expected.

I make an analogy to the “Factory Worker” to state that if your skills are not unique then what value do you personally have to differentiate yourself from the competition for work? Factory workers are tied to the factory they work at. Certainly some of them may be skilled in operations of machines that can transfer to other factories but overall, the focus of the role is:
– turning up on time to work
– being efficient at the task.
– being able to complete a shift.
– skills required of the task are low.

If the above describes your current role, you may need to start questioning your future since now your success is tied to the metaphorical factory which can always move or have your role taken over by a cheaper resource. Just ask any US factory worker of the past 30 years if they are aware of this happening.

Focusing on the phrase of “skills required of the task are low”, think about the fact this means the person can be replaced by another easily. It would not take much to train a person to do their job. Now ask yourself if in your present role you are using skills/experience that could quickly be picked up by another?

If you are not careful and you take on a role or end up in a role that has low skills you are putting your future career at risk.

Time and time again, I see Business Analysts putting in long hours thinking that this will guarantee their future without looking at learning skills/gaining experience that will bring uniqueness to their personal skill set. End result for the ignorant Business Analyst is a future drop in salary and probable unemployment.

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.

3 ways to stay employed in times of large Tech layoffs

With Microsoft announcing 18k being let go because of merger with Nokia, it makes people wonder how to stay employed in the Tech industry.

The sad fact is that with the power of the internet, employees no longer need to be local to the employer which has lead to price competition for work. Mergers also cause duplication of work leading to downsizing. Finally there is also changing technology which leads to skill sets being outdated for the current role.

To stay employable you have to be monitoring your current skill set and be flexible:

1 – Ability to change geographical location

Sometimes the work dries up in your current location leaving no option but to move. To stay would either mean a salary cut or even a change in career.

2 – Willing to accept a salary cut

This is a very bitter pill to swallow. To be paid less to do the same work is like a punch in the gut (on a daily basis). If you do not truly enjoy what you do, you will probably be miserable in a year or less.

3 – New certifications

IT employees are like NFL stars at the pay of regular Joes, meaning that we have a short career in the lime light. In reality, the days of getting a good 20 years out of your skills is long gone. I would say 5 years is about it. After 5 years you are considered old and worthless. Once upon a time employers did value experience over specific skills in that they were willing to train you on the missing parts but now if you are missing a component from your resume, you become like a square peg trying to fit in a round hole. Keep an eye on what is in demand by checking the job boards and make sure that you are getting the certifications / training to pad out your resume. Remember that you are competing against every college kid that just got the new skills while at college and are willing to start for less than you are currently paid.


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.