Tag: Business Analysis

4 Roadblocks That Prevent You from Delivering Value to Customers

Written by Angela Wick on March 29, 2017. Posted in Articles. 2 Comments on 4 Roadblocks That Prevent You from Delivering Value to Customers

Business analysts get cast in many roles on project teams, but one of their most important roles is a customer advocate.

Great Business Analysts understand customer needs and provide the voice of the customer to inform priorities and decisions. When the customer is the focal point of project work, teams deliver solutions that delight the customer.

Most Business Analysts would agree with this in theory, but in practice, customer needs get buried under the day to day quicksand of details, deadlines, politics, and fire-fighting. There are so many things that distract us from our customers. Here are the top 4 roadblocks on our path to customer value:

Roadblock #1: Limiting Our Definition of Customer.

Who is your customer? If you think it’s just an internal customer, think again. Think beyond the silo of your internal customer:

How does the internal customer serve the organization’s external customers?
Who does the internal customer serve in other parts of the organization?
How does the internal customer serve the organization’s external partners?

Even when the project scope appears to be internal, it has an impact on the operation of the organization, which eventually impacts additional end users. Even a tiny database change to an internal system could prevent an internal call center employee from having the data they need to answer a customer’s question.

Avoid this roadblock by identifying your customer chain from start to finish. Understand how their needs connect and help your team keep relevant needs top of mind throughout the project lifecycle.

Roadblock #2: Ignoring the Fact That Our Customers Are Changing

Markets change every day. A new product or announcement from your competitor can significantly change your company’s priorities and objectives. Even customer expectations are changing, rapidly! This means their definition of value is changing rapidly too. If you don’t keep up, lackluster solutions that erode your customer base get delivered.

Think about how quickly our lives are changing—none of us grew up with smartphones and social media, family road trips required an atlas instead of google maps, we couldn’t find good places to eat “near me now,” and breaking news came from the TV instead of Twitter.

Every change brings new demands from customers. In fast-paced, competitive industries, your requirements might be outdated before you get them prioritized!

So, how do you bust through this roadblock? LISTEN to your customers. Be sure you have mechanisms in place to monitor their needs, wants and expectations in real-time and be sure to address roadblock #4. Keep your mind open to noticing subtle changes not only in your project but in other projects around you and even your organization’s marketplace.

Roadblock #3: Only Doing What Leaders Ask Us to Do

What leaders ask for is NOT what they actually want. Their intentions are good, but there’s always more to the story. If the story is incomplete, our customers will receive incomplete solutions.

As Business Analysts, it is our responsibility to help leaders understand the full story. Our leaders want us to challenge scope, approach, and design to discover the full value in their ideas. We avoid this roadblock by intelligently disobeying these requests to implement their intent, not the exact requirement they give.

So, what does it mean to go with their intent and intelligently disobey? It means Business Analysts elicit and analyze to align intent and value. They use engaging techniques to get the team thinking and talking about what is valuable to who. Then, BAs give recommendations and high-value options that align to the leader’s intent.

Dig deeper into expectations of your customers and sponsors. Dig into the data to find data points to support the business vision, goals and objectives more subjectively. Help your leaders and sponsors build robust and thoughtful business cases to support their vision, goals, objectives and expectations. Don’t gather requirements – elicit them. Requirements are not laying on the road around the office for you to pick them up off the floor. You need to ask questions, challenge to gain a deeper understanding and create objective validation of the requirements and link them to the expectations of your leadership and sponsors. Trace and align requirements to the vision, goals, objectives and expectations of your leadership and sponsors. If the requirement doesn’t align – it’s time to red line (or cut the requirement).

Roadblock #4: Using an ineffective and outdated requirements approach.

Old-school requirements include a single requirements phase where BAs write down what stakeholders say they want (roadblock #3) and then hand off requirements to the development team for distant delivery (roadblock #2).

To deliver high-value products that delight customers, requirements of today and the future require a new way of working. Value-packed requirements do not come from scribe BAs who just write down what they’re told. We need to dig deeper to find real customer value.

The products that delight customers are not full of features they asked for, and they are full of features that make them think “wow, that is cool, I wouldn’t have thought of that!”

Business Analysts need to help their team to avoid this old-school requirement roadblock by evolving requirements from “what is stated” to “what will delight.” This evolution requires insight, observation, data, empathy, high impact collaboration, human-centered design patterns, and experiments. This new way of working is paramount to a successful customer centered approach.

Do you deliver solutions that delight your end users? Please post a comment below to share your success story with other BA Times readers!

5 Competencies that help Business Analysts Connect the Dot

Written by Elizabeth Larson on March 28, 2017. Posted in Articles.

What do detectives, entrepreneurs/innovators, doctors, lawyers, and effective business analysts all have in common?

Among other things, they all have to connect the dots¹ to be successful. Like detectives sorting through objects at the scene of the crime, or doctors sorting through sometimes disjointed information provided by patients, business analysts need to sort through information—lots and lots of information—in order to identify problems and uncover requirements of the solution. This process requires the ability to connect the dots.

And although the phrase “connecting the dots” has been around for a long time, it has crept into our popular culture, thanks in part to Steve Jobs. He talked about it in August 2011 when he described what connecting the dots meant to him. He said, “You cannot connect the dots looking forward. You can only connect them looking backwards. So you have to trust that somehow the dots will connect in your future.” ²

Well, that sounds good. But what does it actually mean? How do we go about connecting the dots? Here are some prerequisites:

Experience. We cannot look backwards if we don’t have the background or experience to make sense of the new information we’re taking in. That does not mean we need to have specific industry or project experience. But it does mean that we need to have learned from similar situations. We need to apply appropriate business analysis skills to new situations, guided by what worked and what did not work in the past.
Understanding context. We need to understand the context of the current situation. “Context” is one of the core business analysis concepts in the BABOK® Guide 3.0, an important concept indeed. Understanding the context provides important information about such things as the culture of the organization and the stakeholders, values and beliefs of the organization and the stakeholders, processes followed, conditions that affect the situation like weather (think shoe prints in the snow, or clues washed away in the rain), terminology, and technology—just about anything that can affect identifying the problem and the creation of the solution.
Ability to recognize patterns. Recognizing patterns requires an ability to take in information from a variety of different sources, to synthesize lots of disparate information and make sense of it, to rearrange it, to understand what is important, to stay focused, and not get distracted by the irrelevant. The ability to recognize patterns is what allows us to understand which “clues” are relevant, because we’ve seen them, just in different situations. It’s about the ability to see a problem and say with confidence: his particular solution will work (and this one won’t and here’s why).
Using both the rational mind and intuition. BAs need to use both their rational minds and their intuition.³Several years ago there was a heated discussion on a social media group about which would serve the BA better—being “analytical” or being “intuitive.” Most discussion participants saw it as an either/or. Effective BAs were either more logical or more intuitive.
We do need to be analytical. We need to break down information into smaller pieces and determine which pieces are needed. We need to use our analysis to uncover the root causes of a problem which helps separate facts from hearsay, gossip, and opinion. But we also need to use our intuition if we have any hope of being able to think critically and conceptually, as well as to be able to synthesize a lot of information quickly and be able t make sense of it.⁴
Ability to thrive in ambiguous situations. We often hear about the need for BAs to tolerate ambiguity. I think that effective detectives and business analysts are those who not only tolerate but actually thrive in ambiguous situations. The ability to thrive in uncertain situations allows business analysts to create structure from chaos. When business analysts can synthesize all the information they have accumulated during elicitation activities, put it together in meaningful ways, and are able to create understanding and gain consensus—that’s a true thing of beauty.

Having these competencies does not necessarily mean a BA will be successful. But these skills are necessary to connect the dots and connecting the dots is necessary if we BAs are going to do our jobs of finding problems and recommending solutions that provide value to stakeholders (BABOK® Guide v.3).

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.

References
1 “To draw a conclusion from disparate facts.” http://www.dictionary.com/browse/connect-the-dots?s=t
Originally a form or puzzle involving drawing lines between numbers to form a picture, as in “To draw connecting lines between a seemingly random arrangement of numbered dots so as to produce a picture or design.” http://www.thefreedictionary.com/

2 https://www.youtube.com/watch?v=sr07uR75Qk0 4:41 minutes in

3 The term “intuition” has a variety of meanings and is used differently in different contexts. Although there are different nuances, the term basically is “There are a variety of definitions of intuition. This is from http://www.dictionary.com/browse/intuition?s=t “direct perception of truth, fact, etc. independent of any reasoning process; immediate apprehension; a keen and quick insight.”

4 Critical thinking is the intellectually disciplined process of actively and skillfully conceptualizing, applying, analyzing, synthesizing, and/or evaluating information gathered from, or generated by, observation, experience, reflection, reasoning, or communication, as a guide to belief and action from The Critical Thinking Community, http://www.criticalthinking.org/pages/defining-critical-thinking/766
Conceptual thinking “…make sense of large amounts of detailed and potentially disparate information.” Conceptual thinking is applied “to find ways to understand how that information fits into a larger picture and what details are important, and to connect seemingly abstract information..” BABOK® Guide 3.0, 9.1.6.

5 Long Term Changes in Business Analysis

Written by Ian Huke on March 27, 2017. Posted in Articles.

Will these predicted changes come to pass? If so when? Only the Fates know. So why even consider them?

Let’s challenge our current professional environment and ask the big business analysis question “Why?” Having consulted the bones, read the runes, tea leaves and gazed into the crystal ball: What is our future?

Globalisation

As the world of change has rushed to offshore and near-shore business analysis has largely remained unaffected and the need for the stakeholder relationships to trump all the advocated advantages. Global organizations now have no choice but to work remotely, the business analysis being geographically separated from their stakeholders. They are working through the challenges of making this work and the culture, technology, and processes to make it happen are coming together.

These geographical challenges present themselves to local organizations. Go to any multi-site firm, and you will find people rushing between offices to meet with people. Congestion, car parking issues, travel, and energy costs and of course the lack of geographical mobility in much of the workforce means companies are seeking better ways to connect people.

Once you can connect people, it doesn’t matter if you are half a mile away or on a different continent. With the ability to offshore and near shore your business analysis capability creates a real opportunity access to a larger pool of talent, lower costs, and the ability to speed delivery by following the sun has got to be attractive. Faster, flexible and cheaper transformation is possible.

The Rise of the Center of Excellence

Companies are investing more and more in their business analysis capability in terms of the number of people, salaries, and training. Fantastic! Looking at Business Analysis Practices and you see professional, well-run outfits focussed on delivering great outcomes.

Stand back and look at the bigger change picture. It is slightly different. Many organizations change capabilities are large, with complex demarcation and extended communication lines with questionable delivery records. How’s this going to play out in our “disrupted” future?

We already see “shadow” IT and transformation departments within business units and a growing desire to move away from the classic project delivery model to increase speed and flexibility. Does this herald the move of business analysis into the wider business? In this world business analysis skills become important to everyone in the company.

This is largely how HR now operates; it provides a Center of Excellence supporting the wider business. In the new world business analysis becomes a core business capability, supported by specialists in the Center of Excellence.

Business Requirements

Our beloved functional and non-functional requirements will disappear. Why? All requirements will be business requirements as the boundary between IT and the Business erodes. You can see the blurring already. At one point user experience was expressed as a set of non-functional requirements. Remember screen response times? No longer, we have our digital teams working closely with consumers to deliver great experiences.

Look at little further at cyber security. If I am the operations director what am I going to care about more: a security breach or my operational process? And cyber security isn’t just a non-functional technical challenge; it’s a people and process one as well.

You could argue that our classic non-functional requirements are now our major business requirements. This will have an impact on how we manage them. The black and white world of functional and non-functional requirements will no longer exist with the labels having limited if any meaning.

The Dominance of Design

Think Design. The skills, tools, and techniques we use will still be valid, but the way we organize and use them will change, and new ideas will come to the fore. Design Thinking put simply is about exploring the problem as much as the solution. If the brief for your solution isn’t the best i.e. you haven’t asked the most relevant questions, then your answers and outcomes will be deficient. But then this has been the business analysis mantra for a long time, and Design Thinking can help give it validity.

Architecture is already considering Design Thinking in how it operates. One might argue the Scalable Agile Framework, tries to encapsulate Design Thinking for Agile. The convergence of Business and IT will support this move as people start to work across traditional boundaries and old structures are broken. This is already happening in a few of the more forward thinking Blue Chips who are adopting (by plan or otherwise) Design Thinking across the organization.

Design Thinking doesn’t replace Business Analysis, but it provides a fantastic framework for those skills to be applied against, to create really valued experiences and valuable outcomes.

Simplification

I mentioned earlier that when you look at companies change structures and processes they are bloated and complex. My observation is that the individual elements have grown up with little regard to each other. That means they don’t fit; they have gaps and overlaps.

The multiple roles and the terminology make simple concepts complex. Recently I was involved in an exercise to understand how: capabilities, services, and requirements relate to each other. Surprisingly difficult given they all basically refer to what an organization needs.

As organizations demand a faster pace, greater flexibility, and fantastic outcomes the way they organize and manage will have to adapt. Perhaps people being defined by their unique competencies rather than a generic job title would create a more transparent and flexible workforce.

HR is open to change. It is worth noting that many organizations are moving away from the formal appraisal systems that have been the bedrock of people management, well for as long as I can remember.

Conclusion

Clearly, there are many barriers that may impede these predictions coming to pass. Not least human nature and organizations cultures. But what if the forces of disruption light the burning platform of change?

What if your organization was at the forefront of realizing some of these changes? Think of the competitive advantage and how your workplace could become more dynamic and exciting, with business analysis sitting at the heart of it.

Business Analysis Skills in Action

Written by Victoria Hill on March 22, 2017. Posted in Articles.

Business Analysis skills in action were key to the success of an infrastructure transition project.

To support Department of Defense major site realignment initiatives, I was assigned as the sales and proposal team business analyst. We had an application we thought could help with visualizing and managing hardware, applications, data, and processes that were site infrastructure elements. Under individual agency transition plans, for example, hardware assets were to be moved, reused or eliminated. But hardware assets were linked to other elements of the infrastructure – applications had users, who had responsibility for workloads essential to the mission. We had several things going for us – an existing contract, a lot of experience with DoD infrastructure architecture, and many contacts pleased with our previous work.

Our company valued the business analyst role. In most of the big enterprise architecture projects I worked on, I concentrated on the business sub-architecture. I used many business process analysis tools and created business models to drive system implementations. Business models on their own served important functions. Models clarify because business requirements from important players are captured in the tool and put into standard formats documenting user roles, activities, and data. Teams could then play “what if” as well as clearly define requirements for implementation. But model-building is not for the faint of heart and usually involves a major time and personnel commitment.

My role as explained to me in the realignment opportunity was to listen and record since our agency contact was very close to a decision. However, during my first teleconference, a different story emerged. The customer, it turns out, did not understand what our application had to do with their problem of managing large and complex transitions.

Here is where business analysis skills in action came to the fore. There was no time for theory or illuminating discussions that could form the basis of a full-blown business process model to guide implementation. From many years working with CIO-level clients, I knew that only action and quick results would suffice to allay customer concerns. I’ll describe the steps I took, all based on firm business analysis principles honed in many previous projects, but with the focus on skills in action – ones that were applied successfully.

Skills in Research and Increasing Domain Knowledge

The first two key skills needed to be to obtain accurate domain knowledge quickly and to deploy an effective and timely research approach. Our gap in knowledge seemed to be at the core of the customer’s concern – but how to amass enough of the right domain knowledge quickly? This challenge is always crucial for business analysts – clients, of course, prefer existing domain knowledge of their field, but a business analyst should have the skills to come up with speed for almost any domain quickly.

The priority was to find information generated by the agency on the topic at hand – infrastructure transition. This assertion may sound somewhat silly – why wasn’t this done in the first place, and why not just ask the customer? This is where a business analyst can really shine because agencies are concentrating on other things, and frequently don’t have the experience or time to adhere to all needed business definition and documentation activities, especially in the early stages of projects that may or may not go forward.

The client agency, as most DoD agencies do, had already documented most of their goals and plans. The trick was to gather this information into a form understandable to the team and to scope it into a manageable size. The other side of the coin was to put the technical solution into a more understandable context, and we had a team of specialists on the West Coast ready and willing to do that once they had more insight into the real business problems and goals.

A huge amount of domain knowledge was not needed – just enough to ensure that the key concerns of the client were documented, in their language, in a way that was understandable to the team. This goal was met and exceeded all expectations – using creativity, persuasion and facilitation skills in action.

Skills in Creativity and Persuasion

How to create and share with teams and managers the scoped-down body of knowledge and specific action plan we needed? A business analyst, faced with complex and accelerated project timelines, must come up with novel solutions. Our communications at this stage had to be highly accurate and accessible – we had to define the basic business model and early project implementation information (roles, activities, data, timelines, outcomes) in an easy-to-digest but convincing format. The first presentation to the customer (and to the would-be project implementation team) would contain research results highly massaged and analyzed for accuracy and brevity. It also contained a very high-level scenario showing the how the project would work – a depiction of managers with our application able to detect excess hardware and transferal to another site in need of that exact asset.

After sales team approval, we held our breath when we showed our creation to the customer. We had tried our best – would it be accurate; would it be relevant? Yes, it was. Even over the phone, we could sense we had met the first challenge – persuading the client that we understood the problem and were poised to solve it quickly. We got a vote of confidence – permission to use live customer data to create mini-prototypes along the lines of the high-level scenario.

Skills in Virtual Facilitation and Team-Building

A dynamic period of virtual team facilitation ensued. A business analyst is a key resource between management, technical and client roles. The technical team on the West Coast started asking the right questions; our East Coast BA and management team answered them, using our experience with DoD infrastructure customers and research following our initial thread. The positive outcomes of this collaborative cross-country effort, facilitated by regular teleconferences over about six weeks, continued to accrue. By the end of the vastly enhanced sales pitch, we had to classify our presentation because it held live data – a measure of our client’s trust. For our part, we exceeded expectations and demonstrated how our application could address infrastructure rationalization and other enhancements. For this highly important project, we were invited to submit detailed implementation solutions.

This project was also a demonstration of how key Business Analysis skills, inserted at the right time, at the right level of effort can integrate and expedite project tactics to achieve team results greater than the sum of the parts.

All you need to know about the Process Performance Metrics

Written by Xin Li on March 21, 2017. Posted in Articles.

After defining a new Business Process, how can we measure if the daily work is performed as the process definition?

Then we need Performance Metrics or Performance Indicators. The purpose of measuring Performance Metrics is to control whether the Process is executed successfully and meet the goal of the process. If the Business Process Performance is not good, a follow-up gap analysis can be performed for improvement.

Which Performance Characteristics are meaningful to measure?

A Process is aimed at achieving a goal or purpose. Therefore the Performance Metrics will be all about the achievement of the Process’s goal or purpose. There are several classical Performance Characteristics:

Effectiveness – it indicates whether the goal of the Process has been achieved .

Efficiency – it indicates whether the purpose of the Process has been achieved with the minimum resource (time, money).

Quality – it indicates whether the purpose of the Process has been achieved by meeting the quality criteria.

Timeliness – it indicates whether the purpose of the Process has been achieved in time.

Next to these, some industry-related characteristics can be used. For example, for the Offshore Engineering industry, Safety is an essential core value. So there must be a Performance Metric reflecting the Safety characteristic.

What are the basic attributes for a Process Performance Metric?

In order to define a Performance Metric structurally and consistently, let us first define the basic attributes which a Process Performance Metric should have:

ID
Name
Definition
Performance Characteristic
Measurement Method
Input for the Metric Measurement
Output Registration
Acceptance Value Criteria
Target Value

How to define the Performance Metric for a Business Process?

The definition of a Business Process normally consists of the following elements:

the goal of the Process
sequential Stages and the purpose of each Stage
different Activities within each Stage and the purpose of each Activity
inputs and outputs of each Stage

For example, the Package Dispatching Process of a web hand-crafts shop “Hand Made” is like this:

The goal of this Process is to send the ordered goods within 24 hours after receiving the Order.

The purpose of Stage 1 is to check the completeness and validity of the Order information: article name, quantity, payment information, client name, billing address, delivery address.

The purpose of Stage 2 is to prepare the package with the specified order.

The purpose of Stage 3 is to arrange the shipping within 24h after receiving the order.

The Process Performance Metrics can be defined either for the whole Process or for each Stage, and even for an Activity. Each Performance Metric represents one or multiple Performance Characteristics.

Continue using the example of the “Hand Made” process; a Performance Metric Example is defined below to show how to define the Performance Metrics on Process and Stage level following the attributes mentioned above:

Example 1 Performance Metric 1 – Effectiveness of the Process

ID: M1
Name: Effectiveness of the Process
Definition: this Metric indicates whether the ordered goods is shipped out within 24 hours after receiving the Order.
Performance Characteristic: Effectiveness, Timeliness.
Measurement Method: Calculate the difference between the shipping time and the order time.
Input for the Metric Measurement: shipping time, order time.
Measurement Output Registration: Order Management System.
Acceptance Value Criteria: < 24h.
Target Value: <22h.

Example 2 Performance Metric 2 – Effectiveness of Stage 1

ID: M2
Name: Effectiveness of Stage 1
Definition: this Metric indicates whether the received order contains complete and valid information: article name, quantity, payment information, client name, billing address, delivery address.
Performance Characteristic: Effectiveness
Measurement Method: If the completeness and the validity have been checked, rate 2. If only either completeness and validity is checked, rate 1. If none of them is checked, rate 0.
Input for the Metric Measurement: Order information
Measurement Output Registration: Order Management System
Acceptance Value Criteria: 2.
Target Value: 2.

How to determine the most important Performance Metrics to measure and monitor?

Since the Performance Metrics can be defined for different characteristics and different levels (Process, Stage, Activity), the total number of Performance Metrics could be huge. It is not realistic to measure and monitor all the possible Performance Metrics. Therefore the Process Owner needs to determine the Key Performance Metrics for the process based on the Business Goal. The Business Goal decides which characteristic of the Performance Metric should be measured. For example, the Business Goal of the Package Dispatching Process is Reduce the total Process time. Then the characteristic Efficiency should be certainly measured. Since the total time is divided into activity level, the performance metrics need to be defined till activity level.

What to do with the measured Performance Metrics?

As mentioned at the beginning, the purpose of measuring the Performance Metrics is to control whether the Process is executed successfully and meet the goal of the process. As part of the Performance Metric Definition, Target and Acceptance Value has been defined. If the Performance Metric does not meet the Target or Acceptance Value, it indicates that the process execution or even the process definition needs to be improved.

So the follow-up for the measured Performance Metrics would be gap analysis finding out what is the cause of the mismatch and what needs to be improved. The Performance Metrics should be regularly measured and improved continuously in case the result does not reflect the Process Performance explicitly. Following the TOGAF’s Enterprise Architecture Framework, the solution for solving the identified process performance gap will be evaluated, implemented and governed.

In a word, in order to achieve the Business Goal of a Process, define the Performance Metrics, measure them regularly, improve the Process Performance and Performance Metrics continuously!