Skip to main content

Tag: Skills

Information Science, Knowledge Management and the Business Analyst

In today’s fast changing world, information, and technology are changing the way organizations and nations operate. The quality of information available to an organization, its ease of use and systems of dissemination can make the difference between organizations that thrive and those that get left behind in the archives of history. To understand this better, let’s look at the science of information.

Information science is the discipline that deals with managing information, from creation to final archiving or destruction. It is concerned with the generation of data, the associated technologies, and the transformation of data into information and knowledge. What is information? Let’s begin by defining data.

 

Data

Data can be described as independent entities, , numbers, letters etc. that on their own do not convey any useful meaning. Consider the following data set:  ‘A’, ‘John’, ‘boy’ ‘good’ ‘is’ ‘1’, ‘class’ ‘and’ ‘in’  ‘number’ ‘his’ . Each entity on its own does not really convey any useful meaning. However, when this data is put through a transformation process, with a pattern or structure, it conveys a meaning ‘John is a good boy and number 1 in his class – these entities which has been structured or patterned becomes information within the system.

 

Information

Information can therefore be described as data with a meaningful pattern to the system receiving it, such that it can change the state of the system. In other words when information is received by an individual, an organization or a system, it must be meaningful to that system: they have been transformed by this information. In some cases, the information received enables them to take an action or make a decision. This change in state might be from a current (as-is) state to a future (to-be) state, or just a change in position from point a to b, or from a less informed state to a more informed state.

 

Knowledge

Knowledge: When information has been fully understood, digested, and internalized by a system such that the system can reproduce it in various forms and disseminate it easily to others, it has become knowledge to that system. For example, an employee may build up their knowledge of a domain through multiple channels: training, conferences, water cooler conversations etc.  and become an expert with a full understanding of the subject area. They can simplify it into various forms and train others: the information they have absorbed has become their knowledge.

This relationship between data, information and knowledge can be represented as shown below in a knowledge circle.

 

 

The importance of knowledge to an organization can never be overemphasized. Organizations can thrive or fail depending on the quality of knowledge that exists within them. Knowledge in organizations exists in two forms: explicit and tacit knowledge.

Explicit knowledge is the knowledge that exists in the public domain of an organization. It is in their culture, in their SharePoint systems, books, journals… It is documented and widely available to all.

Tacit knowledge is the knowledge that exists within individuals and SMEs, it is unwritten, can be heuristic, is veritable and often lost when such individuals are no longer with the organization.

Seeing the value of knowledge to the continued existence of organizations, how can businesses best elicit the knowledge within their domain? How can they ensure the quality of their information, and extract valuable tacit knowledge from SMEs? Answers to these questions lies in the domain of business analysis.

 

Advertisement

 

Business Analysts

Business Analysts are change agents who often sit between the business and technology arms of an organization. They help the communication between the business and technology, ensuring data from both sides is translated into meaningful information which both parties understand, ultimately causing a change in the state of the organization. Business Analysts help organizations move forward from a current state to a future state.

Business Analysts by nature of their training can elicit tacit knowledge from SMEs, document the knowledge and ensure organizations do not increase their technical debt when valuable employees leave. They are also well placed to investigate and scrutinize the volume of information accessible to an organization by verifying and validating it with SMEs before such information is used in business decisions, thus improving the quality of an organization’s information and knowledge.

 

Some of the Business Analysts’ skills include the following:

 

 

Concluding Remarks

The knowledge circle will continue to be at the heart of an organization’s growth. Organizations which harness their knowledge correctly will continue to outperform their counterparts, and Business Analysts who understand their role in this circle will continue to be great assets and instrumental to the success of their organizations.

 

Complexity Science Terminology Applied to Business Requirements

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.

 

We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.

 

From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.

 

Advertisement

 

Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.

 

Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

  • Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
  • Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
  • Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
  • Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
  • Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
  • Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
  • Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.

User Stories: A Vital Step to Craft Successful Software

Simple and easy-to-understand user stories are the key to designing and developing successful software applications (products). Mastering the art of writing user stories is crucial for product owners and business analysts. Want to explore more about user stories? Here you go!

 

User Story 101

The foremost step in developing a project is to have a clear view of what needs to be created. Clarity is the most crucial element in software application design and development to end up with the most efficient solution.

User stories are the step-by-step documentation of a process, which describes the actions and results. It is an agile software development tool that mentions the features from the users’ perspective. The well-documented user stories are the foremost step in the agile development process to design and develop a software application that users love to use.

The primary purpose of writing a user story is to define project deliverables and how they will bring value to the user. No matter how complex a product or project can be, user stories are always written in simple terms. It needs to be as simple as possible so that a non-technical person can understand the document. There are some key considerations that make the creation of user stories even easier.

 

Key elements of a user story

  • Simple, straightforward content
  • Keeps users at the focal point
  • Collaborate with team members to gather details
  • Emphasis value deliverables

 

Apart from this, Business Analysts should also focus on making the entire teams’ and stakeholders’ participation by adding an INVEST element to the user story.

 

I – Independent (Self-contained without overlapping actions)

N – Negotiable (Keep the scope for negotiation to design a user-centric product)

V – Valuable (Must deliver values to the end users)

E – Estimable (Estimate, prioritize, and fit into sprints)

S – Small (In the form of small stories to complete in a couple of days)

T – Testable (Confirmation via pre-written acceptance criteria)

 

These elements are crucial in writing well-documented, to-the-point user stories to initiate the product development process. Once you understand the basics of user stories and how they should approach, it becomes easier to create those accurately.

 

Advertisement

 

Now that we have understood what user stories are and their key elements, let’s explore why Business Analysts need to master the skill to write definitive user stories. 

 

Why a BA needs to master the skill to write user stories

User stories are the foundational documentation that works as a blueprint while working on a project. The simple and easy-to-understand documents help the entire team to adhere to the project requirements and develop user-friendly features and functionality.

Moreover, it offers a contextual overview before the initiation of a project so that the team can understand what they need to work on. Also, they can think creatively and employ their best efforts to craft a user-centric product.

 

The most important benefits of user stories include.

 

  • Higher clarity on business values and project deliverables
  • Improved collaboration and visibility across the team
  • Prioritize features and functionality of the product
  • Efficient use of the end-users’ feedback
  • Minimize potential risks like communication gaps, technical flaws

 

As the user story conveys information about potential users and their actual needs, well-written user stories are essential to developing function-rich software applications. Business Analysts should understand the concept of user stories and focus on crafting user stories that drive value for the businesses via developing user-centric products.

 

When user stories are created

Generally, user stories are written at all software development stages BEFORE the development is initiated. Especially, while shaping product ideas, prioritizing features, and functionality, and during the development phase.

 

Who is involved in creating the stories

Business analyst, product owner or project manager, development, and design team, and sometimes stakeholders. Primarily, a business analyst or product owner writes the user stories; however, the entire team’s involvement is essential to create well-versed user stories that contribute to developing a user-centric, feature-rich software application.

 

How to create user stories

User stories are generalized documentation of why the product (software app) will be created and how it will take action. Here’s a simple way to create user stories that lead to a successful project development process. As mentioned earlier, keep users at the focal point along with what and why.

 

  • Who is the user story for?
  • What action is required?
  • Why is the action important?

 

The most commonly used format to create a user story:

As a <user>, I want to <complete this action> so that <I want this function>. Business analysts and the other team members can add other details to make the user stories to-the-point document.

 

Examples:

  • As a <user>, I want <to have to sign up feature> so that< I can log into the system>
  • As a <customer>, I want <to receive text notification when the item arrives> so that< I can pick up the item right away>.
  • As a <customer>, I want <to have online payment terminal> so that< I can pay online for purchases>
  • As a <manager>, I want <to generate multiple reports on dashboard> so that< I can monitor team’s progress>

 

In short, user stories need to be created before product development initiates. The understanding of users and what actions they need to take and why the action is necessary must be reflected in the user story. A well-documented user story will aid in creating a blueprint for project development that will lead to a successful software application. Usually, a product owner is assigned to form user stories; however, a business analyst must know how to create user stories that drive the design and successfully develop a product or software.

Ten Tips for the Young BA

After ten plus years of working as a business analyst, I wanted to highlight a few things that have tremendously helped me become a better BA and advance my career.

As a young professional, I did not have many special talents, skills, or academic education, but I was not going to let those things hold me back from success. I focused on where I knew I would stand out and organized my thoughts into the ten main points below:

 

  • Be on time. For any meetings or working sessions that I was a part of, I made it a habit to be a couple of minutes early. There were life events or uncontrollable circumstances that prevented me from this 100% of the time, but those were one-off occurrences. Generally speaking, I was known to be early and start meetings on time. This showed I was organized and respected the time of others. Additionally, being on time also meant projects and tasks were completed by the time I said they would be. If there were issues that prevented me from hitting a time goal, I would speak up and inform the respective stakeholders in advance so they were aware.

 

  • Take ownership. Anytime a project or task was assigned to me, nobody had to worry or consistently follow up on its completion. I communicated statuses and any obstacles or issues that might impact the final result. This was evident no matter how small the task was. Early on in my career, I was responsible for member service requests. Each interaction was a mini-project to ensure the member got the service they required. Taking ownership of all of my projects and tasks helped build trust with my boss and colleagues. It showed I was ready to handle larger projects and more responsibilities because I excelled with the smaller ones.

 

  • Be flexible. My ability to be flexible about almost anything shined through. My role in one project may not have been the exact same as another one. Priorities and objectives often changed. My colleagues all had different and unique personalities. In some projects, I was the dominant personality when others did not play that role. In other projects, I was the more analytical one when I realized others were observably dominant. Through it all, I remained flexible. I was known as the go-to person for just about anything.

 

  • Nothing underneath me. My first project was a stepping stone to the next one. When I was starting my career, I admittedly was a “yes” person. They could have given me a stamp with “Yes” for my forehead! Before anyone even finished their thought, I said “Yes!”. This helped me get exposure to every single area of my organization and build relationships. Within a short period of time, I could tell you the purpose of each department and why they were necessary for the organization to function properly. I am not saying I could run the department, but I had functional knowledge of their work and what made them tick. I don’t want to give the wrong impression here. As I advanced more in my career, I didn’t have the time to say yes to everything. I learned how to say “no” as my career became more mature. However, when I first started, I wanted exposure to everything and I wanted to show I can handle it.

 

  • Recognize and praise others. I don’t remember accomplishing a goal due to my efforts alone. There were always other people involved. Lots of time in discussions was spent with team members to ensure we were doing the right things. I always made it a point to praise publicly and privately where it was legitimately due. I saw first hand all the hard work that my colleagues put into their daily activities and wanted those efforts recognized. Any time I got praise for doing something, it was only because I had a great team of people supporting me.

 

Advertisement

 

  • My first project. I tried my best to stay excited and eager to learn and do more. When I was just a part-time employee trying to make a name for myself, I was hungry for anything that came across my desk. I started to treat everything like my very first project. I would ask lots of questions, show willingness to go above and beyond, seek help where I need it, and work with others. Every project after the first one was treated like my first one. This is much more difficult than it sounds because at times, work did become mundane and repetitive. I had to make a conscious effort to see the bigger picture and maintain my level of excitement.

 

  • Open to criticism. I had an open mind if someone gave me constructive criticism. This helped me get better as a professional and build my skills. I actively sought out criticism to ensure I produced things of value to the organization. Long tenured employees, managers, and executives all have different insights into different areas. Their advice helped me see things from a different perspective and ensure I took that into consideration moving forward.

 

  • Be courteous. I cannot think of any point where insulting someone, yelling, making sexually suggestive comments, touching inappropriately, or being plain rude was ever welcomed. I paid attention to my tone of voice and ensured my dialogue was objective to the matter at hand. Disagreements are common and objectively addressing them should be the goal, not trying to tear the other person down. Learning about culture, gender, age, race, religion, or any other characteristic that makes us unique, helped me get to the next level of relationship building. Showing common courtesy, being generally kind, and showing basic respect for someone  should not require a whole training initiative.

 

  • Work life integration. I did not seek work life “balance”; where I strictly worked between certain hours and then I strictly lived my personal life during certain hours. My job was part of an overall healthy life; and in order to continue having a healthy life, I needed my job. Sometimes, my best work came from putting in a few hours on a Sunday with some music in the background. Sometimes, I had to handle a personal emergency at the office that took time away from my work. I didn’t get stressed out about those things because I knew the work would get finished and my personal commitments wouldn’t be sacrificed. If responding to an email on a Saturday helped my colleague move on, I did not hesitate to do it.

 

  •  Always learning. I was always confident I could learn anything that I needed to help in my career. Today, I see the younger generation spend hours upon hours on social media, video games, and YouTube. I challenge anyone to take any topic in the world you want to learn. Spend one to two hours daily focusing on and researching that topic. The same focus you would give to having fun. Come back in a year and tell me that you are unable to explain the general and functional information of that topic. I dare you! I was amazed at how much I learned by giving it enough focus and time and you will be too.

 

In conclusion, these ten things made such a positive impact in my career and I know they will do the same for you.

The Dilemma of Test Scripts

Mention software testing to 10 people in IT and you will get several different responses.

“That’s what QA is for.”

“Unit testing covers what we need.”

“What do we need to test for? The application works fine!”

“We’re Agile. We don’t need to test.”

“The client’s not banging down my door – so all is good.”

“No, we can’t release to UAT yet. I’m only halfway through writing the test scripts.”

“I don’t have time to test.”

“I don’t know how to test this. I’ll need some guidelines.”

“That’s not in the budget.”

If you work as a BA in an IT department, you have likely heard all of these retorts – sometimes even from those who should know better.

 

It is also a trigger that can lead down a deep rabbit hole of shortcuts and excuses, with the ultimate result being sloppy code, error-prone software, and possibly tons of rework post-release. Not only impacting you and your team, but also potentially leaving your company with very unhappy customers.

Software testing has several variations, all meant to ensure that the customer is happy in the end and that fewer issues, or bugs come back to haunt the product development team. Unit testing and smoke-testing are two of the most common types of testing. Unit testing is ordinarily done by the engineer as a part of coding and is meant to test the individual functions of the various components of the specific software. Smoke-testing is done after the release of the code into production. It serves as a means to make sure that nothing has been broken by the new code. Another critical form of testing is called regression testing, which focuses on how the new code works with the existing code. Regression testing requires additional planning and visibility of enhancements between releases.

At a bare minimum, unit testing and smoke-testing are essential. They are cheap and easy and require a minimal amount of effort.

 

The real testing, however, comes in the form of functional tests and acceptance tests. This is how you connect the code that is created by the engineers with the business needs of the customers and the real-life use of the application.

Functional tests validate that the newly designed process aligns with the requirements that were provided to the development team. Functional testing is best performed by either the business analyst or the QA analyst. A distinct benefit is gained here when functional tests are designed and completed by someone who is familiar with both the application and the enhancement requirements. Here is a tip: well written requirements and an experienced QA analyst are your best friend for stellar results!

Acceptance tests (also known as User Acceptance Testing or UAT) validate that the finished product aligns with the needs of the business user. This type of testing allows the end user to touch-and-feel the new process to make sure that it will correctly address the defined business need. An end user is also looking to make sure that the workflow is not made worse. At the end of the day, the user still has a job to do!

 

Advertisement

 

A well-designed set of test scripts is the most efficient way to track results, and to facilitate tracing the functionality back to the requirements. A plethora of applications exist that do this for you! Many of these applications can also run the test scripts in an automated fashion, which works great for regression testing. If I have access to an experienced QA analyst, I leave the decision up to that person. I simply provide rock-solid requirements and expectations and make myself available for questions.

That said, I am a big advocate of DIY.

If I am running functional tests myself, I create test scripts the old-fashioned way: Excel spreadsheets. The perception is that this takes too much time. Yes. It can be tedious. However, if you consider that good test scripts can also be used for system and user documentation – a bonus for start-ups – it is an essential task, regardless of the effort. They can be maintained and re-used.

Put your user hat on and give it a try!

 

Begin with a few basic columns:

Who is the user? What role is the user filling while performing this task?

What is being tested? Describe the function in simple terms.

What are the exact steps to get the desired result?

What is supposed to happen when the steps are completed?

What actually happened when the steps were completed? Ideally, you would want this to be the same as what was supposed to happen. Many times, it is not.

Did the test Pass or Fail?

 

Add more context for tracking and tracing back to the requirements, like test IDs for each test and date tracking to facilitate repeat testing.  Add a column for additional comments so that the person who is running through the tests can add additional observations about what was experienced during the test.

 

 

In short, product quality drives customer satisfaction. Complete and consistent testing and retesting is one of the best ways to drive customer satisfaction with new products and product enhancements. It’s well worth your time and effort.

Happy testing!