Skip to main content

Tag: Methodologies

Connecting the Dots: The Crucial Role of Synthesis

A few years ago, I was working in a fast-paced environment where we very quickly needed to achieve a shared understanding of a particular problem that existed, and then elicit and analyze requirements for improving things.

 

I’d spent a couple of days speaking to some of the key people, largely in back-to-back meetings, and I was working really late in the office, energized by the conversations I’d been having. I’d managed to find an empty meeting room where I could spread my notes over a large table to think things through. Over the past couple of days I’d had countless conversations, been given documents to read, been shown IT systems, processes and more… It was a lot to take in! Plus of course not everyone necessarily agreed on the nature of the problem, or even what a desirable solution would look like. So my thoughts went to “what next… how do I arrange and make sense of all of this ‘stuff’?”

Luckily, the meeting room had a whiteboard. I instinctively started drawing the ‘problem’ that had been described to me. I drew people, IT systems, data and information flow, customer interactions, bottlenecks, problems.  It was a messy drawing that wasn’t intended for anyone but me.  If you’re familiar with the idea of a rich picture, it was very much like that. Crucially, it helped me make connections between pieces of information that different stakeholders had told me. This act of synthesis—bringing things together—helped gain a more holistic picture of what was going on.

I was midway through pondering whether two concepts were related to each other, when a very senior stakeholder walked through the door. He asked what I was drawing, and I talked him through my messy diagram. He started instinctively adding things to it, not only adding his perspective to the mix but also highlighting things I’d missed (or misunderstood). Even though this happened years ago, I can still remember parts of the diagram now….

 

Analysis Needs Synthesis

Of course, that drawing on a whiteboard was really just an interim work product. It wasn’t a deliverable, and although I recorded it by taking a photo, it wasn’t ever intended to form part of any user stories or requirements documentation. It was really just an exploration of the problem domain and the connections within it. It helped me to get my own head around the situation, so that I could ask better questions and know which areas to examine further. It also helped me to understand which areas and perspectives I was missing.

This highlights the importance of synthesis as well as analysis. Synthesis is described by the Merriam-Webster online dictionary as:

“…the composition or combination of parts or elements so as to form a whole…”

 

There are of course other definitions too, but this sentence is particularly useful for us as BAs. It’s very easy to think that our job is elicitation and analysis, capturing different viewpoints and pieces of information about a situation.  Yet without synthesis, those different pieces of information are of limited use! There will likely be contradiction, conflict, different views and more.  We all instinctively know this, but it is worth highlighting how important synthesis is in what we do.

 

Advertisement

 

Synthesis Techniques

Ironically, many of the techniques that we use on a day-to-day basis have synthesis, as well as analysis, built at their core.  I have already mentioned a rich picture, but many other techniques (when used with synthesis in mind) can help in bringing together different pieces of information and viewpoints.  Here are just a few examples:

  • Concept model and glossary: Bringing together (and reconciling) different terms, and the connections between terms
  • Process model: Creating a view on how the work should take place, taking into account a number of stakeholder’s viewpoints
  • Prototype: Bringing together and testing assumptions made, or a set of requirements assembled from varying stakeholders,.
  • Multiple Cause Diagram: After conducting ‘5 whys’ with different stakeholders, creating a combined diagram and presenting it back and saying “what else?” and “what’s wrong here?”
  • Workshops: Bringing people together to synthesis and discuss their views
  • … and many more besides

 

The Importance and Relevance

To do our jobs well as BAs, we need to consider synthesis as well as analysis, and this means making time for it. In my opening example, I mentioned I was working late in the office, drawing on a whiteboard. I was working late that night mainly because I was energized and excited about the project but also because time was so short and I’d focussed on planning the elicitation but less so the synthesis of the information I’d gleaned.

When you’ve conducted a whole number of interviews, read documents, seen processes and systems as they are operated, there are so many sources of information. It’s easy to just jump on to the next elicitation activity, or jump straight to writing a problem statement (or user story) or whatever. Yet, doing so robs us of the opportunity to see the bigger picture.

Building in time for synthesis—the sort that allows us to see connections—will help ensure we don’t implement a change in one area that inadvertently makes things much worse elsewhere. Of course, time is always tight… but if we don’t make time for synthesis, we might end up having to make time for rework. And that’s definitely best avoided!

 

Prints, Processes, and Pitfalls: More Than Just Process Design!

I was recently planning the logistics of an upcoming client workshop. I needed 12 copies of a document printed and spiral bound, and I visited the website of a printing company that we’ve used many times before for such tasks. The website had changed, and unfortunately I couldn’t complete the order.  For some reason the website was saying it couldn’t deliver to my address.

 

I’m pretty sure I know why this is.  I live in Portsmouth, on the South Coast of the UK, and to the uninitiated, some Portsmouth postal codes look similar to postal codes used on the Isle of Wight. I suspect some courier firms don’t deliver to the Isle of Wight (or charge extra as it’s an island with no roads connecting it to the mainland). This leads to some online sites (incorrectly) lumping some or all of the post codes together and tag them as an ‘exception’.  This is really, really, bad design, but it definitely happens.

I was trying to place the order on a weekend, so I waited until Monday and went to contact the company by phone. I tried to phone shortly after 9, and then again at 9.30, and then again at 9.45. No reply.  So, even though I’d used this company many times in the past, I just moved on to another supplier. And in fact, I’ll probably use this new supplier in the future, too. So the original printing supplier has lost a customer and it doesn’t even know that. Plus, it missed the opportunity to get feedback about the defect on their website… I wonder how many other cities/postal codes are affected? How many other sales are being routinely lost?

 

Considering The Customer’s Pivotal Moments In Process Design

As a business analyst, this experience made me think about process and operational design. While the example above was an example of bad design, it is impossible to design an IT system, interface or process that truly caters for every situation, nor (in most situations) would you usually want to. Sure, some call centers might have a process which defines the detailed steps to take if the President of the United States calls from a satellite phone while onboard Air Force One and asks for a message to be passed urgently to the CEO… but not many!

The point here is that there will be certain types of situations that are:

 

  • Predictable, but very unlikely and/or uniquely complicated
  • Difficult (or impossible) to predict, with unknown levels of likelihood or complexity
  • Unintended, where with the best will in the world (and lots of testing) still something unexpected has happened which has led to an unintended consequence

 

The first set (predictable) are deliberately not fully catered for by a process as they are either so unlikely that spending time specifying them is overkill, or they are so uniquely complicated that anything beyond broad guidelines can’t be issued. I’d imagine that large companies have a “respond to media request” process which ensures that any inquiry from a TV station or newspaper gets to the right person. The broad process will be structured, and the response will likely be logged in a consistent way. However, how the response is formulated is probably somewhat variable, and more likely subject to guidelines and principles than a strict process. Responding to a request for a photo of the CEO to accompany a “top 10 CEOs” article is likely to be somewhat different to responding to notification that a documentary will be airing showing evidence of corruption within the company!

 

The second set of (difficult or impossible to predict) conditions can’t be catered for as they are unknown, or the effort of trying to predict them is so great that it is prohibitive.  The final set (unintended consequences) are, by their nature, unpredicted! The key here is to find them when they occur and rectify not just the individual case, but the root causes. Taking my printing example, had I got through to the first printing company, I suspect they’d have quoted me via phone and manually processed the order. Great—except the website is still faulty and swathes of other customers might be affected. Understanding what needs to change to prevent the issue happening again is key.

 

So, what aspects can be considered when designing customer journeys, IT systems and/or processes to cater for these types of situations?

 

Advertisement

 

Flexibility, Feedback and Responsiveness are Key Factors

Assuming an organization wants to handle these types of cases, it’s key to design processes with feedback mechanisms built in. Feedback should of course include opportunities for customer or user feedback, but it can also include feedback generated by the process itself.

Take the printing company example I mentioned earlier. As a nationwide printing firm, they are almost certainly finding that there’s been a minor drop in Sales (Portsmouth is a relatively big city, but probably not big enough that the drop in printing sales would ring any warning bells) and the distribution of where they are sending parcels has changed. A curious analyst diving into the data might say “hmmm, it’s odd, there are entire cities where we are no longer sending parcels… maybe we should look into that”.  Making sure diagnostic data is captured and examined is important, and this is so much more than just performance data.

It’s also important to ensure there’s a viable support option and, yes, this does usually mean ensuring someone can speak to (or communicate somehow with) a human being when they need to! That support person or team needs to have sufficient autonomy and be empowered to raise issues for investigation. A team that just “raises tickets” and passes them on to others is unlikely to cut it.

 

Finally, it’s important to note that processes will need to change and this should be expected. Building in responsiveness to the environment is important. Expectations will change, the way people communicate will change and so forth. By designing processes with this in mind, and ensuring they are owned, reviewed and adapted when needed, is a small but important step towards agility.  As BAs, we can often nudge towards this way of thinking, and every step in the right direction is a good thing!

 

 

Crafting a Compelling Business Case: A Practical Guide for Business Analysts

Developing a business case is akin to telling a compelling story—one that captivates your audience and persuades them to invest time, resources, and support in your idea. As a Business Analyst, mastering the art of creating a persuasive business case prior to crunching the numbers and making the pitch is essential for driving successful projects within your organization. Here are eight major points that will help you navigate the intricate landscape of business case development (i.e. “make the case”).

 

  • Basics of Making a Business Case

Let’s kick things off with the foundational principles of constructing a business case. Regardless of the nature of your proposal or the industry you’re in, the process remains surprisingly consistent.

First and foremost, abandon the idea of diving into logical arguments or grappling with intricate numbers right away. Instead, envision yourself as a storyteller, beginning with the identification of a problem or opportunity. Ask yourself: What business need are you trying to address? Once you’ve pinpointed this, it’s time to introduce the characters in your story—stakeholders, beneficiaries, and subject-matter experts.

Stakeholders, often high-ranking decision-makers, hold the power to greenlight or reject your business case. Beneficiaries are those who stand to gain from your proposal, while subject-matter experts provide insights into problem-solving. Collaborate with these individuals to explore various alternatives, considering efficiency, cost-effectiveness, and alignment with your organization’s culture.

Having chosen the best option, create a high-level project plan to estimate the time and resources required. Finally, clearly articulate the value your solution brings, setting the stage for the subsequent number-crunching phase, including ROI, break-even points, payback periods, net present value, and internal rate of return.

 

  • Learn How Your Organization Evaluates Business Cases

Understanding how your organization reviews and approves projects is crucial for tailoring your business case effectively. Answer questions such as: Does your company have a formal evaluation process? Is it connected to other processes, and how detailed do stakeholders want the information?

Leverage the knowledge of a colleague familiar with the evaluation process. In large companies, formal templates and specific review times may exist, often tied to annual budgeting. Some organizations use a “tollgate” process, where approval is sought for project phases, allowing gradual commitment of resources.

Smaller organizations follow a similar pattern, albeit with less structure. Identify decision-makers’ authority levels, and if your organization lacks a defined process, seek insights from successful colleagues who navigated similar challenges.

 

 

  • Know Who’s Calling the Shots

Understanding who holds the fate of your project is paramount. Whether it’s an individual or a small committee, knowing your audience allows you to tailor your case to their priorities. Your boss might have insights into the decision-makers, whether it’s the CFO, division head, or a committee representing various organizational facets.

Identify the dominant department, as their goals often carry significant weight in decision-making. Find a champion within that department or committee who can advocate for your proposal. Remember, the goal isn’t just approval but informed decision-making, even if it means rejection.

Once you know the decision-makers, understand their priorities. Senior leaders look for projects aligning with the company’s strategy, emphasizing the importance of ensuring your case dovetails with broader objectives.

 

  • Understand the Audience’s Objectives

Aligning your business case with your company’s objectives is pivotal. Begin by identifying these objectives through sources like annual reports, CEO letters, and all-staff communications. Grasp the overarching themes—whether it’s growth, cost-cutting, global expansion, or regional focus.

Those evaluating your case are likely responsible for meeting these objectives. Clearly demonstrate how your proposal contributes directly to these goals. Understand the priorities, values, and decision-making styles of stakeholders by engaging with experts from various functions and consulting your boss.

Remember, stakeholders may not always agree on how to achieve company goals, emphasizing the need to involve experts from diverse functions when building your business case.

 

  • Clarify the Need

Before delving into team-building and solution brainstorming, the business need must be crystal clear. Referred to as the “pain point,” it’s the urgent problem or opportunity driving your proposal. It could be a sales force losing bids, service desk requests falling short, or an opportunity for substantial cost savings.

Document the pain point(s) thoroughly, noting the origin, impact, and the solution’s objectives. This documentation serves as the basis for your recommendations, making it easier to present a compelling case to stakeholders later on.

Whether you identify the need yourself or stakeholders present it to you, rigorous research is essential. Document everything, keeping notes on paper or digital files to refer back to when faced with conflicting or partial information.

 

Advertisement

 

  • Build a Cross-Functional Team

Developing a business case is not a solitary endeavor. Relying solely on your perspective risks overlooking crucial aspects. Instead, assemble a cross-functional team comprising individuals from various departments and perspectives.

While you may not have a dedicated team, bring together individuals at different points in the process. Include a finance representative to provide a big-picture view of costs and benefits. Engage beneficiaries to voice their concerns and ensure a holistic problem-solving approach. If the project impacts customers, involve customer-facing representatives like account managers or customer service representatives.

External experts can offer valuable insights, whether sourced from your network, online communities, or vendors. The key is to form a tight team of experts focused on the specific case, respecting the organizational chain of command and securing support from reporting managers.

 

  • Consider Alternatives

The brainstorming phase is where your cross-functional team shines. Encourage the exploration of potential solutions, using problem statements as a starting point. Look beyond individual departments, considering how other organizations or departments might have addressed similar needs.

Emphasize that these sessions are working sessions—opportunities to generate options without delving into detailed project plans or specific vendors. Facilitate creative thinking while reminding the team of limitations and constraints. The goal is to consider all viable options before narrowing down to 2-3 choices.

Thought-provoking questions guide this process. Which option costs the least? Is it the fastest to implement? Does it have the fewest risks or bring in the most revenue? Present each option with at least one significant advantage and be ready to share rejected options and the reasons behind their dismissal.

 

Think Through the High-Level “How”

Paint a vivid picture of how your proposed solution will be implemented within the organization. While not a detailed project plan, this outline provides a realistic basis for estimating costs and benefits. Consider what tasks need to be done before, during, and after the project switch.

Engage subject matter experts and stakeholders in this process. Anticipate potential roadblocks and resource requirements, securing buy-in from involved departments. Validate your proposed solution with your cross-functional team, ensuring feasibility and uncovering any hidden costs or constraints.

This high-level planning stage helps you identify whose support you’ll need and ensures that all costs, including one-time expenses, are accounted for. It sets the stage for detailed financial calculations and further strengthens your business case.

 

Here’s to crafting a compelling case that resonates with stakeholders!

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

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.

  1. Lessons learnt
  2. 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.

  1. 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?

 

Advertisement

 

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.

Editing for Success: Applying Hollywood Wisdom to Projects

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.

 

Advertisement

 

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!