Skip to main content

Tag: Best Practices

Requirements Scope Statements – a tool for establishing the boundaries of Requirements deliverables

The high-level requirements section of the BRD can have many purposes depending on the template you are using.

It can be used to document project information such as a summary of the project, the business objectives, problems/opportunities, scope (often project scope), high-level requirements (although in many cases detailed as opposed to high-level requirements are documented).

Arguably from the perspective of a BA who is responsible for Requirements Deliverables/the Business Requirements Document, the main purpose of the High-Level Requirements section is to establish the scope of the requirements deliverables for the project. That is not to say the other sections are not important from a context perspective – they are. However, the real key for the BA is to convey the boundaries for the requirements deliverables.

One way to set the requirements scope is by following the approach below to document Requirements Scope Statements (RSS) in the High-Level Requirements (HLRs) section of the BRD. I prefer to refer to them as Requirements Scope Statements (RSS) for the simple reason that they establish the scope of the requirements effort.

Guidelines for RSS:

  1. Document RSS using the following syntax (for those familiar with Agile development this is the same syntax that is used to document Epics/User Stories):
    must be able to/ will be able to do in order to .
    – An optional best practice is to indicate whether the requirement is met electronically or through manual means (see example below)
  2. Assign a unique identifier RSS00X in front of the RSS for traceability purposes.
  3. Never make a system/ application a stakeholder for two key reasons:
    a. These are Business Requirements, not system requirements/ design specs
    b. Systems/ Applications should always “do” things for the benefit of someone/ some group i.e. why does a system need to generate a report – for whose benefit?
  4. Document RSS in a table and add a column for priority
  5. The number of RSS depends, naturally, on the size/complexity of the project and number of stakeholders. As a general guide:
    a. Small projects a maximum of up to 6 RSS (remember these are just High-level requirements)
    b. Medium size projects a maximum of up to 15 RSS
    c. Large size projects a maximum of up to 25-30 RSS
    * Note: If you exceed the above guidelines in all likelihood the Business Analyst has gone from documenting High-Level Requirements to documenting Detailed Level Requirements
  6. RSS in Programs – my recommended approach is to document the RSS in the Program level BRD and then assign specific RSS from the Program level BRD to the component projects that make up the program. In general, an RSS from the Program should only be assigned to one and only one project. If the same RSS from the Program is assigned to more than one project, then I suggest breaking down the RSS into smaller RSS that can be assigned to the individual project.

RSS Example:

Reference No. Requirement Scope Statement Priority
RSS001 Investment Advisors must be able to view portfolio performance reports electronically to serve their clients.  

 

As you can see, from a requirements scope perspective you have identified:

  1. Stakeholders – Investment Advisors
  2. Requirement boundary – mid and detailed requirements (user stories in Agile) will be related to portfolio performance statements

Additional Benefits

In addition to establishing the scope of the requirements deliverables, the RSS provide additional benefits:

  1. RSS help BAs to determine what types of mid, detailed requirements will be produced which in turn provide BAs with the basis to create a high-level estimate of the effort needed to elicit, analyze, and document requirements deliverables
    For example in the above example you will probably have:
    – Data dictionary for the data elements in the reports and on the UIs
    – Mock-ups for the printed reports
    – User Interface (UI) Mock-ups for viewing the reports
    – Use cases (depending on whether or not the Business Analyst is playing a systems analyst role) related to generating, presenting and printing the reports
  2. RSS can trace to specific business objectives/problems/ opportunities to the RSS to ensure the needs are being covered
  3. RSS can also trace forward to Mid and Detailed Requirements (or vice versa depending on what traceability approach you are taking)
  4. RSS provide technology groups with a basis to provide high-level estimates of their efforts
  5. RSS enable BAs to make sure all the stakeholders are covered i.e. compare the stakeholder groups documented in the RSS against other documents/artifacts such as Stakeholder Impact Assessments or Context Diagrams to ensure all the stakeholders/ stakeholder groups are covered. If there is a gap, then RSS enable the discussion with other project team members to determine where and why there is a disconnect.

Sign off on RSS

Does RSS require a formal sign-off? The answer to this largely depends on the BAs organizational project methodology. In some organizations, the entire High-Level Requirements Section (including RSS) is signed off and baselined to help manage scope. In other organizations an email acceptance of the High-Level Requirements Section – specifically the RSS – from the project Business Owner, Project Manager is sufficient.

Ultimately there is no right way or wrong way – the organization just needs to define and follow whichever process they are going to follow.

Best Practices for Business Analysts Working on BI Projects

Business Intelligence (BI) can be defined as the access and insight (analysis) into information that provides organizations the ability to improve their existing performance.

The BI ecosystem includes a vast array of applications, tools, and techniques. Working as a Business Analyst on a BI project can be a daunting task as the objectives are clear but the route to success less known. One reason for the uncertainty for the route to success is the variety of stakeholders who feel they are accountable for the activities to be undertaken. Additional issues range from technology advancement and legacy system capabilities. The following sections within this article outline the steps to be followed that will elevate the Business Analyst towards a successful project.

Understand the Drivers for Change

Why is the organization embarking upon a Business Intelligence (BI) project, what are the key elements that are pushing the organization? There are some traditional tools that a Business Analyst can apply to identify this driver for change:

  • SWOT analysis (internal and external scan of the organizational position)
  • Vision analysis (What is the organizational vision? What is the impact of Business Intelligence (BI) on that vision?)
  • CMM (Capability Maturity Model analysis allows the organization to identify maturity across a wide range of processes)

Regardless of the tool uses you will need to understand the overall desire for change and the support for this project.

Stakeholder Analysis

Once the drivers are known the next step for the Business Analyst is to analyze the stakeholders involved and impacted by this project. Stakeholder analysis at is simplest form is the ability to list each stakeholder group and identify their interest and influence.

A Business Analyst who correctly identifies each stakeholder group will be able to quickly understand where they may be issues and concerns as the project progresses.

Business Analyst Work Plan

A critical step in the Business Analyst Work Plan (BAWP) activity is to outline the deliverables, timetable for work activity, RACI, and other project engagement activities. The BAWP allows the Business Analyst to share with the organization the expected activity that they will complete as part of this project. The Business Analyst plan enables the organization to refine the activity before too much work has taken place.

Business Intelligence Specific Activities

The first three steps would apply to the majority of Business Analyst project engagements; this step is now more closely aligned to Business Intelligence (BI). When you the Business Analyst is working on BI projects the deliverables list will include some of the following:

  • Data Dictionary (definitions of all data items contained within the data warehouse)
  • Relationship Diagrams (document the data structure of the systems, their relationships, data hierarchies, and data refresh timeline)
  • Architecture Document (Solutions and technical interfaces, hardware, application, connectivity)
  • BI Standards (naming conventions, interface guidelines, reporting structure, UI expectations, security/access)

The Business Analyst will need to facilitate some discussions/workshops with the subject matter experts (SME’s) throughout the enterprise IT department to effectively capture the requirements to support the completion of the above deliverables.

If you are not familiar with the technology and Business Intelligence (BI) environment before commencing work on such a project, I would recommend you speak with the project sponsor or business lead who will be able to outline the project from a business point of view. Having a common reference point from the business to the technology will support your success in the project delivery.

What If You Don’t Follow Best Practices?

Utilizing best practices allows Business Analysts to learn from the experience of others. Of course, you can jump into the Business Intelligence (BI) project and try not to follow the outlined suggestions. Typically, what will happen is the business is excited about the metrics output from the new BI system. They are keen to get everyone in the enterprise utilizing the BI tool for specific metrics. The Business Analyst will focus solely on the output of metrics and its distribution across the business. Getting the first few metrics and dashboards up and running is seen as a success, and the Business Analyst feels their job is completed.

What then happens is data validation, and confidence issues spring up around the business. Users are complaining about the report they run having old / out of date information. They even stop using the BI tool and revert to the more labor intensive source of information (spreadsheets or hardcopy review). The Business Analyst is brought back into the project, and it is quickly identified that there are issues with the refresh cycle of certain data fields or a new table has been added to an ERP system, and it caused issues to the data warehouse. Now you are going to have to work quickly to resolve the issue.

If only you had completed the required deliverables and obtained sign off from the organization, you would not be in this problem.

9 Actions to Build Your Self-Confidence

Almost everyone suffers from low self-confidence at some time; while many people struggle with self-confidence issues regularly.

Low self-confidence will hold you back from achieving your potential. It can cause you to miss out on many opportunities and leave you with a less happy, satisfying and fulfilling life.

The good news? You can learn to become and remain self-confident. I will reveal 9 actions that can help build your self-confidence. The more you build your self-confidence, the more success you likely will achieve which, in turn, increases your self-confidence even more. Mastering self-confidence can change the rest of your life.

Let’s look at these 9 actions that can help you build your self-confidence.

1. Prepare and Practice

Do your homework. Your self-confidence will receive a huge boost when you have appropriately prepared yourself for some event. For example, if you have a presentation to make, thoughtfully developing the presentation and then sufficiently practicing your delivery and responses to imagined questions can make you both look and feel self-confident. Do not underestimate the power of preparation in giving you the self-confidence that you seek. Preparation and practice are one of the most important actions you can take to raise your level of self-confidence.

2. Express Yourself through Body Language

Your posture and the manner you engage with others can send a strong message that says you are engaged, ready for action and committed to this exchange or event. For example, sit upright with chin up. If standing, stand upright with shoulders back. With people from most cultures, give direct eye contact. Move your head, body, and arms when in discussion or listening one-on-one. Use open gestures and lean forward for emphasis. Don’t cower or withdraw into a fetal position. Shake hands firmly—avoid a limp handshake. Be generous with your smile.

3. Speak with a Deliberate Voice

Do not use a weak, unsure or timid voice. Don’t mumble. Speak with a strong, resolute and passionate voice. Speak slow enough to ensure you are not only heard but also understood. Engage others in conversation and participate in meetings and get-togethers.

4. Promote Positive Self-Talk; Eliminate Negative Self-Talk

You become what you think about all day long. You are listening to yourself; programming yourself. Give yourself respect and positive thoughts. Through your thoughts and actions, you create a self-fulfilling prophecy. The self-talk can come from your inner thoughts, your actual words, notes, and messages to yourself and any other form of self-communication. Don’t be so hard on yourself. Be honest and truthful, but also cut yourself some slack. We are all works in progress with plenty of room for improvement.

5. Do Not Be Controlled by What Others Think About You

It is far less important what others think about you than what you think about yourself. Listen to what people say. If there is a lesson to be learned, then do so and move on. If there is no lesson, then move on. If you give more weight to what others think about you than what you think about yourself, then you are giving control of yourself to others. Don’t give that power away. Interestingly, as an instructor who has a wealth of classroom and mentoring experience, occasionally—but only temporarily—even I slip and begin to focus more on the one negative class evaluation than the 29 positive evaluations. Never allow your source of self-confidence to come from someone else.

6. Listen to Your Own Advice

You have great self-confidence advice to give to a close friend or family member; how about applying that advice to yourself? For example, I expect that you have heard most, if not all, of the advice given in this article—although you may not have heard it packaged and presented in this way. However, it becomes more a matter of accepting and applying that advice and recognizing that it can apply as much to you as it does to others. So the next time you are experiencing low self-confidence, ask yourself what advice would you give a friend who is experiencing the same thing you are; then seriously consider following that advice.

7. Be a Good Actor

Once you know how you wish to be, then act on that image. The notion of acting may sound insincere, but it is not. This is how behavior is changed: through repetitive acting. In effect, you are faking self-confidence in the beginning, and eventually, you will feel more comfortable with your behaviors and become that person. As the saying goes: You fake it til’ you make it.

8. Avoid Being Around People Who Are Toxic to You

People who put you down, are constantly critical of you and overall behave destructively towards you can cause self-doubt and pull you down. This situation not only adds no value to your life, but it can also take away from you developing into the best version of you.

9. Do Something Risky

Step out of your comfort zone and take on something you typically would avoid. When you do, you will experience an inner excitement that has likely eluded you. Afterward, examine your actions and look for any lessons. You will be proud of yourself. Now do it again …and again.

I have listed these 9 actions and their brief descriptions in a 1-page takeaway that you are free to download and make copies.

Often I am asked if I believe that people are typically born with low self-confidence, therefore, must learn self-confidence. My experience is the opposite. I observe that people are typically born with high self-confidence. Notice how small children are curious, nonjudgmental and seem to be game for almost anything. As they grow from childhood into their teens, that self-confidence can be shaken based on the behaviors of the people around them. For example, as a teen, if you frequently experience put-downs, harsh criticism and outright nasty and rude behaviors then your self-confidence could easily come into doubt.

6 Tenets of Self-Confidence

I would like to conclude this article with six tenets to keep in mind on the important subject of building your self-confidence.

  1. Self-confidence can be learned, practiced and become a core part of whom you choose to be. This has to be encouraging to know if you harbor any doubts about your ability to be self-confident.
  2. Self-confidence is largely about what you think about yourself along with your knowledge, skills, and experiences that you have worked hard to acquire. As you achieve more—and recognize yourself for those achievements—the more your self-confidence will grow.
  3. Self-confident people tend to like themselves, believe in themselves, think positively about themselves, are optimists, seize upon the opportunity and live life to its fullest.
  4. The self-confidence you project is seen through your words, actions, and demeanor. The more self-confident you are, the more people see you and accept you this way which serves further to reinforce your self-confidence.
  5. Self-confident people are engaged in life and are always achieving things, big and small. These achievements build the foundation for their success. Low self-confident people avoid life’s opportunities, and therefore success becomes more elusive.
  6. Lastly, self-confidence is an important asset to a happy, satisfying and fulfilling life; it helps you to get more out of your life. Self-confidence will help you better appreciate and savor the good times and help you deal with the challenges that will continuously come your way.

Now, go become your imagined self!

Top 5 Techniques in Business Analysis

Having been involved in several Business Analysis engagements and assignments, I have discovered top 5 techniques that I find most useful for Business Analysis, and they are highlighted below.

One Caveat: I am more tilted towards Strategic Business Analysis.

1. SWOT Analysis

The SWOT Analysis, which stands for Strength, Weakness, Opportunities, and Threat is a very simple, yet powerful technique used by Business Analysts to analyze both internal and external organizations under analysis.

When using SWOT Analysis, the Business Analyst conducts, and thorough analysis of the internal (Strength and Weakness) and external (Threats and Opportunities) actors and factors at play in the space the organization operates in.

In using SWOT Analysis, the Business Analysis answers the following questions under each of the quadrants

  • Strengths: characteristics of the business or project that give it an advantage over others
  • Weaknesses: characteristics of the business that place the business or project at a disadvantage in relation to competitors or other projects
  • Opportunities: elements in the environment that the business or project could exploit to its advantage
  • Threats: elements in the environment that could cause trouble for the business or project

Use: The SWOT Analysis is useful in understanding the position of the organization and helps to recommend the capabilities the organization needs to build or the feasibility of any initiative based on the result of the analysis.

2. MOST ANALYSIS

The MOST Analysis is a very simple and extremely powerful framework tool used by Business Analysts for analyzing and planning the details of what an organization does and initiatives the organization should be looking at doing and helps maintain strategic alignment. It can also be used to give the business or organization a fresh sense of purpose and capability.

The M.O.S.T. Analysis is a highly-structured method for providing targets to team members at every level of an organization. Working from the top down, it ensures that you retain focus on the goals which matter most to your organization

The MOST Analysis comprises of four elements:

Mission: Mission is the top-level, overall reason for being in business and defines outcomes the organization wants to accomplish. The more specific the business is when defining the mission, then the more success the business will have later on trying to define the remaining points within the tool.

Objective: The objectives are one step down from the mission. Think of these as a collection of individual goals that will add up to reaching the overall mission. Just like with the mission, objectives should be specific enough to guide decision making and planning for the future. With the mission in place, it should be relatively easy to develop a list of a few objectives. Objectives should be Specific, Measurable, Achievable, Realistic, and Timely (S.M.A.R.T.). Otherwise, goal-creep will set in, and objectives will become fuzzy and difficult to implement.

Strategy: These are the things the organization or business will do to reach the objectives. What actions should be taken to accomplish the objectives, and in turn, the mission? Strategies offer a way to quickly review and group the tactics implemented on the ground floor, so they make sense as methods to achieve your objectives

Tactics: Tactics are the methods you will use to carry out your strategies. They should be simple and relatively discrete processes that can easily be understood and carried out even by people who do not have a high-level overview of the M.O.S.T. analysis.

Use: The MOST Analysis is used to ensure the BA recommends the solutions that the organization needs to meet its objectives and mission. It is also used for alignment.

3. PESTLE ANALYSIS

The awareness of the influence the environment has on the organization the Business Analyst is working with is a very important factor in any Business Analysis engagement. The PESTLE Analysis, which is also called PEST Analysis is a tool used to identify and analyze the key drivers of change in the strategic or business environment. The analysis looks at the drivers and factors in the following and how the happening in those areas influence the decisions and the type of recommendation the Business Analysts gives the organization

Political: What are the current happenings and factors in the political landscape of the environment the business operates and how can it affect or change our business.

Economic: What are the important economic factors such as inflation or meltdown is happening, has happened, or will happen in our business environment and what do they mean to our business

Social (or Socio-cultural): What cultural aspects are most important that we need to pay attention to

Technological: What are the trends and innovation in the technology space. What is the direction technology is going, and what impact will they have in our organization or business?

Legal: What are the regulations or legislations that directly impact our industry or environment and how do they affect our business

Environmental: What are the environmental considerations we need to make in our business and organization.

Use: The PESTLE Analysis is used to understand the factors and drivers within the environment the organization operates and how those factors will influence the narratives of the organization

4. BRAINSTORMING

Brainstorming in a group creativity technique that is used extensively by Business Analysts to generate ideas, identify root causes of problems, and solve complex business problems. Most of the other techniques such as Mind Mapping, Root Cause Analysis, SWOT, and PESTLE Analysis use Brainstorming and an underlying technique.

I particularly find this technique very useful in generating diverse ideas.

Use: This is used in problem-solving, fact finding and idea generation

5. MINDMAPPING

You want to be sure you have all the areas within the analysis covered, you want to certainly confirm you have considered the different and diverse components and elements under analysis, you do not want to miss anything out? Then you would need the MINDMAP technique.

The Business Analysis function has over the years been greatly helped by this special and often unrecognized technique, but I find it extremely helpful during my business analysis engagement

What are the techniques you find useful in Business Analysis engagement? Share in the comment sections

Strategy Spotlight: Roles, Responsibilities, and Skills – Project Managers and Business Analysts Meet Business Analysis

Project Managers and Business Analysts meets Business Analysis (clarify your perspective)

It still amazes me, after 14 years of speaking, teaching and writing about Business Analysis I still get this question: “What is the difference between a Business Analyst and a Project Manager?” I was teaching a Fundamentals of Business Analysis program for Project Managers when this question was raised. Since the program was focused more on Project Managers, we are using the Project Management Institutes (PMI), Business Analysis for Practitioners: A Practice Guide as a reference.

Related Article:  The Project Manager Vs. The Business Analyst

So here I am with 47 of my new closest best friends having a dialogue about the role and responsibility differences in these professions. The simple answer to this question is the Project Manager is responsible for the beginning, middle and end of a project with initiation, planning, execution and closure whereas the Business Analyst is concerned with the end product and business solution making sure the requirements are met for the key stakeholders.

Here’s the thing: the question being asked is about titles and positions but does not actually ask about roles and responsibilities. For example, as a Director of Operations, you would have the title and a position. In a traditional organization, you might even think you have some authority rights, which in today’s rapid business climate is a bit passé. As Director, you would take on certain roles and responsibilities beyond the position sitting on committees, running initiatives (projects) and even doing Business Analysis work. Maybe at a different level, but you would be.

In reality, Business Analysis can be performed by anyone tasked with understanding the business problem, business opportunity, potential business solutions, implementation of a potential business solution, and measuring project, program or strategic initiative results. So really, Business Analysis is done at all levels and across all departments (strategic, tactical and operational) within a specific context. It gets messy when you seek to place traditional structures around Business Analysis through titles and positions. Unfortunately, a lot of organizations have no choice but to put Business Analysis or at least the

Business Analyst in a box.

Some time ago I was hired as a Program Consultant by a Director of Enterprise Services and the CIO of a large resource company to get ITSM on the strategic agenda of the organization. It meant as a Program Consultant I had to put on a senior Business Analysis hat and get three distinct organizations (utilities, gas, and oil) in two continents to agree ITSM was a good investment for everyone. This was a pure bottom-up initiative where Project Managers would not have been involved since the initiative was not yet approved and funded. The key stakeholders were middle and senior management. Therefore, there was nothing yet to implement. I truly love these kinds of initiatives. Discover if something is a good idea and then, maybe, we’ll bring in the Project Managers.

The program analysis required me to use the soft and hard skills of Business Analysis to determine if service management was a good idea. That meant an assessment and one-on-one interviews with key people to discover their challenges, get their thinking on potential solutions and what the benefits would be before even mentioning the potential solution domain, ITSM. It took 4 to 6 weeks to do.

I reported back to my Sponsor and CIO with a discussion and recommendation we engage key stakeholders from each organization to discuss their maturity levels, what they would like to achieve, the benefits and a develop a set of 6 key recommendations for the executive team. My sponsor approved the next phase of the initiative to work towards building consensus among the management team and the best course of action.

To make a long story short 6 to 8 months later, we got the initiative to the business case stage and presented a business case to the executives and board of directors for approval. From a business standpoint, it made sense to proceed with the initiatives since there was a huge opportunity to standardize and share support services across three distinct organizations. Upon approval, Project Management kicked in. The Project Managers prepared their plans for execution while intermediate to junior Business Analysts joined the team to further flesh out the detailed requirements. In this case, senior Business Analysts started the process, and other Business Analysts completed the process downstream.

In this scenario, for the initiative to get ITSM on the agenda of the organization, I was called a Program Lead and Consultant. The title relevancy allowed me to be categorized within an organization so I could carry out my sponsor’s mandate. From a role and responsibility skill set, I used Project Management and Business Analysis expertise needed to get the job done. For the phase one initiative, we had a project charter and Business Analysis charter blended. This set the boundaries for the evaluation work to be done.

We developed a requirements management plan and a communication plan to ensure we had a path to follow and a means to communicate what we were doing. There was a summary of findings and status meetings, financial evaluations, business case development, and not to mention the one-on-one meetings, interviews, and group facilitations sessions. If you love Business Analysis and Project Management blending at the senior levels, this was a consultant’s dream, a real enterprise initiative working at the senior management and executive levels.

Over the course of my career, I have been a senior consultant and senior Project Manager running small and large scale projects for organizations. The interesting thing is that I have always had to use the Business Analysis skill set in Project Management. I have also been a Business Analyst. In my junior years, I did small Project Management work to get things done.

The big change I have seen is really the change in titles. For me, Project Management has been reasonably stable since the mid 90’s. Business Analysis, on the other hand, has not. I recall a time when I was called a CSR (client service representative). I came to work one day, and I was told my title had been changed to Business Systems Analyst and Coordinator. My job didn’t change at all nor did my pay. Eventually, someone asked me what I did. I told them, and they said, “Oh you’re a Business Analyst.”

Business Analysis is all over an organization. It is not the rightful domain of any one department, group or individual. It is a role, a skill set, and crossing over boundaries to better understand the business need and to come up with creative strategic business solutions to challenging situations. This is a significant difference when it comes to Project Management work of getting it done. Organizations will find Business Analysis being used on agile teams, with process and systems analysts, product managers and owners, Project Managers, requirement managers and a whole host of other places.

I do believe in the importance of advancements in creativity and strategic Business Analysis thinking and abilities. Business intelligent and artificial intelligent will strip away the fibers of traditional thinking, titling and wage structures. Pure talented Business Analysts will rise to the top of a number of organizations where building business brainpower is rewarded. The professional who is willing to master the application of the Business Analysis skill set will rule the future business kingdom while everyone one else will still asking, what just happened. The Business Analyst will already know the answer.

Final Thought – It is not often I write this kind of article, walking the fine divide and complexities of the Business Analyst versus Project Manager’s work. When you are locked in a room with 47 people, and they are all asking the question regarding the difference between a Project Manager and a Business Analyst. What are you supposed to say? Really it comes down to the size of the organization and the many hats you wear. Maybe, the Project Manager asks, is it done yet, and the Business Analyst asks, what solution options are available. The reality is both title professions use the Business Analysis skill-set. You just need to choose which side fits you more naturally.

I suggest you dig deeper and look at the skill set you need to develop for success in your business, career, and life and you will see there is a bit of Business Analysis in all of us. Good Luck.

Remember; do your best, invest in the success of others, make your journey count, Richard.