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.

Project behind schedule it must be because of the Business Analyst

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.

Is the development of your product missing an objective?

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.