Tag: Change Management

The Business Analyst Career Road

Written by Tejasvi Addagada on November 7, 2017. Posted in Articles.

The BA career road-map shows a bird’s eye view of the roles that Business Analysts can navigate in their career.

This also states in which function, the skills of a BA are best required. But, there are other functional spaces that a Business Analyst can embrace apart from the Business Analysis, Decision Support Analysis and Enterprise Architecture. One such functional area is Data management and Governance.

Every organization today, is looking forward to transform their business models emphasizing direct and in-direct Monetization as one of the primary drivers. This calls for a change to the current Business, Information technology landscapes while there is also a need to govern data. This can be a regulatory requirement or an enabler.

Often, we keep referring to hundreds of processes in a firm that are supported by thousands of systems that create, store data in again thousands of data stores, in a fragmented way. Thus, complexity of landscape remains the largest challenge that most organizations are tackling to simplify.
The organizational priorities for the much-required landscape transformation is driving the definition of data strategy. Data is the plasma that reaches every corner of an organization and keeps its actively functioning. There are dimensions of data management including data quality, metadata, risk, security and architecture management that help in simplification and benefits enablement using data.

There is a need for information capabilities and skills governed by Data Governance that manage and control this data. This enables the organization to look beyond regular business models, cost and risk reduction while aiding discovery of new revenue streams.
The benefits of having to manage and govern data are multi-fold, in reducing future costs associated with mergers and transformations, upfront integration costs, operational costs of maintaining redundant data, reducing product time to market, competitive advantages and the list goes on.

Data Governance is the process of setting standards, defining rules, establishing policy and implementing oversight to ensure adherence to data management best practices. Governance is the formalization and empowerment of the data management program, to ensure propagation and sustainability throughout the organization.

Most Business Analysts performing Data Analysis in these organizations, gradually moved into well established roles of Data Management and Governance. A business analyst has the necessary skills to gather data requirements, analyze and model the specifications, translate them in a way that designers and architects understand to build solutions. He further understands the need for Governance, performs enterprise analysis and assesses the solution capabilities.

Is it time that this functional area should be included in the BA career roadmap? The Business Analyst can traverse the roles from a Business Analyst or Data Analyst to being a Chief Data Officer.

A Business analyst followed by a Data Governance consultant and then an executive dimension owner, Business Data Steward and a chief data officer are some established roles that exist in this functional area.

Business Rules and the Importance of the Business Analysis Discipline

Written by Sandra Sears on October 11, 2017. Posted in Articles.

For most organizations introducing a new product or application system or responding to a policy or regulatory change can be a daunting process.

Add to this the fact that rule changes or additions are often externally imposed (by government or regulators), and organizations face significant risks associated with complying with such new or changed rules in an efficient, effective, and timely manner. Similarly, most system replacements or “legacy system modernization” efforts fail, usually after the expenditure of hundreds of thousands or millions of dollars.

If an organization understands, captures, and documents its business rules, the understanding of the impact of any change is much simpler; impact analysis is clear; and, the road to implementation of a change can be planned and managed successfully.

According to the International Institute of Business Analysis, “a business rule is a specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions.”

How do we identify business rules and where do we find them?

Business rules guide behavior, shape judgments, and drive decision-making. Thus, we can extract business rules from company policy statements, procedure documents, product descriptions, filings, and operational documentation.

Certain business rules may be maintained only through “tribal knowledge” and thus exist only in the heads of employees. There will be knowledge loss associated with staff attrition if an organization has not taken the time to explicitly document business rules.

Many business rules are hidden in application code. This may be due to the complexity of many insurance application systems and to the fact that those systems may be undocumented or poorly documented (or the validity of any documentation may be in question). Staff members may not even be explicitly aware that these business rules exist.

Because of the siloed nature of many organizations, conflicting business rules may exist in different areas of the company, again increasing risk to the insurer of undesirable outcomes.

The products of business analysis and the use of a business rules approach can provide clear direction for the discovery of business rules and the ability to trace business rules to the processes, events, roles, and data that they impact. Business process models have “decision” points (indicated by a diamond). For all but the most rudimentary of decisions, these indicate the application of a business rule. The creation of a use case description generates questions that are answered by the discovery of business rules. The analysis of data entities and their attributes trigger the discovery of business rules through the exploration of “how does A relate to B?” Assessment of a business role (possibly through the creation of “personas” – Sally is a twenty-something, tech-savvy individual who hates to have to “look things up”) can also trigger discovery of business rules.

A business rule example

Let’s use a completely hypothetical example of an external event triggering a change to a business rule for a disability insurer.

Most disability insurance policies will provide monthly income in the case of a disability only until age 65. This rule provides the insurer with (1) a clear limit as to how long disability payments must be made, (2) protection against disabilities that occur after age 65 (when disability is much more likely to occur), and (3) the ability to price policies based on actuarial information for a population of age 65 and below, whose risk of becoming disabled is far less than for a population in excess of age 65.

However, today most Americans are working beyond age 65, and Social Security’s full-benefit retirement age is slowly increasing. As a hypothetical, let’s assume that the government passes a law that disability insurance must cover insureds until the age of 70. What is the potential impact of this change?

How disruptive (and therefore risky) can the assessment of a change in a business rule be?

This “minor” change in disability rules would have a sweeping impact on a disability insurer. What are all of the processes, procedures, calculations, documents (such as contracts), and roles that are impacted by a potential change to the rule concerning when disability payments will cease? How many insurers are likely to have immediately available information to answer this question?

The likelihood is that few insurers could respond to this question without undertaking a great deal of research. A change to the simple rule expressed above will impact virtually every area of a disability insurance organization. Constraints imposed by both internal and external stakeholders, such as time constraints for implementation and the need to conduct actuarial analyses based on the change in underlying product assumptions, complicate the situation even further.

The need to adapt quickly to change

To ensure an organization can respond to market, regulatory, and desired product and application changes, the ability to adapt quickly and accurately must become a core competency. This means that the lifecycle for change must be measured in days or months, not years. For many organizations, this seems a truly unattainable goal, leading to the necessity of continuing to deal with the costs of rework and lost opportunity. In the disability insurance example above, it could even lead a company to withdraw from the sale of an entire product line.

The inability to respond rapidly, efficiently, effectively, and accurately to change (particularly change with a fixed deadline imposed upon an organization by an external entity) is a risk of which most organizations are aware, but are uncertain how to address.

The key to rapid adaptation lies in truly understanding one’s business. While the initial investment in business analysis and the documentation of process and rules may seem significant, the long-term payoff to the business is an ongoing return on investment every time a business faces a change – be it a regulation, a new product, the need to modernize technology, or even a changing customer environment. Technology alone cannot solve the problem of change, but the products of business analysis do provide the key to success.

4 Key Learnings as a System Analyst

Written by Srinivas Laxman on October 3, 2017. Posted in Articles. 1 Comment on 4 Key Learnings as a System Analyst

Five years back, I transitioned from Software Development Lead to System Analyst position at large North American Telecom account.

At the onset, my focus was to mainly on capturing functional requirements to help deliver projects on time without any design gaps. This invariably meant my attention was focused on documents, checklists, and procedures. Interestingly, it was only later after collaborating with some excellent peer analysts and observing their behavior did the finer aspects of the role became clear to me.

Here are some of my highlights and personal learnings about the world of Analysis.

Beyond Liaison role

The analyst role is often mistaken to be purely liaison role that acts as a link to assist communication or cooperation between groups of people. This may result in analysts focusing on packaging set of Requirements and delivering to IT and vice versa. An analogy to real world could be mail delivery person delivering package from source to destination. Often with faint idea what’s inside the package. There is little to be motivated about such role and it ends up limiting breadth & depth of influence of an analyst.

On the other hand, some of extraordinary peer analysts I have worked with instead, routinely go beyond liaison role. They are not shy to open the “package”, try to understand contents, ask some questions and gain deeper understanding. They take effort to translate contents to audience-appropriate language and then deliver to recipients. Other times they re-arrange the set of ideas in way that makes the subject clearer. Thereby such analysts add value to chain.

By stepping outside the role of liaison analysts can bring lot of value to project and discover the real essence of the profile.

Power of questions

This is an area where I consistently struggled to adapt during my journey into analysis world from development. Each time I heard of requirement, my mind would immediately have jumped ahead to try to solution. I was more focused on solutioning part and was missing critical piece of stage in the analysis and that is the questioning part.

Interestingly some of peer analysts were doing it bit differently and it was interesting to observe and learn from them. They took the time to ask probing questions to understand the needs better or simply to ask thoughtful relevant questions. Questions like “Can you elaborate this further with a business use case?” or simply to understand “What is the business benefit in implementing this?” A lot of times this not only clarified ask for technology teams but also brought to discussion some finer aspects of requirements.

Author Andrew Sobel elaborates this concept clearly in book Power Questions – “Good questions challenge your thinking. They reframe and redefine the problem. They throw cold water on our most dearly held assumptions, and force us out of our traditional thinking.”

The analyst need not have all answers, yet the art of asking probing questions is the one to be learned.

Stakeholder Relationships

The analyst must have an innate ability to work across large group of stakeholders and effectively lead and manage the relationships. These range from several of the business stakeholders from marketing, legal, accounting, customer experience and over to the technology world comprising of development teams, architects and delivery managers.

Age old attributes in relationship building like trust, straightforwardness and honesty never go out of fashion. The peer analysts in my team who were always pursued out for most high visibility projects were highly trusted individuals and their personal characteristics flowed into their work.

System analysts also have perfect opportunity to recognize the behind the scenes technology team and share the due credits with the team. Thus at the outset the analysis role may not appear to be managerial, however some of thriving analysts on our team were the ones who exhibited leadership and team building skills.

Adjusting the Lens

Finally, the analysts that were highly successful were the ones who could balance the level of detail. The critical ability of system analyst continues to be able to deep dive into functional area and come up with scenarios, clarifications, user stories that capture and cover the business needs. Yet there are several instances when teams are involved in details and lose sight of the big picture.

That is where some of excellent analysts stand out in their ability to balance their attention and level of detail. During discussions with developers, such analysts delve deep into the topic and come up with various scenarios that help supplement the analysis. And on the other hand, while discussing with business and leadership, they have ability to summarize it appropriately to communicate the gist.

The skill of analyst to be able to fine tune the lens and clarify the picture to the audience is always highly appreciated.

Thus to conclude, the role of System Analysis lies at the very cusp of dynamic Business needs and ever evolving Technology layer. It’s exciting to realize that the boundaries and influence of the Analyst are limitless on the project. I wish you luck on your journey and learnings on this path!

The First 4 Things the Business Analyst Should Know on a New Project

Written by Brad Egeland on September 21, 2017. Posted in Articles.

Know may not be the right word here…it may be more like ask. If there’s anything I’ve learned about projects in the past 25 years, it is this…if you need information, don’t wait for anyone to give it to you.

Ask for it. Demand it. Dig your heals and and don’t move until you have it. Hold a meeting to get it. Extend the kickoff meeting an extra day in order to get it, if necessary. But always try to get as much information about and for the project up front in order to help you down the path to a successful project conclusion. This is true for the project manager and it is also very true for the project business analyst.

So, let’s consider the first four things the business analyst should ask about or ask for or know when they are about to begin a new project. The project manager is the project leader and hopefully knows this information or at least has a good idea of it.

What the delivery project team looks like – skill set, etc.

The business analyst is the go-to liaison between the project manager and the technical team. Knowing what he has to work with on the technical side is critical information as he prepares for project kickoff and the next phase design work on the project. In fact, the business analyst, once he has a handle on the project and the requirements at least at a high level, then he should have some input into the make up of the project team. Usually the project resources are requested by the project manager based on the skill set needed and the roles that will need to be filled in order to complete the project effort. The business analyst would be a good – make that great – source to go to in order to make those project resource requests the best and most accurate they could possibly be. The business analyst knows the technical side and should be providing major input to the creation of the project team resources.

The customer team make up.

Likewise, knowing what the customer team make up looks like is critical for the business analyst as well. Why? Because the business analyst will be constantly interacting with the customer on various issues including clarification of requirements, work on change orders, questions about current and future business processes that affect or are to be affected by the project solution, user acceptance testing and what the end user community is expecting to see. If the business analyst has an idea of what they are working with early on in terms of the customer team formula, it will greatly help their planning and will likely have an affect to some degree on what resources are going to be needed on the delivery project team side as well.

What experience and infrastructure the customer has for the likely solution technology.

Are you using cutting edge technology on this new customer project or is it something both the delivery team and the project client are already familiar with? I realize that this is something you may not know completely until the final requirements are fully documented and the project is underway. But often the technology or process that will be used on the solution is known already or at least both sides have a very good idea. This information is helpful to the business analyst on the project for resource planning purposes, for requirements documentation purposes, for helping the client define their own project team and for helping the client define the “to be” business processes that the project solution will be implemented to. It is also very helpful to know this as any post-project technical support and training is being planned for and – again – these are things that the business analyst would be heavily involved in. The training may even be something they design and lead for the project customer.

The state of any high level requirements or business processes.

Finally, what is the state of the project requirements and business process definitions coming into the engagement. There are those clients who have done the work and know what they want, know what they need and have a detailed list of requirements a mile long. That can be a very good thing. It can also be a very bad thing. This type of client may “want” this, but unaware that they really “need” that. And it can be hard to convince them otherwise. Or, in the perfect world, maybe they have all those requirements and project needs documented correctly. Not likely…but maybe. Often times the project client has some idea of the need but it may only be a symptom or 80% of the real need. It’s up to the project team to figure out the real project and that investigation is really the responsibility of the business analyst. It may be led by the project manager and it may be acted upon by the entire team – tech lead and all – but at the end of the day it is the business analyst really leading this effort as they are working on complex, detailed, final documented requirements.

Summary / call for input

I’m not saying that knowing all this information at the outset will end in a successful project implementation. And I’m not saying this is all he needs to know either. But these are four key elements of input from the beginning that will help get the project started off on the right foot and help the business analyst to move forward more confident of a successful project outcome in the end.

Readers – what are your thoughts? Business analysts…do you agree with this list based on your project experiences. What are some other things you consider important to know up front as you move on to a new project? Please share your own experiences and thoughts and discuss.

Agile Framework – a Different Method of Elicitation

Written by Colleen Berish on September 5, 2017. Posted in Articles.

Elicitation can be tricky. Generally, stakeholders know something needs to change or must be created but….

may have a difficult time articulating what that looks like, which makes it difficult to design a solution that adds value to a business process or software system.

After working as a business analyst in IT software development for seven years, I made a career move to learning and development (L&D) for a newly developed division in my existing company with close to 200 people. I became a training department of one. One of my first directives was to figure out how to accelerate the training process because the division expected to hire more than 75 people in the next two years in the midst of 45% attrition due to retirements and a challenging business environment.

The biggest transferrable skill from business analyst to learning guru was the elicitation and collaboration process. In L&D, it’s called a needs assessment – in my case, this meant determining what a division of five distinct departments needed to make training faster and stronger. Sounds easy, right? The challenges resembled every IT project I had worked on in the past. Department leaders didn’t have time to devote to the process, the managers wanted a magic bullet or easy fix and finally, the managers thought the existing process was working. My analyst instincts were on high alert.
My first step in the elicitation process was getting the right people into the process and clearly defining who would benefit most from a change in the process. The people who had the most at stake were the front-line employees in the individual departments. This group would gain the most by getting trainees up to speed faster than before, enabling the trainee to become immediately effective, in turn, increasing the productivity of the entire team.

The next challenge in facilitating the elicitation process was getting a group of diverse employees to quickly brainstorm the problem and identify their needs while recognizing that each department had a distinct set of business processes and represented a different step in the workflow.

The elicitation for the problem was scheduled to occur over three, one hour sessions. For the elicitation process, I utilized a concept from David Crowther and Jim O’Loughlin and the Agile Performance Group called the Agile Framework for Facilitating Strategic Conversations. The process is designed to gather information from stakeholders in a way that removes the tendencies of bias, emotional decision-making and fear of risk. A power facilitator (me!) works with a team of people in a three step, diagnostic process. The process promotes openness and collaboration, where all participants brainstorm ideas and everyone has equal input into the process. We used a series of three brainstorming questions to discover the root cause of the stated problem (how can we accelerate the training process), describe the ideal solution and come up with valid, valuable and implementable solutions. The first step determines “Where are we?”. Stakeholders independently consider where they are in relation to the problem – in other words, what is the current state?

After my first elicitation session, it quickly became clear that the roadblocks were bigger than making the training process faster. The stakeholders quickly identified the real issues – the departments had no structure to the training process, trainers were not equipped to train successfully and there were no tools or documentation for the training process. The added challenge was that each department’s process and tools needed to be consistent among all departments, even though each performed a distinct function. Our problem had suddenly changed from making the process faster to making the training process structured…a problem that looked very different than making it faster.

After all stakeholders agreed on the “where are we”, the group moved onto to the second question in the process. “Where do we want to be?” This is where a good business analyst or power facilitator is the most crucial – encouraging the brainstorming process so that all stakeholders have a voice and are willing to buy into the final, desired product. The group came up with four key areas of development:

Materials, documentation and videos to support a hybrid self-guided and trainer led program
Trainers who have the tools, qualifications and desire to be a part of the training process
Milestones and checklists so trainees, trainers and managers can visually see where the trainee is during the training progression
A structured on-boarding process for all new employees.

After the team confirmed the elicitation results (the desired end state), we went to work creating a task list and process map for next steps. The department stakeholders broke into functional teams to design what we’re now calling the Training Framework. Phase 1 of the framework has been successfully implemented and components include a training checklist with clear milestones, a Train the Trainer certification and an onboarding outline with courses designed to introduce teammates to the company and the industry. Phase 2 is underway and includes the documentation and tools required to support the training process.

Although the stakeholders were not well versed in business analysis, by providing a frame of reference and a clear understanding of where we wanted to be, we were able to incrementally develop and implement a useable product over the course of three months. Had we not taken a step back to look at the real problem, the solution would not have met the real need of the division. Engaging the stakeholders in the business analysis process guaranteed the desired outcome that meets the needs to the employees and the department as a whole.