Are Business Analysts in India really VALUED???

Improving Business Analysis Performance: A systems-model for evidence-based performance improvement

Any manager attempting to improve the performance of a business analysis practice faces a daunting task. Figuring out what factors limit business analysis performance is challenging to begin with; actually measuring business analysis performance in useful ways can be subtle, difficult, and complex. In complex systems like a business setting a performance target may even degrade performance. BA managers may be unable to take meaningful corrective actions on those measures because the problems that limit performance may be outside the managers’ control or influence.


For decades research into business performance has shown that we tend to try simple, short-term approaches to drive performance improvement – and that these often fail. Business performance is the result of a complex set of systems interacting with each other, and can rarely be improved with simple fixes. Business analysis is one factor affecting business performance. Management practices that affect business analysis are another. These are two elements in the complex system we call “an organization”.
The components of an organization interact in complex, unpredictable ways. These interactions mean that business analysis performance is enabled, enhanced, limited, or eliminated by factors that are external to the profession and the professional.
This article explores the organization in terms of systems and subsystems to define the role that business analysis plays in both project performance and overall value realization. It does so in two parts:

  1. The Organization as a System:This section lays the groundwork for understanding the kinds of actions managers can take to improve BA performance. This includes a systems-view of organizations and analysis of the relationships between these systems. Seeing the organization as a system is key to understand what options are available for improving performance. A Business Analysis Performance Systems-Model (BAPSM) is proposed to establish this system view.
  2. Finding Performance Constraints:Variables that enhance or limit business analysis performance are defined, and integrated into the Business Analysis Performance Systems-Model (BAPSM). BA Managers are shown to be in a key position to increase or limit BA performance so much of the analysis relates to this role. Other stakeholders and their effects on BA performance are also identified.

2. The Organization as a System

This section lays the groundwork for understanding the kinds of actions managers can take to improve BA performance. This includes a systems-view of organizations and analysis of the relationships between these systems. Seeing the organization as a system is key to understand what options are available for improving performance.
An organization can be thought of as a set of stakeholders working together to realize value in a specific domain. It is free to set its own direction and purpose, though autonomy may be limited by many external factors. Unlike a project most organizations do not have a specific end-date.
This definition takes a systems-view by describing the organization as a set of interacting components which interact to produce intended and unintended outcomes. One important characteristic of a system is that many of the components that make up a system are also systems, often called ‘subsystems’.
Discussing systems and subsystems can become confusing very quickly.

As a system, an organization is made up of subsystems. These are called ‘Organizational Systems’ and they fall into two categories:

  1. Operational Systemsand their components generate organizational value, when seen from an end-to-end point of view: A factory floor or an assembly line is a type of Operational Systems: things of value to the organization are transformed into things of value to customers.
  2. Change Systemsand their components alter Organizational Systems, to make them more efficient, more effective, or both: Business analysis is a type of Change System: the practice of enabling change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders.

2.1 Operational Systems

Operational Systems, in the most basic sense, are the organization. These are the people, processes, tools, and information that interact to transform organizational inputs into organizational outputs. For example, when an Operational System turns raw materials into finished products it is taking something of value to the organization and turning it into something of value to a customer.
2.2  Change Systems

Change Systems include all the things that the organization does to transform itself in a controlled way. These are the people, processes, tools, and information that interact dynamically to make changes to Operational Systems. Unlike an Operational System, external interactions are not required for a Change System to be complete. Consider an internal Human Resources Improvement Centre that is accessible to employees only. The HR professionals might survey employees for recommended changes, adjust and improve the HR process, and educate the employees on the new process – all without any interactions with organizational inputs or outputs. Change Systems often do have external interactions however, especially when a change is related to an operational input or output. For example, if the HR improvement process also included in an industry-benchmarking step or a vendor assessment step, the Change System would have external interactions.
Change Systems are often described in terms of projects and project management processes, but there are many other approaches. For example, Enterprise Architecture approaches are organizational Change Systems that operate broadly across portfolios. In contrast, business process management approaches to organizational change take a vertical or end-to-end point of view. In each case, business analysis is a critical element of the Change System.

Change Systems should not be confused with feedback and control systems, though they share some characteristics.

2.2.1 Business Analysis as a Change System Component

In this section we have discussed the organization (often called ‘The Business’) from several points of view. Figure 1 consolidates these ideas into a model of the organization, by arranging these components and systems to provide a context for understanding the roles they play in the organization.


3 Finding Performance Constraints

Factors that enhance or limit business analysis performance are defined, still taking a systems-view. BA managers appear to be in a key position to increase or limit BA performance so much of the analysis relates to this role. Other stakeholders and their effects on BA performance are also identified.
Discovering factors that affect business analysis performance is easy. For example, an incompetent practitioner is not likely to deliver high performance. A lack of experience, limited knowledge of the business being changed, or a bad attitude could also limit individual performance.
But how big an effect do these kinds of constraints have on performance?

Which factors represent the biggest levers to shift performance at the level of the Change System?

These questions are harder to answer, especially considering that many performance limits are beyond the control of the individual business analyst. A Project Manager who ignores the plans made by an otherwise effective business analyst would make it very difficult for that business analyst to perform well.
BA Managers are often able to exert some control or influence over many performance-limiting factors like these:

  • Performance Measures, Rewards, and Recognition
  • Types of BA performance measures
  • Types of project performance measures
  • Types of team performance measures
  • Performance targets, including goals for BAs, changes, and other Key Performance Indicators (KPIs)
  • Wages, including contract work, employee pay, and pay for hours vs. expertise
  • Career consequences related to performance measures
  • BA career opportunities in the group and organization
  • Individual BA Competency
  • Training time and budget allocations
  • Frequency and quality of BA peer review
  • Availability of career counselling, mentoring, and coaching
  • Peer Performance
  • Competence of other change agents (Project Managers and Engineers, etc.)
  • Competence of stakeholders in a change (Operational SMEs, Business partners, Clients, Sponsors, Approvers, etc.)
  • Integration of change agent roles in the change process (including vendor / outsourcing relationships)
  • Solution Development and Life Cycle Management
  • Quantity of BA effort allocated to projects
  • Timing of BA effort allocated to projects
  • BA effort allocated to development of business objectives and business cases (before project initiation)
  • Efficiency of requirements approval processes (including vendor relationships)
  • Frequency and complexity of changes made to approved requirements
  • Tools for Managing Organizational Information
  • Usability, complexity, and openness of tools for managing change information
  • Reporting, relevance, and availability of Operational System information
  • Reporting, relevance, and availability of Change System information
  • Speed, clarity, and ease of information sharing across the organization
  • Culture and Bureaucracy
  • Organizational culture (collaborative, structured, bureaucratic, innovative, etc.)
  • Organizational context (layoffs, uncertain business, difficult times, etc.)
  • Time tracking and related accounting practices
  • Quality of relationships with stakeholders the BA works on a change, including clarity of roles, and responsibilities
  • Expectations about the services that a BA will provide
  • Attitude to Operational Change (formality of change process, maturity of industry, unions, professional associations, regulators)
  • Perceived value of business analysis as a practice
  • Perceived value of business analysts as practitioners
  • Flexibility and judgment allowed in governance processes
  • Approach to meeting relevant regulations
  • Approach to standardization (as a foundation or a barrier)


This network of interacting variables is still only part of the story. There are many variables that are contextual; they are relevant, but external. For most BAs and BA managers the regulatory frameworks imposed by the government are part of this context. The regulations are relevant to the task at hand, but cannot be affected by the BA or the manager. BA Managers should be aware of these kinds of factors even if the specific variables are not clear in their organization. BA Managers should also be prepared to discover these variables and then consider the implications of these on BA performance.

Story Point vs Work Hour in Scrum Framework:

“Suchi, this is just a three-point story. We shouldn’t take more than 30 hours to do this,” one of the developers told me during the sprint planning.

And a development manager once advised me, “Suchi, you must not pull in any other stories, because we already committed 30 points’ worth of stories and our velocity is just 28 story points!”

“But we still have capacity, and one of our developers has only committed 50 percent of his time for this sprint. Furthermore, the team does really want to commit another story”, I replied.

“So what? That’s the rule. We cannot commit more than our velocity!” the manager said.

These are common controversies about story points and task hours.

Sprint planning can easily fall into hours and hours of argument with some “should” or “must” that doesn’t make sense — but that I just can’t find any facts or points to persuasively deny.

Then I recall a lesson in a CSPO training that I attended recently.

Lizzy Moris, the trainer, told me story points and task hour comparison can be thought of as the comparison of the weight and height of an elephant. In general, a taller elephant may be heavier than a shorter one, but this is not always the case. There is no biological proof of a weight-versus-height formula, despite the common perception that more height means more weight. The same explanation applies to story points versus task hours: In general, a more complex user story (higher points) should take more hours to complete, but there are always exceptions.

For me, story point is high-level estimation of complexity made before sprint planning. It could be done during release planning, but I think most Scrum teams do it during a preplanning session. Story points and sprint velocity then give us a guideline about the stories to be committed in the coming sprints.

The task-hour estimation, on the other hand, is a low-level estimation made to represent the actual effort in hours needed to accomplish all the requirements of a story. Such an estimation should be done during sprint planning for highest possible accuracy, as the actual development may start the next day. Given the fact that story points and task hours serve different purposes at different times, forcing a relation between them may not be advisable.

How to estimate Story Points:

There are various ways to estimate app development projects. One way is by using so-called Story Points. While this type of estimation might not be the easiest, estimating with Story Points offers benefits to both app developers and clients.

The Story Points approach uses historical data to compare features of one project to features of a previous similar project to generate a precise estimate.

Step 1 — Identify a Base Story

Story Points are a complex unit that includes three elements: risk, complexity and repetition.

To find our Base Story, we search for one medium-sized task that’s understandable for everybody — a task that doesn’t have any ambiguity — and assign it one Story Point. This will be our Base Story.

Step 2 — Create a Matrix for Estimation

There are two types of scales used for creating estimation matrices: the linear scale (1,2,3,4,5,6,7…) and Fibonacci sequence numbers (0.5, 1, 2, 3, 5, 8, 13 …).

Generally, we use Fibonacci sequence numbers. We do this because people are really good at comparing sizes, but not at estimating absolute values such as number of hours. The difference between 1 and 2 can seem insignificant. However, the difference between 1 and 5 is obvious.

When estimating using Fibonacci sequence numbers, we create a matrix with rows for each sequence number and their associated stories. Then, we gather all our stories and start classifying them into rows, comparing the stories to each other and to other completed stories. Notice that our Base Story is already in this matrix in the first row with a value of one Story Point.

Here is one of our matrices:

Story Point Story
As a visitor of the application, I shall be able to visit About link of the application so that I can get information about the firm.
As a visitor of the application, I shall be able to visit Services link of the application so that I can get the information about various services offered by the firm


As an user of the application, I shall be able to create my own user account.
As an user of the application, I shall be able to change the password of my user account
As an user of the application, I shall be able to recover the password, in case I forget it.
3 As an user of the application, I shall be able to search for specific job opening in the Career link of the firm
5 As an user of the application, I shall be able to apply for a specific job opening.
8 As an user of the application, I shall be able to complete one transaction under the Purchase link of the firm.


Step 3 — Planning Poker

To assign story points to each story, we have a meeting where all specialists that will work on the project get together and play Planning Poker.

Planning Poker is a consensus-based estimation technique to estimate product backlogs. It can be used with various estimating units, but we use Planning Poker with Story Points.

Here’s how it works:

Planning Poker Estimation Process

  1. Each estimator gets a set of cards;
  2. All estimators select backlog items, discuss features, and ask questions;
  3. When a feature has been fully discussed, each estimator privately (to make the estimate objective) chooses a card to represent his or her estimate;
  4. When all estimators have made their estimates, they reveal their cards at the same time. If all estimates match, estimators select another backlog item and repeat the same process. When estimates differ, the estimators discuss the issue to come to a consensus.

By the end of Planning Poker, we’ve filled out the whole matrix. Our tasks are divided into rows by the number of story points needed to implement them. Finally, we place each backlog item in the appropriate row. There can be several stories in one row.

Step 4 — Planning the Sprint

Now that we have a size estimate, you may be wondering how we convert these sizes into man-hour estimates. Unfortunately, we can’t do this until the first sprint is completed. While the first sprint is in progress we can track the team’s velocity. As soon as the sprint is finished, we’ll know how many Story Points a team can complete per sprint. We use these numbers to forecast the team’s performance for the next sprints.

When we have all backlog tasks estimated in terms of Story Points, we can understand how many sprints we’re going to need to complete the project. And finally, we can convert these abstract units into real calendar timelines.

Man-Hours: What Are They and Why Don’t They Work for Us?

Estimating in man-hours is one of the most widespread approaches for measuring team work. It relies on an estimate of the amount of work that can be completed by one person within one hour. While man-hours are easy to understand, there are a few big drawbacks to this technique:

  • Some tasks are difficult to estimate precisely.
  • If one developer estimates a project but another completes the task, the estimate becomes invalid. The time needed to complete a task will vary based on a developer’s level of experience.
  • People generally underestimate obstacles they might face and consider only the best-case scenario.

Why Story Points are better than Hours?

With man-hours, developers expect that they’ll log the exact number of hours estimated for the sprint. But that’s a double-edged sword. If they exceed the number of hours estimated for a sprint, then it suggests they’re a poor performer. But if they complete the sprint under the estimated number of hours, then it means that there was something wrong with the estimate.

Story Points offer three main advantages over man-hours:

  1. No correlation with skills and experience of the estimator

As we already mentioned, a specialist who estimates a task isn’t always the one who implements it. Senior and Junior developers need different amounts of time to complete the same task. The only way to avoid all this is to make a developer who estimates a project also implements that project.

Story Points eliminate this problem, because they are a universal measurement across the whole team. The estimate doesn’t depend on who’s implementing the story. All team members, with different skill levels, can discuss it together and come to a single conclusion.

The whole team can get a clear understanding of the story size and complexity. This is the main advantage of story points.

  1. Velocity is Tracked

Another key to the power of Story Points estimation is velocity. Velocity is a powerful capacity planning method that demonstrates how much product backlog effort a software development team can successfully handle in one sprint. The goal of a team is to raise its velocity.

Team members discuss ways to achieve greater velocity during retrospectives after each sprint. The higher the team’s velocity, the higher the team’s capacity to perform a given task quicker and more efficiently.

But velocity is a relative value that can change during the course of the project. And here, we find the next advantage – you will not need to re-estimate your project if velocity changes, whereas estimating in man-hours would require you to perform a recalculation.

  1. No Re-Estimation if Velocity Changes (Flexibility)

Another value of Story Points is that they let you re-plan product release deadlines without re-estimating all tasks if members of the team are changed.

It often happens that one person estimates a project, but other people complete the tasks. In this case, Story Points are indispensable.

Let’s consider several examples.

Example 1

Our company has a project at 200 SP. One developer starts working on it. His velocity is 1 SP per 3 hours. The start date is May 30th. Based on this information, it’s easy to calculate the project release date.

  1. The time needed to finish all the work:

T = Qsp*t,
where Qsp is the general quantity of SP in the project and t is the time to complete 1 SP.
200×3 = 600 (hours).

  1. The number of workdays:

where Nw is number of workdays, T is the time needed to finish all the work, and Prt is the quantity of productive hours in the working day (usually 6 hours)
600 / 6 = 100 (workdays).

Having a calendar at hand, we can then calculate a release date — October 14th.

If for some reasons we change the developer and the new developer works with the velocity of 1 SP per 1.5 hours, then we can quickly re-calculate our date. Now the number of workdays required is 50 and our date of release will be August 5th.

Example 2

Our project should be completed for 200 SP. The team fulfills 40 SP during one sprint. We know that 1 sprint is equal to 2 weeks.The start date is May 30th. Let’s calculate:

T = Ns*t,
where T is the general time for completion of the whole project, Ns is the number of sprints in the project, and t is the time needed for one sprint.
(200/40)*2 = 10 (weeks).

The release date is August 8th.

But let’s say that some changes have occurred, and the velocity of the team has changed. Now the team completes 50 SP during one sprint. It will be easy to re-calculate our date.

(200/50)*2 = 8 (weeks).

The release date is now July 25th. Thus, Story Points allow our Product Owner to see more precise release dates after any changes in the team.

You see that we can convert abstract Story Points into more understandable days without any problems. We monitor the whole development process, and can change it at any stage if it is necessary.

Let’s sum up

Story Points have acquired a reputation as a stable index that’s independent of the skill or experience of team members, lets you track a team’s velocity, and helps you stay flexible in re-planning project release dates.

Recently, some specialists have begun using a combination of both Story Points and man-hours. But still, on the basis of our own experience, we are confident that Story Points offer the greatest utility for high-level planning.

Toastmaster CC6

Sample CC6 speech from Toastmaster manual:

Objective of CC6 is Vocal Variety. Below speech contains a variety of vocal variety offered by various characters. Each part of the speech is having varied types of vocal variety.


“Suchi…, Suchi !!! Look at this, what happened to you, you are the only reason for all this”

It was precisely 3:15 am in the morning, I was jolted for the moment, and opened my eyes and found myself with increased heart beat and full of sweat.

I instantly rushed to my dad’s room and He was in deep and calm sleep. I came back to my bed and started thinking that about my CC4 speech which was scheduled next day and it should be good.

I was really prepared well for it, but unfortunately could not deliver the speech effectively, forgot the speech and stuck in between, this has never happened in my life. Finally finished the speech by using the notes which I had thought I wouldn’t.

I failed at that moment and was not able to remember transition points. My mind was completely disturbed and not in control

I asked myself “Why? What happened to all the confidence that I had in my previous speeches?

I was really disappointed and asked suggestion with my mentor

He said, “Practice well Suchi…Practice well” Practice makes man perfect”

My reply was “I had practiced well, but I don’t know why I have done like this today, There has been some disturbances at my office, not able to focus on anything constantly”

And he said: “Whenever you are on stage, forget everything and try to concentrate only on your speech”

Not only in toastmaster even in my office as well, not able to concentrate on my work.

‘“Is there not any other solution for this, we expect a more technically feasible solution for this…”I had received feedback from my customer demos.

“ Suchi…, these are very ground level research and there are many products in the market exists with this  concept, so try to do more analysis and develop feasible for Indian market” my mentor in my Market Research program told me after going through my product portfolio of market research.

My Manager “Suchi I have never seen you like this before with low confidence”

I had spent many sleepless nights, last mind which resulted in losing my lucky charm wrist watch. I couldn’t even realize where I have lost it. A feeling of loneliness, felt like isolated in a desert and someone trying to chase me in black horse.

Why? What happened? What made me like this?


Dear Toastmasters and guests,

It was 27th April, 2017 afternoon, when I was in my office, got a call from Indigo Airlines cruise member mentioning that my father who was travelling from BBSR to BLR had undergone a mild cardiac arrest in the flight and I had to go there instantly to pick him up.

I was really dumbfounded for that second, a strange feeling started haunting me, My life became very uncertain, then I realized anything can happen at any moment and my days started filling with painful experiences of past and unexpected, fearful thoughts of future.

My mind murmured “If something happens to my dad, then I can never forgive myself, because I always blamed my parents for restricting me in doing many things”

“Suchi…, Suchi !!! see what happened? And you are the only one who is responsible for all this!!!”…. this sentence continuously started reverberating around my ears and mind.

Whatever I was doing… whether I was practicing my speech or doing my market research or office work, this sentence was never leaving me alone to have a peaceful mind.

Then I decided to take many challenges and I have to win in all those, so that I will be able to concentrate in those tasks at least forcefull

Definitely, I had to start from CC4 speech… as my CC1 had brought confidence in me.

Hoping that, the success in my CC4 will bring confidence back in me, I had already set up many tasks, so that I can start those with great confidence, but that failure was the reason of my low confidence, causing my failure in all those tasks back to back, taking me down and down deep inside an infinity loop hole….!!! …

I was not able to make my point clearly  whenever I was sitting to finish my market research assignments.

And in office, I was not up to the point!!!

I bent over backwards, but all the roads were leading me to Rome!!!

But, till how many days, can I continue like this…???

Newton’s first law of motion sates that an object will not change its speed or direction unless an unbalanced force (a force which is distant from the reference point) affects it.

“Suchi, meditate… “ my manager told me…

“I am not able to concentrate even for 10 secs….then how can I sit for half an hour???” I told.

“That’s why, I am telling you…once you start meditation, then you will realize the life is present only in present” he told…

“Listen Doctor…, leave me alone, I can manage myself” I told…

“Hope, you will get well soon, but don’t put yourself in a scenario for which you will have to regret again, in a situation similar to now” he said…

“What do you mean???” I asked

“You know better…!!!” he said…

Then, when I saw around me, I realized that everything was fine… only my mind was disturbed!!!

And because of this, I was never able to live my Present and had lost many deadlines, those I had set up for myself!!!…

Yes, meditation was the yellow brick road for me by helping me a lot to understand myself…

“Thank you, Doctor!!!” I said

“Welcome back!!! May I expect your contribution in getting the next customer into our plate…??? ” he said….

“Sure…why not….!!!” I said…

“Excellent…!!!” my mentor said me after my success in CC5 speech

“This is the great solution… that’s what I was looking for!!!” my customer accepted my proposal….

Now, I am living a life that I have ever dream of with tremendous energy to take any challenge in my life!!!


Friends “Accept your past without regret, handle your present with confidence, and face your future without fear.”


Fellow Toastmaster`s and Guests…

As said in the movie kungu fu panda “Yesterday is history, tomorrow is Mystery, but today is a GIFT, that`s why it is called the present.

If you are depressed, then you are living in the PAST…if you are anxious, you are living in the FUTURE… if you are peace, you are living in the PRESENT!!!!

If Present is the only part of life which I can live, then why I am ruining my life by taking myself to those part of life among which one is already dead and the other is not born yet…

Dear toastmaster`s “Time is very precious, once it is passed, it will never come back, Do not waste a single minute, enjoy every minute of the life.

Now, it’s my time to build my future instead of blaming someone and finding excuses.

Remember “Past is a waste paper, Present is a newspaper Future is a question paper So, read and write carefully, otherwise life will be a tissue paper…