Tag: Tools

Mind Maps for Business Analysis

Written by Jenny Quillian on October 18, 2019. Posted in Articles. 74 Comments on Mind Maps for Business Analysis

The purpose of this article is to demonstrate the use and benefits of Mind Maps for business analysis.

The 5W mind map uses the journalists’ five questions (Who, What, Where, When, Why) plus How to provide a template for a business analysis guide that can be used through the project lifecycle.

This technique is the first action I take for every new project, giving me a project overview that is then used as a check list and visual reminder during the course of the project. I use a free download version, but there are many mind mapping tools available and the paid versions offer more sophistication for presentations and integration with other project tools. (The mind map tools provide the ability to embellish your view with markers, images, colors and labels, but beware of drowning your big picture in a pool of emoji’s).

The diagram below shows the 6 major topics, and the initial round of sub-topics for each. The choice of sub-topic may vary with your project or your own area of responsibility.

USAGE BY KNOWLEDGE AREA

The mind map will grow and change during the course of the project and can be used under each of the BABOK knowledge areas as follows:

Business Analysis Planning and Monitoring
- At the start of each project, create a new mind map to organize and coordinate plans for the analysis tasks
- Add information from the project proposal to each topic
- Use the mind map tool to expand the sub topics as knowledge is gathered
Strategy Analysis
- Identify stakeholders and project partners under Who
- Record the high level business case under Why
Elicitation and Collaboration
- As requirements are gathered, add the high level business requirements and business rules under the What topic
- Record sizing and usage estimates against Who, How or What
Requirements Lifecycle Management
- Use the mind map during the course of the project to maintain focus on the high level requirements and to reinforce relationships between and justifications for requirements
- Use to analyze proposed changes
- Print out the mind map and pin to your wall or the project war room for all to see, especially during team discussions when members need to be anchored
- Refer to the mind map when developing presentations to stakeholders and project teams to maintain consistency over long projects
- Update the mind map during the course of the project, maintaining version numbers
Requirements Analysis and Design Definition
- Validate the requirements against the other project topics
Solution Evaluation
- Identify key aspects of the solutions and delivery methods under How
- Record implementation locations and delivery sites under Where

USAGE BY TOPIC

Each topic provides an opportunity for the BA to start shallow and take deep dives. Add all findings as you go – but do not hesitate to remove or edit as new facts or requirements are discovered.

Who – Stakeholders and Project Partners

The key stakeholders of the proposed system should be identified in the project proposal, but stakeholders are also uncovered during the life of the project. An example is downstream consumers of the product or data being delivered. User estimates can be noted against active and downstream users.

Making a note of the executive sponsors and influencers serves as a flag to follow up when there is an organization change or an executive mind shift. How will that affect your requirements? The BA should be aware of other partners such as Finance, delivery team, and the planned support team as potential influencers of the system requirements.

What – Requirements and Business Rules

Detailed requirements and user stories should be left out of the mind map, but they should map back from your requirements management tool to the mind map. The requirements in the What topic serve as a guide and constraint on the detailed requirements. There should be sufficient information so that the mind map is a stand-alone overview for when you are faced with an executive in the elevator asking what this project is about.

Where – Locations

The Where may prove to be not significant for a particular project, but including this in your initial template provides the opportunity to consider first then ignore – rather than ignoring first. Will the infrastructure be hosted in a public cloud or in-house servers? Will there be international users? Will the support be local or outsourced. The requirements must cover these variables. The delivery variables

When – Project Timelines

Making a note of the high level project timelines at minimum completes the overview of the project, but this branch may also include requirements analysis plans, sprint plans, and/or key business event dates.

How – Solutions and Methods

The Business Analyst is not responsible for technical solutions or project methodologies, but these may have an impact on requirements, and therefore the BA should be aware early of technical decisions such as COTS or Build, In-house or Outsourced, Agile or Waterfall. Record just enough information to show how the technical project decisions support the requirements. Sizing estimates should be recorded here because the technical solution should be compatible with the expected traffic and data volume on the system.

Why–Business Case

Recording the high level justification for the project provides another guideline reference for the business analysis work, and red flags during requirements analysis.

BENEFITS

The following section lists benefits from using mind maps for project and requirements management. In addition, I find them just fun to use. I was hooked on mind maps from the day our new Director introduced himself to the team through a colorful and informative mind map of his resume and interests.

Generate discussion and ideas. The loose structure of the visual and the flexibility of the software work together to open minds and to overcome reluctance to offer ideas and changes.
Multiple perspectives. The mind map shows horizontal and vertical perspectives. The drill-down design allows viewers to see big pictures and their underlying details in a single view. Discussions can go down rabbit holes into the detail but the presenter has a tool to bring them back to the shared big picture.
Highlight relationships. The central positioning of the major topics in the 5W template provide the horizontal perspective, and makes the viewer think about the relationships between topics. How does the project methodology impact the requirements delivery? Do the requirements match the business case? Do the requirements reflect all locations and stakeholders?
Easy to recall. Mind maps create a visual representation of your project, and the picture really can be worth a thousand words. Visuals are easier for memory retention than pages of words.
Enable change. Today’s software development environment is short and agile. The BA operates in an environment driven by change, disruption and transformation. The 5W mind map enables free thinking within defined boundaries, and also provides an impact map to assess shifts and changes.

SUMMARY

The 5W mind map is a useful tool for requirements planning and management. The starting topics of Who, What, Where, When, Why and How provide a check list when collecting requirements and a reference during the life of the project.

The attached file presents an example of a 5W mind map for a hypothetical project to provide digital signage at local swimming pools.

EA and ContinuousNext

Written by Steve Else on October 18, 2019. Posted in Articles. 1 Comment on EA and ContinuousNext

The Enterprise Architecture Ecosystem continues to evolve in interesting ways.

For example, we could almost speak of EA meaning Ecosystem Architecture in terms of all the potential players, themes, etc., tied to different contexts for doing Enterprise Architecture. We need to look at partners in manufacturing, supply, and logistics scenarios, just as we need to look at potential M&A partners.

But we also need to consider how EA facilitates collaboration between the many varied roles essential to build strategy, scope work, define ultimately comprehensive requirements iteratively and with agility linked to incremental delivery of value. Enterprise Architects must work with Solution Architects, Portfolio/Program/Project Managers, Agile Development Teams, Systems Engineers, and Operation and Maintenance specialists.

Also considering the velocity of changes in business models and technologies, EA must have a major role in innovation and as an overall Center of Transformation Excellence, whether driven by technical debt or trying to double the revenue of the enterprise in 5 years!

At the latest Gartner ITxpo in Orlando, Florida in October 2018, Gartner thought leaders introduced the concept of “ContinuousNext” after a few years of beating the Digital Transformation drum. EA has a major role to play in ContinuousNext, but only if it becomes a much more mature discipline, more of an Overall Architecture one that can best shine the light on the opportunities of Mastering the Architecture Landscape in all its dimensions.

To become more mature, architecture roles and roadmaps need to be further clarified and better understanding of enablers needed play the roles and execute the roadmaps are essential — EA approaches, tools, and techniques must become better integrated and then accelerators to value. EA must be perceived as Essential Value Added across all priority Value Streams in the relevant ecosystem, so Key Performance Indicators linked to such an outcome must be defined aggressively.

What Gardening can Teach us About Process Analysis

Written by Alan Gibson on September 5, 2019. Posted in Articles.

In August this year I was informed by my better half (sponsor/programme manager/project manager) that we were going to re-do part of our garden.

It wasn’t a big job, compared to the overall garden, however a border of around 15 feet long and 4 feet wide was to have the bushes and plants removed, stone and membrane lifted, sieve out the rubble from the existing soil and replace with fresh compost.

To finish this off we would fill the space with colourful flowers, which we would maintain on a regular basis (TOM)

Having worked in change for over 12 years, the planning kicked in straight away, which jobs would be done in which order, when were the best days to tackle the jobs etc etc. This was met with initial resistance from the Sponsor, however through careful stakeholder management an approach was agreed, which met our shared vision.

As we progressed, I couldn’t help make the comparisons with uncovering and analysing processes which form such a large part of the Business Analysis role.

It wasn’t until we started lifting the existing membrane that we started to understand the size of task that we had set ourselves. Our initial analysis had underestimated the resource (time) required, and as I was dealing with a very difficult stakeholder, I knew a re-plan was not on the cards. The only option was to proceed at risk.

Let’s consider the existing bush/plant roots as historic processes which underpin the product, the bush or plant. The newer plants/bushes had shorter roots, not as tangled with other roots (inter-dependencies), they had been planted in a logical fashion with more soil preparation. As such these roots were easier to find and remove.

These are comparable to well designed, fully documented processes that align to a Target Operating Model and have a clear owner. The analysis of these is often through the existing artefacts, seeking support from SMEs only when required.

The older bushes however had deep roots, entwined with multiple other roots and the more you dug the more you found. They had been planted over many years, with different aesthetic objectives. Being younger at the time we didn’t spend much time preparing the soil, nor considering how big the plant may grow. They were planted for immediate impact as opposed to forming part of a wider vision.

This category is comparable with historic process, the kind where only one colleague exists across the whole business who has a partial view of the process. There is no existing documentation, no owner and utilisation of the full BA toolkit is required to piece together the process.

Faced with this gardening challenge there were two possible approaches, brute force trying to rip out the roots as quickly as possible, or carefully digging up the roots, using every gardening tool in the shed, to ensure you have it all.

Although the first option would allow me to meet the expectations in terms of time, the quality, and therefore the benefit, would be greatly lacking. The problem with the first option is that you end up with soil filled with broken old roots. The new roots (processes) will struggle to develop as they keep crashing into the remnants left behind. Although the old roots are broken up, they can still use shared resource (water, nutrients) if left in place. The same can be said for processes. Not fully identifying a process that is to be replaced will result in colleagues, on occasion reverting to that process.

At heart business analysts are driven by quality and benefit. We want the end goal or product to make our customers lives better. Sometimes either the complexity of the work, the effort required or the wishes of stakeholders can try and push us of course. However, if your aim is for a garden of roses there are no quick solutions, it’s a case of using all your knowledge and available tools to ensure you reach the required result.

Feeling overwhelmed with the task at hand, I used one of the most important BA tools, seeking guidance from someone with more experience who would understand the challenges and help define a strategy that would both satisfy the stakeholders whilst ensuring the quality of the deliverable. In this case it was my Mum.

I have avoided the other Business Analyst comparison with gardening, which is, to get to the end deliverable we often spend many days knee deep in manure!!

Why Agile isn’t Enough Part 4: Lean Startup Learn Phase and BA Techniques that Enhance it

Written by Richard Larson on July 8, 2019. Posted in Articles.

In previous parts of this article, we covered an overview of Lean Startups and its Build-Measure-Learn (BML) methodology.

We also explored the Build portion of the cycle, the first step in a Lean Startup. Another article examined the Measure phase of the methodology, which can provide the measures to learn if our product is on the right track.

Lean Startup was created by Eric Ries and detailed in his seminal book The Lean Startup published in 2011. Lean Startup helps to guide product development, whether in established companies or startups. It is designed to shorten product development time, helping us deliver products and their features that customers need, not just what they tell us they need.

In this part we’ll examine the remaining portion of the B-M-L cycle, Learn.

LEARN

After building a product or features, the second part of the Lean Startup method is measuring how a product is adopted and used. That phase is covered in part 3 of this series. Metrics should be meaningful and should allow us to measure our learning and progress towards goals. Essentially, a Lean Startup grows when meaningful measurements are obtained and then “validated” to provide the learning needed. Validated metrics are those we can learn from to make needed additions, changes, and even “pivots,” which we’ll get back to.

Validated metrics are those we can learn from to make needed additions, changes, or even “pivots.”

3 Things to Learn

Learning is the key to a successful startup, whether that startup is a product or an entire company. Here are 3 important things we need to learn according to the Lean Startup method1:

What customers really need and want, not just what they say they do (in Business Analysis, we constantly strive for that, right?).
Which elements of our strategy are working (or not). That helps the team to maintain the strategy or modify it.
Whether we’re on the right track to delivering a viable, sustainable product or business. If we are on the right track, we persevere; if not, we need to pivot.

And we’re not just talking about any old learning. We need any learning to be validated: backed by empirical data, which results in more useful truths and actionable information than traditional market forecasting or business planning. Validated learning is our best ally in testing and challenging assumptions and pre-conceptions.

Persevere or Pivot?

This question is perhaps the most important one for a Lean Startup. Returning to our B-M-L cycle again in Figure 2 we need to learn if our target metrics are moving our product towards the goals in the initial vision or not.

If the metrics show we are moving toward the goals, then the startup can and should persevere.
If the metrics are not moving us close enough to the target, we can design new experiments to test possible new features. Maybe we were testing the wrong thing. But failing that, or if we cannot generate new hypotheses, it is time to pivot – either by changing the product or to cancel it outright. I can attest that is a difficult decision having had to make it more than once.

Figure 2: Persevere or Pivot in Lean Startup

Examples of Pivots: The Importance of Learning

Did you know that YouTube began as a video dating service with a slogan of “Tune in, hook up”? It did not grow as they had hoped until they discovered the appeal of a general video sharing service they are today.
Groupon started as a platform for rallying people to social and charitable causes but started to fade after some initial success. They added a subdomain that pooled people together to receive discounts and that feature proved far more popular.
In 2004 Yelp was a service where friends could ask each other for direct recommendations for things, which was not moving the company towards their goals. When they learned users were writing reviews for fun, they pivoted to focusing just on reviews that is their business today.

Learn/Decide – 9 Techniques

Besides the Business Analysis techniques to facilitate learning, I’m including techniques in Figure 3 to help with decision-making. That is because the “persevere or pivot” decision is the most important one a startup must make. Business Analysis skills such as facilitation can greatly assist during “pivot or persevere” meetings. Eric Ries suggests startups hold these roughly every month or two1. A suggested focus of these meetings is to review the relevant metrics against hypotheses and consider alternatives.

Figure 3: Techniques for Learning/Deciding

SUMMARY/KEY POINTS

In summary, we’ve seen several ways in which Business Analysis can help fuel a lean startup.

Lean startup methodology relies on the Build-Measure-Learn cycle. It is focused on learning and delivering on what customers really need vs. what they say they do. What could be more important?
Building – focus on finding “problems worth solving” and start by building an MVP, which is the fewest trips through the B-M-L cycle to build a product that provides the most validated learning.
Measuring – valid measurements are the unsung heroes of a successful startup. Without valid measures we can’t learn as quickly or maybe not at all. Remember to avoid “Vanity Metrics” and collect “Metrics that Matter” using AAA metrics –Actionable, Accessible, and Auditable. They are essential to learning what customers need.
Learning – is the acknowledged key to making Lean Startups succeed. We need to learn what customers really need and want, not what we think or what they tell us. We also use that learning to facilitate “persevere or pivot” sessions.
Techniques – there are several proven, standard Business Analysis techniques that can help at every stage of the Build-Measure-Learn cycle. Not an exhaustive list to be sure, but we covered 20 of them and have a summary of the 20 as a free downloadable “template” available on https://www.watermarklearning.com/resources/templates.php.

Finally, if Build-Measure-Learn is the central engine driving a Lean Startup, then Business Analysis techniques and skills are the fuel for that engine. Accordingly, Lean Startups represent an exciting future for those of us who practice Business Analysis.

[1] Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, New York: Crown Business Books, 2011

[1] 5 Big Brands That Had Massively Successful Pivots¸ Published February 15, 2018. Downloaded June 12, 2019. https://www.entrepreneur.com/article/308975

Why Agile isn’t Enough Part 3: Lean Startup Measure Phase and BA Techniques that Enhance it

Written by Richard Larson on July 3, 2019. Posted in Articles.

In previous parts of this article, we covered an overview of Lean Startups and its Build-Measure-Learn (BML) methodology.

We also detailed the Build portion of the cycle, including the Minimum Viable Product and its importance to the Lean Startup approach.

To summarize Lean Startup, the method was created by Eric Ries and detailed in his groundbreaking book The Lean Startup[1] back in 2011. Lean Startup can guide product development, shorten development cycles, and help us deliver the products and features customers need, not just what they tell us they need.

In this part we’ll examine the next portion of the B-M-L cycle, Measure and why it is crucial to success.

MEASURE

After building a product or features of a product, the second part of the Lean Startup method is measuring how that product is adopted and used. Tools such as focus groups and surveys are useful measuring tools. But beware of over-relying on them since focus groups only reveal how people feel and surveys only tell us what they think.

Beware also of so-called “Vanity Metrics” since they tend to make us feel good and don’t lead to the kind of learning we need. These metrics tend to be easy to capture, such as number of users or site visits, and may show false progress. For example:

The number of visitors to a web site is easy to measure and seeing an increase after a product launch feels good.
Let’s say your team uses a strategy of offering a free version of a product to attract potential paying customers. A large spike in new product users is a vanity metric since it masks how people like the product or how likely they are to become paying members.

Instead, we need to find what I call “Metrics that Matter.” Those are usually harder to obtain, but typically more meaningful. For the above two examples:

Measuring the number of site visitors who return to the website and how quickly they return is harder to measure but gives a better sense of meaningful customer interest.
Tracking the free members who convert to paying customers is harder than just measuring the new members. But those conversions are a much more meaningful measurement – just ask any digital marketing person about the importance of conversions.

To focus on metrics that matter, Eric Ries suggests we use AAA metrics¹, which are:

Actionable – these must prove a clear cause and effect otherwise they are vanity metrics. They should also be significant enough to base a decision on. Example: discovering a new feature that is not used much and then dropping it or deciding not to enhance it.
Accessible – the product team needs to be able to access the measures to gather, analyze, and learn from them. For example, Google Analytics is useful for web site measurements and is highly accessible. But, that tool can provide plenty of vanity metrics such as number of site visits per month. More significant would be to measure the number of people returning in subsequent months and then doing “cohort analysis” on groups of returning customers using Google Analytics.

Find AAA metrics:

· Actionable

· Accessible

· Auditable

Auditable – ensure the data is credible and can be verified. Often this means spot-checking the data with real customers. Auditable also means to keep reporting processes simple, preferably with data directly from operational data (vs. manual manipulation). What this means is that the process by which measures are obtained is simple and can be independently verified. Example: surveying customers directly to verify their purchase decisions.

Measure – 9 techniques

Figure 1 below shows a list of nine standard Business Analysis techniques that will assist in the Measurement part of the B-M-L cycle. In addition, below are two that are not yet in the IIBA or PMI standards, but are still important in the Measuring phase

Cohort Analysis – important for a startup to track how groups of related customers or customer segments are acquired and retained. Cohorts can help us determine which features will be valued by different segments. Google Analytics has a new cohort analysis tool that can help. Cohort analysis is like the use of personas which group users by various characteristics. But the two differ in that cohorts are established by their current and past behavior, not by projected traits, and we can measure cohort behavior.

A/B Split testing – is a simple and effective way to run an experiment to learn which features are used, which marketing messages appeal better, even which kinds of web pages are more effective at promoting a product.

Two test groups are given different product versions to see which group adopts and uses which version to determine the one that is most effective. The differences are usually controlled to see which feature(s) made the biggest difference. Often the versions are tested in a live, production environment to not slow down progress.

It is not an official technique in any BA standard but is referred to as part of experiments.

Figure 1: Techniques for Measuring

In summary, the Measure stage of the Lean Startup methodology lays the groundwork for us to learn what worked and what didn’t with what we built. The measures and the learning from those measures are what separates an ordinary Agile effort from a Lean Startup. I also feel the “M-L” work we do contributes to greater – and faster – success with products we release than with typical delivery cycles.

Some important facets to remember about measuring are to avoid “vanity metrics,” which are easy-to-capture measures that are inclined to make the team feel better about making progress. It is far better to discover “metrics that matter” using AAA metrics –Actionable, Accessible, and Auditable. These are often harder to obtain but will enable the greatest learning.

Speaking of learning, the final part of this series covers the Learn portion of the B-M-L methodology of Lean Startup.

[1] Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, New York: Crown Business Books, 2011