Who pays for the bad analysis?

A photo shared by Pexels on Pixabay

—

When I started feeling cold in an air-conditioned office on a hot summer day, I went for a walk outside among the sounds of birds and trees with a cup of coffee in my hand. As I was warming up with the August sun, I was also thinking about how I could explain and assign the task I was working on to my developer co-worker.
Eureka!

When I got back to my desk, I left the following comment to the developer over the bug tracking system:

Let’s do this in this situation, and let’s do that in that situation and solve the problem.

However, there was something wrong.
The task I assigned to my developer co-worker was returning to me at the speed of light. The comment attached to it was more interesting:

The code was designed based on the requirements given last month.
We cannot change that now, it may cause bigger problems.
We cannot change our design because of a faulty analysis process.
Please make sure what you want, or tell the customer that we cannot do that.

But how are we going to explain to the customer, who told us what they wanted a couple of months ago, that the product will be different than what they expected? Will it be the customer who pays for the bad analysis process?

—

In this article, I will try to explain how underrated the analysis process in the context of the software development cycle and who is affected by how as a result of a bad analysis process. But first, let us look at the definition of analysis together:

According to the two authorities in the IT sector (source), the definition of business analysis is as follows:

• BABOK, published by the International Institute of Business Analysis(IIBA) defines it as:

  “The set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an organization, and recommend solutions that enable the organization to achieve its goals”
  

• Another authority, Project Management Institute(PMI) defines it as:
  “The set of activities used for defining business needs, proposing appropriate solutions, identifying, documenting and managing requirements”That is, the guidance of what and how things are going to be done is called analysis; and the person doing this is called an analyst.

—

Every sector has its own dynamics and specific analysis needs. As a result of that, an analysis done for the finance sector is of course not the same as an analysis done for the telecom sector. However, all analysts have some common traits. These are:

• Bringing the right business partners together,

• Asking the difficult questions, listening and

• Thinking in-depth and making decisions built on strong foundations.

A typical analysis meeting for gathering business requirements.

—

Making a decision is an important qualification. Usually, most of the people avoid making decisions. You can try it tomorrow if you want. Ask your co-workers where they would like to have lunch. You will get evasive responses and usually, they will say “doesn’t matter”.

The thing you try to understand in an analysis meeting is mostly, whether it is big or small, the business model. The business model basically includes people who,

1. represent the customer that will pay,

2. represent the workers/vendor that will provide the service,

3. represent the accounting that will keep the money.

As the employee count increases, the job titles become “cooler”. Maybe some people will call you the “product manager”. But the work you are going to do is generally going to be one of the subjects mentioned above and your daily routine will become listening to people in the meeting room.

Listening is the magic of this world.

The meeting room is the natural habitat of an analyst. You listen, ask, and understand in there. You even tell people what you understood in another meeting room.

Every participant may not express oneself equally, some may have difficulty in expressing what they think.

Some talk slowly, some talk indirectly. You, as an analyst, must have the competency of listening to all kinds of people. Actually, every sentence has a reason and logic behind them and you have to be able to understand the logic behind that sentence by using different techniques to get the right analysis output.

There is a nice word used for that situation called elicitation. It can be explained as the ability to understand what people actually want to say, not what they really say.

Doing the right analysis is actually not that hard. You have to:

• Listen,

• Take notes,

• Document.

However, most of the time we may end up with a bad analysis output because of time pressure, and this bad analysis output is accepted as an input for the software development lifecycle.
Better than nothing, right?

Don’t be so sure.

Let us think about what the bad analysis may lead to:

• Erroneous technical design
  The backend APIs and frontend design mockups may be designed wrong as a result of misinterpretation and you may have to re-design them in the near future.
  
  

• Erroneous development
  The developers may keep writing code by asking themselves “Why do they want it this way? Isn’t it ridiculous?”. The code quality decreases because every if-statement used does not make any sense. Nobody questions it, because that is what is wanted to be done by the analysis, and keep writing code.
  
  

• Erroneous test
  Test scenarios that make no sense may be created in order to meet the business requirements. Without considering the content and logic of the tests, the testers may only look at whether the test passes, and just report the results. As a result of that, after a while, the software compromises on quality.
  
  

• The client that claims the resulting product is not what they wanted
  After the first prototype (or increment, or whatever you call it) is shared with the customer, every employee who thought but did not tell that the requirements were wrong, have to work overtime to fix them.
  
  

• The project management office that could not complete the task according to the plan
  Keeping in line with the time schedule becomes more difficult than before as there will be a need for extra time scheduling for reorganization (analysis, design, development, testing, commissioning).
  
  

• The executives that cannot explain why things did not go as planned
  Something is definitely wrong, but it takes great courage to tell that the analysis was incomplete or incorrect, as the analysis phase had ended a long time ago. The resulting stress begins to reflect on employees.

As a result of the bad analysis process, all the employees are now entering a period when it is difficult for the whole team to laugh and smile. The whole team pays for the price.

In fact, you may cause your customer to miss market opportunities.

Doing the analysis right is actually not that hard. The work to be done fits in a tweet: https://twitter.com/metoinside/status/1201827972212285440

I usually come across the question of how a good analysis is done. The answer I give consists of two words: by listening.

You need to listen to the people, who may be your manager or the end-user, with your full attention by putting aside your own ideas, dreams, and desires.

It is the duty of a good analyst to listen and ask the right and difficult questions.

—

I can tell you (or your company) how a good analysis should be done without any charges. All you need to do is to contact me at cr8product.com, we can talk in detail later.

You can connect with me on Twitter: https://twitter.com/metoinside