Product Roadmap – A Script For Success

by Sunil Powle,

Business Analysts Pty Ltd Consultant

 

It was close to 4pm and George was staring at his third PowerPoint slide for more than an hour, adding and deleting content several times. He felt as if he had no more power left to make a point. George had been leading a lean product team working on a contract management system implementation in an Agile environment.

Jane, an experienced business analyst noticed a worried George and stopped by for a chat.

 

 

Jane: George, you look worked up, something the matter?

 

 

George: My stakeholders just don’t seem to get it. I’ve had several sessions with the leadership team and with the ground staff too, however, they never seem to align with the work we have done and the work we have in our pipeline. Despite several presentations, they seem unsure of our product’s vision.

Jane: Aah, a much familiar ground, it’s always a daunting task to bring stakeholders on the same page. Have you tried building a Product Roadmap?

George: Product roadmap! What is that, another management gimmick?

Jane: I understand your frustration George, but this thing works.

George: Well what is it? Can you enlighten me?

Jane: A product roadmap is a summary that plots the vision and direction of your product offering…umm contract management stuff in your context, over the implementation period. It can be a visual summary, a strategic document or a plan and can be tailored to your audience.

George: Tailored to my audience, what do you mean?

Jane: I mean, for the leadership team, your product roadmap can talk about the product’s vision and how it aligns with the organization’s strategic goals. However, for the ground staff, you can dive into details by focusing on specific product features and add further details. You work in an Agile project management environment, don’t you? So, you can consider including themes, epics, stories and features into your product roadmap.

George: So, the product roadmap will cover features, requirements or initiatives and will outline a path to deliver them over a period thereby describing the anticipated product growth?

Jane: That’s correct! Let me show you how it will look at a very high-level so that you get the gist of what I’m talking about.

Jane quickly scribbled a rudimentary sketch of the product roadmap on her tablet.

 

 

Jane: Look at this picture. You can spread the planned development of your product across the timeline. This way, your stakeholders will have a single view of what is being delivered when.

 

George:…and I will be able to communicate the direction and progress towards the vision for my product, both to the leadership and to the ground staff and thereby establish a shared view and understanding?

Jane: Correct again, you are a fast learner!

George: That sounds interesting, but tell me, how does it fit into an Agile working environment where we have continuous moving pieces

Jane: Good question. Its common knowledge that Agile environment values working solutions. A product roadmap focuses on product/feature/value delivered as against focusing on a milestone or checkpoint. Product roadmap enables iterative delivery by showcasing features that are being delivered currently and those that will be delivered next and at later period.

George appeared a bit confused.

 

George: Hang-on, this sounds like a product backlog, are we confusing the two?

Jane: An Agile expert you are, but there are key differences between a product backlog and a product roadmap. Typically, a product backlog is a translation of how your team will deliver the vision outlined on an Agile product roadmap. The backlog defines product features for near term, but a product roadmap provides a strategic view of where the product is headed over the mid to long term period. It is tied to the organization’s vision and strategic goals often for the next 12 or more months.

George: I am itching to get started! Any input on how should I structure the product roadmap?

 

 

 

Jane paused a while to think:

 

 

Jane: A funnel approach is what comes to my mind.

George: A funnel approach? Boy you’ve got some cool analogies but help me understand more.

 

 

 

 

 

 

 

 

 

Jane: The product roadmap should first tell your product’s story at the highest possible level, consider starting with themes and epics and then work its way down into the smaller, more detailed aspects of that story such as requirements, features or user stories.

 

Jane quickly scribbled the hierarchy on her tablet.

 

 

George: Themes, Epics, that’s right down my alley, but before I get started, are there any limitations to this that I should be aware of?

Jane: Unfortunately, yes. A product roadmap can prove ineffective if the organizational environment is such that it leads to frequently changing vision and desired outcomes. I have seen a few product owners misusing the roadmap as a milestone or a date-driven plan. You will need to be cautious on the level of detail you put into it as it can get very time-consuming to maintain if it is overly detailed or too many variations are made in an attempt to satisfy all stakeholder groups. The trick here would be to find the right balance of details that the stakeholder groups can relate to.

George: I will be mindful of these aspects Jane. I know it’s getting late, but are there any final inputs?

Jane: Well there are a few more things you should consider.

George: Always hungry for more, you have both of my ears Jane.

Jane: Ensure that you as a product owner take ownership of the product roadmap and have your team focusing on maintaining it. Make it a living document rather than a plan set in stone. Regularly discuss, prioritize, estimate, update and share the product roadmap. Ensure that the roadmap reflects the most current priorities and goals, is easily accessible to those who need it. Set expectations with your stakeholders that the roadmap is not a promise. And lastly, keep it simple.

George: You are a star Jane, thank you so very much.

Jane: You are most welcome George; a Business Analyst never shies away from helping where they can. I wish you all the very best!

 

 

Why I Work at Business Analysts Pty Ltd (BAPL)

by Patrick Leaupepe,

Business Analysts Pty Ltd Consultant

 

A couple of weeks ago on a camping trip with some mates, we were sitting around a camp fire and one of the boys asked me “Why do you work for Business Analysts Pty Ltd (BAPL)?” 

This question completely caught me off guard, because what separates one employer from another?

After hours of driving and a cold bevvy or two, I wasn’t able to provide a response that really represented my feelings. However, it did lead me down the path to reflect back on my career, and I would like to take this opportunity to share Why I work at Business Analysts Pty Ltd (BAPL)

I have been working at BAPL for the past three and a half years, and over that time, I’ve had a lot of great experiences and not so great experiences…life of a consultant, right? So, upon reflection, I managed to boil it down to three key reasons. I work for BAPL because we have amazing consultants, great managers and most importantly, a supportive and collaborative culture.

Fortunately for me, I’ve had the opportunity to work alongside a lot of amazing BAPL consultants on numerous projects. Each consultant brings their own style, experiences, knowledge, etc. to the table and regardless of age/gender/background we all respect each other. Due to the mutual respect, I’ve been able to learn new skills and techniques because everyone’s happy to share their knowledge and experiences. And I’ve also built strong relationships, so much so that I’ve made some great friends along the way.

In addition to having amazing consultants, we also have great managers. The managers at Business Analysts Pty Ltd  have been great to me, and the three main managers that I want to focus on are the Service Delivery Manager, Practice Manager and Engagement Manager. Each manager plays a vital role within the business, and I have the utmost respect for each.

 

  • Service Delivery Manager: The Service Delivery Manager is responsible for managing the consultant engagements and client relationships.
  • Practice Manager: The Practice Manager is responsible for training, career development, and resourcing.
  • Engagement Manager: The Engagement Manager is responsible for managing the sales pipeline and allocating resources for new opportunities.

 

Each of the managers above are great, but what makes them really great is that they work together to ensure that each consultant is placed into an engagement where he/she can succeed and be supported to produce deliverables that meet the client’s expectations.

The last point I want to talk about is the supportive and collaborative culture at Business Analysts Pty Ltd. I honestly believe that this kind of culture could not have been achieved without the amazing consultants and great managers in the BAPL practice. As aforementioned, there is a high level of respect amongst the practice and everyone is encouraged to ask questions, share feedback, bounce ideas, and provide their opinions. Whether you’ve been working at BAPL for years or if you’re a new starter, everyone’s contributions are highly valued and that’s what I believe helps drive a collaborative environment.

Furthermore, the support provided by the managers and consultants is second to none. On all of my client engagements to date, I have always felt comfortable to reach out for guidance. The managers are always there to lend a helping hand, and the consultants are happy to help out as well. I believe that having amazing consultants, great managers and a supportive and collaborative culture go hand in hand (in hand), and this is why I have thoroughly enjoyed my time at BAPL to date. So, the next time someone asks me why I work for BAPL, I’ll now be able to answer clearly.

The T-Shape of You

by Henry Elisher,

Business Analysts Pty Ltd Consultant

 

Why you should cross your T’s first

 

Over the past decade there has been a plethora of research done which has emphasised the idea that for professionals to grow, thrive and excel in their respective environments they needed to possess both a deep disciplinary knowledge in their chosen areas of expertise and also have a keen ability to communicate across social, cultural and economic boundaries. The concept of soft skills, those interpersonal (people) skills that are generally understood by the populous as being the ability to communicate, are in fact far more reaching. They are an extensive range of qualities and attributes that encompass such things as attitude, creative thinking, work ethic, motivation, problem solving and conflict resolution, amongst a host of others. These are the key components that allow for the facilitationof interactions between people. Understanding that the majority of us work within a variety of business organisms, that have their own worlds of unique social interactions, it’s fundamental to our success as business analysts to both recognise, embrace, and develop this skill set, especially knowing that the key to our own success lies in the relationships that we build with our stakeholders.

Knowledge and teachable abilities are of course core to the capacity of what an individual brings to a role but what differentiates the performance of one employee over another is their ability to prioritise their focus, to work effectively in a heavily networked and matrixed environment and understand how the informal mechanisms of business work. It’s these unmapped and quite often undefined social concepts that, when grasped and utilised by an individual, will allow them to be identified as a person with the talent and capacity to lead, innovate and drive change. Utilising a quote from Aaron McEwan, Advisory Leader at CEB, he says;

Most of the good stuff in terms of performance happens in the white spaces between people, not at their desks’

It’s an idea that often gets lost in working environments that demand metric driven, quantifiable results but in reality should be obvious to us all in the sense it’s the harnessed expertise in a variety of areas allow us to get to viable solutions. Promoting the culture of ideas through dynamic interaction doesn’t occur whilst staring at a monitor.

 

The T-Shaped Business Analyst

 

These days with a greater number of people undertaking higher education, professional certification and various forms of additional study, the attainment of disciplinary knowledge no longer becomes the genuine differentiator that it once was. Not only is it not a real differentiator but the nature of ‘information attainment’ within educational institutions, that are often one dimensional in their own approach, tend to produce ‘I-shaped’ professionals. By ‘I-shaped’ what I am referring to is a type of professional that has deep, extensive technical knowledge in their area of expertise but lacks the broadness and well roundedness to be able to cross disciplines or industries within their knowledge capacity. Referring directly to fig 1 – The T-shaped professional, the ‘I’ component is represented by the two vertical pillars that state ‘deep in at least one discipline’and ‘deep in at least one system’.  From a business analyst perspective this can be identified as having the requisite knowledge in requirements elicitation, requirements analysis etc.

 

what is the T

Fig 1 – The T-shaped professional

 

As business analysts we can very much fall into the trap of being the classical, ‘I-shaped’ professional. We may very well be comfortable with our core set of skills and have a deep knowledge of the fundamental areas that the IIBA outline in the BABOK but what impact does that this sole focus have on ability in the environments where we ply our trade? Generally it is understood that without a broader, more expansive, interactive outlook, the professional can become knowledge and skill-set bound, essentially trapped, interpreting their workplace as largely a competitive environment, existing within their disciplinary silos and not extending beyond the comfort of the visible horizon.

By comparison, the defining characteristic of the ‘T-shaped’ business analyst, is demonstrated by the horizontal bar in figure 1. This component demonstrates the ability of the individual to collaborate across a variety of different disciplines, to be able to contribute to creative and innovate processes and to ‘tap in’to the unmapped social concepts that exist in organisations. It’s the utilisation of these type of soft skills that will allow the business analyst to share the expertise of their discipline and craft, whilst also having the capacity to translate this knowledge to those that do not fully comprehend the scope of work that a business analyst undertakes, because, along with being successful collaborators we also need to be our own ‘sales representatives’ and become advocates of our own expertise. It’s this promotion of awareness that can break down the power of ignorance and support our cause, but, the unlocking of this potential is only made viable through the development and utilisation of soft skills.

The idea of this readily transferable skill-set of course has special importance in the business analyst world as we should be ready to confidently step across sectors, from entertainment to utilities, from financial services to mining. It’s this agility and adroitness, supported by our set of soft skills that will identify us as unique but also as being the vital promoters in the creation of the new mobile, agile and educated workforce, a factor that’s critical for the global digital economy to prosper and in itself critical to the positioning of business analysts within this economy.

Business leaders have readily acknowledged the criticality of the far-reaching capacity of soft skills. Matt Tindale, the Managing Director of LinkedIn for Australia & New Zealand states that the ‘demand for collaboration, teamwork, EQ, critical thinking, problem solving and conflict resolution …are immensely important enterprise transferable skills’.This is a statement which should appear obvious as these elements really stand as the common base amongst a variety of disciplines and act as both the mechanism and vehicle to drive innovation from disparate, but equally as important knowledge bases.

So, whilst we can identify ‘I-shaped’ analysts and understand that their level of knowledge can obviously be utilised to get the job done, the question arises, at what expense? Muted levels of soft skills means that collaboration, teamwork, conflict resolution and the motivation to drive towards a common goal quite often comes to the ‘I-shaped” analyst with a deal of stress, strain on working relationships and with much less of the dynamic interactions that ‘T-shaped’ analysts develop in natural, organic ways. It’s the ability of the ‘T-shaped’ analyst to find compromises and help motivate others towards solutions that separate the good business analysts from those that are great. It will also be these subjective types of skills that will not only hold the ‘T-shaped’ analyst in good stead for a long, healthy career but will also bring the diversity and necessary degrees of challenges to create well rounded individuals.

 

Analyse like a Boss

by Tanya Harlow,

Business Analysts Pty Ltd Consultant

Article 1 – Define Your Own Business Idea

As Business Analysts we tend to find ourselves working as consultants, contractors or permanent inhouse domain experts on enabling new opportunities or solving problems for medium to large businesses.

Have you ever thought of using your awesome array of BA skills and experience to create, operate and lead your own small business?

When you think about starting your own business the mind starts to boggle with the enormity of it all and it feels very daunting, scary and almost impossible to fathom.  Not knowing where to start and how to move forward is the biggest obstacle to overcome.

A manageable way to approach the creation of a new business venture is to break it down into small key milestones that when set out in a logical order make the enormity easier to digest and will give you a clear starting point.

After having your “Eureka” moment and forming the kernel of your business idea and concept you can leverage your existing BA toolkit and skills to do some research and get your concept down on paper.  Doing some high-level analysis and modelling does not cost anything but your time.  During this initial analysis you will learn a lot about your concept and its viability and takes you a step closer towards your potential new future venture.

Product/Service

  • Consider your product and its key point of difference
  • Create a prototype where possible or a strawman on paper
  • Go through a SWOT analysis (strengths, weaknesses, opportunities, and threats) to assist in seeing the bigger picture and potential risks to work through

Market

  • Analyse the potential market and buyers for your product, who are they, where are they, how old are they, what are their buying habits, how much is their disposable income, what social media do they use, how will you reach them?
  • Use free online census data for understanding customer demographics
  • Conduct competitor analysis and benchmarking, this is great way to see how other similar businesses operate.  How do they market their goods, what are their price points, what do they do well, what could they improve on, what can you learn from their experience?

Financials

  • Analyse the costs for your business start-up
  • Model profit and loss including start up expenses, projected growth targets for the first 5 years of business, cost to operate and sales targets to see how viable the idea is on paper
  • Think about how you might fund the venture, financial institution loan, business partner or give crowd funding a go!

Company Structure

  • Analyse the best company set up for your situation e.g. sole trader, company, partnership.  It is worth seeking advise from an experienced business accountant when assessing these options as they can provide expert taxation advise and can assist if required in the creation of a Pty Ltd company
  • Perform organisational modelling to determine the roles required for your business, size and budget
  • Determine what role you will play within the business.  Always leave room to work onyour business and not just in the day to day operation of your business
  • Define your company’s core values, what does your business stand for, what are your guiding principles
  • Think about your company’s persona, how do you want to present your image to your customers? Is your company cool and hip or friendly and trustworthy? Knowing how you want your company to be perceived is very useful when the time comes for creating marketing materials like logo’s and websites.

Skills and Experience

  • Analyse the key skills and experience you will need to be successful within the specific industry domain you are looking at entering
  • Rate your existing general business skills like accounting, marketing, sales, payroll etc
  • Perform a gap analysis of where you are now, what you need to learn and how you will close the knowledge gap to acquire the relevant skills to enable success
  • Close your education gap including internet research, training courses, work experience and finding a good mentor.

Key Business Processes

  • Process analysis is required to determine what business processes and underpinning forms, reports etc will be required
  • Define your key value stream using a process flow chart identifying points of value and points of waste within and between processes
  • Process benchmark information for specific industries is available from the APQC industry standard website and can help inform you of the typical processes your business may need
  • Create a SIPOC diagram (suppliers, inputs, process, outputs and customers) for all key processes to understand the inputs and outputs and suppliers you may need.

Tools

  • Define your requirements for software tools to manage your accounts, invoicing and payroll (or will you outsource this part of your business to a strategic partner?)
  • Document what marketing tools your company will need including a website, Facebook, Twitter, Instagram and graphic design software tools
  • What customer relationship management tools are available to manage your customer database
  • What financial sales tools will you need to manage point of sale or online ordering?
  • What physical tools do you require to create your product? are these tools best rented with maintenance contracts in place or purchased outright as an asset and depreciated?
  • This information will feed directly into your cost modelling for start-up and operation

 

After doing your analysis on paper you should have a reasonable idea of the feasibility of your business idea, the complexity and associated costs.

If your numbers initially stack up and you are still excited to take the next step with your idea proceed to Article 2 in the Analyse Like a Boss series – “Business Start Up”to understand some of the BA techniques and savvy you can leverage to put together the required deliverables to start up your new business venture.

Business Analyst is a Product Owner’s Best Friend

by Sohail Chatha,

Business Analysts Pty Ltd Consultant

 

A week back, I had a very wonderful corporate lunch with work colleagues. For my dish, I needed a fair bit of customisation. The waiter took all the details patiently even though some may have seemed rather quirky even by my own standards. After a 20 minutes wait, voila I have my dish served & I liked it so much I left a tip.

Once at home, still thinking about how perfectly it was executed, I wondered what if the waiter (BA) was not patient enough to carefully note all my wish-list (requirements) & present it to the Chef (product owner) promptly. Had the Chef not listened to the waiter’s input to make perfect meal (product), I (Customer) would not been able to return home in such festive mode (UX).

In the IT industry’s context, a Business Analyst & a Product Owner often have different deliverables but overlapping roles in an organization. For an enterprise to succeed these variable roles need to work collaboratively across all initiatives to deliver value, RoI.

Role Characteristics:

The BA is an inward looking role with a focus on the requirements and improving an enterprise’s internal processes as a result of a need, change or opportunity. Whereas the Product owner is an outward looking role responsible for realising the product, its vision and defining the evaluation metrics for the product’s success. In today’s competitive environment nobody would bet on success of the Enterprise which is not true to its core, inside and out.

A BA collaborates with various stakeholders to perform documentation/mapping of the processes to enhance efficiency whereas a Product Owner is responsible for product management, marketing, roadmapping, and ensuring the product is aligned to user expectations. If the internal processes are optimized & correctly mapped then a Product Owner would be in a better position to deliver a product efficiently within the timelines. Similarly, feedback loops from end-users & external stakeholders transferred from the Product Owner to the enterprise will help the Business Analyst in reshaping processes with a correct modelling of business dynamics. This will make organizations leaner & customer oriented.

 

Enterprise’s Model:

Often a Business Analyst is expected to work as a Product Owner as well, due to overlapping areas in their responsibilities. After working on the design and approach, a BA is given charge as a Product Owner to deliver the expectations into a real working solution.

Enterprises are very tempted to use these roles interchangeably as the transition path looks seamless. In limited scenario it has been quite successful. However for projects where the risk of failure is intolerable, requirements are subject to change and tight regulation is present, it is a tough challenge to cover both the bases with same resource without impacting the true potential of the product. As with changing circumstances it becomes more crucial than ever to maintain the sight of the business.

More and more organisations realise the face value of their existence is in the survival of their product, therefore after experimenting this model they are moving towards a settled approach which creates opportunities for the BA and Product Owners to work together rather than stretch the capabilities.

 

 

 

Collaboration Value:

Companies want their critical workforce to be agile, objective oriented, smart and product focused to maintain an edge over their competitors. Since the roles of a BA and Product Owner have the same objective, to deliver a product which delivers the desired value to their customer/end-user, the focus has shifted more on channelling these efforts into collaboration.

More than 50% of IT start-ups could not survive their first financial year because they failed to devise a collaboration model not only at individual levels but also at a process level. In absence of a proper handshake between a BA and a Product Owner, the understanding of the requirements remains invalidated. Agile models encourage the iterative collaboration between these two roles because in case of conflicting delivery the cost of the change and effort makes the product less viable for the market strategy. Due to these impacts, our industry is definitely in need of their friendship.

To create the “Rainbow effect” a Product Owner & a BA need to maintain communication, a working collaborative relationship to get to that illusive perfect product. Through their fostered friendship a successful product can be produced which is a recipe for business success in this lean & competitive business environment.

[1]

by Mike Starrs,

Business Analysts Pty Ltd Consultant

 

 

The role of a Business Analyst is broad, but typically it comes down to understanding business needs, value & requirements and assisting business to make informed decisions. These needs are often muddied by a multitude of internal and external factors.  In the end though, the goal is achieving organisational success.  As all organisations exist to provide products and services to customers the best way to achieve success is to incorporate design thinking and human-centred design.

Design thinking is a creative approach to solution-based problem solving that puts people at the centre, enabling solutions that people truly want and need[1].  While not a new concept, design thinking is making a comeback in the business world and producing a number of positive results.  Together with User Experience (UX) and Customer Experience (CX), design thinking lays the groundwork for innovation, development of products and services, and ultimately helps you as a Business Analyst deliver better, stronger and more thorough business analysis.

The main aspect of design thinking is that of a user-centric experience; what is the user thinking and feeling, what is their experience.  Business Analysts already consider these factors, but generally not at the level required to dig into design thinking.  To dig deeper, the Business Analyst must step outside of their analytical mindset (without disregarding it completely) and let their creativity flow.

By understanding the customer journey and experience, we can get clarity on what the real needs are, and options to address them.  Rather than interpreting and explaining what we think our stakeholders need, we can use design to clearly demonstrate what they need through the use of simple language that everyone can understand and use design artefacts to tell the story. When explaining complex issues to a business stakeholder, there’s an increased chance of confusion or misunderstanding if complex (or even mildly complex) approaches are used.  Walking a stakeholder through a complex BPMN is a good example of this. But have you tried simplifying that process into a context diagram that uses simple language and a visual approach to explain the process? By changing the way we communicate complex systems or processes to stakeholders using design thinking, we can turn this interaction into a success. As a Business Analyst, clear communication is a core underlying competency. If we just end up confusing stakeholders, we’re not doing our job.

We have broken our analysis technique into four phases that closely align to design thinking, aligning these to the three phases of human-centred design, and will use this series to explain how the various tools and methods available in the BABOK® can help make your business analysis effort much more effective, adaptive and responsive to a rapidly changing business environment.

Phase 1: Discover – We will look at the Inspiration phase of human-centred design and various BABOK® techniques to understand the current state and help develop a more effective discovery stage.  How can we use design thinking to understand the current state as fast as possible without adding risk?

Phase 2: Refine – Now that you have built a solid foundation and your as-is analysis is complete, how do we transition from Inspiration to Ideation?  How we validate the current state with the business, turn our value streams into epics, iterate our work, and define requirements?

Phase 3: Prototype and Build – At this point we start to look at the future state, what will the to-be processes be, how we move through the Ideation phase.  Prototyping of solutions, iterative building, role-playing and storytelling all play a part here.

Phase 4: Feedback – The Implementation phase of human-centred design, this is where a tangible product or service takes shape.  This phase will often loop iteratively with Build & Prototype, and even back to Refine on occasion.  Here we will be looking at our requirements and user stories to make sure they have been met and fine-tuning our processes to support the finished build.

My view of design thinking is an iterative process to Discover, Refine, Build & Prototype, and Feedback which helps deliver the business need, value and requirements.

 

Phase 1: Discover the current state through Inspiration

 

When we think of discovery, we understand there is a level of uncertainty or a realm of unknowns that we need to identify in order to deliver a successful project.  Unknowns lead to potential roadblocks later with scope creep, failing to properly identify or understand the problem/opportunity, and ensuring a solution is fit for purpose.  Through the use of a few techniques, we can better define the problem up front and ensure we have clear scope for the project.  To do this, there are three key stages a Business Analyst can use to do this well.

Stage 1:  Planning– The BABOK® has a chapter called Business Analysis Planning and Monitoring, so for the sake of brevity I won’t go into too much detail here.  In this stage, the Business Analyst should be laying the foundations for success, by planning the core activities, tasks and deliverables needed, usually in alignment to a schedule.  In the planning stage, the BA should also be performing initial stakeholder analysis activities such as Mind Mapping or creating Stakeholder Lists, Maps or Personas to understand which stakeholders are relevant to the outcome, what the BA requires from them, and the best way to engage with each stakeholder.  An early activity to complete with stakeholders is to identify and prioritise the expected business outcomes for the project.  Use Interviews, Mind Mapping, Value Stream Mapping or Workshops to identify the key business outcomes, and Grouping (high, medium, low) or negotiation to establish the priorities of the business outcomes. These outcomes will play a crucial role later in the project for traceability.

Stage 2:  Current state analysis– A key part of the discovery process is eliciting the current state. What product or services are being delivered to customers.  This is where most of the work should occur in this phase, and relies on a wide range of techniques. The purpose of this analysis is to understand what the intent of the project is, define scope for the project, understand the current processes, and validate everything with the stakeholders.  Current state analysis should always be done, from a new start-up to an existing business or service, there are always unknowns that need to be discovered. Some of the activities you may perform at this stage include:

  • Develop a problem or opportunity statement– Work with the key stakeholders to define and establish the problem in clear and agreed upon terms. This could include a context diagram of the problem, developed in a workshop on a whiteboard, or a mission/vision statement that provides verbal context to why the project is happening.  BABOK® “Business needs are the problems and opportunities of strategic importance faced by the enterprise.
  • Problem statements are about resolving an issue that exists, opportunity statements are about taking advantage of identified opportunities to enhance the organisation.A ‘How Might We’ statement can be used to help develop the problem or opportunity statement, and should ultimately describe an opportunity.  Other techniques available to establish a statement could include Brainstorming and the 5 Why’s.
  • Define a clear scope statement– As part of the same initiation workshop, the Business Analyst should work with the stakeholders to establish clear scope for the project. Use Post-It notes to assist in identifying assumptions, constraints, and dependencies.  Post-It’s can be placed into labelled buckets for anonymity or displayed on a board for all to see.  BA-led discussion should follow to assist in prioritising and establishing the final agreed upon scope.  Scope Modelling or a Business Model Canvas can be created to visually capture and validate scope statements.
  • Prepare for and elicit the current state– There is always a current state, even if the business or service is new & is in start-up mode. What is happening in the market, who are the competitors and what are they doing? These are all valid current state questions.  A successful Business Analyst will have a clear plan and toolkit ready for elicitation. Mind Mapping, User Stories, the use of Personas, Journey Mapping, Value Stream Mapping, and Collaborative Gaming are just some of the techniques available to help elicit the current state from your audience.  The stakeholders, problem or opportunity and scope have been clearly identified in previous activities, now it’s time to conduct your workshops, interviews and other techniques to elicit the current state.

Stage 3: Document the current state –Ensure the processes match products and service offerings.  The use of context models and diagrams, as well as process modelling will help to validate the current state with key stakeholders. The format and structure of the outputs should be agreed with the stakeholders in the planning stage, and distributed for feedback.

By planning, eliciting and specifying a current state, Business Analysts can ensure they are well positioned to capture requirements and develop a future state that is desirable, viable, and feasible for the organisation.  Finding this balance is where innovation generally occurs, which is something we should strive to achieve in everything we do.

 

Phase 2: Refine through Ideation

 

Now that we have defined our current state, it’s time to validate and refine it and start thinking about the future state.  This is where we elicit and prioritise requirements and finalise our scope.  We want to be sure what we’re doing is desirable, viable and feasible, and that we can trace our requirements back to our business outcomes.  There are several stages that can help us refine our work and prepare the Build and Prototype.

Stage 1: Validate the current state –Every Business Analyst should be familiar and comfortable with validation, it’s a core part of the job.  We can use techniques such as Interviews or Workshops and our process models to take stakeholders through the current state and validate that our understanding is correct. There are a wide variety of visual representations and models that can be created to support this stage, the most important part is choosing the right one for your audience.

Stage 2: Requirements Elicitation –Another core activity we’re all used to, we’re now starting to set the stage for our future state through requirements.  Using techniques like the 5 Why’s, User Stories, Epics, Finding Themes, Value Stream Mapping and ‘How Might We’ statements, we can work with our stakeholders to understand their needs and trace these requirements back to our business outcomes.  It is important to make sure requirements have traceability to verified business outcomes, otherwise, how can we be sure they’re adding value to our final product? How your requirements are presented will be determined by the project and acceptable delivery methods, but the techniques you can use will vary.  If you feel one method isn’t producing results, simply try another one or interchange multiple techniques.

Stage 3: Prioritise requirements –Working with your stakeholders, facilitate a workshop and get your audience to determine the priority of each requirement.  By using MoSCoW, 100 points technique, Monopoly money technique or value-based prioritisation, your requirements should all be given an agreed upon priority level during the workshop.  Keep in mind that requirement prioritisation should assess desirability, feasibility and viability in order to find that innovative sweet spot, along with the usual eye on your business outcomes, budget and scope.  Once requirements have been prioritised, they may be grouped into Themes using affinity mapping, and further prioritised and organised into Sprints for a Product Backlog.  With Themes and Sprints, development can be broken down into manageable chunks to achieve key deadlines or milestones more efficiently.

Stage 4: Finalise scope –Through the Discovery phase, work was performed to identify the scope of the project. Requirement elicitation usually captures some things that have been missed and can also confirm previous in-scope items as no longer necessary.  Review the Scope Models or Business Model Canvas that were previously created and validate them against the requirements and business outcomes with your stakeholders.  You may even want to create a quick Storyboard to help visualise scope in another way, and work with the stakeholders to put firm boundaries around the scope of the project.  This is the perfect time to use everything collected during Discover and Refine to ensure there is no scope creep during the development stages of the project.

As you work through each of these 4 stages, you’ll discover a pathway to your solution and future state is already starting to take shape.  The work that has been done throughout Discover and Refine have laid the groundwork for the really creative stuff to begin. Stakeholders have been thoroughly and actively engaged throughout the process so far, and moving into the Build and Prototype phase, they’ll be able to get their hands dirty and drive the direction of the product or service to be offered.

Phase 3: Prototype and Build

 

As we move into the final two phases of using Design Thinking for good Business analysis, let’s do a quick recap of what’s been covered so far.  In Phase 1 we discovered the current state through the Inspiration phase of Human Centred Design, using a range of planning techniques from BABOK® and design-based techniques to elicit, describe and capture the current state.  This strong foundation of knowledge and understand lead into Phase 2 where we used Ideation to look at the ideal future state and started to elicit our requirements.  Using techniques from Agile, Design Thinking and IIBA’s BABOK®, we have been able to create Sprints, wrapped our requirements into User Stories, and developed the product backlog that will take us through to the end of our journey. In the next two phases we will prototype, build, seek feedback, and complete our objective of delivering value through lean and quality requirements to address business needs.

With a full set of prioritised requirements organised in a Product Backlog, commence on finalising the future state process and building prototypes to support the process by transitioning from Ideation to Implementation.  Work on the future state should involve the intended product or service being delivered and how the customer or user will experience it.  How they will interact and use the service or product being created is critical for a successful delivery, and a number of techniques exist to help work this out.

Personas can plan a major role in reaching your destination.  Understanding the different types of users, the demographics of your customer base and what their goals and needs are will be important.  Using these Personas, development of Customer Journey Maps and Storyboards can provide additional tools in developing future state processes and prototypes.  If you have multiple Personas, split off into small groups and brainstorm ideas for each specific persona then re-group to look for common themes.  If your future state is developed enough at this stage, Rapid Prototyping may be used to understand the practical implications of your efforts and work can be undertaken to further refine and develop the product or service.

As your prototypes evolve and refined over multiple iterations, feedback must be consistently gathered to ensure the intended future state process is valid and the product or service remains desirable, feasible and viable.  This can be done through the use of a Build-Measure-Learn loop within the Prototype and Build phase where Concept Models and Prototypes can be used with targeted user groups, observing how they interact with the solution, and adapting changes based on the observations.  Your prototypes are the build, observation becomes the measure, and the outputs from observation become the learning that is then applied to making changes to your process and product or service. By repeating the cycle through a number of iterations until you are happy the process, product and/or service, you can be certain that valuable information is being assessed and implemented as needed to push you closer and closer to success.

Phase 4: Feedback

 

The transition from Prototype & Build to Feedback is not always a clear one and each project will be different. Developing a suitable MVP may be your trigger to move into the Feedback stage and final build, while others may want to spend considerable time with alpha or beta releases in Build & Prototype before they are happy going into Feedback to release a near-final product.

By now you have developed, evolved and refined a number of prototypes, your processes have been tailored, and you’re ready for the final push.  While it may seem like this final phase is repetitive, the intent is quite different to Prototype & Build.  Up to this point you have been working on somewhat of a proof of concept, getting ready for the final sprint to production release, and now you’re almost there.  Feedback is about testing, validation, retrospectives and release.

With requirements encapsulated in user stories in hand, quite possibly with acceptance criteria, thorough testing and validation of processes and product or service can occur.  Acceptance criteria can be used as a baseline for a vast range of test scenarios including system and user acceptance testing. The Product Backlog and requirements will also be used to create test cases and scripts to verify delivery is on track, as expected and defect free.  One method of writing these tests is by creating Given, When, Then (GWT) statements.  These statements are written in the following format:

Given a context or situation, When an action is carried out, Then an expected or specific observable outcome of the action occurs.

Techniques that can be used from BABOK in this phase include GWT and Acceptance Criteria mentioned above, plus Evaluation Criteria, Definition of Done, Process Modelling, and Story Decomposition. Working through Feedback also involves the Build-Measure-Learn loop from phase 3 to continue iterative development. This loop will help ensure testing and the solution is properly scrutinised and vetted, and that it continues to be desirable, feasible, and viable.

 

Conclusion:

 

Design Thinking and Human-Centred Design aren’t new techniques or ideas, and neither are the techniques to support them that have been called out from the BABOK® throughout this series.  What is a more recent development is that Business Analysts can combine these together to go beyond the basics and provide the skills and expertise to work in a rapidly evolving market where the customer is at the centre of everything.  Products often come and go, similar products compete in the market place, but more and more these days we’re seeing that service is a key determining factor in what success is.

By adapting BABOK® techniques and having a Design mindset, Business Analysts will be able to support organisations large and small in guaranteeing that the customer is never forgotten, that processes, products and services continue to centre around customers, and that solutions are built to be desirable, feasible and viable for not only the customer but the organisation delivering them.  The Business Analyst, ultimately, is the key to the innovation organisations are trying to achieve provided they use the tools and techniques available to them to deliver great business analysis.

[1]http://masteringbusinessanalysis.com/mba056-design-thinking-for-better-business-analysis/

Applying Design Thinking and Human-Centred Design to Support Good Business Analysis by Mike Starrs, Business Analysts Pty Ltd Consultant (Phase 3: Prototype and Build)

As we move into the final two phases of using Design Thinking for good Business analysis, let’s do a quick recap of what’s been covered so far.  In Phase 1 we discovered the current state through the Inspiration phase of Human Centred Design, using a range of planning techniques from BABOK® and design-based techniques to elicit, describe and capture the current state.  This strong foundation of knowledge and understand lead into Phase 2 where we used Ideation to look at the ideal future state and started to elicit our requirements.  Using techniques from Agile, Design Thinking and IIBA’s BABOK®, we have been able to create Sprints, wrapped our requirements into User Stories, and developed the product backlog that will take us through to the end of our journey.  In the next two phases we will prototype, build, seek feedback, and complete our objective of delivering value through lean and quality requirements to address business needs.

 

Phase 3: Prototype and Build

With a full set of prioritised requirements organised in a Product Backlog, commence on finalising the future state process and building prototypes to support the process by transitioning from Ideation to Implementation.  Work on the future state should involve the intended product or service being delivered and how the customer or user will experience it.  How they will interact and use the service or product being created is critical for a successful delivery, and a number of techniques exist to help work this out.

Personas can plan a major role in reaching your destination.  Understanding the different types of users, the demographics of your customer base and what their goals and needs are will be important.  Using these Personas, development of Customer Journey Maps and Storyboards can provide additional tools in developing future state processes and prototypes.  If you have multiple Personas, split off into small groups and brainstorm ideas for each specific persona then re-group to look for common themes.  If your future state is developed enough at this stage, Rapid Prototyping may be used to understand the practical implications of your efforts and work can be undertaken to further refine and develop the product or service.

As your prototypes evolve and refined over multiple iterations, feedback must be consistently gathered to ensure the intended future state process is valid and the product or service remains desirable, feasible and viable.  This can be done through the use of a Build-Measure-Learn loop within the Prototype and Build phase where Concept Models and Prototypes can be used with targeted user groups, observing how they interact with the solution, and adapting changes based on the observations.  Your prototypes are the build, observation becomes the measure, and the outputs from observation become the learning that is then applied to making changes to your process and product or service. By repeating the cycle through a number of iterations until you are happy the process, product and/or service, you can be certain that valuable information is being assessed and implemented as needed to push you closer and closer to success.

Have you hired a BA or an SME?

Working for a business analysis consulting company I often come across clients who are looking for BAs with specific industry or solution knowledge. Whether it be Superannuation, Insurance, or software specific such as a certain type of CRM. Each time a filter is applied in the search for the ‘right’ BA, the search results decrease. This isn’t a bad thing, so long as the priority of those filters is applied effectively. If the first filter is the industry knowledge, followed by the business analysis skill set, are you really hiring a Business Analyst or a Subject Matter Expert?

 

The specific industry/solution knowledge may be simple to define. It might be as broad as finance knowledge, or as specific as banking experience focusing on term deposit management using a specific software type. This specificity may be well known by the business.  Business Analysis is a defined skill set, though not always well understood by business.  There are a number of standards, set by governing bodies, that define the knowledge and techniques required to be capable of delivering business analysis effectively.  For a BA to be effective they need to have the right breadth and depth of BA capability suited to your project. The IIBA defines 6 key knowledge areas and a multitude of techniques that are applicable to each of them.  Many, if not all of these knowledge areas are applied to each project. Secondly, underlying competencies, also IIBA defined: cultural fitment including teamwork, collaboration, transparency, integrity etc.

 

When businesses look to engage BAs, all too often they place priority of the industry/solution knowledge, over BA capability with the mind-set that it will take this “BA” less time to get up to speed with the business/solution and therefore be returning value sooner, with less disruption to the people around them. However, in reality unless you have hired someone with good BA capability you have just hired yourself another SME. And this person will apply only what they know to your business, rather than working with embedded SMEs to implement validated and verified solutions.

 

The Business Analyst and the Subject Matter Expert(s) have long had a collaborative and essential relationship.  The SME is of course an expert in a particular area. They hold deep knowledge of the how’s and why’s of the part of the enterprise they work in. They learn this from completing their role day in and day out.  The Business Analysts “enable an enterprise to articulate needs and the rationale for change, and design and describe solutions that can deliver value” (International Institute of Business Analysis 2015, Business Analysis Body of Knowledge v3). I have always believed the BA to be the least knowledgeable person in the room, but the one with the most capability of eliciting the required information from SMEs to deliver well thought out improvements aligned to all levels of the business (strategy to operations).

 

So, if an enterprise has placed industry knowledge ahead of BA capability, what’s the risk? Project success. If your “BA” does not have the capability to work across all levels of the business, collaborating with stakeholders to elicit the business needs, root causes of problems, alignment to business strategy, and be able to articulate this in a way that a developer can code a solution, then the purpose of your project is at risk. Project success is at risk.

 

So, the next time your enterprise is looking to recruit a BA, recruit a real Business Analyst, and let them use their skill set to work collaboratively with your SME(s).

The Paradox of Choice and the Pareto Principle by Henry Elisher

 

Voltaire, a French writer, essayist and philosopher is well known for the saying that ‘[the] perfect is the enemy of [the] good’, meaning that, if you wait to be perfect or wait to achieve perfection then you’ll never get anything done, whilst achieving that which is good, or indeed, very good, is something of worth, especially in the face of nothing at all.

Some of us may reflect on that and ask, ‘well, doesn’t that view just allow us to willingly accept a deterioration in standards’, promoting a type of race to the bottom? To this I would say, if we had the luxury of having a bounty of time, finances, resources and energy then maybe striving for perfection would be both a valiant and noble goal, but our everyday reality dictates otherwise. As business analysts we operate in a world of projects governed by limitations on the resources that we have at our disposal. Aiming for what is good or very good in our world is what commercial entities require and expect of us.

 

THE PARADOX OF CHOICE

In the world that we business analysts reside, within the framework of Western industrialised societies, there is an official dogma that permeates our socio-economic fabric that supposes that if there is a desire to maximise the welfare of citizens, the way to do that is to maximise individual freedom. The extension from that being that the maximisation of freedom is derived through the maximisation of choices.

This central tenet guides all of our decision making and frames the psychology of various spheres or arenas of interaction, specifically in business. In our engagements, within the context of our projects, there is often the desire of the business to strive towards delivering solutions that can do it all, be everything for everyone, have every bell, whistle and toggle imaginable.

The interesting dichotomy between our social reality and the limitations imposed by business is that we, from the outset, seek to do it all, and as business analysts we can, and do, fall into the trap of acting as the agents of these desires. We effectively become the ‘waiters of the business’, running around, taking our orders of requirements, in the understanding that the freedom of the business to choose is paramount to delivering the desired outcome and additionally is paramount to being an effective business analyst. However, this is not the case.

Just as is the case in our everyday existence, when one is overwhelmed by options then we self-inflict our own analysis paralysis. As business analysts if we choose to act as the agents of ‘free choice’ then we too can instigate a type of analysis paralysis where both the decision making and psychology of allowing choices to be made within a set of overwhelming options produces a less satisfactory and less satisfying result, than if there were less options that were more pointed and guided to achieving the outcome of ‘the good or very good‘.

Not only can we inhibit the analytical process by vying to act as a facilitator for everything but we also foster the psychology of dissatisfaction. As business analysts and consultants we have our own duty of care to our stakeholders where we should aim to maximise their aggregated utility of satisfaction by assisting to find ‘best solution’ but not the perfect solution. The ‘best solution’ not being a sum of all requirements possible but rather being the best result within the constraints of the limitation of resources at our disposal. Inclusive within that aim is the management of the satisfaction of our stakeholders. From the perspective of the analyst this means not acting as the ‘requirements waiter‘ but rather being the gatekeep and rationalist driver of change. This means not allowing for a multitude of requirement alternatives to arrive at the bargaining table. We want our stakeholders to be empowered, to feel as though there choices are correct and for them not to be disappointed by having to make decisions that eventually would subtract from the final result or solution (inclusions), even if was a good one.

 

PARETO’S PRINCIPLE – THE 80/20 RULE

There are statistics that show that in software development 45% of the functions developed will never be utilised by users, 19% will be used rarely, 16% occasionally and only 20% will be used frequently or always. It’s an eye opening realisation when considering the resource effort utilised to research, develop and deploy 80% of the entire functionality. It also underlines how the paradox of choice underpins exactly what the principle states, the freedom of choice given to providing a solution undermines the development process of what is core to a solution.

The Pareto principle can be applied in almost any field of life, essentially promoting the thought that 20% of efforts will lend itself to finding 80% of the results. As business analysts this is a principle of significant importance as it can direct our focus to the areas of criticality when we are in our research gathering and requirements establishment mode.

Especially in environments that are Agile centric, the principle is one that a business analyst can use to drive both their focus and drive the entire team effort. Understanding that 20% of the given solution will contain 80% of the stakeholder and customer driven change, or that 20% of the user stories (functional work) probably contain 80% of the value, the business analyst can shape the work path to formulating an MVP (Minimum Viable Product) or MUST (Minimum Useable Subset). It’s a strategy that allows for the harnessing of limited/constrained resources and focusing it on the 20% of the functionality that is going to secure the greater part of the value for the stakeholder/customer.

It’s the utilisation of this strategy as a business analyst and consultant that allows to us to act as the fulcrum of change especially in environments where the freedom of choice inhibits the ability to quickly get to the core aspects of what the solution needs to achieve and how it needs to be developed.

It’s the art of understanding how to achieve the good, or the very good outcome that will prevent what may have been inevitable ‘analysis paralysis’ where the desire to have everything either achieves nothing or achieves a sub-standard result. If the aggregate utility of your stakeholder or customer is maximised by achieving a good or very good outcome as bound by the constraints of a business project, then it will beat a non-existent ‘perfect’ result every single time.

Our secret is not chaos or the latest fad but connecting business acumen with business analysis skills, techniques & competencies that fit the business need & its customers. Business strategy is about improving an organisation through requirements change. Business analysts know this well within our profession, using our own vocabulary for change, moving from “as is” to the “to be”.

Applying Design Thinking and Human-Centred Design to Support Good Business Analysis by Mike Starrs, Business Analysts Pty Ltd Consultant (Phase 2: Refine through Ideation)

Phase 2: Refine through Ideation

Now that we have defined our current state, it’s time to validate and refine it and start thinking about the future state.  This is where we elicit and prioritise requirements, and finalise our scope.  We want to be sure what we’re doing is desirable, viable and feasible, and that we can trace our requirements back to our business outcomes.  There are several stages that can help us refine our work and prepare the Build and Prototype.

Stage 1: Validate the current state – Every Business Analyst should be familiar and comfortable with validation, it’s a core part of the job.  We can use techniques such as Interviews or Workshops and our process models to take stakeholders through the current state and validate that our understanding is correct.  There are a wide variety of visual representations and models that can be created to support this stage, the most important part is choosing the right one for your audience.

Stage 2: Requirements Elicitation – Using techniques like the 5 Why’s, User Stories, Epics, Finding Themes, Value Stream Mapping and ‘How Might We’ statements, we can work with our stakeholders to understand their needs and trace these requirements back to our business outcomes.  It is important to make sure requirements have traceability to verified business outcomes, otherwise, how can we be sure they’re adding value to our final product?  How your requirements are presented will be determined by the project and acceptable delivery methods, but the techniques you can use will vary.  If you feel one method isn’t producing results, simply try another one or interchange multiple techniques.

Stage 3: Prioritise requirements – Working with your stakeholders, facilitate a workshop and get your audience to determine the priority of each requirement.  By using MoSCoW, 100 point technique, Monopoly money technique or value-based prioritisation, your requirements should all be given an agreed upon priority level during the workshop.  Keep in mind that requirement prioritisation should assess desirability, feasibility and viability in order to find that innovative sweet spot, along with the usual eye on your business outcomes, budget and scope.  Once requirements have been prioritised, they may be grouped into Themes using affinity mapping, and further prioritised and organised into Sprints for a Product Backlog.  With Themes and Sprints, development can be broken down into manageable chunks to achieve key deadlines or milestones more efficiently.

Stage 4: Finalise scope – Through the Discovery phase, work was performed to identify the scope of the project.  Requirement elicitation usually captures some things that have been missed, and can also confirm previous in-scope items as no longer necessary.  Review the Scope Models or Business Model Canvas that were previous created and validate them against the requirements and business outcomes with your stakeholders.  You may even want to create a quick Storyboard to help visualise scope in another way, and work with the stakeholders to put firm boundaries around the scope of the project.  This is the perfect time to use everything collected during Discover and Refine to ensure there is no scope creep during the development stages of the project.

As you work through each of these 4 stages, you’ll discover a pathway to your solution and future state is already starting to take shape.  The work that has been done throughout Discover and Refine have laid the groundwork for the really creative stuff to begin.  Stakeholders have been thoroughly and actively engaged throughout the process so far, and moving into the Build and Prototype phase, they’ll be able to get their hands dirty and drive the direction of the product or service to be offered.

Phase 3: Prototype and Build – Is coming soon!