Tag: Business Analysis

7 Tips for Writing Better Requirements

Written by Dustin Snyder on June 22, 2017. Posted in Articles. 1 Comment on 7 Tips for Writing Better Requirements

The success or failure of a project is due, in large part, to the requirements underpinning the effort.

When written with these steps in mind, project managers are likely to get buy-in from stakeholders sooner. Additionally, the project team will experience time savings on development as well as a more comprehensive set of testing scenarios as a result of well-written requirements. Whether they’re business, functional, or performance requirements, these steps are sure to up your game and make you a more impactful Business Analyst.

1. Know Your Audience

When sitting down to begin composition of your requirements, take a moment to think about the potential readers. In most cases, your requirements will be read by leadership, project stakeholders, developers, and testers. As you consider these sub-sections of your company, reflect on the collective skill set of each group. What would they expect to see in a requirements document? What questions can you preemptively answer for each user group? How can you write to the satisfaction of each of these disparate groups?

2. Use Plain Language

Incorporating plain professional language in your business requirements will always pay dividends when attempting to satisfy colleagues across the company. The key to writing a good requirement is balance. The more technical the requirement, the more necessary it becomes to state it for even your least technical audience member plainly. A new employee should be able to read your requirement on the first day of their job and be left with a basic understanding of what should happen. At the same time, you want the requirement to be succinctly stated and contain all of the necessary technical information the developers and testers require to complete their jobs. A good example of this balance might look like this:

Req 9.0 – A section labeled “Member Details” is present on the details window outlined in Req 7.5. This section contains the following field:

Date of Birth – mm/dd/yyyy
A. When a member is a primary subscriber, this value is populated from the DB712 segment on the 1100F section of the returned member transaction file.
B. When member is the dependent of primary subscriber, this value is populated from the DB712 segment on the 1100G section of the retuned member transaction file

In this example, I’ve provided the developers the necessary field formatting and specific data origination points to allow for mapping while still clearly and succinctly stating what should happen when this requirement is executed. A project stakeholder or new employee can look at this requirement and, while they may be unfamiliar with the referenced file, they can exactly understand what needs to occur and what the expected output should be.

3. State the Purpose in Requirement #1

In each section of your requirements document, the very first requirement should always provide a holistic picture of what is expected as it relates to the particular sub-section of the project. For example, I might be writing requirements for the creation of a new webpage. My first requirement will always outline each element on the page with a single descriptive sentence indicating what function the element serves.

This method allows everyone from testers to leadership to wrap their heads around the expected outcome at the outset, before diving into the details of each element and potentially getting lost as you take them deeper into the weeds. This requirement also serves as a touchstone for programmers and testers which provides them a high-level picture of the finished product as well as a single, easy to read a checklist of elements to address.

4. Enumerate, Then Enumerate Some More

Let’s look at the example requirement again.

Req 9.0 – A section labeled “Member Details” is present on the details window outlined in Req 7.5. This section contains the following field:

Date of Birth – mm/dd/yyyy
A. When member is the primary subscriber, this value is populated from the DB712 segment on the 1100F section of the returned member transaction file.
B. When member is the dependent of primary subscriber, this value is populated from the DB712 segment on the 1100G section of the retuned member transaction file

Here we see a single requirement broken down into several bullet points. The singular reason for this level of delineation: testing.

When composing test scenarios, this style of enumeration is helpful when the requirement contains an if/then statement. In this case, we’re pulling the member’s date of birth into a field Depending on the member’s relationship to the primary subscriber; we have one of two locations to pull this data from.

Individuals tasked with testing this requirement will want to ensure all scenarios are accounted for. Based on this style of enumeration, a tester might compose their test script as follows:

Req 9.0.1.A – Member is subscriber, DOB is pulled from DB712 on 1100F section of member file

Req 9.0.2.B- Member is dependent, DOB is pulled from DB712 on 1100G section of member file.

This can be especially helpful I’ve included multiple elements into a single requirement. For example, I may have a date of birth, ID number, last name, and first name. I would assign a number to each of these elements and a letter to each if/then statement to help my QA analysts ensure their test scenarios are in lockstep with your requirements.

5. Make Them Specific & Definitive

When writing requirements, there’s no room for wishy-washy language or a passive tone. These requirements are the foundation for the project and absolutely must be adhered to. While it’s never advised to tell the developers exactly HOW to execute the job, it’s imperative to be specific and state the expected outcome with zero wiggle room.

Note the tone and the specificity of the following example:

Req 1.2 – End-user cannot query a future renewal date exceeding 15 days from the date of the inquiry (current date). Additionally, end-user cannot query a historical renewal date exceeding 12 months from the date of inquiry (current date).

Future Renewal Date

Dates exceeding 15 days into the future are disabled on the date selection calendar control.
When a future renewal date exceeding 30 days from the date of inquiry is manually entered, the following error is displayed in red text:
“Date of service cannot be more than 30 days from today.”
Any manually entered date value deviating from MM/DD/YYYY format generates validation error documented in Req 1.1.
Any manually entered date value containing a non-numeric character generates validation error documented in Req 1.1.
Historical Renewal Date
Dates exceeding 12 months into the past are disabled on the date selection calendar control.
When a historical renewal exceeding 12 months from the date of inquiry is manually entered, the following error is displayed in red text:
“Date of service cannot be older than 36 months from today.” Search eligibility button remains disabled.
Any manually entered date value deviating from MM/DD/YYYY format generates validation error documented in Req 1.1.
Any manually entered date value containing a non-numeric character generates validation error documented in Req 1.1.

This wording of this requirement is specific and leaves no opportunity for misinterpretation by developers and testers alike.

6. Account for Edge Cases

Within the scope of any project, there will always be outlying scenarios causing unexpected outcomes. Some of which may require an almost perfect set of circumstances to occur. While these edge case scenarios may seem impossible, your project is always subject to Murphy’s Law.

I now make it a practice to consider every conceivable edge case, which often includes consulting with colleagues to brainstorm all of the ways a product could produce unwanted results. Once a comprehensive list of scenarios has complied, include them in your requirements. Some stakeholders may feel this is overkill. However, your developers and testers will appreciate the forethought.

7. State the Obvious

Both seasoned and new business analysts alike can display a tendency to assume a base level of knowledge for all project participants. For the sake of brevity, we often avoid documenting what are considered “implied requirements.” In today’s professional culture of contracted employees, we can no longer omit the obvious details. Considering the rate of churn experienced during the lifetime of a project, the risk of your audience omitting a vital detail in the development and testing of the product is significantly higher. With the addition of temporary contractors, you may find the makeup of the project team is radically different at the time of development than at inception.

Don’t be afraid to state the obvious, even if it appears unnecessary or redundant. You’re not writing a fictional short; you’re composing a vital project artifact that aims to answer every question and leave no stone unturned.
Are there any other tips you’ve found to be useful in writing your requirements?

Please share in the comments section.

7 Approaches that Business Analysts Should Use to Get Out and Network

Written by Richard Lannon on June 20, 2017. Posted in Articles.

I received a phone call from a peer in another company, asking me if I had ever written anything on how to network.

She mentioned that she had reviewed my blog and couldn’t find anything thing on the topic. They were particularly interested in the idea of business analysts networking and going to events. The sun was out, spring was in the air, and they liked golf—great reasons for getting out of the office.
Their interest got me thinking about the importance of getting out of the office and building a network.

Go with a Purpose

It never made sense to me to go anywhere without having a purpose for being there. As a professional, I have to go to networking events. Because I build a career in the consulting profession, networking has been somewhat mandatory. Honestly, for the majority of these events, I would have rather been somewhere else. That is where purpose comes in. Now when I attend events, I set a goal (nothing big) and focus on how I can help someone else. Try creating a purpose beyond just meeting people, collecting cards and speaking.

Managing Time

I am terrible at setting time aside to attend events. If I don’t mark my calendar with vacation time, long weekends and events, chances are I will forget them. I will work. It is the way I am wired. So I had to learn the skill of looking at my calendar annually and setting time aside at the beginning of the year when I am not available to work. A business associate and friend who’d noticed that I never put time aside, challenged me to book events so I wouldn’t have to be in the office all the time. It’s hard to avoid distractions, but unless you plan your time for when you are going to attend events, there is a good chance you won’t go to them. So set the time aside now.

All by Yourself

We tend to go to professional events with the same people. Your friend at work is going, so you attend also. During the evening or day, you hang out with the same people. Why not go alone? You can add a purpose. For example, maybe you want to meet someone; a decision maker, recruiter or vendor so you can have a private or personal conversation. If someone in your network introduces you to that person, seek that person out and have a conversation without peers around you. More importantly, set yourself up, so you are not always with the same people. Expand your network and make new friends.

Become Part of a New Team

I try to do this when I am going to a professional event. In the introduction, I stated that my peer mentioned attending an Association golf event. This would be a great opportunity to meet new people. I once did this and ended up on a team with two CEOs and a CFO from three different companies. We all had a great time. Throughout my career, they have helped me to connect with a lot of other people. Maybe golf is not your thing. That is fine. There are lots of ways you can become part of a new team. Just be willing to step out there and make it happen.

Be Informed Through Research

If you’re attending an event where you are meeting people, you have a limited amount of time to make an impact. It is important that you be informed about an event before you attend it. This includes checking out the host’s background, the sponsors, the types of people attending the event and determining who you want to meet. Get the information you need from Twitter, Facebook, LinkedIn and the professional association’s website. For example, I am a music buff; I play the guitar, and I listen to rock stations on Spotify. There was a CEO I wanted to meet. I noted on Facebook that he played guitar for fun and loved to jam with other musicians. So I decided to meet him and talk to him about music. We had a great discussion and created a relationship. You don’t have to research business-only things. Your research should be about finding and sharing common interests. I guess that’s another lesson learned.

Dress for Success

Can’t say I have always liked that term as it means different things to different people. Clothing is such a personal thing. In the context here, I think it has to do with knowing the event and dressing accordingly. I often contact an event’s coordinators and ask what the appropriate attire is for the event. Some events are formal, while others are downright casual. I have done a lot of work in the ICT industry (information, communications, and technology) where the standard of the organizations is a T-shirt, a pair of blue jeans and no shoes. I have to admit I feel at home in these organizations. Periodically I have to wear a suit and play the part. Still, you can find a signature piece to wear; something that creates conversation. Try a unique, colored shirt, or a hat or pin. I am a man of many hats; from baseball caps to fedoras with different styles for different seasons. I initially wanted protection from the sun, but as things progressed, I started to wear different styles. Interestingly enough, they have become conversation starters. I think you can dress for your success and be unique at the same time.

Have Your Coordinates Ready

Years ago (and maybe today) they are teaching to always bring business cards with you to events to give out to people. In my mind, this is very traditional and is important for a certain generation. Now we have so many options when it comes to sharing our coordinates as a means to connect with people. Still, it is important to pre-plan how you are going to share your information with your new friends. First, consider business cards since they still have a place at networking events. Second, if your company is no longer providing business cards, consider having something unique to hand out. If can be small. For example, I am an author, so I carry bookmarks with me that have the 10 Steps of Strategic Planning written on them. You could easily have something like that for your business; a small keepsake to hand out when you need to provide your coordinates to someone. Third, chances are you have your smartphone. Don’t be afraid to get someone’s email or cell number and text them your coordinates. It is the easiest way to connect with people. Follow up quickly and share information.

Final thoughts

Personally, just like a lot of people, I struggle with going to networking events. So I had to create a process around attending events; setting the time aside, going with purpose and being prepared. Sitting in your office all the time is not good for your long-term career and business. You have to get out and meet new people to share information with, get new ideas and have fun. I think the truth is that people want the same things from networking that you want: enjoyment, meaningful conversation and to create relationships. All you have to do is pick your events and go do it. Good luck.
Remember, do your best, invest in the success of others and make your journey count.

Richard.

What a Business Analyst is not?

Written by Tim Coventry on June 15, 2017. Posted in Articles. 1 Comment on What a Business Analyst is not?

Many articles have been written about what a business analyst is—articles that define a business analyst as…

someone who helps stakeholders make decisions, facilitates, communicates, acts as a bridge between business and IT, etc.But any person in an organization can do this! Many other professions help stakeholders with decision-making, such as management consultants and business coaches. Very little has been written about what makes a business analyst different from any other person in an organization, role, or profession.

To me, a business analyst is someone who performs business analysis through eliciting, analyzing, specifying, and managing needs, value & requirements at a level of competency. If you can’t perform all four of these areas competently to deliver the business need, you are not a business analyst.

Statistics show that many people call themselves a Business Analyst—a simple search in LinkedIn displays over 80,000 people in Australia with the phrase in their title, and over 1.7 million in the rest of the world using the title “business analyst.”

The BABOK® Guide also states that “a business analyst is any person who performs business analysis tasks described in the BABOK® Guide, no matter their job title or organizational role.” The BABOK® Guide does not make the distinction of business analyst quality, competency, and experience breadth of tasks and techniques; however, the IIBA® certification and competency model does require breadth across the six knowledge areas (KA).

Evidence in the field strongly suggests good business analysis is more likely to be achieved by a business analyst who is well trained, industry aligned, certified, practice-supported, and experienced in multiple approaches and end-to-end business analysis across the BABOK® Guide.

Unfortunately, many individuals in our profession don’t understand how to connect eliciting, analyzing, specifying, and managing needs, value & requirements. I often observe individuals with the title “business analyst” or another specialist role (process analyst, business architect, project manager, business rules analyst, data analyst, etc.) performing some of these activities but not tightly coupling them to perform a high standard of business analysis.

There are also good business analysts not promoting themselves and giving a voice to the power of performing excellent business analysis. The connection of eliciting, analyzing, specifying, and managing requirements is hard work, but when performed well provides great value to organizations, saves wastage, and reduces failure.

You can perform excellent business analysis if your title is not “business analyst,” but you must have the underlying competencies of eliciting, analyzing, specifying, and managing requirements. Remember that being able to apply a Band-Aid does not make you a nurse.

Many professions perform elicitation—for example, teachers, doctors, and lawyers. Engineers, physicists, and process analysts perform analysis, while technical writers and solution architects specify. However, Business Analysts manage needs, value & requirements, tracing to join things to make sense of them. To manage requirements well, you need to plan, elicit, and analyze continuously—often under pressure.

Business Analysis In A Disruptive World: A New Frontier For Business Analysis Professionals, a discussion paper from IIBA & BCS, states, “As an example, the Agile Principle: ‘Business people and developers must work together daily throughout the project’ was interpreted as only developers and business stakeholders. Additionally, popular adaptive approaches don’t identify all key roles that are needed to successfully execute work in this way. As an example, SCRUM identifies two critical roles and everyone else is part of the development team. Misconceptions and misunderstanding led to organizations ignoring the need for business analysis expertise and assuming that developers and business stakeholders would jointly understand how to elicit requirements.”

Some Agile approaches assume team members will manage needs, value & requirements, even though many of those team members do not have the necessary skills, experiences, and competencies with requirements.

An expert business analyst requires a unique skillset that many senior executives have never experienced. Excellent business analysis is more likely to be achieved by a well-trained, certified, and practice supported business analyst. You need to know that you are engaging high-quality business analysts if you want a greater chance of project success.

Managing requirements occurs throughout any organization from strategy, operations, portfolios, programs, and projects, and a competent business analyst will improve requirement clarity, efficiency, and outcomes.

What is a business analyst?

Tracing is key to business analysis. If you can’t trace both forwards and backwards, then you can’t see moving parts and determine possible solutions for business issues or opportunities. In my opinion, this is the top skill that anyone performing business analysis needs.

A business analyst should be independent from managing or being accountable for the customer journey that the business analysis is being performed on. Giving well-analysed and synthesized options to stakeholders is better than making recommendations, as options give the ownership to the stakeholder.

Adrian Reed says “We need to focus on the benefits of business analysis rather than the tools or techniques. To draw a (deliberately) left-field analogy, if an airline said we maintain, fuel and fly aircraft, issue and validate tickets, specializing in transatlantic flights” that may well be accurate. But a far more compelling message is “We can fly you from Heathrow to JFK in 7 hours”.

I agree with Adrian we must explain the benefits of business analysis, but we must also add our point of different (POD) that sets us apart from any other profession. An excellent business analyst elicits, analyses specifies and manages needs, value & requirements effortlessly, somehow sorting the wood from the trees so that stakeholders can make informed business decisions.

In 2017, hopefully, all great business analysts stand up and perform excellent business analysis using the unique skill of managing needs, value & requirements to help organizations improve business performance!

Meeting Facilitation Boot Camp

Written by Caprice White on June 14, 2017. Posted in Articles.

Meeting facilitation is a soft skill that is a vital part of your business analyst toolkit. It is rare to be a business analyst and not facilitate meetings.

Over your Project Management or Business Analyst career, you will attend, schedule, plan, many, many meetings.

As a facilitator, you must remain a neutral party. You are responsible for meetings and works shops that uncover and reveal requirements, are productive and provide an environment that fosters open communication and enables all stakeholders to reach agreements and consensus. You can do this, Of course, you can! YOU are a superstar when it comes to meetings.

Even superstars need a refresher once and a while, so it’s meeting facilitation boot camp time!

1. Plan Your Logistics

Logistics are the who, here and when part of the process. The list below should assist you with your logistic preparations:

Who are your participants? Ensure that you invite the correct stakeholders to your meeting.
Where will your meeting take place? Make sure your meeting space is the appropriate size for the number of stakeholders who will be in attendance. Do not make the rookie mistake I did in my early days and book a meeting room suitable for 8 when I had 15 attendees. You want to make sure your stakeholders are comfortable and have enough room for any presentation materials.
Are there time zone considerations? Does your company have people working remotely offices located in various time zones? If so, you need to take this into consideration when booking the time for your meeting. Make sure it is at a reasonable time where all parties can attend.
Pre-book any resources required such as shared conference call lines, meeting room, projectors, laptops or web-sharing software.
Ensure you familiar with all of the equipment you will be using during your meeting. Just to be on the safe side, schedule a dry run before your meeting so you can address any technical issues to ensure things don’t go pear-shaped.
Print out any documents or handouts required for your stakeholders. If your meeting requires pens, paper, post-it notes or larger writing sheets ensure these supplies are on hand and ready to go before your meeting.
Who will be taking notes? If you are facilitating the meeting, will you have time to take notes or do you need assistance from another Business Analyst or Admin? Arranging this beforehand can help with the efficiency of your meetings.
Will you be serving food or coffee? If so, ensure these are pre-order for your participations. I find a box of donuts and coffee goes a long way in eliciting requirements from early morning stakeholders.
Always have a backup plan in place. Sometimes resources fail, or rooms get double booked. Ensure you have a backup plan.

2. Set the Agenda

Once you have your logistics sorted, it’s time to send out meeting invitations and set the agenda.
Have you ever received a meeting invite and had to contact the organizer because it was unclear what the meeting was about and what the expectations were? Any confusion can be avoided by sending your stakeholders a clear agenda that includes the following:

An objective for the meeting
List of discussion topics
Need your stakeholders to do some homework? Don’t forget to include attachments or pre-reading for attendees to review.

3. Ice Breaker and Introductions

Once your stakeholders have arrived and are settled in, take the first 5 minutes of the meeting for people to introduce themselves and what their roles are on the project. This allows your attendees to understand other’s roles and responsibilities on a project, creates context, and gets them comfortable and ready for the meeting.

If there is time, I like to throw out an icebreaker question, unrelated to the project or meeting to get people comfortable in the right headspace to communicate. A few sample icebreaker questions for the group are:

When you were a child, what did you want to be when you grew up?
What is the strangest food you have ever eaten?
What is the longest you have ever stayed awake and why?

4. Review the Agenda and Get This Party Started!

Now that your participants are settled, take 5 minutes to review the agenda. This establishes meeting guidelines and context, which will make the meeting a lot more productive.

Review the objective of the meeting and the agenda
Restate the project objective as a refresher to the stakeholders.

This demonstrates that the meeting or workshop you are holding is relevant and aligns itself with the project objectives and priorities.

5. Facilitator Not a Participator

Remember, you as a meeting facilitator are a neutral party. Your job is to lead the discussions, and drive out requirements by engaging your audience. You are the liaison between the project sponsors, stakeholders, and software development teams. Remember to remain neutral and allow your stakeholders to make decisions required to move forward.

6. Manage Distractions

If your stakeholders are holding or being distracted by side conversations or are getting way off topic, it’s your job as the facilitator to bring their focus back to the agenda.

7. Parking Lot items

Sometimes it seems that your group may wander off topic or wish to discuss items not on the agenda, or have questions and concerns that will not be addressed during your limited meeting time. I have found the best way to address this is to create a “Parking Lot” list of items. This lets your stakeholders know that you are listening to their questions and concerns and that they will be addressed in the future but not during this meeting.

8. Use Visual Business Modeling Tools

Using visual business modeling tools during your meetings and workshops can help drive out requirements or uncover processes for your stakeholders. These assist with identifying and analyzing user requirements, system requirements and capture business rules.

9. Conclude with next Steps and Action Items

Once your meeting is complete or if you run out of time, it is a good idea to wrap up your session by reviewing the following:

Parking lot items
Action Items
Next Steps

10. You are not done yet superstar…follow up with your stakeholders

Just because your meeting has concluded, it does not mean your work has ended.

Distribute your meeting notes including action items. It is best practice to do this within 24 hours of your meeting.
Set deadlines and follow up on any action items
Set up and send out invitations for the next meeting if required
Remember to thank your stakeholders for attending. A simple thank you can go a long way.

Big Picture Thinking: Where Does the Business Analyst Fit In?

Written by Lenesh Naidoo on June 13, 2017. Posted in Articles. 1 Comment on Big Picture Thinking: Where Does the Business Analyst Fit In?

Recently my manager and I were having an in-depth discussion about the different levels of a Business Analyst (BA).

How do you figure out a BA to be junior, intermediate, senior and in some cases, principal/lead? Surely an analyst’s thought process and ability to understand plays a critical role when defining what level that BA is at.

During the discussion, we went to a boardroom, where my manager drew to circles on either end of a white board with a dotted line in between. On one side he wrote ‘shareholders’ and on the other, he wrote ’data captures.’ He then asked me to fill in the dotted lines with how the data captures affect the shareholders and show him where the BA fit between the two sides. The ability for you as a Business Analyst to build an end-to-end picture in your mind of the business you service will directly show in the detail and quality of the output you provide as a Business Analyst.

In this article, I fill in the blanks and show you what else fills in the ‘moonshot’ as I call it.

Data captures in business are, generally, at the very end of the organization’s value chain, while shareholders, on the other hand, are those who have their money (value) in the game. How does a business give the shareholders more value? Generally through innovation, process improvements and doing things better.

Thus a board of directors (BOD) or executive committee (EXCO) will decide on the best strategy to increase value for their shareholders. In this article, we can assume that the executive committee has decided to offer a product via a mechanism that has given them an excellent reputation in the market, which would differentiate themselves from their competitors; make it easier for customers and reduce operational costs.

EXCO or the BOD have communicated this strategy to the senior management team in the organization and have made it a high priority as they believe this will allow them to attract a big percentage of the target market.

With the senior management team, EXCO has determined that to achieve their strategic objective, a mechanism in the business has to be rebuilt. EXCO and the senior management team then pull in the projects/IT team to help achieve this objective.

EXCO, senior management and the Projects/IT team defines the objective; the business owner of the project; the stakeholders; the scope, and the deliverables required by the project/IT team.

Furthermore, SME’s and specific employees are identified to ensure the rebuilding process delivers the relevant functionality.

You might ask, why is the projects/IT team out of line and where is the BA? The BA falls between the strategy and the users. I say it in this manner because the BA has to know why a project is being initiated and ensure the deliverables of the project/IT team align to the users/employees who will be directly affected.

The BA should understand the strategy; the purpose; the moonshot or the reason as to why a project has been initiated. Yes, some stakeholders will push their agenda, but it lies upon the BA to filter/manage requirements/instructions and ensure the project/IT team deliver according to the strategy/purpose of the project. The BA has to align the requirements of the end users to the strategy of the business and communicate this back to the project/IT team for them to deliver.

The better you understand requirements about the strategy/moonshot, the more value you can provide. You can challenge certain requirements/changes, or you can propose requirements/changes that better align to the users need and strategy of the project. You can better determine solutions or realize requirements missed by the end user, thus ensuring a more accurate deliverable by the project/ IT team.

Producing a deliverable that does not align with the strategy or provide value to an end user can directly result in zero value for business and zero value for shareholders. Thus move away from being a note taker and move towards becoming a Business Analyst!