Skip to main content

Tag: Business Analysis

Strategy Spotlight: 8 Tools & Techniques to Apply to Strategic Analysis & Planning

Written by Richard Lannon on . Posted in Articles.

There are many definitions, tools, and techniques that can be applied to strategy analysis. If you do an internet search you will find all sorts of options available. The challenge is selecting the best approach, tools, and techniques to use given the business problem or opportunity.

Another part of the challenge is understanding what strategy analysis means since there can be many definitions. This can make it confusing. It is best to simply say that strategy analysis is an approach to facilitating, researching, analyzing, and mapping an organization’s abilities to achieve a future envisioned state based on present reality and often with consideration of the organization’s processes, technologies, business development and people capabilities. Part of that whole process is the ability to bridge gaps that exist between the strategic, tactical, and operational aspects of the organization. This requires a look at the present state, the future state, risk and financials and the creation of change requirements to achieve the desired outcomes.

Related Article: Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

Even though the definition of strategy analysis varies, there is common thinking on the key planning requirements.

  • Preparation for planning through the identification and review of information relevant for strategy analysis
  • Performing high-level environmental scan looking at the internal and external business environment with consideration for mission, vision, stakeholders, structure, existing plans, people profiles, and question responses.
  • Applying a choice of different tools and techniques to analyze the present state of a business environment and mapping out its future.

Some of the more common analysis tools and techniques include:

VMOST: This stands for Vision, Mission, Objectives, Strategy, and Tactical.

Success in an organization happens with top-down or bottom-up alignment. I was recently reminded of is when working with a client who stated that their tactical is not connected to the strategy. VMOST analysis is meant to help make that connection.

SWOT: The standard analysis tool, defined as Strengths, Weaknesses, Opportunities, and Threats.

Strengths and weaknesses are internal to the organization, opportunities and threats are external. SWOT requires you to be candid and provide an honest assessment of the state of things. It forces you to create a dialogue with stakeholders to get different viewpoints. Eventually, you focus in on the key issues.

PEST: This is a great tool to use in tandem with SWOT. The acronym stands for Political, Economic, Social and Technology.

PEST reveals opportunities and threats better than SWOT, the direction of business change, projects that will fail beyond your control, and country, region and market issues through helping you create an objective view.

SOAR: This stands for Strengths, Opportunities, Aspirations, and Results. This is a great tool if you have a strategic plan completed, and you need to focus on a specific impact zone.

I used SOAR to help a business that needed to focus on their business development requirements due to an external market change. The organization needed to discuss how they would recapture lost sales by $1 million per month to ensure they maintained their profitably. Given that they had already done everything they could to cut costs and operate a lean business, the SOAR was critical in helping define the focus for the next 12 to 24 months.

Boston Matrix (product and service portfolio): This tool requires you to analyze your business product or service and determine if it is a cash cow, sick dog, questionable, or a flying star.

I have applied this tool to product and service reviews with to help make product decisions with consideration for market share and market growth. But it has no predictive value, does not consider the environment, and you need to be careful with your assumptions. It does force discussions on your present offering and whether it makes sense to maintain or enhance those offerings. For example, maybe you are holding onto a business product that you love but is really a sick dog and maybe there is a cash cow in your business that you are not optimizing. A decision has to be made.

Porter’s Five Forces: This tool helps you understand where your business power lies in terms of present competitiveness and future positioning strength. It forces you to analyze the bargaining power of suppliers and customers, the threats to new entrants and substitutes, and competitive rivalry in your marketplace. Using this tool helps you understand the balance of power and to identify areas of potential profitability. According to Porter, this model should be used at the line of business level.

Maturity Models: There are many maturity models that can be applied to a business. From the evolution model, the technology model, to the team model. The idea is that every business or department goes through a maturity cycle. The standard cycle is chaotic, reactive, proactive, service, and value. If you were looking at processes in a department, you would look to see where that process is on the continuum. Then you would determine where you need to be and what it would take to get to that point of maturity. This is a simple explanation. When using a maturity model, it is important that you have a clear problem definition and solution context.

Root Cause Analysis: This is important, as there are times in the strategy analysis process you need to dig deeper into a problem. This is where RCA is used. The key is that you need to identify and specify the problem correctly, analyze the root cause using a systematic approach, verify the causes, and determine the corrective actions. Implementation of the corrective action is extremely important.

There are many definitions, tools, and techniques that could be addressed. The ones mentioned here are only the tip of the iceberg for strategy analysis and become a foundational part of the strategy analysis toolkit. In a short blog, there is no way to mention them all. But you could create a tool checklist that you could use in your next planning and analysis engagement to help you and your team define the present, future, risk and change state that you need to succeed.

Until next time, be your best, invest in the success of others and make your journey count.

Richard

Check out Richard’s workshop at Project World * Business Analyst World Toronto on Thursday, May 12 – “Strategic Business Analysis – Techniques to Uncover and Define Business  Need“

Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

Written by Richard Lannon on . Posted in Articles. 1 Comment on Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

While waiting at a gate for the next available airplane at an airport, I met a fellow business traveler. We started talking about business and what we did for a living. He was a COO (Chief Operations Officer). So I asked about their planning process, what it means to be strategic and the common challenges he had witnessed. He opened up like a child that couldn’t wait to be heard. The conversation lead to eight common mistakes made in strategic planning.

1. Not knowing what it means to be strategic

Not everyone knows what it means to be strategic. To be strategic means you have to get clear on the future you want (future state), where you are at today (present state) and where you came from (past state). With that in mind, strategic planning looks to the future state and works its way backward to the present state.

2. Inappropriate use of the word strategic

Knowing the difference between a strategic and tactical discussion. Confusing things like marketing, people approaches, or technology with strategy. A value proposition, improved human resources, or technology integration is not strategy. These items are usually elements of a larger plan often requiring analysis and decisions by company representatives to determine solution options and to achieve the strategic results required.

Related Article: Strategy Spotlight: 4 Parts of the Strategic Planning Process

3. Poor upfront preparation

We both agreed we see this one all the time. Someone says let’s do some strategic planning. They get a group of people together, go into a room, and use their preferred approach and develop a shopping list of tactical items that go nowhere. A poorly planned or guided planning (requirements) workshop was executed. Don’t make this mistake.

Strategic planning means you need a planned approach that is appropriate for your department or company. It is not one size fits all. I have a standard engagement approach, but it is adaptable relative to the client needs. Sometimes preparation could take up to 3 times the actual session time. This is especially the case in complex situations requiring a lot of preparation and communications.

4. Let’s look at last year’s plan

Looking at previous years’ plans at the wrong time can bring you down a rabbit hole where dialogue leads to nowhere. Mostly you end up re-hashing old items. There is an appropriate time to review previous year plans, but generally, it is not when you are embarking on future think.

Consider using the old plan as a historical document and a business artifact. Scrap what you did before and start again to discuss the future and then later bring in the now and old plans.

5. Not asking the right questions

Lots of people are not comfortable with asking questions, especially the right questions. Often the questions you ask are specific to the tool or technique you choose to use in your strategic planning process. There are natural questions that come out of a SWOT, PEST, SOAR, APAE, or from TTY (tomorrow, today, yesterday). The key is to focus your efforts on a specific area, use the best tool to address your concerns and develop a set of questions around that focus area.

6. Playing with your belly button

This is also known as navel-gazing. The mistake most often made is putting your attention on you. Dialogue needs to be focused away from the self-indulgent or excessive contemplation of oneself or a single issue, at the expense of a wider view. Things that are strategic can’t be mixed with tactical items. Items need to be categorized as strategic, tactical or operational.

7. Missing external world issues

By spending too much time on internal issues, you will miss the outside world impacts and opportunities.

Strategy means that your need to find ways to improve and move ahead no matter what is happening in the external business environment. We have all experienced good times and bad times. That is the natural course of the economy. You may have to change your business, try new things or potentially alter your business model entirely to achieve your strategic vision. This will come from having an outside-in view of your business.

8. Losing your imagination

This is the thinking by people that their product won’t change much because it is a bunch of plastic and metal. Therefore, there is not much they can do. If you hear this statement, you need to make some adjustments quick.

An option is to establish creative teams and have them answer the question, how could the whole market be served better in the future. Creative teams’ imagination generates scenarios and solutions for an organization whom product and thinking has matured. Strategic leaders leverage the creative minds and the imaginations of others to create options for tomorrow.

This was a great conversation to have. It was nice to get someone else’s perspective on the challenges in strategic planning. You just never know what you will discuss with a stranger at an airport. We both agreed that strategy is a long game – that it required overcoming some common mistakes.

Almost all business leaders tell me that their greatest asset is their people. If that is the case, with a little upfront work and guidance people can move their thinking from tactical to strategic and beyond the present state.
Invest in the success of others and make your journey count.

Richard

An IT BA on a Cross-Functional Technology Team

Written by Janet Walker on . Posted in Articles. 1 Comment on An IT BA on a Cross-Functional Technology Team

If you, like me, have spent most of your BA life sitting amongst other BAs or inside a cluster of business partners, you can appreciate the “shock and awe” I experienced moving into a workspace filled with engineers and QAs.

Half of our IT team re-orged into system-specific cross-functional teams. The business analysts combined with the QAs, system engineers and even a database engineer (DBE) or two to form a cohesive group of support, brainstorming and execution. I went through this transformation last year and can say the experience has been nothing less than eye-opening.
Keeping the engineering side of your business in focus is important for any BA, but when our business wants to turn left and our engineers – developer, programmers, DBEs, etc. – are diligently working on how to use the latest technology to turn right, we find out how painful it can be!

The engineers (I lovingly refer to them as my Geeks) are as committed to driving our business as I am and are always looking for the inches of improvement around us. Suddenly, the total commitment to our business partners involves some tough choices for me, the BA.

One day I’m in a devoted business partnership, the next day I’m in a devoted partnership of driving the business during system upgrades and failovers!

The first thing that shocked me on the Geek-filled team was finding out I was actually skating on thin ice all those years as I was driving our business forward on top of new technology. Yes, I understood how the system worked and what some of the possibilities were, but all that time the engineers were looking for better ways and innovating like crazy. Suddenly, I understand why the engineering response to my change requests was often “WHAT?”, “WHEN?”, “WHY?” and sometimes “Wait!” I was driving the business on top of a system or systems the Geeks were constantly improving. Understand, our company culture is deeply ingrained in all team members, but sometimes during those days as a business BA I wondered if the Geeks and I worked at the same place. Getting on the same page, or not colliding on the same page, was the source for a LOT of discussions, but, the real challenge had been making the business better on top of the ice and how to make the system better below.

{module ad 300×100 Large mobile}

The second “wake up” moment was when I spent the first month with my Geek team and realized we had been meeting and making decisions over the years while saying the same words and meaning completely different things. For example, I have used the term Doc Type for about 14 years and never knew the engineers supporting my system have been mentally translating it to Doc Type Number. Only when I physically joined their world did I hear the comment from one to another “She means the number.” A simple difference, but really got me thinking. Geeks talk differently. In my part of the world, they speak English, but a different kind of English. There I was, thinking I was an expert at translating technical changes into business-speak, and I found myself needing to come up to speed on translating geek-speak to technical changes to business-speak.

Thankfully, I landed on a team with patient engineers and QAs. I think this patient Geek may be few and far between, but if you find one – listen and learn! My experience with Geeks is that they run fast and when they get an idea – watch out! A discussion can go from clear and orderly to “Wait, what if we do ….” and “No, I heard about something that ….” REAL fast. Your BA skills are needed like no time before. Remember how you led that meeting with business big shots and their conflicting agendas? Child’s play. Now you need your special skills, as I like to say, to herd cats. You are dealing with super-smart, ready-to-execute, get-it-done individuals and what we don’t EVER want to do is stop that innovation and passion for execution.

You just want to figure out how to do what our business needs us to do and make it to your next meeting (or lunch) on time. Remember how I mentioned I work with patient engineers? Well, even their patience is limited when it comes to asking them to remind me (again) what a thread is. You will want to decide what questions you need to ask during a meeting like this and what questions can wait.

My suggestions, if you find yourself gifted with an opportunity to work on a cross-functional technology team:

  1. Concentrate on just listening during your first few team meetings. Ask an engineer or QA afterwards to translate what you didn’t quite “get”.
  2. Slowly start asking questions to find out if anything on the agenda will affect your business partners. This is a way to bring the business closer to your engineers, QAs and DBEs.
  3. Add something to the agenda that is pure BA, pure business. Get ready for odd looks, questions and maybe even some chuckles. This is where you find out how wide the chasm is between what your Geeks think the company does, and what you know it does.
  4. Make an effort to educate your team members as you get educated yourself. Share your current business meeting challenge, your thoughts on acceptance criteria for a task or other things in your typical BA day. Pretty soon you find the discussions become mutually informative, and the action items have you all on the same page.
  5. “BA” for your engineers! Give them the support and input they probably didn’t know they could ask for. Do the analysis, contact the subject matter experts for any clarifications, and learn to test something from the very bowels of the code. Show your cross-functional team what they have been missing all this time and why they need you in their lives!
  6. Lastly, enjoy the most exciting team experience you have ever experienced. Dive deep, sweat a little and celebrate the big wins as a cross-functional team.

The A in BA

Written by Mani Ramasarma on . Posted in Articles.

According to IIBA, business analysis is defined as “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders”. This is what a BA is and should be. However, in most places the role of a business analyst is confined to just two words in the definition – “defining needs”.

The others are given a short shrift. Whether this is by choice or due to a lack of confidence in the skills of a BA is unknown. Probably we as BA’s are to be blamed partly for this. Many of the candidates I interview for positions in my organization also have a narrow view of what a BA must and should do, and this is confined to eliciting and documenting requirements. Many do not address the most important job of a BA – the “A” in BA. A thorough analysis of a problem statement leads to identification and recommendation of the best solution for an organization, deliver value to stakeholders and thus provide complete justice to the definition of business analysis.

It is extremely difficult to explain analysis in its entirety in this article but let me attempt a synopsis.

{module ad 300×100 Large mobile}

So what is analysis? According to Merriam-Webster dictionary, analysis is “a careful study of something to learn about its parts, what they do, and how they are related to each other”. More importantly the plural of analysis, analyses, is defined as the “separation of a whole into its component parts”.

Now, that looks familiar. As applied to business analysis, it is the separation of requirements into their functional component parts aka functional decomposition. Besides being part of a BA’s job, why is it necessary for us to analyze? Why is it necessary for a BA to break down the requirements into their components?

As the saying goes “the devil is in the details”. Not focusing on the details or focusing too much on narrow details without considering the impact on upstream and downstream systems is a sure-fire recipe for disaster. Many projects fail for one or both reasons. Once the time for analysis has passed it is difficult, nay impossible, to analyze at later stages of the project when the focus must be on DDT – Design, Development, and Testing (not dichlorodiphenyltrichloroethane, it is banned). During such crunch situations, people resort to the ‘next best thing’ – assumptions – and it is downhill from there.

Projects typically require large financial investments, and it is important that we do not miss on the material details that could boomerang in the testing phase and blow up in the face. Whether it is waterfall or agile, analyzing requirements is very important, i.e., breaking down the requirements into their components so that the scope is well defined early on in the project lifecycle. This ultimately reduces the need for (often incorrect) assumptions later. The process of breaking down requirements into functional details is called Functional Decomposition.

As with every other thing in this world, there are people who swear by Functional Decomposition (FD) and there are detractors who feel its value is greatly overstated. To each his opinion. I fall in the first category where I believe that functional decomposition, as applied to business analysis, is a fundamental technique that every analyst must not only be aware of but should also use to varying degrees. It provides a logical sequence and a natural flow from the big picture requirement down to its components.
How to decompose requirements into its functional components?

Related Article: Cooking Up Business Analysis Success

This is a standard interview question. Two important things are required to get FD right – visualization and clarity of thought. This must be followed by validation by the business users. The level of visualization needed is a function of the maturity of the business process – the greater the maturity level of the process, the lesser the need for visualization and vice versa. Why? A matured process defines the minutest of tasks very clearly and unless there is a strong need to change it, visualization plays a minor role. The point to be noted here is that even when the processes are well-defined certain amount of visualization is necessary to identify the impact on other upstream, downstream, and peripheral systems.

What is Visualization?

It is the formation of visual mental images. You may have read about visualization in Wallace Wattle’s book “The Science of Getting Rich.” This is slightly different, at least the goals are. Given a requirement you role-play, mentally, the various tasks that a user can perform. Imagine what the end-system must look like.

Further, imagine that you are the user who will be using the system. It is called Receptive Visualization and is akin to watching a movie in your head. Here is a beautiful article on visualization in Huffington Post. The second type of visualization this article mentions, Process Visualization, is similar to Receptive Visualization. Visualization can also be seen as internal brainstorming. You can visualize jointly with others too – external brainstorming. Visualization requires business, process knowledge, and a lot of creativity. Along with visualization, you need clarity of thought.

What is “clarity of thought”?

Clarity of thought is the ability to perceive, understand, and follow a train of thought. Why is this important? Clarity crystallizes the goals that we wish to achieve. It is like writing the script or dialog for a movie. You don’t want to omit sentences that make the dialog non-sensical.

Lack of clarity often results in re-work, increased cost, delayed project delivery and, if you really make a mess of it, making it to the Gartner and Forrester’s survey of failed projects.

How to achieve clarity?

While visualizing adopt a step-by-step approach. At each step try answering the 4W’s (Who, What, When and Why) and the 1H (How). There are 2 H’s – Business and Technical. Focus on the Business How. ‘Who’ defines the actors, ‘What’ is the outcome expected of the step, ‘When’ refers to the timing and ‘Why’ provides the raison d’etre of the step. ‘How’ is used, for example, as in a calculation or formula. Ask, in your mind, the questions and put it down on paper. Revisit the steps as documented (as in the dialog above) and see if it makes sense. Now, this may seem like a lot of hard work. Initially it is, but as you gain experience it becomes second nature, and you should be able to visualize with clarity, edit mentally, and put it on paper all in one go. As you can see visualization and clarity go hand-in-hand.

In a later article I will explain this in detail.

Is it worth the effort to visualize and come up with all those innovative things? I firmly believe so, as otherwise you end up with a system that will probably be antiquated within a year or two. Of course, visualization and clarity do not come easy, and it takes plenty of experience. It is a skill that can be developed.

Realizing Value – The Latest Trend or Here to Stay? Part 1

Written by Elizabeth Larson on . Posted in Articles.

In January we published our annual article about the seven trends in business analysis and project management. If we examine these trends, we see that they have one theme—they are all about value. We see and hear the word “value” in articles, blogs, on videos, and even in the definition of business analysis: “…analyzing business needs and recommending solutions that deliver value…” (BABOK® Guide 3.0).

ith so much emphasis on value, we wonder whether the term “value” is just the latest buzzword, or if there is enduring significance to the word. This article will examine each of the seven trends, discuss its relationship to value, and explore whether the concept of value is simply a trend or here to stay. 

But what is “value?” It means so many different things to different people. Does it have to be quantified or can it be subjective? One of the authors (Elizabeth) has worked with an equal number of sponsors who required value to be measured and those who inherently understood the value of strategic projects. The latter group didn’t want to waste time quantifying something like “competitive advantage” or how much it would cost to upgrade technology, or although it could be done, measure the cost of risk avoidance. 

So first, let’s attempt to define that very ambiguous word. As we said, it means different things depending on the application of the term to the business at hand. For example, in Marketing, the focus is on the customer perception of the goods and services and their willingness to pay for them. In economics, there are two components—utility and power. In Accounting, it has to do with monetary worth.  We suggest that project managers and business analysts consider all these different aspects. 

In 2015, the central theme of our Trends article was Innovation, without addressing whether innovation delivered value. It seemed that every organization wanted to be innovative, and every person wanted to be an entrepreneur. However, we have seen that innovation, disruption, and entrepreneurship for their own sake is not productive. Organizations now realize that a focus on “disruptive” innovation can indeed be, well, very disruptive. More and more of them are finding that disruption is expensive and that entrepreneurship might better be handled by internal people (intrapreneurs) who have organizational history and knowledge. Said another way, there has to be a business case for innovation, and it must provide enough value to outweigh the costs and risks of disruption. 

{module ad 300×100 Large mobile}

With this in mind, let’s look at first two 2016 trends and the ways in which they bring value to organizations.

Trend #1 Proving our value through Business Relationship Management

As we said in the January article, executives have long been interested in getting the greatest value from initiatives. However, they have struggled with how to determine and measure it, as well as what the term actually means. We suggested that the role of the business relationship manager could work with executives and business managers to help them define value for their initiatives (projects, programs, and portfolios), as well as help them measure the value at agreed-upon intervals. We have seen an uptick in the number of articles, conferences, and webinars on this topic, which indicates an increased awareness of the importance of organizational performance and value. 

Trend #2 Agile is gaining wide acceptance but still faces challenges 

We suggested that although Agile is gaining traction and has reached a level of maturity, there are still significant challenges. If we look through the prism of value, it seems that these challenges have arisen because many organizations view “being Agile” as an end in itself, rather than focusing on how Agile projects provide value. 

In his article published in BA Times on February 9, David Shaffer called this out by saying, “The goal of software development is not to be Agile. …Being Agile is a worthless goal.”

Related Article: It’s Time to put Value in the Driver’s Seat

Let’s look at the challenges we listed and how a focus on value would resolve these issues.

  • Is everyone on board?  We have long talked about how common it is to have a mismatch of goals among the executives, mid-level management, business stakeholders, and team members. The result of the mismatch is unmet expectations and disappointment. However, if every group was committed to providing value rather than becoming Agile, there would be a greater alignment of expectations and reduced conflict.
  • Can teams be truly cross-functional? There are many online discussions about having generalists vs. specialists on Agile teams. It seems that there is a great deal of emotion surrounding the discussions, in which some parties say that if there are specialists, it is not real Scrum while others talk about Scrum having outlived its usefulness. 

Perhaps if we changed the conversation from the makeup of the teams to getting products to business stakeholders sooner, thus delivering value sooner, then the emphasis would be on what is the best makeup of the team to add value, rather than on adhering to Agile/Scrum roles. 

  • How much governance should the team follow? Needless to say, the amount of governance depends on how much is needed to ensure the solution delivers value. 

In this article we discussed the importance of value, we defined it, and described value as a central theme for all the project management and business analysis trends. We suggested that innovation for the sake of being innovative and Agile for the sake of being Agile were not only unhelpful but also meaningless as ends in themselves. Finally, we looked at the first two trends through the prism of adding value to the organization. In Part 2 we will discuss value in relation to the other 5 trends. 

1  Business Dictionary http://www.businessdictionary.com/definition/value.html

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.