Category: Business Analysis

The Intrapreneurial Business Analyst

Post author By formalobjects
Post date March 9, 2020

The Intrapreneurial Business Analyst

Business analysts have ‘street knowledge’ and deep insights into the main pain points in business. Who better then, to lead the charge in a multinational organisation that has distributed, virtual teams and foster a startup mentality?

Manoj Phatak

9 March 2020

A Call to Business Analysts

Would you like to be more involved in identifying opportunities for strategic change?

Would you relish the chance to exercise your natural leadership skills?

If so, a more intrapreneurial mindset (i.e. acting as an entrepreneur within your organisation) would be good for you and also for your organisation.

Intrapreneurship fosters a culture in which the multinational (or some part of it) remodels itself as a startup, capable of disrupting traditional processes and traditional customer expectations, to the benefit of both.

The business analyst occupies the essential and lucrative position of ‘inside entrepreneur’ in this culture, leading teams of customers, investors and suppliers (within or outside the organisation) to solve new or existing problems in innovative ways.

Business analysts must combine both technical and personal skills to minimise the threats posed by disruption and deliver benefits to the organisation, both financially and socially.

Why the BA?

Experienced business analysts have typically spent years developing competences in communication, forming crucial relationships with key stakeholders, identifying business needs and ultimately delivering solutions.

Business analysts have ‘street knowledge’ based on myriad conversations, workshops, customer shadowing and deep insights into the main pain points in business.

Who better then, to lead the charge in a multinational organisation that has distributed, virtual teams and foster a startup mentality that cuts through the traditional bureaucratic red-tape and drives the business unit to innovative and profitable new products and services?

Key competences

Key competences of an Intrapreneurial Business Analyst include:

Fostering an innovative mindset focussed on the bottom line rather than on implementation details
Quantifiable and controlled risk-taking
Communication, leadership and relationship-building
Measuring business benefits and delivering on them
The capability to ‘Show Me the Money’ i.e. knowing how to sell an idea to senior management

The role of the BA is transitioning from a humble ‘Taker of Requirements’ into a Leader, an Innovator and a Disruptor.

Christian Koch (in ‘Rise of the Intrapreneur’, Director Magazine) claims that intrapreneurs are the ‘secret weapon’ of the business world.

If businesses stand still for too long, they will find themselves being overtaken from the right, from the left and from above and below.

So, the real question is:- Can you afford NOT to innovate?

Benefits to the Organisation

Some of the benefits an organisation would receive would include:-

Being voted into the coveted ‘Best Place To Work’ awards and consistently winning top talent
Capturing young energy and new ideas with a sandboxed, lean approach to innovation with shoestring budgets
Forcing your BAs to think in terms of ROI, which can permeate into other more traditional projects in your organisation

Back to The Garage

How do we enable such a change in culture?

Take some lessons from Google X Labs, the LinkedIn [In]cubator, John Lewis JLabs, Lockheed Martin’s Skunk Works programme, Intel, 3M, HP, and the list goes on.

All these companies have survived today thanks to innovation.

Here are some quotes from these companies:-

LinkedIn [In]cubator

“We see [in]cubator projects as small investments that have the potential to become big wins for the company. So far, we’ve approved five projects. One of our projects, an internal tool called go/book, has already shipped and is deployed across all 26 offices worldwide, and has completely changed how we book meetings at LinkedIn. The project was so successful, in fact, that we approved the go/book team for a second round of development.”

Google X Labs

“The self-driving car project started in 2009 to develop technology that could make our roads safer and improve mobility for everyone. In October 2015, the team completed the world’s first fully self-driving trip on public roads in a car without a steering wheel, pedals or test driver. The project graduated from X and is now Waymo, an independent Alphabet company”

John Lewis JLabs

“JLAB is recognised as one of the best and most popular retail accelerator programmes attracting hundreds of hopeful companies from around the world. We listen to feedback every year so we can continuously improve the JLAB experience for the startups involved, which is why we are delighted that Waitrose have decided to be part of JLAB. The knowledge and expertise Waitrose will inevitably add to the programme makes for a very exciting fourth year”

Salesforce

“We’ve finally understood that the key to “Sustainable Transformation” is in democratizing Innovation. Organizations must embrace and reward employees who explore, experiment and learn as part of their daily job, not just the “special project”. That’s how you drive continuous and holistic innovation, that’s how you make it a sustainable way of being.” – Kristin McClanahan Raza (Salesforce)

Key Tips to Ensure Success

Do not penalise failure
Foster out-of-the-box thinking
Use early customer validation
Force a shoestring budget to reduce risk and increase potential ROI

And finally, ask yourself this question:-

Can you name one market-leading organisation that has succeeded in the last decade by standing still?

Share this post

Business Analysis for IoT

Post author By formalobjects
Post date March 9, 2020

Business Analysis for Internet of Things (IoT) Projects

Business Analysts need to figure out how to provide a seamless fit between customer experience, burgeoning IoT technologies and the continuous drive for business operational efficiency.

Manoj Phatak

9 March 2020

Once Upon a Time

Once upon a time, a long long time ago, computers lived in large ventilated rooms.

Then they moved to your desktop.

Then they moved into mobile phones, and smart traffic lights and ‘black boxes’ for automotive insurers.

Once Upon Another Time, Business Analysis was only performed in large companies, with large mainframes and even larger teams that spanned IT, marketing and finance.

Then, with the advent of cloud-based business intelligence and web analytics tools, it became possible for everyone to customise market demand estimations, explore KPIs and to see click-through metrics. Anytime, anywhere and for free.

What, Another Dashboard?

We are now so used to seeing dashboards, that we forget Business Analysis, Business Analytics and Business Intelligence are simply different facets of the same underlying ‘movement’. To visualise. To explore. To discover.

And as the Internet of Things (IoT) brings more intelligence to more devices which pervade invisibly into every aspect of our lives, Business Analysts will need to factor their existence into the Use Cases that drive business today:-

Smart shelves in supermarkets that reduce understocking by comparing the measured popularity of items to the sales figures for that item.
Smart boarding passes that check up on lost passengers who according to the FAA cost airlines USD 28 billion in 2018 alone.
Smart windows with embedded IoT sensors to measure light incident on building facades and to change the glass transparency, reducing the incoming heat that balloons the air conditioning costs in commercial buildings.

As you can guess, all this technology is going to have a major impact on people’s lives wherever we are; at home, at work or at play.

The work of the Business Analyst will be to figure out how to provide a seamless fit between the customer experience, the burgeoning IoT technologies and the continuous drive for business operational efficiency.

In the Beginning, There Was Darkness

The companies that are really driving IoT are Startups, of course.

And by Startup I mean the hungry, bootstrapped, seat-of-the-pants type companies, founded by 15-year-olds in their parent’s garage.

In fact, this has been the case since the days of Microsoft and Apple. Nothing has changed.

Recent IoT startup success stories include:-

Nest (bought by Google for USD 3.2 Billion, in cash)
Fleetmatics (bought by Verizon for USD 2.4 Billion)
Ring (bought by Amazon for USD 1 Billion)

The startups listed here have all shown the potential to deploy cloud-based IoT technologies that can change lives. The really interesting thing is how such tech can change the way Business Analysts view the user persona.

My User Story

Business analysis involves principally two things:-

Understanding the business issues of most importance (problems and opportunities).
Proposing changes to improve the business.

The first step remains the same, irrespective of the technologies available and involves interviewing stakeholders to understand strategic goals, business processes, use cases and a conceptual data model, culminating in a detailed statement of requirements.

It is during the second step that BAs need to map those requirements to a set of features which can be implemented within the project budget and project timescale. All this needs to be driven by the User Story.

So, when your supermarket client complains that customers cannot find nappies on the shelves because they are understocked, BAs must work with technologists to find solutions, which could include IoT-based smart shelves.

But how will a ‘smart shelf’ affect the customer buying experience?
If personalised discounts are also shown alongside the merchandise, will customers realise that certain behaviours can trigger a larger discount?
Will the technology drive people away because it is deemed ‘too salesy’?

Let’s take another example:

What if your airline client complains about missing passengers who delay flights and cause excessive costs and even regulatory fines?

BAs would need to bring together IT and Operations that may need to explore the benefits of smart boarding cards.

But will such devices constitute an invasion of privacy?

Should they be available on existing smartphone platforms or on a dedicated piece of hardware so you can track passengers’ location within an airport?

What will the delay be in recovering the physical hardware during boarding?

You get the picture.

It Only Gets Better

The good news for Business Analysts is that your job just got more difficult.

This protects your hard-earned degree from being superseded by AI-based software (at least for the time being).

Bringing together complex technologies is hard enough when the systems in play are primarily large-scale software apps. But when the tech involves hardware and software and changes to the customer experience, then BAs had better get their act together and up-skill.

You will need to understand what IoT is of course, but you will also need to dig into case studies on the legal ramifications of how IoT can affect everyday business scenarios.

You will also need to consider the costs, the benefits, the risks and the compliance issues in typical business scenarios, for example, a beleaguered mom dragging a screaming 4-year old round a ‘smart’ supermarket, while trying to find washing-up liquid and getting distracted by a 10% discount on shampoo which just popped up on her smartphone.

Because this stuff is already here. And it is being deployed right now.

Summing Up

Business Analysts who develop the knowledge and experience in how IoT affects customer buying journeys, customer experience and business models can stand out from the crowd and propel their careers into the future.

Share this post

The Whole Requirement

Post author By formalobjects
Post date December 10, 2019

The Requirement, The Whole Requirement and Nothing But the Requirement

Business Analysts must take care to observe the ‘real’ requirements. What stakeholders say may not be the same as what they do.

Manoj Phatak

10 December 2019

An Exercise in Observation

Whilst working on a large automotive project to build an infotainment system in Germany during 1999-2000, I conducted an academic exercise in observation. I wanted to see how difficult it would be to capture the ‘real requirements’ for a hypothetical InCar Email Dictation System.

So, I fitted a video camera to the dashboard of my car and asked 3 colleagues to drive round a pre-specified route. Their objective was to dictate an email to an imaginary dictation system whilst driving the car. I filmed all 3 attempts and transcripted the videos:-

[Engine starts running]
Hi…[engage clutch][change gear] errr…I would like to send
[1 sec pause] an email [change gear][look in rear view mirror]…errr…
I would like to send an email [2 sec pause] to Mary to tell her…[brake as approach turnoff]
[down a gear]. This is an email for Mary [up a gear][accelerate] just to tell her [change gear]…errr…that I will be late home tonight [down a gear for upcoming ascent] [1 sec pause]….errr….. so
please don’t wait up [brake][down a gear], as I have a meeting running late so please don’t
wait for me [down a gear][decelerate][turn left]…….

From the transcripts, it became clear that the system would have to be very smart to make sense of the above…..garbage…!! The transcripts contained:

Pauses: do these mark the end of a phrase or sentence? Repetition: does the user mean to repeat? Words which are not really words: such as ‘errrr’, ‘ummm’ and ‘ahhh’

It was obvious that the driver was much more concerned with driving the car than dictating the email (quite normal considering his / her life depended on it).

When I showed the video to my project manager, we both decided that email dictation systems posed a challenge since the requirements were much more difficult than we had imagined.

Now, if we apply this to a project where you are looking to improve process efficiency, it would be wise to not take for granted what our business stakeholders tell us. It will always be safer to carry out pure observation (just as above) to ensure we have the right data regarding how long a process takes for example (and therefore the ‘real requirements’) before starting out on implementation.

Business Analysts must take care to observe the ‘real’ requirements. What stakeholders say may not be the same as what they do.

Another Example: UK Mortgage Application Process

Business Rule: A mortgage loan of a given borrower can only be secured by securities that are owned by the given borrower.

From the above UML fragment, we see that a MortgageLoan is associated to a Property (which it views as it’s Security) and to a Borrower (which the MortgageLoan views as the Customer of the bank). The Property views the Borrower as the Owner. There are different types of MortgageLoan: namely, InterestOnly and Repayment.

The business rule above may need reading a few times to fully understand it. We realised in fact that this statement alone may not be correctly interpreted by our development team, so we decided to break it down further using OCL, the Object Constraint Language:-

The OCL statement says basically what the business rule above says, but in a less ambiguous way, which is less open to misinterpretation by the development engineers. In fact, we found that this process often unearthed problems early on, well before they reached development. Many times, we had to go back to the business to clarify specific aspects (and sometimes even they were not sure).

context MortgageLoan 
inv onlyOwnedSecurities: 
security.owner>forAll(owner | owner = customer)

Conclusion

It is wise to use whatever techniques we can to discover the ‘real’ requirements and business rules before embarking on development. Videoed observation is a key technique that allows us to see what is really happening in a business process. After all, the camera never lies.

Share this post

Business Analysts Can Enable Innovation

Post author By formalobjects
Post date December 10, 2019

Business Analysts can Enable Innovation

Business Analysts must learn to decode the wishes of customers into requirements that focus on what the solution must achieve, but in a way which allows for multiple possible implementations.

Manoj Phatak

10 December 2019

“If I had asked my clients what they wanted, they probably would have said a faster horse.” — Henry Ford, Founder of the Ford Motor Company

This infamous Henry Ford quote is often mistakenly used to justify that we do not need to talk to our customers, because they do not know what they want or because they do not know what is best for them.

This thinking is essentially flawed.

If Henry Ford had had access to a Business Analyst at that time, he might have arrived at a better statement of the ‘real’ requirement, namely:-

A medium of transport capable of carrying 100 kg of persons and goods a distance of 10km within 1 hour, without stopping for ‘food’.

Now, if you give such a statement to your engineering department, they will need to think outside of the box to reinvent the concept of a ‘horse and carriage’ that can meet those requirements.

It is this very thought process that may force them to create the concept of a ‘mechanical horse’. This is the basis of innovation.

The Business Analyst contributes to innovation by defining the requirements in an abstract way that focuses on the end-result, without specifying how the design or implementation is to achieve it.

Here is another example:

The bad requirement specifies how to implement the idea, whereas the good requirement abstracts away from the implementation details to focus on what we are trying to achieve, namely ‘to search’.

If we take the ‘good requirement’ to our IT department, they will be obliged to find a mechanism that can search effectively through an ‘infinite’ list of media items. Given some thought, they may come up the idea of a circle.

It is possible that this was the basis of creating what we know today as one of the most revolutionary changes in digital user interface design – the Apple iPod, which was one of the first digital products to introduce the concept of scrolling using a circular search mechanism.

On the other hand, if we had given the ‘bad requirement’ to our IT department, we would have stifled any attempts at innovation because the engineers would have been forced to work with a drop down listbox, which may not be as effective at allowing rapid search within a very large group of items.

Instead of an innovative product, we would have ended up with a real turkey of a product..!

Comparing Patent Claims to Requirements

So, even if you are convinced that writing requirements in an abstract way can facilitate innovation, how far should we go? Well, patent claims take an approach which is somewhat similar to writing requirements (although the end-result is protection of intellectual property, rather than solution development).

Let’s look at some similarities:-

So, do Business Analysts need training in how to write patent claims before being set loose on requirements definition? Not at all.

However I do believe that Business Analysts can learn from how patent attorneys build abstract and legally binding descriptions of products as patent claims in order to allow breadth (and therefore value) to the patent.

If only Business Analysts could write requirements in the same way. After all, when is the last time you saw a requirements document that would stand up in a court of law?

Conclusion

If Business Analysts are to enable innovation, we must learn to decode the wishes of our customers into abstract requirements that focus on what the solution must achieve but in a way which allows for multiple possible implementations.

This opens up the design space to ideas which may not have existed previously and hence fosters innovation, both within the multinational as well as for small enterprises.

Share this post

It’s Traceability, Spock, just not as we know it

Post author By formalobjects
Post date December 10, 2019

It's Traceability, Spock - just not as we know it

Change happens on a project – whether we choose to manage it or not. What are you currently doing to minimise it’s negative impacts? A traceability matrix can be the answer.

Manoj Phatak

10 December 2019

Introduction

If you change the Product Price on a line item in a Purchase Order, you expect to see the Total Price at the bottom also change, right? That is traceability!

We can achieve the same thing on projects, by mapping business needs, stakeholder benefits, product features, requirements and designs – such that if one of them changes, we can assess the downstream impact.

And since traceability is bi-directional, we can also assess which benefits, features or requirements map back to the business needs, and eliminate those that do not have a strong mapping.

Some people claim that traceability tools are too expensive. Some cannot justify spending time on them. Some claim they are difficult to explain to business sponsors.

For small or medium sized projects, traceability can be managed with a simple spreadsheet. The question is whether we can afford not to put in place the processes, tools and people that manage change.

Change is going to happen anyway. What are you currently doing about it?

Projects need to be managed, whether or not there is a Project Manager on the team. The same is true of Traceability.

Stakeholder Benefits

Describing stakeholder benefits can be a challenge. If we fail to accurately understand what the real benefit is to our customer, it is difficult to know what to implement and whether the customer goal has been met by the end of the project.

I often find that Twitter helps on these occasions.

Can you describe each benefit (in your current project) in less than 140 characters? And get consensus across your stakeholder community?

Product Features

But what benefits are received by users of having a taller display? Or a longer battery life? Or a better camera?

The stakeholder benefits will depend on who we are talking to. Some users may see great benefit in faster connectivity or a higher-resolution camera, some may not.

It is up to the Business Analyst to ‘measure the value’ to the stakeholders of each feature and map this on a traceability matrix.

Traceability Mapping

The example traceability matrix below maps business needs, benefits and features to the requirements and design for the iPhone.

Can you connect the boxes together and thus show how the design maps back to the requirements?

And how requirements map back to features?

And how features map back to benefits? And finally how benefits map back to business needs?

Of course, building a solid traceability matrix cannot be done alone – you will need the help of your stakeholder community. That means business, IT, legal, marketing and son on…

If you would like to see the finished result, please contact me.

Conclusion

Change happens on a project – whether we choose to manage it or not.

What are you currently doing to minimise it’s negative impacts? A traceability matrix can be the answer.

If properly managed, this simple, inexpensive tool can minimise threats and identify the value to our stakeholders of key features, before starting implementation.

Share this post

Digital Business Analysis

Post author By formalobjects
Post date December 10, 2019

Digital Business Analysis

The Digital Business Analyst combines market analysis, competitor analysis and keyword analysis to understand the Voice of the Customer.

Manoj Phatak

10 December 2019

What is Digital Business Analysis?

The Digital Business Analyst combines market analysis, competitor analysis and keyword analysis to understand the Voice of the Customer.

With this knowledge, we are equipped to feed market intelligence into product / service development to give customers what they need.

A Cry Out for Help

After all, each keyword typed in by a person somewhere in the world is a cry out for information, often at the time of maximum need. It is at this crucial time that our products and services must be ranked highly enough that our prospective customers can find us.

Not only that. Our content must be engaging enough to create real interest. Our brand must convey trust. Our team must convince. The value we provide must be tangible. Not easy, right? Right.

Traditional Business Analysis

But not impossible either. The traditional role of a Business Analyst has often been limited to internal projects, with face-to-face interviews, workshops and surveys to understand what our internal customers often do not understand either: what they really need.

Cost Centre vs Profit Centre

The traditional Business Analyst department / service / team is often seen as a Cost Centre, often within IT, so often ignored by Business and seldom given the chance to explore the real business needs.

Enter the Digital Business Analyst, capable of deciphering the wants, needs and desires, typed in as queries into a web browser, by prospective customers, often looking desperately for an answer to a burning issue.

So, why can Business Analysis not be seen as a Profit Centre, rather than a Cost Centre?

Why can Business Analysis not be set free into the Big Bad World to explore what customers really need, be they B2B or B2C, or even C2C? (Think eBay).

Connecting The Dots

What if Business Analysts could connect the dots from the vast resources of global keyword databases, cutting through the noise and define the requirements of our next killer app, without having to conduct a single face-to-face interview.

After all, how could we interview the world, anyway?

I am talking about using the power of the Web to understand our Customers better.

I am talking about using Big Data metrics to find out what Customers want or need, and assess the market size, market demographics and market trends before developing products.

All the data is already there. We just need to connect the dots.

So, empower the traditional Business Analyst with Digital skills and set them free to explore the world.

We might just define that Next Killer App before our customers realise that our product is exactly what they were looking for all along.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

The Intrapreneurial Business Analyst

Manoj Phatak

A Call to Business Analysts

Why the BA?

Key competences

Benefits to the Organisation

Back to The Garage

LinkedIn [In]cubator

Google X Labs

John Lewis JLabs

Salesforce

Key Tips to Ensure Success

Share this post

More From Our Blog

Business Analysis for Internet of Things (IoT) Projects

Manoj Phatak

Once Upon a Time

What, Another Dashboard?

In the Beginning, There Was Darkness

My User Story

Let’s take another example:

It Only Gets Better

Summing Up

Share this post

More From Our Blog

The Requirement, The Whole Requirement and Nothing But the Requirement

Manoj Phatak

An Exercise in Observation

Another Example: UK Mortgage Application Process

Conclusion

Share this post

More From Our Blog

Business Analysts can Enable Innovation

Manoj Phatak

A medium of transport capable of carrying 100 kg of persons and goods a distance of 10km within 1 hour, without stopping for ‘food’.

Comparing Patent Claims to Requirements

Conclusion

Share this post

More From Our Blog

It's Traceability, Spock - just not as we know it

Manoj Phatak

Introduction

Stakeholder Benefits

Product Features

Traceability Mapping

Conclusion

Share this post

More From Our Blog

Digital Business Analysis

Manoj Phatak

What is Digital Business Analysis?

A Cry Out for Help

Traditional Business Analysis

Cost Centre vs Profit Centre

Connecting The Dots

Share this post

More From Our Blog

Company