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.

Negotiation is an important part of the work I do and sometimes the clients I work with are stuck in the mud when it comes to accepting progress.

When a client refuses to move on after the benefits of the new product / solution are explained, then I move at them with the risks.

Simply put, I document the risks of staying with the existing option and get them to accept that they are willing to live with those risks.

Purpose of the exercise is to make the client think about their current approach from their point of view, not with me trying to sell them on it. If the client has managers further up the food chain, and they are advised of risks being present they also help to put pressure on the hold outs to think carefully about their approach.

Usually after a few days of discussion on the client’s side around the risks, the client is willing to adopt some part if not all of the new product / solution. Even if they do not adopt, I have not wasted my time negotiating against a brick wall.

If your product is going to replace a human in a work role, it does not need to do the work faster than the human it replaces if there is currently a wait time or reliability issue involved with the human role it replaces.

Examples of where you can see this today in current society:

1 – Elevators – most standard tall buildings have somewhat dumb elevator control systems that take no account of the number of people in the elevator or where they are going. Contrast this with the days of when elevators were controlled by humans and they were much more efficient in getting to their destination.

Elevator was full, the operator did not stop at floors to pick up new people but instead emptied the elevator out first.

When letting people off on a floor, they would ask anyone waiting for an elevator where they were going to see if it made sense to jump on their elevator or wait for the next one.

However, if for any reason there was a shortage of human elevator operators, then effectively the elevator had to be taken out of service. By removing the human element, there is now less of a chance of the elevator being taken out of service thus reducing the potential wait.

2 – Self check out – have been springing up in stores all over the place. One employee can now monitor dozens of check outs that the customer uses. There is no way I can check out as fast as a seasoned cashier but I am now less likely to have to wait for a cashier and this reduction in wait is the benefit.

There is one caution to this story however. As time passes, people are going to remember less the benefit of the slower solution which leaves the market open for a company to invent a new product that works faster than your product. Bit by bit, elevator systems are becoming more sophisticated which means as companies look to replace their aging systems, the old benchmark of performance may no longer be good enough. I can see in a few years where the mere fact of me scanning a product at a self checkout will be replaced by RFID tags inside my cart that automatically scan. Eventually it may even get to the point that I do not even go in a store but instead pick my items up at a terminal outside.

Looking at the grocery store today, I can see in the near future where the human shelf stackers could easily be replaced by a warehouse robot that did the job. That way the company would no longer be dependent on humans to do the work.

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:

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.

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:

The User Interface ties in perfectly with the User of the product requirements.

The Product looks and feels great to the user and the UI dovetails nicely into the UX.

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?

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.

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.

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!

No research done with users to get their feedback on UI / UX / Usability before or after the product is created.

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?

Understand your users in detail.

Work with experts that know how to establish the important interface requirements to meet the user needs.

Track the user experience before and after the product is released to pinpoint problems.

Don’t rely on the UI person to do the UX and Usability or to even have the skills to do this analysis.

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.

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:

Does my department need to interface with other departments for either development or testing?

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 your developers or UX people wanting more details from the rich mockups produced by the graphics department but you have been unwilling to spend the money on a license for them to use Photoshop?

Now Adobe has a $9.99 a month option for access to this usefultool.

https://creative.adobe.com/plans/photography

Other departments will be able to access the details behind mockups without having to continually go back to the graphics department to get an explanation.

This of course should not be a substitute for a guidelines document that explains look and feel of your product. However it can speed things up in the near term when the guidelines documents is still under development.

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:

If you think it is great to have wonderful graphics or industrial designers that claim to know UX and will help you build your wonderful whatever, think about how they will maintain consistency.

Time and time again, I run into situations where there is no documented rules followed by the UX folks. They do as they please with different designers adding in their own flavor. Products comes out in different blends of colors because one designer preferred a color over another.

It is like reading a book with chapters written by different authors.

Without a foundation of the rules being captured and documented it can be hard weeks, if not months later to work out what something should look like from a UX perspective. Time is wasted revisiting design decisions that were made in the past.

Make sure that whatever shop you use for your UX design actually knows how to do the job professionally.

Ask up front for the UX guidelines to be documented as they are defined. Don’t ever assume that just because everybody who works on your product comes from the same design shop that they will somehow know what is expected.