Tag: Business Analysis

Is your Learning Curve like a School Bully?

Written by Aditi Sharma on July 12, 2017. Posted in Articles. 2 Comments on Is your Learning Curve like a School Bully?

One of the most difficult things for a business analyst to undertake is moving from a business domain where the Business Analyst has significant experience, into a new business domain where they have little or no experience.

The first few days for the Business Analyst in this new business domain sector is typically reserved to grasp and understand the ‘new’ business domain.

The expectations are high from Project Managers and stakeholders. The Business Analyst is expected to hit the ground running. To avoid getting lost in this transition from the old business domain into the new business domain, the Business Analyst can keep these four tips in mind to quickly learn a new business domain.

1. Search Far and Wide

Go far and wide by looking at Domain specific websites, Government Regulatory Bodies, Training Manuals, Intranet, Google searches, or any knowledge sharing depository in your company. Start looking for valuable information. You may find an Excel calculator or testing results with screenshots explaining a few process or system behaviors.

Skimming through technical documentation can reveal information about different system interactions, system boundary, input/output file, and so on. For example, reading about Redbook API or RMS API or Payment Gateways would help you to understand the constraints and boundaries within which the existing system is expected to function.

Don’t forget to write it down for later reference. Quick notes and diagrams can jog your memory.

2. Speak Up and Volunteer

Let your team know that you are ready to learn and to lend a hand where possible. Your team members may have creative ideas to use your skills. For example, helping to put together a presentation for a senior sponsor would provide an opportunity to learn more about business and stakeholders. It would also give the Business Analyst the chance to build and strength stakeholder relationships. This engagement can help you gain valuable information and connections.

Get in touch with change management team. Armed with a wealth of information such as Training Manuals, User Guides, and previous communications to users, the organization’s change management team is helpful in quickly learning the new system. Even if these documents are not the latest versions, they will provide insight on the way systems works and are often rich in screen shots & diagrams. Discover more about the organization’s hierarchy by looking at the creator, author, or approver names on these documents. Using this technique can broaden your list of people to speak to and gain valuable information.

3. Scenarios & Customer Point of View

You can always try to gauge how business and processes need to react when a customer (“Human Actor”) approaches with a certain request. That helps to build on the scenarios on which you can build understanding quickly since you can pretend to be the ‘customer’ requesting information in these scenarios.

You can perform scenario analysis using “use cases” technique to write down different scenarios and get that reviewed by peers / Subject Matter Experts. You may draw use case diagram during this phase. However, this would have to be supported by narrative (e.g. actors, trigger, pre-conditions, post-conditions, normal scenario, alternate scenarios).

For example, if you are expected to document high-level requirements for a new customer banking portal, look up what is offered by different banks to their customers and create a list of potential enhancements for items you feel are missing. Using this benchmarking approach of comparing your organization’s capabilities with those of the organization’s competitors gives you a deeper understanding of the system even if you haven’t worked on a banking project previously earlier.

Use a Gemba approach or respectful observation. Put yourself in your customer’s shoes and walk through the process from beginning to the end. Get a feel for the ups and downs a customer experiences when dealing with the organization.

4. Look for Patterns

A Business Analysts experience in dealing with processes, issues, and solutions would help in the journey of exploring and discovering this new business domain. Using your experience with a capability such as a fee calculation in a previous business domain can be used by the Business Analyst in the new business domain where similar calculations. Exception handling, error handling routines, mathematical calculations and other functions learned in one business domain can be applied to the new business domain.

You can also group or link similar issues or stories together to build the bigger picture in a current project. That would help you trace the hanging parts together. This is especially useful when working with data in the data analyst role. For example, if you have worked on outbound documentation earlier, then you would be familiar with the involvement of different teams – legal, content, business, development, mail house, etc. – when working on adding new capabilities to your project. This would help you to understand where to look for information and who can provide what for bridging the gaps. This in turn builds up your understanding of this domain and linking it to the bigger requirement.

Summary

Eliminating the learning curve is of course not possible. However, the tips above would help you in channeling your time and efforts in a more structured way allowing you to wade past the tides of the new work and challenges that this new project throws at you. Being proactive and not holding back would add to your credibility, knowledge, and experience rewarding you with more opportunities and referrals enhancing your career further.

Better, Not Bigger!

Written by Karen Schemmel on July 6, 2017. Posted in Articles. 3 Comments on Better, Not Bigger!

After working as an IT Analyst in the same organization for over twenty years, it became apparent to me that every year our project load got bigger and bigger.

Just when you thought that someone was going to stop the madness, every new year we ended up out-pacing the previous year’s project load. It wasn’t just the shiny, new initiatives coming on the scene. There was a cumulative effect when a few of the previous year’s projects would spill over, creating a nice overlap effect. Unanticipated architecture changes halted project progress and impacted deadlines. The end-result was an overwhelming dog pile of projects that over-consumed resources and frustrated many.

Year after year, it was like Ground Hogs day, where we relived the same vicious cycle. While strategic planning did occur, strategic project selection was based on which got the most votes by upper management. Most of the time IT resources did not see project requirements until projects were launched.

Moreover, strategic projects did not include system or application upgrades, those of which consumed large portions of IT resources.

The trouble for me was that I knew there were better ways to manage the project capacity load, and thus avoid the relentless chaos. The ways to achieve more was not to add more on to the plate! After spending the past five years learning Business Analysis tasks and techniques, I knew there were recipes and ingredients for counteracting and avoiding the various problems we faced.

Imagine that the organization described above chose to hire a Business Analyst to help address the project chaos. With the skills and discipline that a Business Analyst can provide, this company could have transformed their chaotic project life-cycle into a well-oiled machine. With a revamping of their project processes, this company should be able to better focus on the priority strategic initiatives that provide the most value, rather than spreading itself thin with the vast number of projects. In fact, with proper capacity planning, they might possess a greater ability or agility to act on opportunities, such as offering new products or services faster than their competitors. Furthermore, they may even open up a new window to engaging in process improvements for their operational functions.

You might be wondering how this amazing transformation would take place. What specific tasks and techniques would this Business Analyst use to effect such dramatic change in this company? I contend that the most dramatic changes would come from starting at the beginning in the initiation and planning phases.

During the initiation phase, our talented BA could follow a predictive approach and use the following techniques to minimize uncertainty and mitigate “surprise” architecture changes, as well as better identification of resources needed:

Business Case – this should be used to outline the justification for pursuing the project, as well as the value it will provide. The Business Case illustrates the value a problem or opportunity will bring if realized. The Business Case would also outline constraints (i.e., need to install security equipment, upgrade servers, etc.) before setting the schedule!
Enterprise Analysis – this would compare the current state of the environment to the desired future state, thereby illustrating the gaps.
Requirements Analysis – this will outline the specific needs, and specific technology needed for the solution design. This process will also uncover any non-functional requirements needed, and then ultimately whether the proposed solution would meet the needs. To provide the benefit of proper capacity planning, capture this information in the analysis and design phase of the project rather than at kickoff!
Functional Decomposition –If the project scope was broken down into smaller pieces for analysis, then project resource and timeline uncertainties could be greatly reduced.
Estimation – With the requirements analyzed, a far better estimate of the amount of effort and needed resources for the project will be much accurate.
Prioritization – by identifying the value (or ROI), the complexity, and risks of each project, we could then assign a customized rank to each one. This ranking should guide the company in determining which projects to pursue in the appropriate order.
Stakeholder Analysis – by outlining who might be impacted by the solution or the implementation of the solution, this will guide in resource capacity planning.
Backlog Prioritization and Management – by regularly reviewing the entire backlog of projects to determine if priorities or needs have changed would be essential in keeping the company focused on those projects that bring the most value to them.

There is one final tool that I am certain would have revolutionized the company’s formulation and prioritization of goals and strategies: a Business Model Canvas.

TABLE A- BABOK V3 – BUSINESS MODEL CANVAS

Table B – BABOK V3 – BUSINESS MODEL CANVAS DEFINITION

“A Business Model Canvas can be used as a diagnostic and planning tool regarding strategy and initiatives. As a diagnostic tool, the various elements of the canvas are used as a lens into the current state of the business, especially with regards to the relative amount of energy, time, and resources the organization is currently investing in various areas. As a planning and monitoring tool, the canvas can be used as a guideline and framework for understanding interdependencies and priorities among groups and initiatives.

Business model canvas allows for the mapping of programs, projects, and other initiatives (such as recruitment or talent retention) to the strategy of the enterprise. In this capacity, the business model canvas can be used to view where the enterprise is investing, where a particular initiative sits, and any related initiatives.

A business model canvas can be used to demonstrate where the efforts of various departments and workgroups fit and online to the overall strategy of the enterprise.”

IIBA BABOK Version 3.0

In closing, after enduring years of frustration over the overwhelming burdens, it finally occurred to me that I was not a good fit for this style of operating. Luckily for me, I was recently able to find the perfect new job leading the newly formed Business Analysis department! To be in a position to guide others in using the techniques and framework that the practice of Business Analysis provides is like making it over to the other side of the rainbow! I can’t wait to work on my new organization’s transformation!

References/Bibliography
BABOK V3, A Guide to the Business Analysis Body of Knowledge. International Institute of Business Analysis.

The Use Case and I – My 10-Year Journey

Written by Michelle Green on July 5, 2017. Posted in Articles.

I’ve been a BA for nineteen years, and it wasn’t until about ten years ago that I met my first Use Case.

Since then I’ve used use cases in different ways for different types of project efforts. I’ve used them for:

As stand-alone requirements
As a supplement to stakeholder requirements
As a vision and scope communication tool
As functional requirements

In this article, I’ll be taking you through my journey with Use Cases in the hope that you might gain a better understanding of what use cases can do for you. I’m not saying that any of these approaches is right for everyone or even work all the time, but learning is an evolution. I live by the Brian Tracy quote, “You can only grow if you’re willing to feel awkward and uncomfortable when you try something new.”

Stand Alone Requirements

Ten years ago, we were picking up a new automated workflow system to replace an outdated product. An independent consultant was brought in to help our newly formed Business Process Office (BPO) determine some standards and processes they wanted to use within their organization. The objective was to learn how to identify, document, and select business processes that were good candidates for automation. I was brought in to learn the new processes and help identify ways that the company’s Business Analysts and the new BPO Subject Matter Experts (SME) could work together with the system developers as one team. One of the tools the consultant recommended to capture workflow automation requirements was a Use Case Specification Document, including, among other things the Use Case Diagram and Use Case Narrative.

It was an “Ah-Ha” Moment. I had never used use cases before, but I could tell right away that it was going to be the start of a beautiful friendship! I had finally found something that the business and the technical team could both relate to while representing the voice of the customer.

During the next couple years, we used a Use Case Specification Document as our sole requirements document for all things “automated workflow.” In hindsight, this approach only worked well because we were developing workflow automation. Business SMEs were the workflow designers, business analysts were working with them during use case development, and the technical resources were active team members for the entirety of the project. We weren’t working within an agile framework, but the co-located team principal and light documentation concept applied.

Supplement to Stakeholder Requirements

Flash forward a couple of years. The BPO had grown and was now engaged in most business projects that involved workflow enhancements. They were comfortable with use cases, but we had a project where use cases alone weren’t enough. We agreed to attach the use cases to the Business Requirements Document (BRD) and trace to them in the stakeholder requirements. Functional requirements were then written and traced back to the Stakeholder requirements.

During System Integration Testing we noticed some inconsistencies in expectations. What we found was that although many of the stakeholder requirements traced back to the use cases, the programmers were concentrating on delivering on the functional requirements, ignoring the higher-level detail. They had only looked at the use cases the first time they reviewed the Business Requirements Document (BRD) and didn’t follow the traceability all the way through. They considered them as a guide rather than an expectation. There was not cohesive understanding of the purpose of the use case.

Here’s the lesson we learned: If I could do that project over again, I would have included the use cases in the functional requirements and highlighted the purpose they provide.

Vision and Scope Communication Tool

I was paired with a Project Manager (PM) and Solutions Architect (SA) to work with a business unit to determine a high-level scope of a project for making a buy versus build decision. The goal was to replace an existing user interface system with one that could handle more complex business rules. We were on a tight deadline and every day counted.

In the first Joint Application Development (JAD) session it became obvious the business had a very clear vision for the system capabilities. It was also evident that the architect did not fully understand the scope of the request to determine what technology should be considered. We only had days to present options and t-shirt sizes to our sponsor. I needed to quickly achieve a joint understanding of the vision and scope and communicate it effectively to both the business team and the solutions architect.

Then it hit me. I could create a vision use case. Writing the use case at a high-level, I was able to insert existing system interfaces (which could potentially be re-used), show exceptions, and get a business agreement that the use case met their expectations for the new system. I took the use case to the architect, and we walked through it. With his previous architecture experience, he leveraged the use cases to draft different context diagrams highlighting interfaces for each of the build/buy solutions. The two items together allowed the business to make a quick decision, and the documents became our scope and outline to fund our detailed requirements.

Moral of this story was that in the right landscape, you could utilize use cases to communicate vision, define scope, and by the time you’re done have a great high-level requirements document,

Functional Requirements

With use cases there tends to be two different schools of thought: 1) Functional requirements are written to support use cases, and 2) Use cases are functional requirements. For this last project, and most of my projects after that, I have been leveraging use cases as functional requirements.

I was assigned the task of eliciting requirements for implementing custom packages for a Commercial Off-The-Shelf (COTS) system. In the BRD there were plenty of standard functional “The system shall…” requirements for pieces of functionality, but where a workflow was involved, use cases were embedded with the functional requirements.

Example:

In later projects, I have been known to add another section in the functional requirements for Use Cases as stand-alone components.

Conclusion

I have read different articles where experts recommend placement of use cases in requirements documents, but I like to go with the principal that the best direction to take is whatever gets you to a place of joint understanding before your audience. Learn all you can about how to use the tools in your BA Toolbox, then experiment with how to use them for your audience, as I did with my friend the Use Case.

Collaboration, Collaboration, Collaboration

Written by Pascale Weir on June 28, 2017. Posted in Articles.

A good Business Analyst is always focussed on stakeholder management, helping elicit, specify, analyze and manage their needs to help them improve their business.

This is very simple when the Business Analyst is engaged purely for this purpose, and the stakeholders are clear. However, BAs often work as part of a team to assist with implementation of solutions, and in our ever-changing world, where there are more resources working on a project, the BA may overlook the stakeholders who are right under their noses.

Why? Well, the reason is very simple – as part of a team. The Business Analyst often believes and works with the view that a project team is a unit, and that everyone on the project team has the same views and objectives – often forgetting, that each team member on the project is an individual with their views, ideals, and objectives.

Lack of collaboration within a project team can lead to delays on the project due to lack of communication, undefined or lack of expectation management and a lack of or incorrect requirements being elicited. Every member of the project team is an integral, vitally important stakeholder on the project, who needs to be supported, just as much, if not more than all the other “business” stakeholders. The question then arises “How do we manage the expectations and needs of these integral stakeholders?” There are a few ways in which this can be done effectively, and if done correctly, it can contribute to the successful completion of a project.

Using requirement elicitation techniques such as interviews, meetings, and workshops (formal or otherwise), you could identify the needs of the other project team members, and develop a clear understanding of what the benefit of your analysis would be for them on the project. Don’t underestimate the process of discovering, refining, and validating these requirements. These needs are likely to change as the project progresses, so continuous improvement is a core concept for effective team collaboration and productivity. This underpins self-organisation within a team. You can also embrace some of the collaboration techniques. For instance, collaborative games are great at breaking down silos or establishing teamwork foundations. They also drive focus towards working efficiently. Additionally, embracing visual displays allows team members to be constantly reminded about key concepts, and enables open group conversation.

For managing work in progress and dependencies, incorporating Kanban boards and story maps provides a more tangible way for the team to understand what is currently underway and any gaps in business value. These strategies are the same, no matter what kind of project you are working on, waterfall, iterative or agile project. In fact, the more “fluid” the project, the more important the collaboration and communication within the project team.

The key to collaborating effectively in a project team, is clear, factual communication, along with flexibility and adaptability to change. Additionally, respecting others area of expertise will allow team members to communicate and develop an understanding of what the needs are for each of these team members.

Of course, this doesn’t guarantee that there will not be any conflicts or disagreements within the project team, but through using effective communication and flexibility, conflict can be resolved timeously. This allows all the team members to focus on the work to be done to complete the project successfully; business outcomes, on time, within budget and to the satisfaction of the customer.

Customer Experience (CX) is the new black!

Written by Gareth Jones on June 27, 2017. Posted in Articles. 1 Comment on Customer Experience (CX) is the new black!

The customer journey is a great technique to improve the Customer Experience (CX).

“You’ve got to start with the customer experience and work back toward the technology, not the other way around.”
– Steve Jobs

The customer, not technology, must be the core of your strategy.

As customers are driving consumption in the digital age, it is necessary to understand that this shift in product or service delivery cannot happen successfully without keeping the customer in the forefront. I recently spoke with a previous colleague of mine who has helped his digital services team re-evaluate their position in service delivery. His opinion, they are now front line staff. Why? Well, who sits between them and the customer?

This way of thinking is imperative for all businesses to incorporate when designing any new or improved service delivery channel. The customer experience will determine whether a customer transacts or re-engages with a company. But how do we understand what impression the customer gets from the product and service delivery methods? Enter the Customer Journey.

The Customer Journey Map is a visual representation of the customer’s experience across a company’s product and service lines. They are cross-functional in nature (ideally following the business value stream) and supported with data (something that is increasingly available and valuable in the digital age). They provide a sense of what the customer wants to achieve, and how effective the business is at enabling that desired outcome. This then enables the business to develop and deliver targeted initiatives to meet these customer needs.

Customers who have good experiences with a company are more likely to stay on as customers, increasing their total spend, and just as importantly, increasing the likelihood that they will pass on positive sentiments to other potential customers. A poor customer experience then increases the chances for the exact opposite.

The customer journey doesn’t just need to be externally focused. Internal processes have customers also. Onboarding new staff can be an expensive and frustrating experience. Ever turned up to a new job only to be told you have no place to set-up, and nothing to set-up anyway? What about when you request an asset via the on-line self-services portal? How often does this result in increased time trying to find a number to call, out of sheer frustration? Capturing this data and modeling these experiences will provide a greater context for the improvement ahead. By putting the customer at the forefront, the business can make the necessary changes to improve that experience and subsequently improve one of the first impressions a new employee has on their new employer.

It doesn’t matter if your business is implementing a new product or service or improving an existing one. Nor does it matter that your focus is internal, not external, the customer experience matters. Not focusing on this customer journey will reduce the likelihood of project and business success. Businesses exist to service customers, why would you look at it any other way?