Paul Mulvey

Article / Updated 09-22-2022

In the business analysis profession, there is no one-size-fits-all solution. As you develop your project type, you need to know all the tools available to you; think through all the variables related to the people, project characteristics, and the process; and then determine what tasks you need to complete. Data warehouse projects A data warehouse is a solution that brings together information from diverse sources and puts it in a format that stakeholders can easily access when making complex business decisions. A data warehouse supports a company’s tactical and strategic goals. Data warehouses are useful for trend analysis, forecasting, competitive analysis, and targeted market research. Data is often summarized by specific subject area, function, department, geographic region, time period, or all of these. Most data warehouse projects fall into the “large project” category and result in a substantial project planning effort for you as the business analyst. These projects often have a company-wide focus. The business priority for the project depends on what critical decisions need to be made to address a business threat or opportunity. Include these types of tasks in your data warehouse project work plan: Identifying what information the data warehouse must contain, identifying who should have access to it, and making sure users have the right level of access. Identifying and prioritizing subject areas to be implemented. Managing the scope of each subject area iteration or release. Validating the data accuracy and consistency during the extract/transform/load (ETL) process. Defining the correct level of data summarization. Establishing a data refresh schedule that’s consistent with business needs, timing, and cycles. Researching and reviewing available commercial off-the-shelf (COTS) business intelligence tools used for complex reporting. Planning for a user-friendly, powerful desktop query tool for users to access data without IT assistance. Planning for the user training and support needed to learn how to use tools and access data. Ensuring thorough testing is done prior to user acceptance testing (UAT). Process improvement projects Companies find competitive advantages by looking closely at their business processes and determining whether they need to improve their business operations. Depending on the changes to be made, those changes may occur in small segments over a long period of time (evolutionary changes) or may be made at one time (revolutionary changes). As a business analyst, your evaluation of the business process may result in a recommendation for software changes, procedural changes, organizational changes, or personnel changes. The tasks you perform when completing a process improvement project include analyzing the current process, capturing metrics as a baseline, identifying the problems, and identifying solutions that fix those problems to achieve better performance. Reengineering — another approach to changing a business process — happens when you start from scratch to ask what the organization needs in order to succeed instead of fixing something that already exists. You ignore current roles, silos (compartmentalized departments in organizations), and outdated business rules, and challenge assumptions to create enterprise-wide changes. Reengineering implies that you’re innovating dramatically to design new, streamlined processes. Tasks related to process reengineering projects include the following: Performing root cause analysis to find out the real problem that exists within the business Brainstorming with the project team alternative approaches to address the problem area Choosing the best approach that solves the business problem Infrastructure projects Infrastructure projects are internal technical upgrades that impact systems, hardware, platforms, or tools in order to improve the technology that supports the business and the information technology (IT) efforts. Typically, these projects are called IT projects because they’re driven and sponsored by IT departments. Tasks to include on your work plan include the following: Assessing how software interface changes (even small ones) may impact usability Assessing how the project may impact user productivity and whether training may be required Determining whether any change to a work process needs to be made based on the project With infrastructure projects, the changes often affect stakeholders, external customers, or suppliers. Business analysts are involved to manage requirements and expectations of these changes among all project stakeholders. Here are some things to keep in mind: Business analysts sometimes underestimate or miscommunicate business impact, technical risks, and priorities, so be careful. In particular, don’t forget about implementation considerations and transition requirements (user training, timing, and support). Although infrastructure projects aren’t intended to change user functionality, user productivity often decreases during the learning curve as users get used to the new elements. Because these projects are technology improvements, they may often be delayed to make room for more business-critical efforts, assuming their delay doesn’t significantly impact the business. These projects may be initiated because vendor support is no longer available. Web development projects In today’s environment, many users expect feature-rich websites and applications accessible from anywhere with any web browser. They also expect functions to be delivered in short time frames. Think about the applications you use today, like online banking, social media, and shopping websites. Web development projects are customer-facing web applications that are targeted at consumers and are available inside or outside the organization. As such, they require some special considerations in your work plan. When planning for this type of project, make sure to prioritize the features and functions. Doing so allows the team to work on and implement the highest value features first. Using an agile approach (building a highly skilled, tightly knit, self-managed, and collocated team that stays with the project from beginning to end and delivers software quickly) works well for these types of projects. Key stakeholders involved in these projects include usability experts, marketing product owners, and a customer representative or surrogate representative, such as marketing or business analyst. The following are some tasks to include on a web development work plan: Eliciting usability and security requirements Use cases, user stories, wireframes, prototypes, and simulations Testing activities like UAT

Article / Updated 09-22-2022

The data flow diagram is a helpful diagram for business analysts that shows the parties and systems involved with a particular process, as well as the data and interfaces involved when dealing with external agents (those parties or systems that exchange information with the project but over which your project has no control). It’s most commonly used for the project level context diagram (or scope diagram). Although the data flow diagram is a graphic, as the name suggests, you can also use a text-based version called the external interaction textual template. You use these techniques to analyze and communicate. If text communicates better to your stakeholders, use the textual template rather than the diagram. Introduction to data flow diagrams for business analysis The data flow diagram consists of three basic symbols: circles, curved lines, and rectangles. Each symbol represents something different: Circles: The circles represent the process (or the function) that actually works to transform inputs into outputs. In the example below, the process involves taking in all the information from the guest (input) and sending it off to the reservation system (output). Curved lines: The curved lines represent the data flowing into and out of the process. These bits of data aren’t detailed data elements but rather a conglomeration of data called net flow. In the example, dates coming from the guest into the process are arrival and departure dates (including times), but instead of getting that detailed, the diagram simply summarizes them as “dates.” Rectangular boxes: The rectangular boxes represent external agents that are sources or recipients of data. Your project has no control over how these sources execute their internal processes (their work), and the project can only send data to and receive it from them. For example, you have no idea how the reservation system processes its data, but based on what you send the system, you get the availability and price information from it. Credit: Illustration by Wiley, Composition Services Graphics Here are some examples of when you should apply this technique: When identifying stakeholders (those external agents!) When scoping your project and figuring out your boundaries Like any analysis method, data flow diagrams have advantages and disadvantages. In the advantages column is the fact that the diagram is a very clear way to show the scope boundaries for the project so that everyone is on the same page with regard to the area being analyzed (the scope). It also highlights the items that aren’t part of scope and can be documented as “out of scope.” The disadvantages primarily have to do with reader understanding: The diagram doesn’t show sequence, so some businesspeople may have a hard time following it. The diagram presents the data flowing into and out of the project at a rather high level. It doesn’t show all the data elements, which may be problematic for detail-oriented folks. The data flow has kind of fallen out of favor because, outside the scope diagram, businesspeople don’t relate to the many levels of the data flow diagram. They prefer a workflow. Here’s how to create a data flow diagram: Identify the process you’re documenting (the circle in the middle of the diagram). Identify all the parties and systems (the rectangles) involved in the process. Elicit from the stakeholders the data (the curved lines) flowing among the parties, the systems, and the process. Have the stakeholders validate your diagram. The external interaction textual template for business analysis An external interaction textual template may sound complicated, but it’s really not. You use the same information you’d use for a data flow diagram but present it in a text table rather than a graphic. A textual representation may be preferable when your stakeholders don’t understand the diagram or when teaching them how to read it takes too much time. You can see that the left-hand column lists the external agents (the rectangles on the data flow diagram), and the middle and right-hand columns list the data itself (the curved lines on the diagram). Credit: Illustration by Wiley, Composition Services Graphics

Article / Updated 03-06-2017

In prototyping, you create a model of the proposed solution. In business analysis, a prototype, or mockup, generally means a representation of a computer screen and examples of how the user will interact with the application to accomplish a task to solve the business problem. The business analyst creates the prototype, usually with help from the technical team. Prototyping is a great tool to communicate what a software solution will look like. You just need to make sure that the solution doesn’t come before the underlying problem has been identified. Sometimes, a stakeholder draws a picture showing you what he thinks the solution should look like. That initiative isn’t necessarily bad, but it puts the cart before the horse. In this situation, you still need to understand what the underlying problem is within the business domain. Here are the reasons why prototyping is so great: Prototypes give users something tangible to review. People are visual. Many people are interested in seeing what something looks like, and the prototype fits this bill. When done properly, prototypes can speed up the project lifecycle. If a picture is worth a thousand words, prototypes save a lot of talking. In fact, in a commercial off-the-shelf (COTS) system, business analysts often start with prototypes because the screen has already been designed. The changes to the screen and the configuration will be modified on the mockup. Be careful about using prototypes too early in the project. Users may get caught up in the aesthetics of the screen and want you to make the fonts sans serif or something like that. Unless someone presents a valid reason for changing the aesthetics, remember the purpose of the prototype: You’re only trying to understand how the solution should function. In addition, make sure everyone knows the prototype is just a picture. Some prototypes may look, and even feel, like a real system. People tend to think the system is already built and ready to be used, but it hasn’t. That said, sometimes aesthetic changes matter. Paul once created a dashboard for his manager that showed the health of the manager’s projects with green, yellow, and red boxes. Unfortunately, the manager was colorblind, so the red and green boxes weren’t useful. That is a valid reason to change colors! Throwaway prototypes You may be shocked that we’d suggest you throw away something you took a long time creating, but that’s essentially what you do with throwaway prototypes. Throwaway prototypes are just pictures. You may draw them on a whiteboard or with an application like Microsoft Word or even on a napkin. These may be kept as artifacts, but they are thrown away in the sense that they are not used to build the system directly. Sure, they’re useful graphics, but that’s the extent of it. The development team starts to build or update the application from scratch because the prototype can’t be leveraged (it doesn’t include code that developers can use when programming the solution). Here is an example of a throwaway prototype for a computer application. What’s hard to notice is that it’s just a drawing. Nothing more. That means the developers have to start coding from scratch. Credit: Illustration by Wiley, Composition Services Graphics When you make throwaway prototypes, follow the concept of “just enough.” That is, spend only enough time on the prototype to get the project team to understand what needs to be done, and then move on. Time is tight, so you don’t want to spend any longer than is necessary. Evolutionary prototype Evolutionary prototypes let the development team leverage the effort of the analysis; basically, what starts as a prototype turns into the actual solution. The advantage with this approach is that the expectations from the business are solid. They see the actual front end of the solution, and the developers make the necessary changes as the team works to clearly define the solution. Many times, the development team is involved in the creation of the front end and can guide the team on approaches. Simulation prototype Simulation prototypes are sort of like throwaway prototypes on steroids. Ultimately, the development team can’t leverage these prototypes for code (although at the time of this writing, some simulation tools are allowing some code snippets to be exported like in an evolutionary prototype). The advantage with the simulation is it gives the business stakeholders something tangible to walk through. Users can interact with the solution and see how it works as they click and navigate through the proposed solution.

Article / Updated 01-27-2017

Verification is what most people think of when they hear the word testing — it’s the process of testing whether a business analysis solution does what it’s designed to do. During verification, the testing team (which may consist of developers, quality assurance [QA] people, and some business analysts [BAs]) put the software through its paces to both confirm that it operates as expected and ensure that it conforms to the design specifications laid out earlier in the project. Verification testing includes four phases — one pretest phase and three phases of actual testing. Smoke test Also called a build verification test, a smoke test is a pretest that determines whether full testing can even begin in the first place. It reveals any simple failures in the solution that may prevent you from executing the tests in the next three phases. Some project teams may link this test to unit testing. Unit test The unit test is the first actual phase of testing. It involves testing each unit of the system as a stand-alone test. The development team generally performs line-by-line testing of both function and structure to find bugs within the unit before any other tests are done. Although unit tests are performed by the development team, you should have another group test in order to ensure unbiased testing. Credit: Illustration by Wiley, Composition Services Graphics Integration test The second phase of testing, the integration test, ensures the individual units can actually work together. These individual units working together can be considered a subsystem or just linked units. The objective of this test is to find problems with how the components of the system work together It tests the validity of the software architecture design. The development team generally performs the integration test, although BAs may help by providing test cases and reviewing test results. Keep the following in mind about integration testing: Units aren’t included in integration testing until they’ve successfully passed unit testing. Sometimes integration tests can have multiple levels of integration. That is, sometimes several subsystems are brought together and tested, and then those sub-systems are integrated with larger sub-systems. System test This test is the testing phase you’re most involved in as a BA. The objective of the system test is to find problems with how the system meets the users’ needs. You run this test through the entire built system from end to end, auditing all units and integrations from a linear perspective. The system test is the last chance for you and the project team to verify the product before it gets turned over to the users for a user acceptance test. It also confirms whether the software meets the original requirements, answering the “Did we build it right?” question. Requirements validation test This test verifies the system logic to ensure it supports the analysis requirements. Even though this work seems like it should be part of validation, you’re actually verifying whether you built your system according to what your requirements dictate. Regression test This test is basically a retest (regression refers to going backward). You use this test to ensure that the changes you made to the system as part of your solution don’t break what was already working. Regression usually impacts more than one program and requires more than one test. When thinking about regression tests, you need to know what applications are impacted by the solution so you can test those applications to make sure nothing has changed. This point is where a traceability matrix can come in handy. Dynamic test In a dynamic test, you test the software to see how it performs when run under different circumstances and check the physical response from the system as those variables change with time. This test term is linked with three different types of tests: Performance test: This test measures how fast the system can complete a function. To determine whether the test passes or doesn’t pass, refer to the nonfunctional requirements in your documentation that states what the response time should be. Stress test: The stress test seeks to push software to its limits in terms of users, rate of input, and the speed of the response. If you have only 3 users, you probably can do this test manually; however, if you have to ensure that 2,500 users can be logged in at the same time, you’re probably going to have to use an automated tool to load the system with the number of users. Volume test: This test checks high-volume transactions to verify the software can handle all growth projections. Security test Security testing ensures that unauthorized users can’t gain access to confidential data. It also certifies that authorized users can effectively complete their tasks. A good diagram to determine which users can perform which functions is a use case diagram or a security matrix (a diagram that shows which users may access which functions). Installation test This test makes sure the software installs on the machine as you expect it to with no problems in the installation process. When testing, make sure the requirements for the system you’re installing on are stated. Configuration test This test determines how well the product works with different environmental configurations. For example, if your requirements state the product requires a PC or Mac with Internet Explorer’s latest version or Safari, you need to test installation with both operating systems (OS) and with the configuration of the browsers on both those systems. Usability test A usability test is really a validation test; however, it’s sometimes done during system test time. If it’s a website that millions of customers will use or see, chances are you want to bring in usability engineers to build in usability instead of waiting to test it at the end of the project. Although your project may not be a multimillion dollar release, you still need to ensure that users will be able to effectively use it.

Article / Updated 03-26-2016

Aside from fulfilling a business analyst (BA) role at a company, you may have the opportunity apply your various business analysis skills to other roles. You can parse out individual business analysis skills to make yourself more marketable, take advantage of opportunities, and meet a company’s specific needs for growth and improvement. Here are ten roles (other than a BA) that you can fulfill because of your business analysis skills. Data analyst A data analyst analyzes, organizes, and anticipates the data that businesses want to track. This person focuses on the logical design and strategy for capturing the entities, attributes, and relationships that are core to the business, as well as the business’ ability to operate effectively. Business intelligence analyst As a business intelligence analyst, you home in on making sense of information in business data warehouses or reports to glean important insights. You answer key business questions and determine what intelligence can be generated that provides new knowledge important to the business. Product analyst The product analyst supports and develops requirements for products and solutions offered commercially to consumers or other businesses. Her concern is with analyzing market and customer needs information to determine what products, concepts, or features are most useful, valuable, and profitable; she often plays (or grows into) the role of product manager or marketer. Process analyst Process analysts are interested in the outcome and execution of core business processes. They deal with identifying value streams, reengineering processes, and redesigning delivery models to streamline business operations and eliminate waste in manufacturing, delivery, and supply chain operations. Business architect As a business architect, you chiefly focus on the organizational structure (or architecture) of an enterprise. You ensure that departments, operational groups, and individual roles responsible for executing on the business mission are effectively chartered, organized, and resourced to deliver with no gaps or overlaps in responsibility. Strategic analyst A strategic analyst analyzes and evaluates the strategic mission, offerings, and operational results of the business in the context of business, world, and financial markets. He recognizes trends, risks, and opportunities and determines whether the business is performing optimally against its strategic vision. He also identifies potential areas of business improvement and determines whether new strategies or shifts are necessary or appropriate. Business functional manager The business functional manager directs activities and initiatives within a business department or unit. This position achieves specific objectives and is responsible for managing teams to deliver revenue or cost-savings results and impacting the bottom line. Consulting analyst Consulting analysts serve different companies experiencing challenges that need help. They’re typically experienced in the relevant business domain and study business problems and analyze operational or functional concerns at all levels of an organization. These tasks allow them to summarize root cause of the issue and develop solution requirements from the perspective of an external trusted advisor. Technical systems analyst As a technical systems analyst, you identify technical requirements, constraints, assumptions, and solutions after confirming functional and nonfunctional requirements from higher-level analysis. The systems analyst creates development-ready design requirements and identifies technical configurations for lower-level solution components, including software programs and services, devices, and interfaces. Program analyst A program analyst translates business cases and scopes large initiatives into multiyear execution and implementation programs while supporting program managers or performing the program manager role directly. In this job, you articulate business objectives and solution requirements and suggest approaches for distribution across multilayered work streams or collaborative project teams. You define metrics and key performance indicators, business benefits management programs, and processes for capturing and reporting program delivery progress to senior leaders.

Article / Updated 03-26-2016

When verifying and validating solutions, you perform a requirements review, a structured audit in which you give participants the opportunity to ask questions and make suggestions in order to improve the quality of the product being reviewed. Keeping the requirements review session moving forward is the facilitator’s job; because you may be wearing that hat during the meeting, here are some tips for conducting the requirements review session: Put on a thick skin when documents you authored are being reviewed. Listening to people find mistakes and confusing statements within something you created isn’t fun, but you have to get used to it. The purpose of the review is to improve the quality of your end result. Think about how much worse you’d feel months later if that mistake caused a huge defect and delay in the system test! Make sure reviewers provide constructive criticism. Participants really shouldn’t criticize the author or the product unless they offer a suggestion. When someone points out an error, ask her to explain how she would’ve fixed it or written it. In this way, you get people to improve the quality, and the resulting suggestions reflect the group’s effort. Use a parking lot. If items crop up that are taking you off topic, list them on a parking lot (a temporary holding spot for items that arise in the meeting). Using this tool keeps the meeting momentum flowing without losing track of potentially important points. At the end of the meeting, review the parking lot list and assign those items that weren’t discussed. To encourage people to participate, send each an individual e-mail ahead of time to identify areas that you’re going to ask for personal input on. People will be more inclined to review a specific section if they know they’ll be called on. Don’t get caught up in the grammar of the text or the aesthetics of a prototype. The primary purpose of the meeting is to come to one common understanding of the requirements. Correct the grammar and aesthetics only if they keep participants from understanding the meaning.

Article / Updated 03-26-2016

On new development or mission-critical projects, several people may perform business analysis work. If so, business analysis planning may be divided among different business analysts. In these cases, the lead or senior BA should work with the sponsor, who has acquired funds to do the project and ensures project alignment with strategic goals. If the project requires multiple business analysts, consider dividing business analysis work in any of these ways: By subject matter expert (SME) or business unit. By deliverable type. For example, a data analyst is responsible for the data, and a process analyst is responsible for the process. By phase or iteration. For instance, if you have four phases and two BAs, figure out which phases are more complicated and assign your senior BA to those. By pairing junior BAs with senior BAs. On large projects, when multiple BAs are working together with a larger team, sharing resource schedules to create a realistic plan is critical. Keep these things in mind: Use a small planning team (such as project manager, business analyst, business leader, and IT lead/architect) to determine the appropriate project methodology to follow. Consider an incremental and iterative process such as RUP (where the project team performs risk analysis before each iteration and works on the portion of the system that has the highest risk) or an agile methodology, where the product is delivered in short iterations of 2 to 4 weeks. Develop a communication plan with the project manager to minimize confusion (such as conflicting meetings or messages between the business analyst and the project manager). Plan analysis tasks around strict time boxes (separate time periods — generally two to six weeks — that each have their own measurables). Doing so reduces analysis paralysis (getting caught up in overanalyzing every last detail without ever moving forward) and makes sure you clearly document what deliverables you’re delivering. Think beyond typical analysis tasks like eliciting, analyzing, and communicating requirements. Plan for rigorous requirements-review activities, adequate user testing, and transition activities.

Article / Updated 03-26-2016

Although many teams nowadays have one person function as both the project manager (PM) and business analyst (BA), a lot of teams still have different people performing those roles. One of the challenges on a project with a separate BA and PM is clarifying the responsibilities between the individuals. Because you and the PM interact with the same stakeholders, you both need to be very clear on what roles each of you’ll play during a project. To help tackle this challenge, schedule a PM and BA partnership meeting. Have this meeting early in the initiation phase of a project to open the lines of communication and give yourself and the PM a greater chance for success. Here’s a four-step process you can follow to help guide the meeting. Assess yourself. Prior to the meeting with your PM, have a clear picture of what you want to do and how you can best contribute to the project. To build a strong partnership, you first need to know yourself. What are your strengths; what tasks do you enjoy doing the most? What are your personal preferences? People always work harder and better on work they enjoy. For example, if you enjoy all aspects of project scoping, let the PM know that you can help with or lead that activity for the project. Get to know each other and discuss how best to work with one another. If you haven’t worked together recently (or ever), discuss individual strengths and weaknesses. Find out as much as you can about your partner. Does he work better in the morning or afternoon? Does he prefer working mostly as a team, or would he rather do certain tasks on his own and then review with you later? Here are some specific items to discuss: work history (jobs, roles, projects, and so on); passions, strengths, and areas of challenge; feelings about the partnership and how you each like to work with others; tasks (both PM and BA work) you each enjoy and excel at. Using the information you gather about each other and the project, decide who will do what on the project. Titles and predefined tasks for that title matter less than getting the best person to accomplish a task. Ideally, you want a balance between a strong PM and a strong BA. Discuss project characteristics. Discuss the project specifically, using the project charter as your guide. Think through the best ways to communicate with each other and the various stakeholders during the project. Make sure both of you are clear and in agreement on the project objectives and the key stakeholders. Discuss the requirements approach. Make sure you and the PM are in agreement on your requirements approach and on which requirement types need to be elicited, analyzed, and communicated. Confirm what documentation may be required for the project. For elicitation, discuss the techniques you may use. If your stakeholders are at different locations, talk about the possibility of some face-to-face sessions and discuss providing a travel budget to accommodate that need.

Article / Updated 03-26-2016

“Why” is such a powerful question that it’s the basis for a root cause analysis technique called the 5 whys. The thought is that by the time you ask a stakeholder “Why?” 5 times, you generally have arrived at the root cause. Consider this example: Q: “Why did you submit a purchase requisition for $750?” A: “Because we need to purchase 150 staplers!” Q: “Why do you need to purchase 150 staplers?” A: “Because our agents need to staple the pages of the driver’s license application together.” Q: “Why do they need to staple those pages together?” A: “Because we need to keep the two pages together. When we received the new printer, IT changed the default setting from double-sided to single-sided printing, and now we print out two pages rather than one.” So now you’ve figured out the real problem: It’s the printer settings for the network printer, and it has nothing to do with the stapler. The business created a solution to the problem, but they’re fixing it the wrong way. And you didn’t even need all 5 whys!

Article / Updated 03-26-2016

In business analysis projects, plans become outdated as soon as you start executing. As you discover new information about the people, project characteristics, and process, those changes impact your plan. Things may change from minute to minute, so your plan can only be as good as what you have now. Here are some tips to help you deal with the unforeseen: Tell your team right away about any changes you have to make. The earlier the team is aware of changes, the more easily everyone can adjust. Always preface your plans with “This is the information I know now.” Doing so lets them know they are getting the most recent knowledge and that the communication is not cast in stone. Have a plan B. You should develop a response for the high-impact, high-likelihood scenarios that may arise. Be flexible and open to change. Don’t stick to your plan for the sake of sticking to your plan. Change happens. Planning isn’t a perfect science. You can’t make your work plan final until you have all the information you need, but you acquire information and data at all sorts of different times. You can’t possibly plan for all possibilities, but you can plan for how to deal with change when it does come (and it will).