Skip to main content

Tag: Planning

BATimes_Mar2_2023

Business Analysis Amalgamation with Product Management

Written by Neethu Nair on . Posted in Articles.

In today’s fast-paced business environment, organizations constantly seek ways to improve their processes, products, and services. Business Analysis and Product Management are two key areas essential to achieving these goals. Traditionally, these functions have been viewed as separate disciplines, with Business Analysts focusing on identifying and analyzing business requirements, while Product Managers focus on the development and management of products and services.

However, there has been a growing trend towards amalgamating these two functions to create a more integrated approach in recent years. By combining Business Analysis with Product Management, companies can benefit from a more holistic understanding of customer needs, more effective use of data, and improved collaboration and communication between teams.

An Overview of Business Analysis and Product Management:

Business Analysis is the process of identifying, analyzing, and documenting business requirements, processes, and workflows. The role of a Business Analyst is to help organizations improve their processes and systems by identifying areas of improvement, gathering and analyzing data, and making recommendations for change. Business Analysts often work closely with stakeholders and other teams within an organization, including IT and project management.

Product Management, on the other hand, is focused on developing and managing products or services. The role of a Product Manager is to identify market opportunities, define product requirements, and work with cross-functional teams to bring products to market. Product Managers must have a deep understanding of customer needs and market trends and/ or the ability to manage budgets, timelines, and resources.

 Benefits of Amalgamating Business Analysis and Product Management:

While Business Analysis and Product Management are distinct roles, there are many benefits to amalgamating the two functions. Here are a few of the key advantages.

  • Better understanding of customer needs:

One of the key benefits of amalgamating Business Analysis and Product Management is the ability to better understand customer needs. By working together, these two functions can create a more complete picture of customer requirements, preferences, and pain points. This can lead to better product design, more effective marketing, and higher customer satisfaction.

  • Alignment towards Business Goals:

Amalgamating Business Analysis and Product Management also improve team collaboration and communication. These two functions can ensure that everyone is aligned on business goals, product requirements, and timelines. This can lead to better project outcomes and faster time to market.

 

Advertisement

 

  • More practical use of data:

Another benefit of combining Business Analysis and Product Management is effectively using data. Business Analysts are skilled at collecting, analyzing, and interpreting data, while Product Managers deeply understand market trends and customer needs. These two functions can leverage data to improve product design, pricing, and marketing decisions by working together.

  • Faster problem-solving:

Amalgamating Business Analysis and Product Management also lead to faster problem-solving. By having a team of experts who can analyze data, identify issues, and recommend solutions, organizations can respond more quickly to changing market conditions or customer needs. This can help companies stay ahead of the competition and achieve their business objectives more effectively.

  • Better outcomes over outputs:

Finally, combining Business Analysis and Product Management can improve project outcomes. By working together, these two functions can ensure that products are designed to meet customer needs and that projects are delivered on time and within budget. This can lead to improved customer satisfaction, increased revenue, and a stronger competitive position in the market.

The amalgamation of Business Analysis and Product Management can benefit organizations looking to stay ahead in today’s competitive business landscape. By combining these two functions, companies can improve collaboration and communication, better understand customer needs, use data more effectively, and achieve better project outcomes. Whether a small start-up or a large enterprise, an integrated approach to Business Analysis and Product Management can help you achieve your business objectives more effectively.

BATimes_Nov23_2022

Avoid Illusory Constraints And Incentives

Written by Adrian Reed on . Posted in Articles.

If you were learning to drive in the UK, chances are you’d get in touch with a driving instructor. Over here, many of the driving schools they work for have company names starting with the number 1 (often ‘1st CompanyName Driving School’).  I suppose if I were a driving instructor my default company name would be “1st Reed” or something similar.

It might seem curious as to why there are so many driving schools with “1st” in their company names. We might assume it’s a signal that people who learn with them pass their driving test first time… but I suspect there’s another legacy reason, which goes back twenty years or more.  You see, when I learned to drive, you didn’t Google a driving instructor, you used the Yellow Pages.

 

For anyone unfamiliar with the Yellow Pages, it used to be a thick local telephone directory of different companies. It probably still exists, but twenty years ago it was an essential reference for every household and could usually be found close to the (corded) landline telephone.  It was printed on thin yellow paper, and had thousands and thousands of companies listed.

You’d search for a category (‘driving instructor’) and then (with the exception of paid ads) the companies were generally listed in alphabetical order.  And company names starting with numbers were given preference, so a company named “1st Aardvark Driving School” would be listed above “Aardvark Driving School”… hence the incentive to start a company name with the phrase “1st…”.

 

Advertisement

 

The Constraints and Incentives Of Yesterday Might Be Irrelevant Today

Today, I would guess that very few people search for a driving school using a paper telephone directory, so this necessity to preface a company name with ‘1st’ is no longer valid.  Not only this, it could actually hinder findability…. Imagine if you heard somebody say their company name was “First Reed”.  Would the URL be 1stReed.com, FirstReed.com, First-Reed.com, or something else?  What keyword would you type into Google to search for them?

I wonder if issues of ‘digital findability’ might also start to affect musicians. With more and more people using voice-activated assistants, bands might get more airplay if they have a band name and a song name that is “voice assistant friendly”.  Don’t believe me? Try to get an AI assistant to find music by 90s band Campag Velocet and you’ll likely see the problem.

The point here is that constraints and incentives of yesterday (“We must start our company name with ‘1st’” or “Unusual band names sell records!”) might actually be disadvantages today.  The incentives and constraints have changed, and those that recognize that can use it to their advantage.

 

What This Means For BAs: The Importance of Healthy Challenge

This is where good business analysis helps.  It often feels that there is a human tendency to revert-to-norm and to “do what we’ve always done”.  In our world as BAs, this might relate to the way work is undertaken, the way a process works, or the way that technology is used.

In these situations there is a huge opportunity to tactfully challenge: to ask does it still need to be that way? And also ask what are the implications if it is implemented that way? Are we ‘baking in’ a constraint that is no longer relevant?

This starts by identifying those tacit assumptions and constraints and seeing whether they are really still valid. Techniques such as ‘five whys’, the brown cow model, or just informally asking questions with curiosity and listening deeply to the response can help a great deal.

Whichever techniques we use, having the confidence to build rapport and tactfully challenge accepted practices is key. Sometimes there might be a valid reason for the status quo… but if there isn’t, we might be able to help co-create a better way with our stakeholders. And if we can create something better, cheaper, slicker, better… that has to be a good thing!

BATimes_Nov16_2022

Recruitment Metrics for BA Teams

Written by Christina Lovelock on . Posted in Articles.

Being involved in BA recruitment is a big responsibility. It’s hard to recruit right now, and it’s easy to blame the competitive market and skills shortage. It’s tempting to leave measurement and metrics to HR teams, but there are a number of key concepts all those involved in BA recruitment need to understand.

 

Time To Fill

From the point we become aware that a new or replacement BA role is needed, a clock starts ticking. Whether someone has handed in their notice, or a new project has emerged, we now have a gap that needs to be filled. It is so important to understand our average time to fill (TTF) for each role on the BA career path, as this aids decision making, including the use of short term resources such as consultants, contractors and secondments.

Typically more senior roles take longer to fill, because the talent pool is smaller and the demand greater. Having internal talent pipelines reduces the TTF and creates internal progression routes and clear BA career pathways. Ensuring these are in place improves knowledge retention, employee loyalty and morale and serves as an attraction factor for BAs outside the organization.

TTF includes internal processes of gaining agreement and approvals, getting a role posted and engaging with recruiters. This is often a hidden time over-head, and usually an area where organizations can speed up their recruitment.

 

Time To Hire

This marks the time between making a role available for applications and having someone in post. It includes the interview process and the notice period of the candidate.

Recruiting managers often put pressure on candidates to try to reduce their notice period. This is unfair, when it is the only period of time in the whole process which is outside of the recruiting organizations’ control. If we want people in faster, we should look to improve our own processes! Sometimes organizations exclude notice periods from their time to hire metric, to stay focused on the elements within their control.

Knowing the average time to hire helps us keep stakeholders informed, and contributes to better planning and onboarding.

 

Advertisement

 

Conversion

At each stage of our recruitment process people drop out or are ruled out. This can be visualized as a recruitment funnel. Understanding the conversion rates between different steps in the process allow us to answer question such as:

  • How many applications do we typically need to find one appointable BA? [conversion rate from application to accepted offer].
  • How many candidates accept our offer? [conversion rate from interview to accepted offer].
  • What can we do to improve our conversion rates? (Faster processes? Better marketing of roles? Better communication with applicants?…)

 

If we understand where in the process we are losing people, and really consider the candidate experience, we increase the chances of a successful recruitment outcome, and save both time and money. Different organizations have different levels of formality, and may include more or less interview rounds and steps in the process. However formal or informal, it is valuable to understand the key conversion rates.

 

Attrition/Turnover

This is the rate which we lose BAs from the team over a given period. Not all attrition is bad, we need to support people to move to new and appropriate roles, and we need to allow BAs with new ideas and different experiences to join the team. Generally an attrition rate of less than 10% is considered healthy for team stability and business continuity.

Retention is the opposite measurement to attrition. This is the percentage of the team that stay during a given period. Focusing on ‘increasing retention’ is a more positive framing of the issues than ‘reducing attrition’. Recruitment is expensive, the cost of replacing BAs is far more than the cost of investing in appropriate initiatives which retain talented BAs in the organization. By asking and listening to what individual team members want from their role and employer we can increase retention rates (money will be a key factor, but not the only one!).

 

Tenure

This means understanding how long people stay with us and can be considered  at different levels:

  • Average length of time in each role/grade within the BA structure
  • How long people stay within the BA team
  • Total amount of time spent within the organization.

 

This is helpful to understand the rates of progression within the team. If we have entry level/development roles within the team, how long before people typically progress to a practitioner role? It allows trends and patterns to be explored. If we find people either stay less than 1 year or more than 10 years, what insights can be gained? What does that tell us about our recruitment and retention processes?

With further analysis we can understand the push and pull factors which keep BAs within the team or encourage them to look elsewhere. It also allows us to consider what internal development routes we offer into related professional disciplines.

 

Conclusion

In this competitive market, with increased demand for business analysis skills and the ‘great resignation’ making people consider their options, BA teams need to fully understand our own processes and look for improvements. A greater focus is needed on recruitment and retention, and we can no longer rely on ‘recruiting as we always’ have to make great appointments and grow our teams.

 

Further reading
Are you Losing BAs? C Lovelock, February 2022
Job Crafting for BAs C Lovelock, July 2021
BATimes_NOV3_2022

The Tyranny Of “Default”: Be Careful When Choosing Analysis Techniques/Artifacts!

Written by Adrian Reed on . Posted in Articles.

At its essence, a lot of what we do as business analysts involves co-creating a shared understanding. Whether that’s a shared understanding of a problematic situation, or of a set of requirements or features, a common theme is that we work to understand different perspectives and ensure that people are ‘on the same page’.

This can cause some challenges when we want to communicate complex ideas. Text is a challenging media to convey complexity, and the English language is just brimming with words that have multiple meanings. For that reason, it’s very usual to use a combination of text, models and conversations to ensure that key stakeholders are aligned.

 

When we create a model, we are essentially codifying some information in a way that can be later referred to. Codifying typically involves using some form of notation (whether that’s a business process modeling notation, or the symbols of an alphabet when writing text), and there will usually be particular rules on what elements of the notation mean and how they should be used.  For example, particular shapes on a process model represent particular things, particular words in a textual paragraph have a particular meaning.

Yet when we encode our analysis in this way, how often do we reflect and think “will my stakeholders understand this?”.  Will the consumers of the information both know how to read it, and, ideally like referring to it as it’s a format that works for them?  Perhaps we don’t think about this quite as often as we could…

 

Advertisement

 

The Tyranny Of “Default”

I have a confession to make. I love Business Process Model & Notation (BPMN).  I could quite easily ‘geek out’ and create process models to an executable level, using just about every BPMN symbol and construct that is available to me.  But, as those of you who are familiar with BPMN will attest, if I did that the resulting diagram wouldn’t be very accessible to the average stakeholder.  It would be somewhat akin to me sending an email in French to someone who only speaks English.  It might be possible to pick out some elements of the communication and work out what is going on… but it’d be very difficult to draw conclusions.

This absolutely isn’t an argument against BPMN by the way—it’s stil one ofl my preferred notations—but it highlights the importance of thinking of the artifact’s audience and choosing an appropriate level.  With BPMN, I might create a ‘view’ of a process using a cut-down palette of symbols, and model at a much higher level, so it is more intuitive. Equally, I might choose to use ‘boxes, arrows, diamonds and lines’ instead where it is appropriate to do so…

The key point here is flexibility.  It is very easy to get stuck in a rut and choose a technique because it’s the default.  You probably have a favorite approach or technique, which might mean you tend to default to a particular type of artifact. Or perhaps your organization has templates or tools that ‘nudge’ you towards a particular style.  That can be useful, it can embed consistency… but it can also lead to things being articulated in a particular way “because that’s the way we do it here, and that’s the way that we’ve always done it”.  Neither of which, on their own, are particularly compelling reasons.

 

Light The Fuse: Ask “Why Are We Using User Stories”

If you like a bit of controversy, next time you are working on an agile project, ask “why do we use user stories here?”.  Usually, the response will be a blank face, followed by either “because we’re agile” or “well… the tool is set up for user stories… so….that’s what we do”.

But are these really valid responses?  There’s certainly nothing in the agile manifesto that decrees user stories are mandatory.  The term ‘user story’ isn’t in the Scrum guide at all. So why default to user stories?

Of course, user stories do have merit, particularly in agile. Yet the choice to use them should be a conscious one. In fact, user stories alone are probably not enough… they will probably need to be supplemented with regular collaboration, acceptance criteria and you might even decide to document some journeys or prototypes.  It’s likely that most successful teams already do this, but it is worth highlighting.   Some of this might emerge as you discover more about the requirements… but having at least an idea of what the requirements architecture will look like up front will save pain later (e.g. “We might use prototypes, so let’s agree that one prototype will span multiple user stories… we’ll capture the links here…).

So, this article certainly isn’t criticizing user stories. However, as with any profession, we need to regularly challenge ourselves and challenge our ‘defaults’.  It is worth remembering that we have a wide toolkit at our disposal. If a plumber approached your sink with a hammer and started smashing it (rather than figuring out the right tool for the context), you’d be somewhat annoyed. An explanation of “ah, I always use a hammer” is unlikely to help.  The same is true in our profession too… and it is worth remembering how broad our toolkit is. Which provides us with many possibilities!

BATimes_OCT13_2022

To BA or Not To BA: Why Every Team Needs Business Analysts

Written by Katie Cubitt on . Posted in Articles.

The importance of having a business analyst (BA) on your team can’t be overstated. Acting as the bridge between stakeholders and technical teams, the BA wears many different hats. On any given day, a BA can be expected to work on a number of different tasks, whether that’s defining business cases, validating solutions, or even working with data (See this article on the role of BAs in an increasingly data-driven landscape). Able to straddle both worlds and speak the language of businesspeople and techies alike, BAs really are one of the most versatile members of the team.

 

The Story of an Ask

Many businesses are concerned with their ideal state, while the nitty gritties of how to actually get there are very much back of mind. “Often, the client is not able to fully explain what business problem they wish to solve and how to translate their business requirement into language the technical teams can understand,” explains Lizande Botha, a BBD project manager for a major financial services client in Africa “which is why BAs are a vital part of the process”. Put simply, BAs are responsible for translating a business ask into detailed requirements that can be understood and actioned by technical teams.

But how do we get to this point, when the ask itself is unclear? “The first question I tell the BA to ask the client is: What is the problem we’re trying to solve?” explains Botha, adding that the cardinal role of the BA is to ensure that the client ask is clearly defined. “For clients who really are unsure of what it is they want, the BA needs to keep digging and asking questions to truly get to the core of the problem” she adds.

 

Advertisement

 

Once this key piece of information has been gathered, the BA can start drilling down into the different possible solutions, what the budget is for the project, and other confines or expectations the client might have. Understanding the requirements and clearly defining the scope of any given project from the get-go can be make or break – so much so that CIO magazine reports that up to 71% of failed software projects can be attributed to poor requirements. Thus, consulting with a BA at the start of a project can avoid potential stumbling blocks.

While this early engagement is vital, the job of the BA doesn’t start and end there. Leveraging rapport built with business stakeholders, they must check in regularly to provide progress updates, while ensuring that on the engineering side things are running on course and to the requirements of the client’s business. They’re even able to partake in platform or application testing. Truly, the BA’s impact is felt throughout the project lifecycle!

 

BBD’s Drive to Help and Resolve

BBD’s teams are all complemented with BAs who are well equipped with experience and a thorough understanding of the industry they’re operating in. As each industry offers complexities unique to its environment, BBD strives to best match their analysts to sectors where they can bring their experience and real-life learnings to the table, explains Botha. This is a high priority for BBD, a software solutions company which delivers software solutions for clients across the industry spectrum, from financial, education, public sector, gaming, and beyond. Assigning BA’s that already understand the nuances, jargon and processes of a particular industry enable us to expedite the solution process” says Botha

But beyond managing teams to ensure the best hands are on board, BBD is ready to tackle any problems their clients have. And when it comes to understanding what those problems are, BBD has BAs on call to bridge the client-engineer gap and ensure the success of all of their solutions.

Looking for a software partner to help you on your next ask? Get in touch with BBD.