The Business of Business Analysis

By

Sarang D Khare

Dated: August 29,2019.

The term ‘business analysis’ first started to do the rounds back in 2003-04. The earliest job descriptions indicated that the role required post graduate qualifications in banking and finance/insurance with at least 5 to 7 years’ experience in the banking and financial services industry, better known simply as BFSI. However the precise nature of the role was not very clear and the earliest job posts appeared to have the potential to mislead applicants in to believing that it was something of an economic and business advisor role where the business analyst would need to analyze the macro as well as micro business environment and provide decision making inputs to management. Be that as it may the role became increasingly visible in the months that followed and many of us who had spent a decade in banking or in finance or manufacturing or in a combination of these domains were naturally drawn to it.

Initial inquiries about the role in an organization on the Pune-Bangalore highway suggested that its job description was still not appropriately articulated.It would be another year before the role came to be mentioned again ,this time during an interview for a faculty position in an MNC. It was suggested during the interview that a business analyst profile was the logical next step after say, an eighteen month stint with learning and development aka training. There existed in the organization at that time a department that comprised only business analysts. It sounded great because a clear career progression road map was being offered at the very outset. Eighteen successful months later the progression to this business analyst group was made after first clearing a fairly arduous selection process comprising of written tests, presentations and group interviews. Core banking is where yours truly was placed. It was a logical domain to be in after nearly a decade in retail banking.

It was during that first year that the real meaning of business analysis came to light and flippant replies such as “Ask the boys….” were swept away. Business analysis had nothing to do with a study of the micro and macro-economic business environment nor did it involve providing decision making inputs to management. It was all about requirements gathering, requirements analysis and requirements management with a view to develop working software. Period.

It was a good place to be though with its heavy emphasis on deep domain knowledge and its application to requirements elicitation and analysis. The business analyst team was additionally expected to design domain training programs for the entire organization, ranging from retail banking to mutual funds, payments, cash management and insurance. At one stage in 2006 there existed some 14 domain training programs that business analysts were expected to design and deliver. Moreover, every version of a program was to be a brand new offering. The work was good and the rewards were great by the standards of the times. ‘All Hands Meets’ with senior management added to the glitter and on site opportunities were the rule rather than the exception. “Am travelling…..” was an often heard remark. Business analysts were borrowed by a particular department within the organization that needed them for a specific project and returned to the business analyst group when that engagement ended. The department had its own very unique identity and looking back, the only thing missing was a department T –shirt. This would have made a great souvenir and something to remember the department by because not long after, that business analyst group lost its unique identity during one of the periodic reorganizations, better known simply as ‘reorgs’. It was great while it lasted. Prestigious too.

That first year in business analysis was an eye opener because it brought to the fore life on the shop floor in all its detail – late night and early morning conference calls, business requirements documents, requirements walkthroughs, project specific domain trainings, UI reviews, process models, use cases and data dictionaries. That first project was a God send because it had everything a banker fresh to the world of business analysis would want to learn. Then again there were 6 business analysts on that engagement, all sitting in one rather large cubicle. We would interact with on-shore business analysts and it became apparent that business analysis as a career option had one drawback – frequently changing requirements. If you were averse to frequently changing stakeholder expectations it was not the place for you. It was also apparent that the business analyst role was still an evolving one with arguments raging about whether the business analyst was responsible for writing only ‘business’ use cases or ‘system’ use cases as well or whether ‘system’ use cases were to be written by the technical team. The year was 2007.

A four month onsite stint in Vancouver in 2008 revealed that the role was evolving there as well although the expectation was clearly laid out that the business analyst was concerned with pure business or functional requirements and that he had nothing to do with databases or programming per se. In fact the view there was that a business analyst needed to have excellent analysis, documentation, communication and stakeholder management skills, with domain being learnt ‘on the job’. It was another eye opener. Deep domain knowledge coupled with an appreciation of technology makes for more intuitive business analysis but the view in some quarters was that if you possess deep domain knowledge it may induce an element of bias resulting in the business analyst asking fewer questions to business which would likely prove counterproductive from the perspective of solution validation. However, in most areas of business analysis work, deep domain knowledge can be a huge advantage. For instance if you are from a banking background then you are definitely at a huge advantage when working on projects in the risk or regulatory reporting domain. If you have worked in manufacturing industries and have management accounting expertise then working in the arena of SAP consultancy or implementation becomes a lot easier.

In the years that followed business analysis became a hot spot for engineering and testing communities partly because it was a stimulating role and also because it offered opportunities for overseas travel. The strong element of domain expertise came to be eroded gradually and it ceased to be a prerequisite for being a business analyst. Engineers brought with them a good working knowledge of databases and programming and whilst these skills were not required in requirements gathering or analysis they came to usher in a new order of things as well as an altogether new role ,namely ‘techno – functional business analyst’ aka IT Business Analyst. Not surprisingly business analyst job descriptions started to wear a different look over time. Nonetheless the pure functional business analyst continued to be in demand, especially in product companies where you built something conceptually original from scratch and where deep domain knowledge drives product development collaboratively with engineering.

The career progression of a business analyst depends on how much time he or she would like to invest in the field and also where work experience is garnered. A captive unit is where you get work at your desk and you can learn all there is to be learnt in terms of business analysis artifacts and deliverables. If the business analyst moves from a captive unit to a service organization then he gradually begins to gain an awareness of what it took that organization to get a piece of work at his desk. If he makes another movement after say a couple of years to a product company then he will understand how products evolve as they are built and what it takes to achieve market acceptance. There is more to business analysis than foreign travel and monetary reward. Varied experience and hands on work is a treasure unique in itself and an investment well worth making.In some rare bizarre instances the business analyst will find that the engineering team has already started its work and requirements are being documented subsequently - a form of reverse engineering you may say.

If the business analyst starts an independent practice and hires a junior apprentice the realization will dawn very soon that what matters with any new hire is the value he or she brings to the table and there will be a more refined appreciation of why immediate notice is not always taken by organizations of demands for a pay hike.

Speaking of pay hikes there is the question of different billing rates for business analysts in different geographies. An onshore business analyst will be priced differently from an off shore one and there will be instances where a blended rate is applied depending on organization policies at any given point in time. It is quite common for a subject matter expert to command $200 an hour overseas but the offshore rate will not necessarily be the same.

It would be fair to say that between 2006 and 2015 waterfall methodologies were used in requirements gathering and analysis for the most part. Agile was beginning to make its presence felt. Looking back, many projects of that time would likely have benefited from an agile or even a hybrid approach. Agile is really an excellent way to develop software and professionally very satisfying because the business analyst not only elicits and analyses requirements but also gets to see the results of the business analysis work every two or four weeks, depending on the size of each sprint. Since agile as a methodology does not suit every project under the sun a business requirement document may first be written in the manner of waterfall, then implemented in the manner of agile. This hybrid model works rather well. Agile is a collaborative work culture and a mindset where the team will have its daily huddles and monitor progress. The feeling of seeing working software that was built on requirements you have elicited, analyzed and documented is great. You may get that satisfaction in waterfall one or even two years after you first wrote the requirements by which time you could be on another engagement in part. Really good agile teams have no designation hang-ups and stay focused on quality delivery, responding frequently to change.

Working in an agile environment and that too in a startup is a tremendous learning experience because you prepare process models on a white board, take a picture of the process flow using your mobile phone camera and send it to the team on mail or even on Whats App from where it is taken up for development. Open source software such as Plant UML gets to be used instead of MS Visio. Conference calls happen over Skype. It does not matter as long as you deliver working software so that the enterprise gets its next round of funding. Your work in one sprint may well impact funding for the next hence you really need to be on your toes. It is a uniquely different experience.

Speaking of elicitation techniques there is none to match process modelling and yet many business analysts seem to believe that it constitutes an unnecessary overhead. Here is the thing – business may not necessarily have time to read a 40 page document to decide whether the business analyst has understood its business needs correctly but it will have 10 or 20 minutes to look at a process model and confirm whether the requirements have been elicited correctly. If they have been correctly elicited then the detailed documentation can be structured based on the signed off process model. It’s a simple fact of life that is lost on many business analysts. The best process modelling tool is MS Visio. Every business analyst in independent practice must invest in it. If the project requires BPMN (Business Process Modelling Notation) then Visio offers a great user experience. Admittedly it is an expensive tool but it pays for itself in the long run. Requirements management tools prove useful when business analysts in multiple geographies are participating in an online workshop. It goes without saying that it takes a financially strong organization to offer these tools and nurture Communities of Practice or CoP’s where best practices can be shared as well as preserved.

How closely the business analyst will work with engineering communities will depend on the culture prevalent in the organization. A product development environment is where the business analyst really comes in to his own. Having first elicited and documented requirements he may then have to work collaboratively with the engineering team to discuss system design which is where his knowledge of Use Cases will come in to play. As any experienced business analyst will tell you the real skill is not in documenting use cases ( since a ready to use template exists for it )but rather in identifying them after first determining system boundaries, actors and all possible user system interactions that can emerge from each functionality. Use Cases can be determined better when you have first developed process models at varying levels of granularity. Thus, in a stimulating product development environment the business analyst will work closely with engineering teams and confirm whether the solution meets the business need.

The humble but hugely effective Traceability Matrix (TM) is a document that is neglected by many with harmful consequences. Maintaining or not maintaining a TM can often make the difference between staying in office all night to resolve a production issue or resolving it quickly and going home at a more earthly hour. It is a simple excel sheet where each business or functional requirement is linked to its corresponding business analysis and technical artifact. Each functional group will be linked to a functional requirement within it, then to a corresponding process model, use case, UI reference and test case reference. Finally it gets linked to a technical reference binding the requirements in a chain as it were, backwards to the business need and forwards to the solution. The business analyst fills his part of the TM, the testing team fills its section and the engineering team does likewise. All it takes is a reminder mail on Friday evening to all stakeholders urging them to fill in their part of the TM. Sadly, many people think it is a boring activity and ignore it. Others refer to it as ‘unnecessary overhead’. More’s the pity.

This brings us to certifications and the value they add to a business analyst’s profile. A CBAP certification for instance is available only if the business analyst has a certain amount of relevant work experience. A CBAP certification will impart a more structured and orderly approach towards requirements management as a science and represents a finishing school of sorts. When organizations make it a prerequisite for growth it becomes a ‘must have’.

Speaking of growth a business analyst’s growth path is driven by where he or she works. In a captive unit business analyst designations may be mapped to corresponding technical designations. You can start as an Associate Business Analyst and finish as a Senior Manager Business Analysis. There it will end. In a product company you can be a Product Owner or Product Manager depending on what blend of domain expertise and technical knowledge you bring to the table, not to mention knowledge of industry and market trends. Firsthand experience suggest that business analysts are more likely to receive recognition in product companies than in captive or service units. Some organizations prefer a flat organization structure whilst others may offer vertical structures with ‘Account Manager’ and ‘Director’ designations. Some business analysts move to project or program management,others return to the industry they originally came from.

A business analyst fresher once asked,” Process models, business requirements documents ,use cases ,data dictionaries, UI reviews, test reviews ….is this all there is to it?” The answer was a rather bland, “Yes.” Beyond the world of IT business analysis lies the world of business consulting which requires an altogether different skill set and mental makeup. Unless you have a high quality post graduate qualification in finance and are equally knowledgeable about technology it is not easy to break in to the consulting space. There are big players there. You may work for them but competing with them independently is a tough ask.

It is one thing to be involved as a business analyst in every phase of the software development life cycle and another to be a business consultant studying how India’s sugar yield can be increased and placed on par with Brazil. You will need to first gain an in depth understanding of the sugar industry, then apply business analysis techniques such as process modelling and requirements elicitation to the study, supplement it with an application of cost and management accounting concepts as they are applicable to the sugar industry and finally provide your recommendation with a formal report or business case. Similarly designing a Balanced Score Card for a startup requires experience and blending of multiple skills. This kind of work comes along once in a while. It does not constitute ‘bread and butter’ work.

Experience suggests that every Business Analyst should have two areas of domain expertise – primary and secondary. For example, retail banking may be a primary area and regulatory reporting may be a secondary area. This will ensure that he or she will likely have a project to work on more often than not thereby minimizing his or her 'unbilled' time.

There are multiple areas of value adding specialization within the business analysis field - 'Usability BA' and 'Business Intelligence' (BI) BA are two unique areas that spring to mind.Going forward that range may well expand to include 'Artificial Intelligence (AI) BA', 'Robotics BA' and 'Blockchain BA' to name a few.

Business analysis skills can be learnt through a systematic training program and honed through regular practice.However, stakeholder management and negotiation skills are learnt through real life experience. It helps to have a senior manager as mentor who can hand hold you when you are promoted to a managerial role in business analysis but not everyone gets to experience that privilege.Moreover not every manager or senior manager will maintain an awareness of the sensitivities associated with seniority. Nonetheless a 'go to' senior manager whose advice can be sought on managerial issues such as employee behavior, intimidating escalations,onshore-offshore relationship management and budgeting is a big asset.

There is really speaking no age limit in business analysis. It depends on your circumstances. If you come to business analysis after say 5 years in the BFSI space you will likely be starting at 28 or 29 .You can continue for at least 15 years without any problem. The trouble starts when you are in your mid-forties because at that stage of your life you may have personal responsibilities that may demand greater attention. As we begin experiencing challenges on the personal front we have to accept a new order of things and it may not always be possible to work 10-12 hours a day or stay on site for 6 months at a stretch.

Moreover, the business analyst needs to assess where he or she fits in the broader organization at any given point in time. For example if you have been made to work on ‘change the organization’ type projects because legacy systems are to be phased out gradually and you find yourself in a situation after say 10 years where the ‘change the organization’ initiatives haven’t taken off resulting in you being redirected to the very legacy system that was to be replaced, you have a real problem on your hands because you do not know that system at all. You will have gained rich experience as a business analyst globally and still end up being a fresher /novice on the legacy system which is a paradox. This is not a great situation to be in especially if your manager does not appreciate your discomfort or the possible consequences (on project delivery and performance appraisal) of a lack of timely review support on system related work. If there are no user manuals to guide you then it further aggravates the situation ,especially when the manager does not appreciate your efforts to create user manuals or user guides for the benefit of business analyst freshers. The business analyst will need to take an informed decision whether to stay in the organization and continue working on 'run the organization' type projects or move on. As the saying goes, it is better to relocate where you are likely to be appreciated rather than stagnate where you may be tolerated at best or injured .

Business analysis is not immune to organizational politics. As long as you are not perceived of as a threat no one will bother you. The trouble will start when you fulfill all prerequisites for growth and unknowingly unsettle your peers as well as superiors. In a meritocracy politics will not be permitted to flourish but in a top heavy organization where opportunities for vertical growth are limited you need to be very careful. A simple tool known as Minutes of Meeting ( MoM) where you document everything that is discussed during meetings is a very effective way to neutralize the games played by people with negative intent. “Your mom is your best friend at home and your MoM will be your best friend at work.” is a saying worth remembering. MoM’s that are circulated to all stakeholders on time will protect the business analyst. An incompetent and roguish manager will then realize the truth of the old saying – “You can fool some people some time, some people all the time but not all the people all the time.”

Speaking of business analysis managers, there are broadly speaking two types – the one who develops people and shares knowledge freely, reducing hard dependencies to a bare minimum and one who deliberately withholds knowledge, increasing hard dependencies on himself as much as possible. The first type works collaboratively and builds careers. The second type is likely to nurture harmful competition within a team and will stimulate attrition. Worse, the manager may then try to manage that attrition by plugging open positions without giving due thought to skill set requirements, thereby placing the project at risk. Fortunately there still exist enough professional managers you can navigate safely to. It may need an organization change though.

Managing a team of business analysts ( or simply BA's as they are often called) requires frequent functional reviews, preparation of charge-backs, quarterly performance appraisals and emotional intelligence of a high order. If there is an expectation to keep utilization at a certain level and deploy the BA’s across multiple domains then there is the added responsibility of ensuring that every business analyst is provided ample opportunities to acquire new skills.The business analyst manager is no longer dealing with Generation Y because there is a Generation Z now to manage and this is a generation that has seen only technology since childhood. Managing them or even working with them requires an understanding of the way they think and feel. For instance they are not even accustomed to waiting in a queue for a cinema ticket because they booked it online. It is not uncommon for a Generation Z business analyst to ask his manager or colleague upfront, “Why are you asking me this question?”

Independent freelance practice as a business analyst or consultant is now fortunately a viable proposition if you have invested time in networking and building relationships through sheer professional excellence. The business analyst will do well to additionally keep a hold on learning and development activities because what you learn on projects can be shared with your audience during training programs and the knowledge base that you have created for your training programs may in turn help you on projects. It is a win-win situation. If people think you are purely a faculty or trainer then that is their problem, not yours. The proof of the pudding is in the eating. Your client will be pleased as punch with your business analysis work and your audience in class will be thrilled with your sessions. Let people think what they want to.

Whether a business analyst will gain anything by learning Python or SQL will depend on what type of profile he or she is looking for. A banker or insurance expert who learns programming or database management skills will likely not work in those areas for the most part because there exist skilled people who have been doing that work for ages. What the business analyst will gain by acquiring programming skills or a knowledge of database concepts is a knowledge of how programmers and architects/system designers think. This may enable the business analyst to structure and organize requirements differently. It is advisable however not to make this knowledge of technology apparent. For example a business analyst should know what is continuous integration and continuous development in the context of DevOps and the role of automation in it so that he can relate better to technical discussions.

The future of business analysis is very bright because it is the only profile that is immune to redundancy on account of technological innovation and will likely retain its position as a sunrise career option for some time to come. As long as the need is felt for a person who can combine deep domain knowledge with an appreciation of technology to bridge the gap between IT and business, business analysts as a community will always flourish. If you are willing to be domain agnostic and work on any domain as a requirements manager then the scope becomes even broader. You can work as a business analyst even at 70 because the profile will allow you to, as long as you stay focused on your work without having designation hang-ups.In an era of increased life expectancy it is a safe area to be in long term as long as you keep learning and acquiring new skills. You can hope to be gainfully self employed as a business analyst for as long as your health permits.

As long as business analysts remember that life is first about people, then about communication and then about work they will do just fine. Big picture awareness, an ability to connect the dots, keep things simple and bring value to the table by providing crisp requirements that produce working software on schedule – that then is the business of business analysis.

---------------------------------------