Tag: Planning

Do you realize that relationships are BAs bread and butter?

Written by Tom Henricksen on March 30, 2022. Posted in Articles.

Working as a developer for over twenty years I have noticed developers lack social skills. Now I know you are shocked! You probably spilled your coffee when you read that.

As a Business Analyst, you may take your social skill prowess for granted. As Epictetus said, “It is impossible for a man to learn what he thinks he already knows.” Let us revisit those skills now.

Re-Focus on Relationships

It can be helpful to review these skills periodically. We can fall into the trap of complacency. Use a few basic questions to evaluate your progress.

Who are my most important business relationships?
How am I investing in these relationships?
What value am I bringing to this relationship?

Similar to the agile retrospective we can have a relationship retrospective. Check-in with your most important people. See how things are.

Occasionally things can seem fine at the surface. Of course, when we dig in we find something different. Perhaps the relationship can be strained. The person may feel you are taking advantage of them.

Overlooked

My mother would often dispense wisdom when I was growing up. She was a teacher for many years. She shared this one once, “Secretaries make things happen.”

As a kid, many people would overlook the school secretary. Using my mother’s advice I made sure to stay on the good side of Mary.

Mary was our high school secretary. She could put in a good word for you in case you got in any trouble. That may have happened to me a few times. Mary was a life-saver!

Are there any professional relationships you are overlooking? Perhaps you need to patch things up with some of the testers. Team harmony is vittle to a smooth project.

Have a plan

A few years ago I was fortunate to work with a transformational leader. He led a technology team. John was his name. He saw the potential to change the way his team worked.

John brought me into his office. He said to me, “Tom technology people can be a bit transactional. They get asked to fix a problem and they do. Similar to the way a bank teller gets a check and deposits the check.”

“Yes, I see that, but how is that an issue?” I said to John.

“Bruce just visited our biggest center. He upgraded the two servers and got on the plane to go back home. A day later the community director called me and asked why he didn’t complete the upcoming maintenance patching. Bruce never spoke to him.”

“Tom I want my team to be more like financial planners. A financial planner builds relationships. Then they can anticipate needs. I want you to help change my team to think like financial planners.”

John then shared with me a plan on how we could transform his team. He outlined how each time his team members traveled they would talk to the community directors.

This would help them build relationships instead of just fixing the problem. John wanted his team to build in time to connect. Have a plan for relationships.

In summary, as Business Analysts we should not overlook the fundamental aspect of relationships. Don’t leave them to chance, have a plan. Keep them in focus as they are your bread and butter!

Tom Henricksen is a Technical Professional and Human Skill Enabler and you can contact him on LinkedIn at https://www.linkedin.com/in/tomhenricksen/

The Delicate Balance

Written by Liina Pruulmann on March 1, 2022. Posted in Articles.

As a new analyst in the User Account Management team in Playtech I often find myself making a challenging choice. On the one hand there is the option to build a new feature, create a new configuration, etc. On the other hand, there is the option to create a new automated rule and custom tags to simulate the same outcome. The dilemma of dev vs no dev. And it is often not a clear-cut case.

As fellow analysts or product owners know, a proper feature for a set of use cases is… neat and tidy. It is easy to refer to when answering questions from users. It can be reused. It can be further developed. It feels like something got done.

The challenging alternative is to choose an already existing powerful tool (for example Automation Service Engine) that can be used to create business rules based on defined parameters. This is awesome! No more dev for us. We have created a tool that replaces custom dev. But wait, we need to do some small tweaks to this tool before it becomes capable of achieving the desired outcome.

After having done some soul searching on this eternal dilemma, I have found it comes down to these 5 considerations:

Backwards Compatibility

We have 118 operators with a total of 385 brands. When adding new configuration options, we need to be extra careful to make sure that current setups do not suffer. Often this means we need to come up with a default value that would maintain the status quo in addition to the new value that would enable the new behavior. Boy have I ever felt the caricature of “repairing an airplane mid-flight” to hold truer.

Let’s take Self-Exclusion for example. It is already quite complex and at the same time business-critical. If we make a minor change and this feature then starts acting even in a slightly different way, we’ll potentially have several major regulatory breaches that can end up in large fines or even lost operating licenses for whole countries.

Futureproofing

If we invest time here now, will it be reusable for future cases? Will there be similar requests in the future? In what ways do we need to design flexibility into the feature? This comes down to the infamous “gut feeling”. I have a gut feeling that in the future we will see a lot more focus on active intervention in regulations. Licensees would have to actively monitor their player base to determine at-risk players and proactively suggest different self-governed limits or indeed apply limits without consent (but still with a duty to inform). This would mean a well-rounded interface that would incorporate communication features, at risk player discovery (using machine intelligence), flagging said players, and responsible gaming features well at hand. This would be a considerable interdisciplinary effort. Would it be worth the investment?

Maintainability

We are the guardians of the system. We should know the best ways to solve business and regulatory requirements by using either existing features or creating new ones where appropriate. The more ad hoc solutions we offer, the more cumbersome it becomes to maintain. The limitations of the human memory in combination with the problems of organizational memory mean we would soon have no overview how different configurations are achieved or know how the system behaves when using combinations of said ad hoc solutions that are not specifically designed to work together. I would argue that if there is a combination that is only meant to work together and excludes all other options, then this can effectively be considered a new separate feature. The goal is to have fewer dependencies and fewer configuration options within one feature.

Fast Release Cycle

Every party involved in software product development wants to have a solution that requires the least amount of work possible. Our time is extremely valuable, and the cost of missing opportunities is even higher.

The time constraints also come into play regarding go-live dates, certification deadlines and so on. If there is a faster option for developing a new feature that must be adopted by all parties down the line… often the best solution is to go ahead with the workaround. Sometimes the workaround becomes permanent, sometimes we get to phase two.

Adaptability

I am picturing the IMS setups of existing licensees as brides on their wedding day. It took months of preparation and multi-party negotiations to get every detail right (and somehow still over budget?) If possible, no-one must touch the setup that works. Do not fix what is not broken, right? Mostly people are just too afraid to upset the bride.

But it is also our hope that when we create a cool new feature that would benefit existing licensees, they may become interested in improving their business processes, security, or customer experience. Indeed, they are paying for a continuously developing platform so they can benefit from new features, and we are actively promoting them.

These features need to be extremely easy and fool-proof to adopt. If a client gets burned once they will be even more hesitant to change their working setup the next time.

No Clear Answer

Usually, you can get some sort of an answer to almost any problem by creating the famous Pros and Cons table. The problem is – I cannot draw a table (I tried) with all these considerations and two columns – one to tick if in favor of dev and other for no dev. It is not a binary choice, but more like a scale. Sometimes the scale is only slightly in favor of one or the other in each aspect, sometimes more decidedly so.

Finally, I would like to give you some insight into how I adapted to this situation – maybe fellow analysts will recognize the steps below:

A new-to-me, established, fully functional, super customizable system. There cannot be a problem too big that cannot be solved with a few simple tweaks.
Uh-oh. Tweaks are not enough. New features are the order of the day! Everything should be solved with new features.
Wait… could we add a small checkbox here in this feature to create a configuration option?
Too many configurations! Who on earth can keep track of them all?
Aha! A rule engine… and tags! Let’s see how many problems could be solved just by using them?
Write an article
Continue to learn and develop.

Approaches for Being a Lead BA

Written by Aly Cassam on January 27, 2022. Posted in Articles.

You’ve worked your way up the BA ladder – started as a Junior BA, then a BA, then a Sr. BA, and now you’re a Lead BA on a project working with other BAs. What do you do? This article focuses on some of the Do’s and Don’ts of being a Lead BA. Some of it is science and some of it is art.

Requirements Governance:

1. Who do you take direction from your PM or your BA Manager:

The first place to start as a Lead BA is establishing your own personal Requirements Governance. Who do you provide status updates to and who do you take direction on requirements from – PM or your BA Manager? The scenarios I’ve encountered are:

You as the Lead BA take your BA requirements direction from the PM and provide status updates to your BA Manager.
You as the Lead BA take your BA requirements directly from your BA Manager and provide status updates to your PM.
The third and most often scenario is where both the PM and your BA Manager are of the opinion that you take requirements direction from them and provide status updates to the other.

Tip: Right at the beginning of the project start the conversation with your BA Manager and clearly establish the relationship you’ll have with him or her and with the PM (in my experience coaching BAs too many Lead BAs don’t have the conversation upfront and then find themselves in a bind when scenario C) above becomes an issue during the project itself). If the answer is taking your requirements direction from them, set up a short meeting with your BA Manager and the PM to establish this relationship as PMs generally don’t like that arrangement, and it’s best to get them to discuss it face to face. If the answer is taking your requirements direction from the PM, then simply follow-up the meeting with a confirmation email to your BA Manager and just let your PM know that you’re effectively going to report to them and take, where appropriate, BA approach direction from them.

2. Establish your role as Lead BA on the BA team:

Make sure it’s clear to the BAs you’ll be leading that you are the Lead BA, and they will work with you in that capacity. A couple of ways to communicate this:

Ensure you’re called out on the project governance as the Lead BA and ensure the BAs you’ll be leading review the project governance
Where you’re taking your Requirements direction from your BA Manager have them send out an email to the BAs you’ll be leading that you’re the lead and that you’ll be guiding the approach etc. to the Requirements deliverables

3. Start by learning about your BAs:

At the beginning you’ll need to establish how experienced the BAs are with eliciting, documenting, and analyzing requirements, how familiar they are with the project subject matter, etc./ by scheduling quick little chats with the BAs you’ll be working with

If you’re dealing with Sr. BAs with lots of experience, then your focus with them will be on making sure things are going smoothly and that they working to the timelines for their requirements work packages; You can give them fairly large and complex requirements work packages
If you’re dealing with more Jr. BAs then you will be in a more guidance/ mentoring mode – periodically reviewing their requirements and providing feedback, mentoring on approach to different types of requirements such as documenting process flows and business rules, etc.; Initially limiting the scope of their work packages to small well-defined pieces of requirements; have little chats with them about how things are going

4. Develop a view of the requirements work packages:

Typically, a group of BAs is assigned to a project because the project is complex and there are multiple “groups/ categories” of requirements that need to be created to deliver the scope of the project. At the outset understand the drivers and objectives of the project and establish a view of the requirements work packages. Some examples of this are:

a. Achieving compliance with regulations or another compliance-related purpose:

1. You may need to look at work packages focused on complying with different sections of the regulations
2. If the compliance covers multiple departments or Lines of Business (LOB) you may need to focus on requirements for each department/ LOB to comply with the regulations

b. Developing and implementing a large technology system or platform:

1. 1. You may need to look at requirements work packages focused around different groups of users with the system – for example if it’s a workflow system you likely have work packages for customer-facing components, back-office-facing components, etc.
  2. You may need to look at requirements work packages focused on different functional features. For example, a customer-facing platform for a direct investing platform may consist of trading-related features, viewing account holdings, researching different securities, etc.

5. Managing the requirements work packages:

a. Establish a view of the project timelines with respect to the requirements work packages based on their complexity etc. I prefer a matrix like this to do so (using the direct investing platform as an example) based on the requirements lifecycle – plan, elicit, analyze, document, get sign-off (note do this in Excel or Project to track progress, etc.)

	Plan	Elicit	Analyze	Document	Sign-Off
Trading requirements	01/01/22 to 10/01/22	10/01/22 to 25/01/22	25/01/22 to 02/02/22	02/02/22 to 16/02/22	16/02/22 to 28/02/22
Security Research requirements	01/01/22 to 10/01/22	10/01/22 to 25/01/22	25/01/22 to 02/02/22	02/02/22 to 16/02/22	16/02/22 to 28/02/22
View account holdings requirements	01/01/22 to 10/01/22	10/01/22 to 25/01/22	25/01/22 to 02/02/22	02/02/22 to 16/02/22	16/02/22 to 28/02/22

b. Based on what you learned about the BAs you’re leading assign them to different work packages – and monitor their progress on their work packages against the. I’ve found the best way to keep track of this is using a matrix like this that I update on a weekly basis:

Legend:

P – Plan, E- Elicit, A- Analyze, D- Document, S- Signoff

	BA1	BA2	BA3
Trading requirements	P – Jan. 1/22
Security Research requirements		P – Jan. 1/22
View account holdings requirements			P – Jan. 1/22

With these 2 matrices, you can keep track of who’s doing what and how they are doing against the target dates so you can provide status reports to the project team as required.

6. Monitoring progress and connecting the BAs as a team:

The most effective approach that I’ve found to monitor the progress of my BAs is to hold weekly meetings – with a twist. Most people just do a status check-in during their weekly meetings – how are you progressing against your timelines. I believe that weekly meetings are a good chance for the BAs to inform and help one another. I encourage them to talk about challenges they are having – someone else in the team may have encountered this and have a solution/ approach to tackling it. I encourage them to talk about effective approaches that they’ve found to doing things that may be helpful to other members of the team. Finally, I ask each BA to give a brief overview of the requirements they are working on. As most projects with a BA team have a common goal – by talking about requirements it will quite often identify synergies or conflicts between requirements/ work packages that will help move the project forward more efficiently.

Conclusion:

Hopefully, these approaches will help you become a more effective BA Lead. There are lots more approaches and in future articles, I may expand on them.

Practicing Practical Optimism

Written by Christina Lovelock on January 12, 2022. Posted in Articles.

What we believe is pragmatism can be perceived as pessimism. Is it time for BAs to start practicing practical optimism instead?

The Problem With Pragmatism

There are many words that BAs hold dear – objective, holistic, pragmatic. They guide our approach. We want to consider all factors and all perspectives, avoid bias and ensure appropriate action is taken in light of all relevant information. Pragmatism should mean planning for the worst, but hoping for the best. We are skilled at identifying the worst-case scenario, highlighting gaps and risks, and getting to root causes; have we become so focused on being ready for the worst outcome, that we have forgotten to hope for the best outcome? Has our pragmatism turned to pessimism?

We really do want to move forward, learn lessons, and avoid re-making past mistakes. It can feel like a way to achieve that is to focus on everything that has gone wrong previously. This past-focussed pragmatism nudges us closer to negativity.

The Problem With Optimism

Many BAs see optimism as naivety. We believe that if people really understood the issues (as we do) then they wouldn’t be quite so positive! We think that the role of analysis is to surface and clarify needs, issues, and problems, and it’s very hard to talk about these topics in a positive way. We also know that over-optimism in planning and delivery causes many projects and products to fail.

Optimism has become synonymous with unrealistic and uniformed.

The Benefits Of Optimism

There are wide-ranging benefits, observed in comprehensive research from all around the globe.

Optimists are healthy and live longer. They are more likely to achieve their goals. They are more resilient and less stressed. They are more productive and have better relationships. Optimism increases the likelihood of success.

The good news is optimism is a skill and mindset we can all practice and improve at, whatever we consider our ‘natural’ disposition.

Practical Optimism

Optimism does not mean naively hoping for the best, denying reality or failing to prepare. The phrase “practical optimism” acknowledges the unspoken accusation of “blind optimism” and provides a path to taking sensible steps towards the best possible outcome. Genuinely understanding the best-case scenario and always keeping it in mind makes that outcome much more likely to occur!

Risk identification and problem-solving seem to get much more airtime than benefits and drivers. Reminding ourselves of why we are doing something, who benefits and how is a great motivator. Reflecting on how far we have come, highlighting successes, and celebrating milestones all contribute to future-focused thinking. This creates the right climate for practical optimism to thrive.

Conclusion

Pragmatism seems like the perfect balance between uninformed optimism and immobilizing pessimism. In reality what feels like pragmatism can easily look like pessimism. Striving for an approach of practical optimism rather than pragmatism can lighten our mental load, improve our relationships and lead to better personal and business outcomes.

Being realistic can be about striving for the best possible reality. It’s time for business analysis to look on the bright side.

Further Reading:

[1] When BAs Go Bad, C Lovelock, BA Times, 2019 https://www.batimes.com/articles/when-bas-go-bad/

[2] How To Incorporate Realistic Optimism Into Your Life, Forbes, 2021 https://www.forbes.com/sites/forbescoachescouncil/2021/01/07/how-to-incorporate-realistic-optimism-into-your-life/?sh=465ae45476f0

Business Analysis as A Service

Written by Business Analysis (BAPL) on October 6, 2021. Posted in Articles.

One billion dollars wasted, 100 million over budget, a 40-million-dollar initiative costing $250 million dollars! Recent announcements in the press regarding significant initiatives, projects & product overspend and minimal value, are testament to this. Successful initiatives are key to organisational success, and an effective requirements process is the key to successful initiatives. This is costing organisations millions of dollars in wasted expenditure, and many more millions in lost opportunity. If your Customer Journeys, Epics & User Stories are not correct and aligned, then your initiative is certain to fail.

A service is a means of delivering value to customers, by facilitating the outcomes customers need. Effective services start with the understanding of that need, and work towards providing the best possible outcome(s) within the customer environment. Business Analysis is a service like all others and considering it as such is important for that services success.

However, business analysis is a broad service offering that can cover anything to do with innovation, people, process, and technology. In addition, the customers of Business Analysis also vary including Product Managers & Owners, Developers, Testers, Solution Architects, all the way through to CIOs, CEO, and Company Directors.

What is Business Analysis as a Service?

Why not have your business analysis serviced like you do your car?

When your car needs a service, you book it in, arrive, hand over the keys, return later that day, pay and drive home. You trusted the dealership to do what you paid them to do, service the car.

You never asked for a specific mechanic, you never asked for a subject matter expert, all you wanted was for the service to be completed, the logbook to be signed and to have a checklist of the agreed work that was performed. No hassle, all done.

The way you and your internal customers (Product Owners, Project Managers, Development Leads etc) receive business analysis should be no different. You should have the confidence and expectation that you will receive the right outcomes to drive the initiative in the right direction.

When your business needs analysis, you book it in with us, you return later, pay, and receive the agreed outcomes. You can trust BAPL to do what you paid us to do.

You never need to ask for a specific consultant, we engage with your SME’s, you never need to ask for special requests as we scope and identify the requirements to the appropriate levels, highlight any risks or assumptions and deliver the agreed outcomes, bringing value for money, in shorter timeframes resulting in improved initiatives. No hassle, all done. It’s called Business Analysis as a Service, and our service is second to none.

In a Business Analysis as a Service model, we work in collaboration with you and your internal customers to establish the required services needed to deliver the analysis for the organisation’s improvements to their products and services. We would understand the need, define an appropriate approach, set timelines etc.

This provides an opportunity to identify the competencies and capabilities required to fulfill this need. The assigned BAs would work develop an approach and delivery plan, provide consistent reporting to ensure the agreed upon outcomes are being delivered, and to manage any issues that may be putting these outcomes at risk.

This model puts the accountability of business analysis outcomes back to the BA Team and BA Manager, rather than on the shoulders of the individual or the team they are working in. In doing so, it provides the BA Team Manager the ability to forward plan resourcing, forward plan capability uplifts, and assign the right person to the deliver the right service. This results in the right service, delivered in the right time, with the right analysis, resulting in better outcomes for your organisation.

This model works in both small and large team environments, agile and waterfall.