Skip to main content

Tag: Methodologies

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!

Beyond the Finish Line: Understanding the Art of Value Enablement

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!

 

Advertisement

 

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?

 

Work like a Surgeon

There is an old joke about a surgeon and a mechanic that goes like this:.

A mechanic was removing an engine part from the motor of a car when he spotted a world-famous heart surgeon in his shop. The heart surgeon was waiting for the service manager to come take a look at his car. The mechanic shouted across the garage, “Hey Doc, can I ask you a question?” The famous surgeon, a bit surprised, walked over to the mechanic working on the car.

The mechanic straightened up, wiped his hands on a rag, and asked, “So, Doc, look at this engine. I can also open it up, take the valves out, fix them, and put in new parts, and when I finish, this will work just like a new one. So how come I get a pittance and you get the big money when you and I are doing basically the same work?” The surgeon paused, smiled, leaned over, and whispered to the mechanic, “Try doing it while it’s running.”

 

The world in which a business analyst operates is quite like the surgical world, in the sense that a BA works with a live or running organisation and needs to make the necessary changes or improvements to the company without shutting down the currently running processes, delivering the required change while reducing impact to the minimum.

We will extend this analogy a little further from the beginning of the process (the patient comes in for consultation) until its logical conclusion (the patient goes home with the issue fixed) and see what observations we can gain from the medical world. We will also use this journey to look at the toolset available to a business analyst and determine which tool would work the best for which stage of the process.

 

Let us follow the example of a hypothetical heart surgeon. A patient complaining of chest pain is referred to him by a local GP.  The surgeon reviews the medical exam tests conducted by the GP, forms some initial conclusions about the issue, and validates the same through further diagnosis of the patient. Based on the diagnosis and the testing, the surgeon determines that the heart is not in a good condition and that there is a high chance of heart failure. The surgeon advises that heart surgery is required to resolve his condition.

This carries some risk; however, avoidance of the surgery carries a greater risk and is more likely to result in cardiac arrest. He directs the patient to the hospital admin team to get an idea of the costs involved. The hospital admin team provides the patient with all the details, including the overall cost, including the pre-operation treatment, cost of operation, cost of recovery procedures, and timelines of each stage, so that the patient has a good idea of when the operation procedure will start, how long the entire process will take from end to end, and how much it will cost.

The patient agrees with the cost and the timelines and makes the arrangement to pay the funds to the hospital by the agreed date. The surgeon proceeds with the operation. The operation is successfully completed on time, and the patient is discharged with regular follow-ups scheduled.

Now, let us consider a parallel example in the software sector, i.e., a medium-sized software company. The company has noticed a steady decrease in profits along with an increase in customer complaints and wants to fix this issue. The company engages a reputed consultancy for this.

The BA from the consulting team arrives at the company and conducts a detailed study of the current state and the reported complaints. Through a series of discussions with the company members and interviews, the BA identifies all the key parties involved in the processes and complaints. The BA organises a series of workshops with the company representatives and uses several problem-solving techniques, such as the 5 Whys, root cause analysis, the fishbone diagram, and flowcharting of the current process, to get to the bottom of the issue.

 

Advertisement

 

The BA ensures that all the relevant parties understand the question by providing them with clear objectives for the workshops and what is expected of them. During the workshop, the BA also ensures that all the members get an opportunity to express their views, so that the findings are as unbiased as possible.

After this process, the BA gets a good understanding of the current state and the main causes of the issues that the company is facing. It appears that the existing software used by the company is quite old.  not in line with the current needs, resulting in inefficient and time-consuming processing. There are also a few legacy processes being carried out, with some steps that are no longer relevant but are still being carried out as the staff have always worked that way.

This is resulting in a poor customer experience, with a corresponding decrease in sales and an increase in customer complaints.

 

These series of workshops have helped the BA and the senior management of the company get a clear understanding of the current state and the main causes of the issues being faced by the company. To take the next steps, the BA also needs to get a good understanding of the future state, i.e., what the company aims to achieve as part of its short- and long-term objectives. To do this, the BA requests that the company provide its vision, goals, and the approach or strategy decided to achieve these goals. Some of this may be readily available in the company documents but may require further discussion with senior stakeholders to clearly flesh it out so that there is no misunderstanding.

For example, the company may have planned, say, a 20 percent increase in market share, but may not have thought through or clearly spelled out all the associated elements, say, an increasing rate of production, the addition of new machinery or employees, the setup of further logistics, getting additional funding, etc. The BA helps the company work through all the dependencies and impacts and create a comprehensive future state model.

The company now has a good understanding of the as-is, or current state, and the to-be, or future state. The BA now organises another set of workshops involving all the key participants to get a clear understanding of what needs to be done to move from the current state to the future state; in other words, the BA is gathering and eliciting the requirements. During this process, the BA ensures that all the identified problems and issues and the vision of the future state are clearly understood by all the participants. This helps to ensure that the requirements are in line with the needs of the company.

Based on the feedback received from the various members of the company and their understanding of what is available in the market, the BA recommends a set of options, including some quick wins through process changes and long-term solutions such as upgrading the software or replacing it with a more efficient one. The BA clearly highlights to the senior management of the company the risks associated with staying as is and the costs, benefits, and risks of the proposed solution options. The BA also supports the company with the change impact analysis process, i.e., how the changes would impact each of the company staff involved in the current process and what can be done to ensure a smoother transition.

Once the BA gets agreement from the key stakeholders on which solution or solutions they would like to progress, the larger team, including the project managers, system architects, IT consultants, testers, and other change management personnel, is brought together along with the key members of the company, and the project is initiated. The BA carefully monitors the requirements through the various stages of the development process using a requirement traceability matrix to ensure that there is no dropping of key requirements or addition of wants based on the personal desires of some stakeholders.

The BA also ensures that the company representatives are kept well informed about the progress of the project and that there is proper end-to-end, two-way communication. This ensures that the project is successfully delivered with minimal post-project impacts.

Introduction to the 4 Pillars of Digital Transformation

In the wake of World War I, French Premier Georges Clemenceau advised the French people that “War is too important to be left to the generals”. Paraphrasing his words I would say that “Digital Transformation is too important to be left to the marketing and sales departments”- Why? Because they are infatuated with the client and it is right because it is their main objective and priorities.

While the customer is very important, I will say paramount, I believe the causes of so many pitfalls and failures in the implementation of DT (Digital Transformation) are the obsession of marketing and salespeople on the customer the hyper concentration in the customers disregarding what I believe are the foundation of DT: The Four Pillars of Digital Transformation.

Even before any consideration of the digital part (Software and Hardware) of the DT equation we need to take care of what I call the 4 pillars of Digital Transformation.

  1. Culture
  2. Process and Policies
  3. Data
  4. Security

They exist in a hierarchical cycle so while some overlapping is possible, the same that when you wear your shoes, you first need to put your socks on. In the four pillars, Culture comes first, then Processes, Data and Security.

Following the diagram of The Four Pillars of Digital Transformation:

 

Advertisement

 

For marketing and sales, a customer is an external agent, a person that buys the company’s goods (products and services) for the DT practitioner. The concepts should be broader, instead of customer we should think about USERS.

Please, do not read me wrong. The Sales and Marketing people are paramount for the success of your DT but are not the only ones, in my humble opinion. DT is a matter of life and death for your company and if the CEO and all the C-Level are not deeply involved in the DT projects the probability of success is null, zero, nada.

I am using data as a general term because what we call data is often confused with Information and Knowledge, other two important blocks of the ILC, as I explained in my article “Do we know what are Data, Information and Knowledge?” on this website.

In my other model, “The Intelligence Life Cycle” which I used to discover the AI limitations, I explained what Data, Information and Knowledge really are and created a model of the intelligence Life Cycle based on 4 axioms or postulates in the style of the ancient Greek mathematician Euclid’s. I am going to present the ILC and the Limitations of AI at the PMBA Conference in Orlando next year.

Data is not the New Oil as the hyper propaganda instigated by the media and some data scientists in search of fame, support and money claim, and as you can see from the above diagram, occupied a 3rd position in importance.

You can get more details by watching my 4 Pillars of the Digital Transformation at the Virtual BA and PM conference in Dec this year.