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.

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.

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.

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.

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.

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:

At some point in your Business Analyst career you may be asked to meet with Board level staff. This should not frighten you if you follow some logical tips.

1 – Don’t go it alone.
Find someone to help you setup, run and share results/minutes of meeting.

2 – Make sure someone in the room can vouch for you.
Someone in the room of a senior enough level has to be able to support you when things get tough. If you don’t know anyone, reach out to at least one individual prior to the meeting to introduce yourself and get them on your side. Failure to do this could leave you in front of a firing squad.

3 – Know who the most senior people are in the room and respect their authority.
If you don’t know who a person is that has the power to end your job, better to find out before you challenge their meeting behavior or statements.

4 – Define the rules and objective of the meeting.
Always good to define the rules and objectives. Please note however, the higher the level of meeting the less the participants are willing to listen to the rules, in those cases you have to go with the flow.

5 – Dress to match the meeting participants.
If the meeting is a suit and tie affair, wear them.

6 – When things go astray.
Ask the participants if they are open to taking a break.

7 – Be Bold but not Reckless.
Be careful of how you control the meeting. Being respectful to participants is key and don’t get sucked into arguing with them. Note and accept their objections then move on.

8 – Meet one on one post meeting to resolve issues.
Since you avoided the argument, afterwards is when you meet with the individual or subordinate and work to resolve their issues.

9 – For long meetings, meetings at lunch or dinner make sure the food and drinks match the level of staff.
Quite often you can reach out to the personal admin of the highest of the participants and work with them to schedule the right food and drinks.

10 – Be flexible.
Senior level staff availability changes at the last minute. You may find your meeting getting shrunk or bumped. Often these people are used to meeting in the evenings post the regular work day.

11 – Learn the individual personalities before hand.
Knowing what to expect from the individuals involved in the meeting keeps the surprises to a minimum.

12 – Know the terminology / acronyms
Either learn the stuff before the meeting or have someone with you who can whisper / Instant Message you what is being said.

13 – Use IM to get live meeting feedback
If you or your companion is not presenting, have your senior friend in the room (point 2) let you know if you are going off track by Instant Messaging you feedback to the computer that is not presenting – don’t want the IM to appear on screen.

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.

Since I have been working for so long at different clients I have gotten a good understanding of terms used in the business world. However others of you may not have the same experience. This lack of understanding can affect you doing your job and even getting hired in the first place since you may have to do a scenario interview.

To help you with this, I have added a link to a online dictionary of terms used in the work place to my blog and also provided it below.

Often I hear a fellow Business Analyst say that the sponsors of his project and the project manager are complaining that they, the Business Analyst are taking too long.

Assuming that the Business Analyst is competent then why does this project delay occur?
1 – Business did not really know what they wanted or needed from the project but they thought they did.
2 – New Technology or unproven technology is involved.
3 – Project schedule was unrealistic to begin with.
4 – People that need to answer questions are not making themselves available or are not available.

Business Analysts need to determine the above issues as quickly as possible and bring them to management attention. Delay in recognizing these problems will lead the blame on project delay to be directed towards the Business Analyst instead of people working to find solutions to the obstacles.

Note: Not all managers are created equal! Business Analysts have to be aware of how a project runs and be willing to bring issues to management attention hopefully with recommendations on resolving them.

Sometimes we invent an wonderful product for a job but then find out it is missing a supporting component.

While watching a recent program about fighter planes in the US Vietnam war it talked about how initially the planes were only equipped with missile technology to shoot down enemy aircraft.

What was found in practice was that shooting down an aircraft from a distance was great but unfortunately at the time the pilot firing the missile did not know if the aircraft was friendly or not. The pilots would then close into investigate and end up in a dog fight where their missiles were not as good as a gun. Eventually guns were added back to the aircraft.

Taking from this lesson 2 points that were missed during the design / testing phase:

1 – Tests carried out were too controlled and did not reflect reality of the environment. It is not enough to be able to shoot down an aircraft at a distance, we also need to know if it is meant to be shot down. This identification piece did not come up in testing since the pilot picked a target he was given and shot it down.

2 – Focus was on single objective without consideration of supporting objectives. Objective of being able to shoot down an aircraft at a distance, did not include a secondary objective of how to identify if it was to be shot down.

If we look at a High Level requirement statement for the above:

“Pilot of airplane needs to be able shoot down an enemy plane first”

Main points of the requirement:

1 Airplane:

a) Needs to work with the device that will shoot down the plane

2) Shoot Down

a) Enemy plane needs to be removed from the sky somehow

3) Enemy

a) Need way to identify the Enemy from friendly

4) Pilot

a) Needs way to target device against Enemy plane to be shot down

5) First

a) Hit the enemy before the enemy hits them.

All but points 3/5 were completed successfully. Since the understanding of the word Enemy is common place, there is the assumption that technology will also understand what an enemy is without instruction. This was the failure of the project.

When working with clients, it is important that your role as a Business Analyst is not degraded.

In my last post, I talked about how Business Analysts are involved with negotiation. Part of negotiation is maintaining a tight control on communication so that mixed messages are not communicated that can lead to misunderstandings of roles / responsibilities.

Never allow someone on the development / production team (builders of solutions / project managers etc.) to contradict a statement that you have made to the users of your products / lines of business that you are doing the analysis for. It is fine for the development / production team to make suggestions on changes with you personally so that you can craft a response to share with your users / lines of business that does not alter your perceived position.

If the communication is not managed, then the users / lines of business can start to wonder if you are the person they need to be talking with since others can present statements that make them seem as if they have the final say on what is analyzed. Nobody wants to waste time talking to the assistant. If others can contradict you, it makes your role seem like the assistant role. You will then find that people will make themselves less available to talk with you or will question your ability to do your job because they perceive someone else as being the lead.

Make sure therefore that all understand the rules of communication after you have presented information to your users / lines of business.