Tag: Business Analysis

Maximizing Business Analysis with ITIL: A Strategic Integration for Success

Written by Suchita Panchal on January 25, 2024. Posted in Articles.

In the dynamic landscape of modern business, the role of a Business Analyst (BA) stands as a linchpin between technological advancements and strategic objectives. Within this realm, the integration of ITIL (Information Technology Infrastructure Library) principles has emerged as a pivotal force, reshaping the way BAs navigate and optimize business processes.

Understanding ITIL:

At its core, ITIL represents a comprehensive framework that encapsulates a set of best practices for IT service management. ITIL has evolved into a globally recognized framework, offering guidance on aligning IT services with the needs of the business. It comprises a collection of detailed practices, emphasizing service lifecycle management, continual improvement, and customer-centricity.

Enhancing Business Analysis with ITIL:

For Business Analysts, the incorporation of ITIL principles serves as a catalyst for profound change, fostering a more strategic and holistic approach to their responsibilities. Let’s explore how ITIL augments the role of a BA:

Structured Process Analysis: ITIL provides a structured framework for analyzing, designing, and improving processes. BAs leverage this methodology to gain a comprehensive understanding of IT service lifecycles, enabling them to streamline operations and enhance efficiency.
Facilitating Effective Communication: With a standardized language and terminology, ITIL bridges the communication gap between IT teams and business stakeholders. BAs proficient in ITIL can effectively convey complex technical concepts in a language that resonates with organizational objectives.
Informed Decision-Making: By embracing ITIL methodologies, BAs gain insights into service strategy, design, transition, and operation. This knowledge equips them to make informed decisions that align IT services with overarching business goals.
Continuous Improvement Culture: The core principle of continual service improvement in ITIL aligns seamlessly with the BA’s pursuit of optimizing business processes. BAs facilitate a culture of ongoing enhancement and adaptation, ensuring that IT services evolve in tandem with organizational needs.
Risk Mitigation and Adaptability with: ITIL equips BAs with the tools to anticipate and mitigate risks effectively. This proactive approach minimizes disruptions, ensuring business continuity in the face of technological or operational challenges.

Real-world Impact and Success Stories:

Numerous success stories attest to the transformative impact of integrating ITIL into the scope of Business Analysis. Organizations have witnessed improved service delivery, increased operational efficiency, and a more strategic alignment between IT initiatives and business objectives. BAs proficient in ITIL frameworks have played a pivotal role in orchestrating these successes, driving innovation, and fostering a collaborative environment that embraces change.

Challenges and Adoption:

While the benefits of ITIL integration are substantial, challenges in implementation persist. Resistance to change, organizational inertia, and the complexity of aligning ITIL methodologies with existing processes often pose hurdles. BAs navigating this landscape must demonstrate strong leadership, communication skills, and a keen understanding of organizational dynamics to facilitate successful integration.

Continuous Learning and Evolution:

In the ever-evolving realm of technology and business, the journey of a BA integrating ITIL principles is an ongoing process. Continuous learning, staying abreast of updated ITIL practices, and adapting to changing business landscapes are essential for sustainable success.

Conclusion:

ITIL isn’t merely a set of guidelines for IT management; it’s a strategic enabler for Business Analysts. Its integration empowers BAs to be strategic partners, driving organizational success by aligning IT initiatives with business objectives, fostering innovation, and enabling a culture of continual improvement. Embracing ITIL principles expands the horizons of Business Analysis, transforming it into a proactive and value-driven function crucial for the modern enterprise.

The synergy between ITIL and Business Analysis isn’t just a trend; it’s a strategic imperative for organizations seeking to thrive in an increasingly digital and competitive landscape.

An End and a Beginning: A Practical Application of Business Analysis Techniques

Written by Nosa Adagbasa on January 24, 2024. Posted in Articles.

Business analysis is not just an IT-related profession; it is a profession that has expression in every facet of life, and hence one of the reasons why you should take pride in this profession if you are a business analyst or why you should aspire to be one.

The tools and techniques are transferable skills that have applications or expressions in other aspects of life.

I briefly discuss two as the curtains close in 2023.

Lessons learnt
MoSCoW

Have you taken time to reflect on 2023 and list out the lessons learned? Making use of this powerful BA technique is one of the ways you can identify what went well in 2023, what didn’t go well, where you made mistakes, and what you can put in place to avoid those mistakes in 2024.

Note that this does not only apply to the current year or next year; rather, it is a set of business analysis techniques that can be applied to different seasons and phases of life.

Lessons learnt

What went well?

A1: Why did it go well?

B: What didn’t go well?

B1: Why did it not go well?

C: What mistakes did I make?

D: What can I do to rectify or avoid the mistake in the future?

E: What are my achievements?

F: What lessons have I learned?

2. MoSCoW

Based on your analysis above and the lessons learned, you can draw up your plan for the future (the next phase).

A: What must be done?

B: What should be done?

C: What COULD be done

D: What won’t be done

This can also be seen as a positive thing to do in the new year and a negative thing to avoid.

While new year resolutions may be difficult for some, using the above BA skills should help you plan your coming year with hopefully less pressure.

Concluding Remarks

As a phase comes to an end and you look forward to a new beginning, take time to consider these business analysis techniques, take time to reflect on the lessons learned, and plan the MoSCow for the future.

Best of BATimes: Approaches for Being a Lead BA

Written by Aly Cassam on January 17, 2024. 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.

Published on: 2022/01/27

Editing for Success: Applying Hollywood Wisdom to Projects

Written by Adrian Reed on January 10, 2024. Posted in Articles.

I’ve long been a believer that a good movie is 90 – 120 minutes long. Sure, there’s the occasional storyline that can keep my attention for longer than that, but generally speaking after a couple of hours I’m getting pretty restless. One of the reasons I rarely go to the movie theater these days is that films seem to be getting longer and longer, and unlike watching at home I can’t press ‘pause’ in the theater!

It turns out that I’m not alone. Celebrated film director Sir Ridley Scott, who directed films including Alien, Gladiator and Blade Runner recently spoke about the ‘bum ache’ (‘butt ache’) factor of films. Too long sitting down and apparently movie-goers will get uncomfortable, and this is something that he takes account of in his editing. A classic case of “less is more”, and a director being empathetic to his audience.

Less Is More

I know virtually nothing about movie production, but I’m guessing that it is probably technically easier to produce and distribute a long film than it was, say, 40 years ago. I gather that in the past films came on multiple spools, all of which had to be physically duplicated and distributed. Apparently since the early 2000s, films have been distributed digitally to theaters. With fewer constraints, you could have a ten hour film if you really wanted it.

Yet being unconstrained isn’t a good thing. I’m guessing few people are lining up to watch the ten hour film “Paint Drying” (which is a real film, but was a protest against the cost of censorship). The fact that it’s possible to do something because a constraint is removed doesn’t mean that it’s actually a good thing to do. Sometimes constraints can foster creativity.

From Hollywood To Projects: Time As A Constraint

I’m guessing that you probably don’t work on Hollywood movies, but there’s a direct parallel with projects here. After all, a Hollywood movie brings together a collection of specialists for a period of time to create a deliverable that will generate benefits for its sponsor… which sounds strongly analogous to a project!

One constraint that you and I probably come up against frequently is time. There never seems to be enough, and time is always the thing being squeezed. It is easy to become somewhat jaded to this, and either just accept the deadline (but implicitly know that it’ll never be met) or rally against it.

Certainly, calling out unrealistic deadlines is an important thing to do. Yet, in some circumstances an alternative approach is to test the constraint and see how it balances against others.

Let’s imagine that a sponsor has set a deadline of 1st January for the launch of a product or project deliverable. We feel there’s a risk that this is an arbitrary deadline, so we start to tactfully ask “if it was two weeks later, but 10% cheaper, would that be beneficial?”. If the sponsor says “Absolutely, yes!” then we know that they probably value the budget over a fixed deadline. Or we might ask “How about we delivered it on that date, but the quality was lower?”. They might answer “No! Absolutely not”, at which point we know quality is paramount. We might ask these types of questions about all sorts of things, including scope, timeframe, deliverables, style of delivery and so on.

What we’re doing here is understanding which are hard constraints that genuinely can’t change (or, there would be a significantly negative impact of breaching) and those that can potentially bend. Not achieving regulatory compliance by a mandated date, where the regulator is strict and there’s a significant fine, might be an example of a hard deadline. It’s better to pay more now, and dedicate more resources to ensure compliance. Other things which appear to be constraints might be more malleable.

Product Management and Business Analysis as Film Editing

Once the hard constraints are identified, it’s tempting to be deflated. Rarely are we dealing with a situation where there’s too much time, resources and budget. Yet another way of looking at this is to think about the movie theater experience… sometimes less is more. Much as an ambitious scriptwriter might have a scene cut because it’s not essential to the story (or the location is too expensive to hire), we can ‘edit’ elements of a project or product in or out.

This probably sounds obvious, I mean scoping and prioritization is crucial. Yet, too often scoping and prioritization are carried out somewhat in isolation. It’s easy to end up with an incoherent set of features, or (worse) to find that only the person who shouts the loudest gets what they want…

If we reframe this as a process of ‘editing’, then we are keeping in mind the coherence and desirability of the product as a whole. Imagine asking twenty people for their favorite ever scenes in movies. Perhaps one mentions a scene from Wargames, another from the Barbie movie, another from Love Actually and so on. Now imagine making a film out of these ‘best’ scenes… it wouldn’t make any sense. The same can be true of a product too. If the features aren’t coherent it can become somewhat of a Frankenstein’s monster that is difficult to use and doesn’t really serve any single purpose well.

Another thing about editing is that it involves compromises and making difficult decisions. I’d guess actors probably hate having their biggest scene cut. And script writers probably hate being told they can’t have that on-location scene in Barbados due to budgetary cuts. But, it is the editing that means that the film makes money (achieves its financial outcomes) while also providing an experience that the consumer wants (achieving another of its core purposes).

I suspect this is a balance that we all tread on our projects and products, and bringing it to the fore and making tradeoffs transparently and purposefully can only be a good thing!

Beyond the Finish Line: Understanding the Art of Value Enablement

Written by Adrian Reed on December 27, 2023. Posted in Articles.

We recently needed some repair work done to the roof of our house, so called some local roofing firms. Understandably, roofers don’t always answer their phones immediately (I guess they are often out on site working), so we left voicemails for three different roofers.

Out of the voicemails we left, only two of the roofers replied. Both came round, inspected the roof, and explained what needed to be done. They both said they had availability and would send over a quote showing how much the work would cost. However, only one of the roofers actually sent a quote. We accepted the quote and I’m pleased to say that the work is now complete. But this got me thinking about business, business analysis, and value-enablement more generally.

Close, But Stopped Short

Let’s examine the approaches that the different roofers took. The first one didn’t reply. We might argue that this is bad customer service, but if they knew they were busy and had no shortage of business, then not replying might be an acceptable thing to do. It might not be a good long-term approach, but it doesn’t waste any of my time or their time. So while I might have preferred them to drop over a quick reply, I can understand why they didn’t.

The roofer who I really don’t understand is the one who came out, inspected the roof, but didn’t follow up with an estimate. They were so close to actually getting the work, but they failed because they didn’t carry out the final task. They’d spent time (and gas) driving out to see the roof, only to implicitly ‘give up’ by not following up. I found this really puzzling!

When Is Value Enabled?

This led me to think about value in a broader context, and I think it has some interesting parallels with business analysis. The roofer did all the work to potentially enable some value for him (payment) and for me (a fixed roof), but stopped just before a crucial moment.

In a project or product context, usually we are building (or changing) something with the purpose of enabling value for a range of stakeholders. The value that is enabled may vary for each stakeholder group. A retail bank releasing an app might provide convenience for its customers, while also saving money (and increasing profit) for its shareholders. For the app to be a success, it needs to balance the different perspectives on value. If it’s inconvenient, or hard to use, it’ll backfire—it might actually increase the number of times people call the call center, meaning operational costs increase. Knowing what different groups value is important so that this balance can be struck.

Yet as well as knowing what value can be enabled, it’s important to know when that happens and what the precursors are. Imagine a bank released a self-service banking app but didn’t advertise it to its customers. Sure, some early adopters might find it in the app store, but there would be a range of people who would use it if they knew about it that probably aren’t actively looking for it. Delivering the app without a communications and engagement plan alongside might end up being similar to the roofer who didn’t send a quote… it stops just short of the line for value enablement.

Finding The Finish Line

It is worth fostering discussions over what needs to happen not just for a product or project to be delivered, but what needs to happen for value to be enabled. It is too easy to stop just short of the finish line and declare success prematurely. “On time” and “on budget” are important aspects, but “on strategy” and “on benefit” are things that make a long-term difference. In the fog of urgency, it’s important that we don’t lose sight of these.

As James Clear comments in his book Atomic Habits, there’s an old saying that “the last mile is the least crowded”. Perhaps that’s just as true in a project and product context, and by focusing on the last mile and cultivating conversations about value we can help achieve better results for our stakeholders and communities. And surely that’s worthwhile?