Process improvement through nudging

As business analysts, we are called in often to look at ways to improve the current process. Measurable improvements desired by the business to justify the process improvement could be in:

  • Quality
  • Reductions in costs
  • Increase in processing per hour

Any process to be improved has a certain amount of dynamic variability to it. From a high level math perspective, the processes are looked at as “dynamic resource allocation” because of the variability factor. By controlling the variability with nudges we can improve the process.

  • NOTE: With the advent of stronger AI, in the future we will see more reliance on AI to advise as to the best way to improve a process and it will be left up to the Business Analyst to help put AI advice in place.

What is “nudging” and how is it used to improve a process?

Nudging is where we don’t force a change of process or add new processes to improve process but instead nudge the behavior of the participants in a the current processes to get the results desired. A current example of this is where financial institutions offer rewards to customers if they go paperless for their statements. Going paperless improves:

  • Percentage of outstanding statements processed per hour as smaller printing backlog.
  • Speed of delivery as they are delivered in hours instead of days.
  • Quality in the sense that the statement does not get delivered to the wrong address, does not get damaged in printing etc.
  • Cost reduction as less mailing costs.

You can see from the 4 bullet points above, that a lot can be achieved by just nudging the customer in the statement process to no longer expect a paper statement.

So the next time you are looking at improving a current set of business processes, ask yourself if you can make improvements by “nudging” the current users of the business process in a direction that would support measurable improvements for less cost than force implementing changes or building solutions that have to manage many variables.

What kind of business are you in?

The question “what kind of business are you in?” seems simple enough and is a standard question that businesses ask themselves to stay relevant and not lose sight of their market. However as we know, the answers to simple open questions can end up being complicated. Looking at an example of a wrong answer for this question: railroad company thinks of themselves as a company in the railroad business, not realizing they are in the transportation business. An extreme example of bad decision making was Kodak not realizing they were in the memory / emotion capture business and instead they focused on providing film and print material because it had made them money for over 100 years. By the time they realized what business they were in, it was too late.

You might be wondering what direction I am taking this in. I want you to consider how you would answer this question in relation to your current career as a business analyst.

As a business analysts, I consider we are there to help generate improvement of profit and or reduction of costs for the companies we work at. However most employers (who are actually our customers) don’t see that in our role but instead look upon us to be specific in what we provide them in terms of knowledge and experience. Examples would be:

  • Payment handling
  • Healthcare data processing
  • General data analytics
  • Anti money laundering
  • Utilities
  • Mobile applications development
  • etc..

This narrow role definition by our customers puts us back into the mental mode of thinking that we are in the railroad business and not in transportation. Basically our customers are not going to tell us that they plan to make us obsolete with a new solution to their business needs or that they are losing market share in their industry (leading to job losses). We have to think beyond what we immediately provide to the customer and consider at least two things in our careers.

  1. Industry trends
  2. Tools we use

Industry Trends:

  • Is the Industry that we are working in shrinking or growing in our geographic location of work? Example – think of factories that get closed or corporate mergers either of which would reduce people needed in the industry.
    • To overcome, you would either need to gain experience / knowledge in a new industry or move location to where the work is (if that is an option).
  • Are there current or future disruptions to the way the work is being done in our industry that we need to be aware of? Example – looking at the railroad, the rails, trains and railcars are just a tool used in transportation. Certainly they help the railway business make money but as the railway companies found out in America after the interstate roads were built, new options for transportation by road upset the apple cart. Money invested in trains and railcars was lost because these tools did not work on the road. Basically being only in the railroad business was going to cause a loss of market share, decline in profits and decline in employment opportunities.
    • To overcome, you need to stay aware of advancements in technology / process that could impact your industry and seek knowledge / experience with the new and even considering changing industry if the new will make your industry obsolete and or reduce its market share causing a reduction in employment.

Tools We Use

  • Are the tools required to do your job changing? Example – with the move to more Agile IT work we are expected to have used formal tools for managing user stories, backlogs etc.. Reporting is another area where tools are continually evolving.
    • To overcome, you need to monitor the tools specified in job postings prior to your next job, have a budget set aside for training, get the training and if possible work out how to get experience with the tool/s.

In summary, don’t let your current success with customers blind you to the market. Stay current with what industries are doing (growing or shrinking) and what tools you need to do your job. That way you will continue to help companies improve their profits and reduce their expenses. Plan to budget for time and money to be spent to keep yourself marketable to customers. Be prepared to ditch an industry if the future looks grim. Don’t focus on pure profit, invest in yourself to stay in line with the market otherwise you may become the next Kodak.

VW a lesson in marketing versus regulations

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.

 

The industrial revolution 2.0 – where Jane & John Doe programs make sense

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.

Amazon pickers is an example of the humans still meeting the need.

When do you ask does it make sense to replace the human programs (lets call them Jane & John Doe)?

NOTE: This article is a somewhat tongue in cheek consideration of the removal of humans from the workforce and is not meant to offend anyone who is worried about AI takeover.

Let’s first look at the benefit of our human Jane and John Doe programs:

1 – Easily programmed if task is not too complicated.

2 – Can be programmed by other existing programs.

3 – Adaptable interface – Buttons, levers, switches etc.. are not an issue.

4 – Can be replaced if failing.

5 – Low short term investment costs.

6 – Can be easily reprogrammed as tasks change.

7 – Multiple interface methods for programming – auditory, touch, visual.

 

The cons of Jane and John Doe:

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.

 

When software kills due to incomplete requirements

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.

Lessons from spaceship two’s crash

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.

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.

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.

UX, UI and Usability – 3 Components that affect Product Greatness

Today I am going to discuss the Hot Topic of User Interaction since it seems to cause many companies problems.

Looking at the main components of User Interaction, we have:

3-Parts-Of-Usability

UX, UI and Usability. The 3 components of good interaction design.

UX (User Experience) – This is the catch all for the user experience with your product that has not been covered by your personal User Interface definition (UI). It is all encompassing. Things like color, texture, speed, efficiency, reliability, words, fonts etc. can fall into this bucket. Depending on what your product does, the list could be vast.

UI (User Interface) – This is interface between the user of your product (may not always be human – think dog door) and the product itself. Depending on how well you understand the users, the interface may be great or a complete miss. UI can be built without any consideration for UX since at the end of the day by definition, UI enables a user to interact with a product. To explain the previous sentence, think of a Light Switch. Your office may have light switches that are all the color red. If I give you a white light switch to replace a red one, it is still a valid UI solution since it can be used to turn lights on and off but from an overall UX perspective I have just changed the color to not match any of the other light switches.

Usability – Different users will have different usability needs. A cat door will not work with a large dog but may work with a small dog. Understanding the needs of your users will influence the User Interface. A misunderstanding here could lead to a UI that is only partly successful. In the perfect world, the UI should be a perfect match for the needs of the users.

 

UX-Good-Design-Components

Good Interaction Design means that the UI (User Interface) and the users that will use it are a great match and overall the interface creates a great UX (User Experience).

When we look at a well designed product be it software, web site or a physical product like a Dog Door certain things are evident:

  1. The User Interface ties in perfectly with the User of the product requirements.
  2. The Product looks and feels great to the user and the UI dovetails nicely into the UX.

 

UX-Bad-Design-Components

Bad UX means that the User Interface does not match the requirements of the Users and the overall UX is not great.

If we look at bad interface design it has missed the needs of the users and the overall user experience beyond the user interface is not great.

Why do we end up with bad interface design?

  1. Expectation that the person designing the User Interface (UI) understands the current needs of the users that will be using the product. Just because someone is able to build a UI that does not mean they understand the users that will be using the end product. Think of the light switch example given previously.
  2. Not building a new UI when it is not working or significantly changing the UI to meet the needs of the current users or new users without research.
  3. Usability requirements incomplete or the users of the product not understood. You could come up with a great touch screen application for use in food factories only to find out that they cannot have the glass of the touch screen on the factory floor because of contamination risks to the food product if the glass was to break in an accident!
  4. No research done with users to get their feedback on UI / UX / Usability before or after the product is created.
  5. Cost cutting done at the expense of Usability / UX i.e. the focus being on getting the UI released at all costs.

How to create good interfaces?

  1. Understand your users in detail.
  2. Work with experts that know how to establish the important interface requirements to meet the user needs.
  3. Track the user experience before and after the product is released to pinpoint problems.
  4. Don’t rely on the UI person to do the UX and Usability or to even have the skills to do this analysis.
  5. Leverage interfaces that have already established good Usability / UX and modify them to meet your product’s needs – Don’t reinvent the wheel unless your product further enhances Usability / UX and you have proven that with research.

 

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.

Are you losing money by not monitoring how your customers are using your product?

July 13, 2014 by · Leave a Comment
Filed under: Business Analyst Skills, ROI, Web Sites 

If you have a product that customers use to reach other customers have you considered the ramifications should customers start to use it in unexpected if not undesirable ways.

The outcome here can be both positive and negative.

Think Craigslist.org – they came under the spotlight at one time because people started to use their software to sell sex and in some cases it involved trafficking of people. I am sure that the founders of Craigslist did not foresee this unfortunate outcome of their useful product. Gun manufacturers fall into the same issue with people using their weapons to commit crime.

Alternatively if you monitor how your customers are using your product you may find opportunities to expand beyond your original mission statement. Anecdotal story was that at one point, students at a university were taking the milk / bread crates from grocery stores to make dorm furniture at a university in Ohio. It got so bad that stores had to start arresting the crate thieves. Now some smart person at the company that made the crates realized they could sell them to the students and make some money. The rest is history.

It is important to keep track of how your product is being used by customers:

  • It can prevent damage to your brand.
  • It can provide a possible new revenue stream.

Next Page »