What Do I Mean By “Solve The Problem Abstractly?”

Requirements and Design Phases

Looking at the phases I’ve described in my business analysis framework, I wanted to describe the major difference between the step for requirements and design. The artifacts created as part of these phases, which usually include documentation but can also include prototypes, can vary greatly. I’ve seen these steps take a lot of different forms and I’ve certainly written and contributed to a lot of documents and prototypes that looked very, very different.

As I’ve described in my presentations, the phases in my framework are:

  • Project Planning: Planning the engagement, what will be done, who will be involved, resource usage, communication plan, and so on.
  • Intended Use: The business problem or problems to be solved and what the solution will try to accomplish.
  • Assumptions, Capabilities, Limitations, and Risks & Impacts: Identifying what will be included and omitted, what assumptions might be made in place of hard information that might not be available, and the consequences of those choices.
  • Conceptual Model: The As-Is state. Mapping of the existing system as a starting point, or mapping a proposed system as part of requirements and design for new projects.
  • Data Sources: Identifying sources of data that are available, accurate, and authoritative.
  • Requirements: The Abstract To-Be state. Description of the elements and activities to be represented, the data needed to represent them, and any meta-information or procedures needed for support.
  • Design: The Concrete To-Be state. Description of how the identified requirements are to be instantiated in a working solution (either as a new system or as a modification to an existing system) and the plan for implementation and transition.
  • Implementation: The phase where the solution is actually implemented. In a sense, this is where the actual work gets done.
  • Test Operation and Usability: Verification. Determining whether the mechanics of the solution work as designed.
  • Test Outputs and Suitability for Purpose: Validation. Determining whether the properly function system solves the actual problem it was intended to solve.
  • Acceptance: Accreditation. Having the customer (possibly through an independent agent) decide whether they will accept the solution provided.

The requirements and design phases are sometimes combined by practitioners but I want to discuss how they can and should be differentiated. Also, given the potentially amorphous and iterative nature of this process, I’ll also discuss how the requirements phase interacts with and overlaps the conceptual model and the data sources phases.

As you can see from the description of the phases above, I refer to the requirements phase as coming up with an abstract solution to the problem under analysis. People have a lot of different conceptions of what this can be. For example, it can contain written descriptions of actions that need to be supported. It can be written solely in the form of user stories. My preference is to begin with some form of system diagram or process map to provide a base to work from and to leverage the idea that a picture is worth a thousand words. That is to be followed by descriptions of all events, activities, messages, entities, and data items that are involved.

Data

Even more specifically, the nature of all the data items should be defined. Six Sigma methodologies define nine different characteristics that can be associated with each data item. They can be looked up easily enough. I prefer to think about things this way:

  • Measure: A label for the value describing what it is or represents
  • Type of Data:
    • numeric: intensive value (temperature, velocity, rate, density – characteristic of material that doesn’t depend on the amount present) vs. extensive value (quantity of energy, mass, count – characteristic of material that depends on amount present)
    • text or string value (names, addresses, descriptions, memos, IDs)
    • enumerated types (color, classification, type)
    • logical (yes/no, true/false)
  • Continuous or Discrete: most numeric values are continuous but counting values, along with all non-numeric values, are discrete
  • Deterministic vs. Stochastic: values intended to represent specific states (possibly as a function of other values) vs. groups or ranges of values that represent possible random outcomes
  • Possible Range of Values: numeric ranges or defined enumerated values, along with format limitations (e.g., credit card numbers, phone numbers, postal addresses)
  • Goal Values: higher is better, lower is better, defined/nominal is better
  • Samples Required: the number of observations that should be made to obtain an accurate characterization of possible values or distributions
  • Source and Availability: where and whether the data can be obtained and whether assumptions may have to be made in its absence
  • Verification and Authority: how the data can be verified (for example, data items provided by approved individuals or organizations may be considered authoritative)

These identified characteristics provide guidance to the participants in the design and implementation phases. Many of the data items may be identified as part of the conceptual model phase. These are the items associated with the As-Is state (for cases where there is an existing system or process to analyze). New data items will usually be identified as part of the requirements phase, both for modified parts of the original system and for the elements needed to control them. Data items may also be removed during the transition from the conceptual model to the requirements if an existing system is being pruned or otherwise rearranged or streamlined.

I wrote here about one of my college professor’s admonitions that you need to solve the problem before you plug the numbers in. He described how students would start banging away on their hand-held calculators when they got lost (yeah, I’m that old!), as if that was going to help them in some way. He said that any results obtained without truly understanding what was going on were only going to lead to further confusion. The students needed to fully develop the equations needed to describe the system they were analyzing (he was my professor for Physics 3 in the fall of my sophomore year), and simplify and rearrange them until the desired answer stood alone on one side of the equals sign. Then and only then should the given values be plugged into the variables on the other side of the equals sign, so the numeric answer could be generated. Problems can obviously involve more than single values for answers but the example is pretty clear.

So, the requirements should identify the data items that need to be included to describe and control the solution. The design might then define the specific forms those representations will take. Those definitions can include specific form of the variables (in terms of type and size or width) appropriate for the computer language or tool (e.g., database implementation) in which the solution (or the computer-based part of it) will be implemented. Those details definitely must be determined for the implementation.

The requirements descriptions should also include how individual data items should naturally be grouped. This includes groupings for messages, records for storage and retrieval, and associations with specific activities, entities, inputs, and outputs.

Contexts

An important part of what must be captured and represented is the information needed for the user to interact with and control the system. The conceptual model, particularly when a simulation is involved, mostly contains information about the process itself, but can clearly simulate a limited scope of user interactions. The requirements phase is where it’s most important to incorporate all contexts of user behavior and interactions.

The two major contexts of user interaction involve manipulations of data items (typically CRUD operations) and initiation of events (typically non-CRUD operations). Another contextual differentiation is the operating mode of a system. Modes can involve creation and editing, running, maintenance, analysis, and deployment, among others.

Skills Required for Different Phases

Identification of activities and values can be performed by anyone with good analysis skills, though it always helps to also have architecture and implementation skills. Business analysts should have the requisite skills to carry out all actions of the requirements phase.

The design phase is where practitioners with specific skills start to be needed. The skills needed are driven by the environment in which the solution will be implemented. Solutions come in many shapes and sizes. Processes for serving fancy coffees, making reservations at hospitality and entertainment venues, and manufacturing hand tools can be very different, and the skills needed to design solutions can vary widely.

A standard, BABOK-based business analyst should be able to analyze and design a process for serving customers directly in a store. Designing a computer-based solution will require different skills based on the scope, scale, and components of the solution envisioned. A solution based on a single desktop might require basic programming experience. A solution based on peer-to-peer networked computers might require experience in programming, inter-process communication, and real-time considerations. A simple, web-based system might require knowledge of basic web programming, different levels of understanding of tools like WordPress, or other automated web-builder tools. An enterprise-level, web-based system might require knowledge of DevOps, server virtualization, cloud computing, and clustering. People mostly seem to refer to this skillset when they use the term solutions architect, though I interpret this term more widely. Designing a manufacturing system might require knowledge of engineering, specific physical processes, and non-trivial knowledge of a wide range of computing subjects. A knowledge of simulation might be helpful for a lot of different solutions.

No matter what skills are required or thought to be required by the design practitioners, the business analyst needs to be able to work closely with them to serve as an effective bridge to business customers. I’m certainly capable of creating designs in most if not all of these contexts, even if I don’t have some of the specific implementation skills. No one knows everything, what’s important is to know what’s needed and how to work with and organize the requisite practitioners.

The skills required for the implementation phase are definitely more specific based on the specific nature of the solution. A business analyst needs to be able to communicate with all kinds of implementation practitioners (in both directions!) in order to serve as an effective liaison between those implementors and the business customers they serve.

Summary

Solving the problem abstractly, to me, means writing a comprehensive set of requirements that facilitates the creation of an effective design. The requirements are the abstract representation of the To-Be state while the design is the concrete representation of the To-Be state. It describes what’s actually going to be built. The implementation results in the actual To-Be state.

Posted in Tools and methods | Tagged , , , | Leave a comment

Unified Theory of Business Analysis: Part Three

How The Most Commonly Used Software Tools Apply to the Solution Effort and the Engagement Effort

Continuing last week’s discussions I wanted to analyze how business analysts tend to apply their favorite software tools.

  • Excel (24)

    Microsoft Excel is such a general purpose tool that it can be used to support almost any activity. It is highly useful for manipulating data and supporting calculations for solutions but is equally useful for managing schedule, cost, status, and other information as part of any engagement. I’ve been using spreadsheets since the 80s and I know I’ve used them extensively for both kinds of efforts.

  • Jira (14)

    While Jira and related systems (e.g., Rally, which surprisingly never came up in my survey even once) are used to manage information about solutions, it’s less about the solutions than keeping it all straight and aiding in communication and coordination. As such, I consider it to be almost entire geared to support engagement efforts.

  • Visio (14)

    Visio could be used for diagramming work breakdown structures, critical paths, organizational arrangements, and so on, but it seems far more directed to representing systems and their operations as well as solutions and their designs. Therefore I classify Visio as primarily as an aid to solution efforts.

  • Word (13)

    Like Excel, Microsoft Word is another general purpose tool that can be used to support both solution efforts and engagement efforts.

  • Confluence (8)

    Confluence is a bit of an odd duck. It’s really good for sharing details about rules, discovered operations and data, and design along with information about people and project statuses. It suffers from the weakness that the information entered can be difficult to track down unless some form of external order is imposed. The tool can readily be used to support both kinds of efforts.

  • Outlook (7)

    Microsoft Outlook is a general communication tool that manages email, meetings, facilities, and personnel availability. It is most often leverage to support the engagement effort.

  • SharePoint (6)

    SharePoint is another Microsoft product that facilitates sharing of information among teams, this time in the form of files and notifications. This makes it most geared towards supporting engagement efforts.

  • Azure DevOps (5)

    I’m not very familiar with this tool, having only been exposed to it during a recent presentation at the Tampa IIBA Meetup. It seems to me that this product is about instantiating solutions while its sister product, Visual Studio Team Services (VSTS) is meant to serve the engagement effort. I would, of course, be happy to hear different opinions on this subject.

  • Team Foundation Server (4)

    I’m mostly classifying this as supporting the engagement effort, since it seems to be more about communication and coordination, but to the degree that it supports source code directly iit might have to be considered as supporting solution efforts as well. Like I’ve said, feel free to pipe in with your own opinion.

  • PowerPoint (4)

    I’ve used PowerPoint for its effective diagramming capabilities, which sometimes allow you to do things that are more difficult to do in other graphics packages like Visio. That said, as primarily a presentation and communications tool, I think it should primarily be classified as supporting engagements.

  • Email (3)

    Email is a general form of communication and coordination and is definitely most geared toward engagement efforts.

  • Google Docs (3)

    These tools provide analogs to the more general Microsoft office suite of tools and should support both solution and engagement efforts. However, I’m thinking these are more generally used to support the engagement side of things.

  • MS Dynamics (2)

    These tools seem to be mostly about supporting engagements, although the need to customize them for specific uses may indicate that it’s also something of a solution in itself.

  • Visual Studio (2)

    Any tools meant to directly manipulate source code must primarily be used to support solution efforts.

  • Notepad (2)

    This general purpose tools can be used for almost anything, and is thus appropriate for supporting both solution and engagement efforts.

  • OneNote (2)

    This is another very generalized Microsoft tool that facilitates sharing of information that can be used to support solution and engagement efforts.

  • SQL Server (2)

    SQL Server is almost always part of a solution.

The survey respondents had identified 38 other software tools at the time of this writing, none of which were mentioned more than once. They were mostly variations on the tools discussed in detail here, and included tools for diagramming, communication and coordination, and analysis. A small number of explicit programming tools were listed (e.g., Python, R) along with some automated testing tools that are usually the province of implementation and test practitioners. It’s nice to see BAs that have access to a wider range of skills and wear multiple hats.

Here’s the summary of how I broke things down. Please feel free to offer suggestions for how you might classify any of these differently.

Software Tool Survey Count Effort Type
Excel 24 Both
Jira 14 Engagement
Visio 14 Solution
Word 13 Both
Confluence 8 Both
Outlook 7 Engagement
SharePoint 6 Engagement
Azure DevOps 5 Solution
Team Foundation Server 4 Engagement
PowerPoint 4 Engagement
Email 3 Engagement
Google Docs 3 Engagement
MS Dynamics 2 Engagement
Visual Studio 2 Solution
Notepad 2 Both
OneNote 2 Both
SQL Server 2 Solution
Posted in Management | Tagged , , | Leave a comment

Unified Theory of Business Analysis: Part Two

How The Fifty Business Analysis Techniques Apply to the Solution Effort and the Engagement Effort

Yesterday I kicked off this discussion by clarifying the difference between the solution effort and the engagement effort. Again, the solution effort involves the work to analyze, identify, and implement the solution. Note that the solution should include not just the delivered operational capability but also the means of operating and governing it going forward. The engagement effort involves the meta-work needed to manage the process of working through the different phases. An engagement can be a project of fixed scope or duration or it can be an ongoing program (consisting of serial or parallel projects) or maintenance effort (like fixing bugs using a Kanban methodology). It’s a subtle difference, as I described, but the discussion that follows should make the difference more clear.

I want to do so by describing how the fifty techniques business analysis techniques defined in the BABOK (chapter ten in the third edition) relate to the solution and engagement efforts. I want to make it clear that as a mechanical and software engineer, I’m used to doing the analysis to identify the needs, do the discovery, collect the data, and define the requirements; manage the process from beginning to end; and then doing the implementation, test, and acceptance. A lot of BAs don’t have the experience of doing the actual implementations. To me it’s all part of the same process.

The definitions for each business analysis technique are taken verbatim from the BABOK. The descriptions of the uses to which they can be put within the context of my analytical framework are my own. I also refer to different kinds of model components as I described here.

  1. Acceptance and Evaluation Criteria: Acceptance criteria are used to define the requirements, outcomes, or conditions that must be met in order for a solution to be considered acceptable to key stakeholders. Evaluation criteria are the measures used to assess a set of requirements in order to choose between multiple solutions.

    An acceptance criterion could be the the maximum processing time of an item going through a process. An evaluation criteria might be that the item must exit a process within 22 minutes at least 85 percent of the time. Similarly, the processing cost per item might need to be less than US $8.50. These criteria can apply to individual stations or a system as a whole (e.g., a document scanning operation could be represented by a single station while a group insurance underwriting evaluation process would be made up of a whole system of stations, queues, entries, and exits).

    Identifying the acceptance criteria is part of the solution effort. Knowing this has to be done is part of the engagement effort. Note that this will be the case for a lot of the techniques.

  2. Backlog Management: The backlog is used to record, track, and prioritize remaining work items.

    The term backlog is usually used in a Scrum context today, but the idea of lists of To-Do items, either as contract requirements or deficiency punch lists, has been around approximately forever. I’d bet my left arm they had written punch lists when they were building the pyramids in Egypt.

    Managing the backlog is primarily part of the engagement effort. Doing the work of the individual backlog items is part of the solution effort.

  3. Balanced Scorecard: The balanced scorecard is used to manage performance in any business model, organizational structure, or business process.

    This is a technique only a consultant could love. In my opinion it’s just a made up piece of marketing twaddle. Like so many other techniques, it’s just a formalized way of making sure you do what you should be doing anyway.

    OK, taking off my cranky and cynical hat I’ll say that techniques like these exist because somebody found them useful. While it’s clear that managers and practitioners should be evaluating and improving their capabilities from the point of view of customers, internal processes, learning and growth (internal and external), and financial performance, it never hurts to be reminded to do so explicitly. And heck, my own framework isn’t much more than an organized reminder to make sure you do everything you need to do in an organized way.

    I would place this activity primarily in the context of the engagement effort, since it strikes me as a meta-evaluation of an organization that defines the context that determine the kind of solutions that might be needed.

  4. Benchmarking and Market Analysis: Benchmarking and market analysis are conducted to improve organizational operations, increase customer satisfaction, and increase value to stakeholders.

    This technique is about comparing the performance of your individual stations or activities and overall system (composed of collections of individual stations, queues, entries, and exits) to those of other providers in the market, by criteria you identify.

    This seems to lean more in the direction of an engagement effort, with the details of changes made based on the findings being part of solution efforts.

  5. Brainstorming: Brainstorming is an excellent way to foster creative thinking about a problem. The aim of brainstorming is to produce numerous new ideas, and to derive from them themes for further analysis.

    This technique involves getting (generally) a group of people together to think about a process to see what options exist for adding, subtracting, rearranging, or modifying its components to improve the value it provides. This can be done when improving an existing product or process or when creating a new one from scratch.

    A “process” in this context could be an internal organizational operation, something a product is or does, or something customers might need to improve their lives. It’s a very general and flexible concept.

    Brainstorming is mostly about the solution effort, though engagement issues can sometimes be addressed in this way.

  6. Business Capability Analysis: Business capability analysis provides a framework for scoping and planning by generating a shared understanding of outcomes, identifying alignment with strategy, and providing a scope and prioritization filter.

    Processes made up of stations, queues, entries, and exits represent the capabilities an organization has. They can be analyzed singly and in combination to improve the value an organization can provide.

    The write-up in the BABOK approaches this activity a bit differently and in an interesting way. It’s worth a read. That said, looking at things the way I propose, in combination with the other ideas described in this write-up, will provide the same results.

    Since this technique is about the organization and its technical capabilities, it might be considered a mix of engagement and solution work, but overall it tends toward the engagement side of things.

  7. Business Cases: A business case provides a justification for a course of action based on the benefits to be realized by using the proposed solution, as compared to the cost, effort, and other considerations to acquire and live with that solution.

    A business case is an evaluation of the costs and benefits of doing things a different way, or of doing a new thing or not doing it at all. Business cases are evaluated in terms of financial performance, capability, and risk.

    Business cases can be a mix of engagement and solution effort.

  8. Business Model Canvas: A business model canvas describes how an enterprise creates, delivers, and captures value for and from its customers. It is comprised of nine building blocks that describe how an organization intends to deliver value: Key Partnerships, Key Activities, Key Resources, Value Proposition, Customer Relationships, Channels, Customer Segments, Cost Structure, and Revenue Streams.

    Again, this is a fairly specific format for doing the kinds of analyses we’re discussing over and over again. It is performed at the level of an organization on the one hand, but has to be described at the level of individual processes and capabilities on the other. Once you’re describing individual processes and capabilities, you’re talking about operations in terms of process maps and components, where the maps include the participants, information flows, financial flows, resource flows, and everything else.

    This technique also applies to both engagement and solution efforts.

  9. Business Rules Analysis: Business rules analysis is used to identify, express, validate, refine, and organize the rules that shape day-to-day business behavior and guide operational business decision making.

    Business rules are incorporated in stations and process maps in the form or decision criteria. Physical or informational items are not allowed to move forward in a process until specified criteria are met. Business rules can be applied singly or in combination in whatever way works for the organization and the process. If mechanisms for applying business rules can be standardized and automated, then so much the better.

    Business rules are almost always created and evaluated at the level of the solution.

  10. Collaborative Games: Collaborative games encourage participants in an elicitation activity to collaborate in building a joint understanding of a problem or a solution.

    This has never been one of my go-to techniques, but I admire the people who can think up things that are applicable to a given real-world problem. I’ve seen these used pretty much exclusively as teaching and team-building exercises, and it’s difficult to imagine how this activity could be mapped directly onto a process map or its components.

    That said, there are ways to gamify almost anything, even if it’s just awarding points for doing certain things with prizes awarded at intervals to individuals and teams who rack up the most. When I was in the Army a colleague came up with a way to have us remember a sequence of actions a weapon system crew had to call out to track and fire a missile, reinforced by calling out items as we passed a volleyball among ourselves.

    If anything this technique belongs more in the realm of engagement efforts.

  11. Concept Modeling: A concept model is used to organize the business vocabulary needed to consistently and thoroughly communicate the knowledge of a domain.

    This is an integral part of domain knowledge acquisition, which I consider to be a core function of business analysts.

    The description in the BABOK talks mostly about defining the relevant nouns and verbs in a domain, free of “data or implementation biases,” which is good advice based on my experience. The nouns and verbs of a process or domain should be identified (and understood) during the discovery phase of an engagement and then, only when that is done, the data should be captured during an explicit data collection phase. It’s possible to do both things at once, but only if you have a very clear understanding of what you’re doing.

    This detailed work is almost always performed in the context of solution efforts.

  12. Data Dictionary: A data dictionary is used to standardize a definition of a data element and enable a common interpretation of data elements.

    This technique goes hand in hand with the concept modeling technique described directly above. Instead of describing domain concepts, though, it is intended to catalog detailed descriptions of data items and usages. Where domain nouns and verbs identify things (including ideas) and actions, data items are intended to characterize those things and actions. For example, a domain concept would be an isolated inspection process, which is a verb. The location or facility at which the inspection is performed would be a noun. The time it takes to perform the inspection is a datum (or collection of data, if a distribution of times is to be used in place of a single, fixed value) that characterizes the verb, while the number of items that can be inspected simultaneously is a datum (or collection of data is, say, that number changes throughout the day according to a schedule or in response to demand) that characterizes the noun.

    The general type of data (e.g., continuous vs. discrete, integer vs. real, logical vs. numeric vs. enumerated type) may also be recorded in the dictionary. Specific information may also be recorded based on how the data is used in terms of the implementation. These may include numeric ranges (minimums and maximums), valid enumerated values (e.g., colors, months, descriptive types or classes of items or events), and detailed storage types (short and long integers, floating point variables of different lengths, string lengths, data structures descriptions, and so on).

    A data dictionary is definitely associated with the solution effort.

  13. Data Flow Diagrams: Data flow diagrams show where data comes from, which activities process the data, and if the output results are stored or utilized by another activity or external entity.

    Data flow diagrams can be process maps of their own or can be embedded in process maps that also show the movement and processing of physical entities. Different representations might be used to make it clear which is which if both physical and informational entities are described in the same map, to improve clarity and understanding.

    This technique is used in the context of the solution effort.

  14. Data Mining: Data mining is used to improve decision making by finding useful patterns and insights from data.

    People typically think of “Big Data” or “AI” or “machine learning” when they talk of data mining, but the concept applies to data sets of any size. Intelligent perusal and analysis of data can yield a lot of insights, even if performed manually by a skilled practitioner.

    Graphical methods are very useful in this regard. Patterns sometime leap right out of different kinds of plots and graphs. The trick is to be creative in how those plots are designed and laid out, and also to have a strong understanding of the workings and interrelationships of a system and what the data mean. The BABOK mentions descriptive, diagnostic, and predictive methods, which can all use different analytical sub-techniques.

    Although this technique can be used in support of the engagement effort if it’s complex enough, this kind of detailed, high-volume methodology is almost always applied to the solution.

  15. Data Modeling: A data model describes the entities, classes or data objects relevant to a domain, the attributes that are used to describe them, and the relationships among them to provide a common set of semantics for analysis and implementation.

    I see this as having a lot of overlap with the data dictionary, described above. It aims to describe data conceptually (as I describe in the Conceptual Model phase of my analytic framework), logically (in terms of normalization, integrity, authority, an so on), and physically (as instantiated or represented in working system implementations).

    This technique is definitely used in solution efforts.

  16. Decision Analysis: Decision analysis formally assesses a problem and possible decisions in order to determine the value of alternate outcomes under conditions of uncertainty.

    The key point here is uncertainty. Deterministic decisions made on the basis known values and rules are far easier to analyze and implement. Those can be captured as business rules as described above in a comparatively straightforward manner.

    Uncertainly may arise when aspects of the problem are not clearly defined or understood and when there is disagreement among the stakeholders. The write-up in the BABOK is worth reviewing, if you have the chance. There is obviously a wealth of additional material to be found elsewhere on this subject.

    Interestingly, this kind of uncertainty is largely distinguished from the type of uncertainty that arises from the systemic variability stemming from concatenations of individually variable events, as found in processes described by Monte Carlo models. That kind of uncertainty is manageable within certain bounds and the risks are identifiable.

    This technique is always part of work on the solution.

  17. Decision Modeling: Decision modeling shows how repeatable business decisions are made.

    This technique contrasts to Decision Analysis in that it is generally concerned with decisions that are made with greater certainty, where the factors and governing values are well understood, and where the implementations of the required calculations is straightforward. Note that the processes and calculations can be of any complexity, the differentiation is about the level of certainty or decidability.

    This technique is also always part of the solution effort.

  18. Document Analysis: Document analysis is used to elicit business analysis information, including contextual understanding and requirements, by examining available materials that describe either the business environment or existing organizational assets.

    Document analysis can aid in domain knowledge acquisition, discovery, and data collection as described and linked previously. Documents can help identify the elements and behaviors of a system (its nouns and verbs), the characteristics of a system (adjectives and adverbs modifying the nouns and verbs), and the entities processed by the system. It the entities to be processed by the system are themselves documents, then they drive the data that the system must process, transport, and act upon.

    In all cases this work is performed during the solution effort.

  19. Estimation: Estimation is used by business analysts and other stakeholders to forecast the cost and effort involved in pursuing a course of action.

    Estimation is a mix of science and art, and probably a black art at that. Any aspect of a process or engagement can be estimated, and the nature and accuracy of the estimate will be based on prior experience, entrepreneurial judgment, gathered information, and gut feel.

    The BABOK describes a number of sub-techniques for performing estimations. They are top-down, bottom-up, parametric estimation, rough order of magnitude (ROM), Delphi, and PERT. Other methods exist but these cover the majority of those actually used.

    As described in the BABOK this technique is intended to be used as part of the engagement effort.

  20. Financial Analysis: Financial analysis is used to understand the financial aspects of an investment, a solution, or a solution approach.

    Fixed and operating costs must be balanced against revenue generated for every process or group of processes. Costs may be calculated by working bottom-up from individual components and entities while revenues come from completed (through the sale) work items. The time value of money is often considered in such analyses; I took a course on this as a freshman in engineering school. I’m glad I gained this understanding so early. Risk is often calculated in terms of money, as well, and it should be remembered that uncertainty is always a form of risk.

    I’ve always enjoyed analyzing systems from a financial point of view, because it provides the most honest insight into what factors need to be optimized. For example, you can make something faster at the expense of taking longer to make it, requiring more expensive materials, making it more expensive to build and maintain, and making it more difficult to understand. You can optimize along any axis beyond the point at which it makes sense. Systems can be optimized along many different axes but the ultimate optimization is generally financial. This helps you figure out the best way of making trade-offs between speed, resource usage, time, and quality, or among the Iron Triangle concepts of

    Detailed cost data is sometimes hidden from some analysts, for a number of reasons. A customer or department might not want other employees or consultants knowing how much individual workers get paid. That’s a good reason in a lot of cases. Companies hiding or blinding data from outside consultants for reasons of competitive secrecy are also reasonable. A bad reason is when departments within an organization refuse to share data in order to protect their “rice bowls.” In some case you’ll build the capability of doing financial calculations into a system and test it with dummy data, and then release it to organizations authorized to work with live data in a secure way.

    This is always an interesting area to me because four generations of my family have worked in finance in one capacity or another. As an engineer and process analyst I’m actually kind of a black sheep!

    Financial analysis is a key part of both the solution and engagement efforts.

  21. Focus Groups: A focus group is a means to elicit ideas and opinions about a specific product, service, or opportunity in an interactive group environment. The participants, guided by a moderator, share their impressions, preferences, and needs.

    Focus groups can be used to generate ideas or evaluate reactions to certain ideas, products, opportunities, and risks. In terms of mapped processes the group can think about individual components, the overall effect of the process or system, or the state of an entity — especially if it’s a person and even more so if it’s a customer (see this article on service design) — as it moves through a process or system.

    This technique is primarily used in solution efforts.

  22. Functional Decomposition: Functional decomposition helps manage complexity and reduce uncertainty by breaking down processes, systems, functional areas, or deliverables into their simpler constituent parts and allowing each part to be analyzed independently.

    Representing a system as a process map is a really obvious form of functional decomposition, is it not? A few more things might be said, though.

    I like to start by breaking a process down into the smallest bits possible. From there I do two things.

    One is that I figure out whether I need all the detail I’ve identified, and if I find that I don’t I know I can aggregate activities at a higher level of abstraction or moit them entirely if appropriate. For example, a primary inspection at a land border crossing can involve a wide range of possible sub-activities, and some of those might get analyzed in more detailed studies. From the point of view of modeling the facility, however, only the time taken to perform the combined activities may be important.

    The other thing I do is group similar activities and see if there are commonalities I can identify that will allow me to represent them with a single modeling or analytical component or technique. It might even make sense to represent a wide variety of similar activities with a standard component that can be flexibly configured. This is part of the basis for object-oriented design.

    A more general benefit of functional decomposition is simply breaking complex operations down until they are manageable, understandable, quantifiable, and controllable. The discussion in the BABOK covers a myriad of ways that things can be broken down and analyzed. The section is definitely worth a read and there are, of course, many more materials available on the subject.

    Functional decomposition is absolutely part of the solution effort.

  23. Glossary: A glossary defines key terms relevant to a business domain.

    Compiling a glossary of terms is often a helpful aid to communication. It ensures that all parties are using an agreed-upon terminology. It helps subject matter experts know that the analysts serving them have sufficient understanding of their work. Note that this goes in both directions. SMEs are assured that the analysts serving them are getting it right, but the analysts are (or should be) bringing their own skills and knowledge to the working partnership, so their terms of art may also be added to the glossary so the SMEs being served understand how the analysts are doing it.

    The glossary is chiefly part of the solution effort.

  24. Interface Analysis: Interface analysis is used to identify where, what, why, when, how, and for whom information is exchanged between solution components or across solution boundaries.

    This is a particular area of interest for me, so I’m going to break it down across all the concepts described in the BABOK.

    • User interfaces, including human users directly interacting with the solution within the organization: Users and user interfaces can be represented as stations or process blocks in any system. They can be represented as processes, inputs, outputs, and possibly even queues in a process map. In other cases they can be represented as entities which move through and are processed by the system. (Alternatively, they can be described as being served by the system or process.) The data items transmitted between these components and entities are themselves entities that move through and are potentially transformed by the system.
    • People external to the solution such as stakeholders or regulators: Information or physical materials exchanged with external actors (like customers) are typically represented as entities, while the actors themselves can be represented as entities or fixed process components.
    • Business processes: Process maps can represent activities at any level of aggregation and abstraction. A high-level business operation might be represented by a limited number of fixed components (stations, queues, entries, and exits) while each component (especially stations) could be broken down into its own process map (with its own station, queue, entry, and exit blocks). An example of this would be the routing of documents and groups of documents (we can call those files or folders) through an insurance underwriting process, where the high-level process map shows how things flow through various departments and where the detailed process maps for each department show how individual work items are routed to an processed by the many individuals in that department.
    • Data interfaces between systems: The word “system” here can refer to any of the other items on this list. In general a system can be defined as any logical grouping of functionality. In a nuclear power plant simulator, for example, the different CPU cores, shared memory system, hard disks, control panels and controls and displays and indicators mounted on them, thermo-hydraulic and electrical system model subroutines, standardized equipment handler subroutines, hard disks, tape backup systems, and instructor control panels are all examples of different systems that have to communicate with each other. As a thermo-hydraulic modeler, a lot of the interface work I did involved negotiating and implementing interfaces between my fluid models and those written by other engineers. Each full-scope simulator would include on the order of fifty different fluid systems along with a handful of electrical and equipment systems. Similarly, the furnace control systems I wrote had to communicate with several external systems that ran on other types of computers with different operating systems and controlled other machines in the production line. Data interfaces had to be negotiated and implemented between all of them, too. The same is true of the Node.js microservices that provided the back-end functionality accessed by users through web browsers and Android and iOS apps.
    • Application Programming Interfaces (APIs): APIs can be prepackaged collections of code in the form of libraries or frameworks, while microservices provide similarly centralized functionality. The point is that the interfaces are published so programs interacting with them can do so in known ways without having to worry (in theory) about the details what’s going on in the background.
    • Hardware devices: Communication with hardware devices isn’t much different than the communications described above. In fact, the interfaces described above often involve hardware communications. (See a brief rundown of the 7-layer OSI model here.)

    I’ve written a lot about inter-process communication in this series of blog posts.

    Data interfaces can be thought of at an abstract level and at a concrete level. Business analysts will often identify the data items that need to be collected, communicated, processed, stored, and so on, while software engineers and database analysts will design and implement the systems that actually carry out the specified actions. Both levels are part of the solution effort.

  25. Interviews: An interview is a systematic approach designed to elicit business analysis information from a person or group of people by talking to the interviewee(s), asking relevant questions, and documenting the responses. The interview can also be used for establishing relationships and building trust between business analysts and stakeholders in order to increase stakeholder involvement or build support for a proposed solution.

    Interviews involve talking to people. In this context the discussions can be about anything related to a process as it is mapped, in terms of its functional and non-functional characteristics. The discussions can be about individual components or entities, subsets of items, or the behavior of a system in its entirety.

    I’ve interviewed SMEs, executives, line workers, engineers, customers, and other stakeholders to learn what they do, what they need, and how their systems work. I’ve done this in many different industries in locations all over the world. The main thing I’ve learned is to be pleasant, patient, respectful, interested, and thorough. Being thorough also means writing down your findings for review by the interviewees, so they can confirm that you captured the information they provided correctly.

    This work is definitely part of the solution effort.

  26. Item Tracking: Item tracking is used to capture and assign responsibility for issues and stakeholder concerns that pose an impact to the solution.

    In the context described by the BABOK, the items discussed aren’t directly about the mapped components and entities of a system of interest. They are instead about the work items that need to be accomplished in order to meet the needs of the customers and stakeholders being served by the analyst. In that sense we’re talking about tracking all the meta-activities that have to get done to create or improve a mapped process.

    I really enjoy using a Requirements Traceability Matrix (RTM) to manage these meta-elements. If done the way I describe in my blog post (just linked, and here generally, and also throughout the BABOK), the work items and the mapped components and entities will all to accounted for and linked forward and backward through all phases of the engagement. Indeed, the entire purpose of my framework is to ensure the needs of the stakeholders are met by ensuring that all necessary components of a system or process are identified and instantiated or modified. This all has to happen in a way that provides the desired value.

    In the context discussed in the BABOK, this technique is used as part of the engagement effort.

  27. Lessons Learned: The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases.

    Like the item tracking technique described above, this is also kind of a meta-technique that deals with the engagement process and not the operational system under analysis. The point here is to review the team’s activities to capture what was done well and what could be done better in the future. This step is often overlooked by organizations and teams are created and disbanded without a lot of conscious review. It’s one of those things where you never have time to do it right but you always have time to do it over.

    It’s supposed to be a formal part of the Scrum process on a sprint and project basis, but it really should be done periodically in every engagement, and especially at the end (if there is an identifiable end). Seriously, take the time do do this.

    As stated, this technique is also used during the engagement process.

  28. Metrics and KPIs: Metrics and key performance indicators measure the performance of solutions, solution components, and other matters of interest to stakeholders.

    These are quantifiable measures of the performance of individual components, groups of components, and systems or processes as a whole. They’re also used to gauge the meta-progress of work being performed through an engagement.

    The BABOK describes an indicator as a numerical measure of something, while a metric is a comparison of an indicator to a desired value (or range of values). For example, an indicator is the number of widgets produced during a week, while a metric is whether or not that number is above a specific target, say, 15,000.

    Care should be taken to ensure that the indicators chosen are readily collectible, can be determined at a reasonable cost, are clear, are agreed-upon, and and are reliable and believed.

    Metrics and KPIs are identified as part of the solution effort. Note that the ongoing operation and governance of the solution by the customer, possibly after it has been delivered, is all part of the solution the BA and his or her colleagues should be thinking about.

  29. Mind Mapping: Mind mapping is used to articulate and capture thoughts, ideas, and information.

    I’ve never used an explicit mind-mapping tool, and I’ve only encountered one person who actively used one (as far as I know). That said, there are a lot of ways to accomplish similar ends without using an explicit software tool.

    This technique actually has a lot in common with the part of the functional decomposition technique that involves organizing identified concepts into logical groups. Brainstorming with Post-It notes is a manual form of mind-mapping, and the whole process of discovery and domain knowledge acquisition (as I describe them) is supposed to inspire this activity.

    For most of my life I’ve taken notes on unlined paper so I have the freedom to write and draw wherever I like to show relationships and conceptual groupings. Another way this happens is through being engaged with the material over time. I sometimes refer to this as wallowing in the material. Insights are gained and patterns emerge in the course of your normal work as long as you are mentally and emotionally present. These approaches might not work for everyone, but they’ve worked for me.

    This technique is primarily applied as part of the solution effort.

  30. Non-Functional Requirements Analysis: Non-functional requirements analysis examines the requirements for a solution that define how well the functional requirements must perform. It specifies criteria that can be used to judge the operation of a system rather than specific behaviors (which are referred to as the functional requirements).

    These define what a solution is rather than what it does. The mapped components of a process or system (the stations, queues, entries, exits, and aths along with the entities processed), define the functional behavior of the process or system. The non-functional characteristics of a process or system describe the qualities it must have to provide the desired value for the customer.

    Non-functional requirements are usually expressed in the form of -ilities. Examples are reliability, modularity, flexibility, robustness, maintainability, scalability, usability, and so on. Non-functional requirements can also describe how a system or process is to be maintained and governed.

    The figure at the bottom of this article graphically describes my concept of a requirements traceability matrix. Most of the lines connecting items in each phase are continuous from the Intended Use phase through to the Final Acceptance phase. These cover the functional behaviors of the system or process. The non-functional requirements, by contrast, are shown as beginning in the Requirements phase. I show them this way because the qualities the process or system needs to have are often a function of what it needs to do, and thus they may not be known until other things about the solution are known. That said, uptime and performance guarantees are often parts of contracts and identified project goals from the outset. When I was working the paper industry, for example, the reliability (see there? a non-functional requirement!) of the equipment was improving to the point that turnkey system suppliers were starting to guarantee 95% uptime where the previous standard had been 90%. I know that plant utilization levels in the nuclear industry have improved markedly over the years, as competing firms have continued to learn and improve.

    I include a few other lines at the bottom of the figure to show that the engagement meta-process itself might be managed according to requirements of its own. However, I consider non-functional requirements analysis to be part of the solution effort.

  31. Observation: Observation is used to elicit information by viewing and understanding activities and their context. It is used as a basis for identifying needs and opportunities, understanding a business process, setting performance standards, evaluating solution performance, or supporting training and development.

    Observation is basically the process of watching something to see how it works. It can be used during discovery and data collection activities.

    Observations are made as part of the solution effort.

  32. Organizational Modeling: Organizational modeling is used to describe the roles, responsibilities, and reporting structures that exist within an organization and to align those structures with the organization’s goals.

    Organizational models are often represented in the form of classic org charts. However, the different parts and functions within an organization can be mapped and modeled as stations (and other model components) or entities. Furthermore, entities are sometimes resources that are called from a service pool to a requesting process station to perform various actions. They may be called in varying numbers and for varying time spans based on the activities and defined business rules.

    This activity is performed during the solution effort.

  33. Prioritization: Prioritization provides a framework for business analysts to facilitate stakeholder decisions and to understand the relative importance of business analysis information.

    This technique refers to prioritizing work items through time and different phases of an engagement. It does not refer to the order in which operations must be carried out by the system under analysis, according to business and other identified rules.

    The BABOK describes four different approaches to prioritization. They are grouping, ranking, time boxing/budgeting, and negotiation. These are just specific approaches to doing a single, general thing.

    Prioritization in this context is absolutely part of the engagement effort.

  34. Process Analysis: Process analysis assesses a process for its efficiency and effectiveness, as well as its ability to identify opportunities for change.

    In a sense this is the general term for everything business analysts do when looking at how things are supposed to get done. That is, everything having to do with the functional parts of a process involve process analysis. Examination of the non-functional aspects of an operation, what things are as opposed to what they do, is still undertaken in support of a process, somewhere.

    In terms of a mapped process this technique involves identifying the components in or needed for a process, how to add or remove or modify components to change how it operates, how to move from a current state to a future state, and the impacts of proposed or real changes made.

    Interestingly, simulation is considered to be a method of process analysis and not process modeling. This is because the model is considered to be the graphical representation itself, according to the BABOK, while simulation is a means of analyzing the process. I suppose this distinction might matter on one question on a certification exam, but in the end these methods all flow together.

    Although the engagement effort is itself a process, this technique is intended to apply to the solution effort.

  35. Process Modeling: Process modeling is a standardized graphical model used to show how work is carried out and is a foundation for process analysis.

    Process models are essentially the graphical maps I’ve been describing all along, as they are composed of stations, queues, entries, exits, connections or paths, and entities. Information, physical objects, and activities of all kinds can be represented in a process map or model.

    When they say a picture is worth a thousand words, this is the kind of thing they’re talking about. In my experience, nothing enhances understanding and agreement more than a visual process model.

    The BABOK goes into some detail about the various methods that exist for creating process maps, but in my mind they’re more alike than different.

    This technique is clearly to be applied as part of the solution effort.

  36. Prototyping: Prototyping is used to elicit and validate stakeholder needs through an iterative process that creates a model or design of requirements. It is also used to optimize user experience, to evaluate design options, and as a basis for development of the final business solution.

    A prototype is a temporary or provisional instantiation of part or all of a proposed solution. Prototypes are created so they can be understood and interacted with. The idea of a prototypes is extremely flexible. They can range from temporary models made with throwaway materials to working bits of software to full-scale, flyable aircraft.

    A simulation of something can also serve as a prototype, especially simulations of systems with major physical components.

    Prototyping is absolutely part of the solution effort.

  37. Reviews: Reviews are used to evaluate the content of a work product.

    Work products in my framework are created in every phase of an engagement, and thus reviews should be conducted during every phase of the engagement. This is done to ensure that all parties are in agreement and that all work items have been addressed before moving on to the next phase. The review in each phase is performed iteratively until the work for that phase is agreed to be complete. If items are found to have been missed in a phase, the participants return to the previous phase and iteratively complete work and review cycles until it is agreed that attention can be returned to the current or future phases.

    Note that multiple items can be in different phases through any engagement. While each individual item is addressed through one of more phases, it is always possible for multiple work items to be in process in different phases simultaneously.

    Reviews are meta-processes that are part of the engagement effort.

  38. Risk Analysis and Management: Risk analysis and management identifies areas of uncertainty that could negatively affect value, analyzes and evaluates those uncertainties, and develops and manages ways of dealing with the risks.

    The subject of risk can be addressed at the level of individual components in mapped systems, especially when provisions for failures are built into models, but they are more often handled at the level of the system or engagement. The BABOK gives a good overview of risk analysis and management and many other materials are available.

    Risks are evaluated based on their likelihood of occurrence and their expected impact. There are a few straightforward techniques for calculating and tracking those, mostly involving risk registers and risk impact scales. The classic approaches to risk are generally categorized as avoid (take steps to prevent negative events from happening), transfer (share the risk with third parties, with the classic example being through insurance), mitigate (act to reduce the chances a negative event will occur or reduce the impact if it does occur), accept (deal with negative events as they occur and find workarounds), and increase (find ways to take advantage of new opportunities).

    Risk has been an important part of two classes of simulation work I’ve done. The first involved dealing with adverse occurrences in nuclear power plants. A variety of system failures (e.g., leaks and equipment malfunctions) were built into the fluid, electrical, and hardware models in the operator training simulators we built. If such failures happened in a real plant (see Three Mile Island, where a better outcome would have resulted if the operators had just walked away and let the plant shut down on its own), especially since the likelihood of any particular adverse event was rare, there would be the possibility that the operators would not know how to diagnose the problem in real time and take the proper corrective action. Building full scope training simulators reduced the risk of operating actual plants by giving operators the experience of reacting to a wide variety of failures they could learn how to diagnose and mitigate in a safe environment. In terms of mapped processes, the failure mechanisms were built in to the model components themselves (stations, paths or connections, entries, and exits, and so on), and controlled by training supervisors.

    The second way I worked with risk in the context of simulation was when I worked with Monte Carlo models. These involve running a simulation through multiple iterations where many of the outcomes are determined randomly. The combinations and permutations of how those many random events concatenate and interact can result in a wide variety of outcomes at the whole-system level. The purpose of these simulations was to learn how often negative system outcomes were going to occur (based on potentially thousands of possible failures that occurred at known rates), and work on ways to mitigate the effects of negative systemic outcomes.

    Risks are managed at both the solution and the engagement level. It is one of the most important considerations for any analyst or manager.

  39. Roles and Permissions Matrix: A roles and permissions matrix is used to ensure coverage of activities by denoting responsibility, to identify roles, to discover missing roles, and to communicate results of a planned change.

    This technique is used to determine what which actors are empowered to take which actions. In terms of system maps the actors will be represented as process blocks or possibly resources able to interact with an trigger other system events.

    In the context of the BABOK this analysis is part of the solution effort. It deals with how the customers will interact with the provided solution.

  40. Root Cause Analysis: Root cause analysis is used to identify and evaluate the underlying causes of a problem.

    Root cause analysis is always served by knowing more about the system being investigated. The more you know about the components and interactions of a system the easier it will be to determine the root cause of any outcome, whether desired or undesired.

    Process or system maps greatly aid in the understanding of a system and its behavior and the behavior of its components. Fishbone diagrams and The Five Whys are important sub-techniques used in this kind of analysis.

    This technique is used as part of the solution effort.

  41. Scope Modeling: Scope models define the nature of one or more limits or boundaries and place elements inside or outside those boundaries.

    Process or system maps make very clear what is within the scope and outside the scope of any system. Note that systems can be defined in many ways and that many subsystems can be aggregated to form a larger system. An example of this from my own experience is the creation of fifty or more separate fluid, electrical, and equipment handler models to construct a full scope operator training simulator.

    Scope boundaries are usually determined by grouping components together in a logical way so their interactions and effects have their greatest effect in a specified range of space, time, function, and actors (people). The scope of different systems also defines responsibility for outcomes related to them.

    An example of scope determined by space would be hydrological models where the flow of water is governed by the topology and composition of the landscape. An example of scope determined by time is the decision to include hardware and components that affect system behavior when a plant is operating to generate power, and not to include equipment like sample and cleanout ports that are only used when the plant is in a maintenance outage. An example of scope determined by function is the isolation of the logical components that filter reactor water to remove elements like boron and other particulates. An example of scope determined by actors is the assignment of permissions (or even requirements) to give approval for certain actions based on holding a certain credential, as in requiring sign-off by a civil engineer with a PE license or requiring a brain surgeon to have an M.D. and malpractice insurance.

    Analyzing the system’s components is an aspect of the solution effort, while determining what components and responsibilities are in and out of scope might be part of the engagement effort, since this may involve negotiation of what work does and does not get done.

  42. Sequence Diagrams: Sequence diagrams are used to model the logic of usage scenarios by showing the information passed between objects in the system through the execution of the scenario.

    Sequence diagrams are a specific kind of process map that organizes events in time. The specific methods for creating them are defined in the UML standard (I bought this book back in the day). The diagrams don’t necessarily show why things happen, but they do give insight into when they happen and in what order. They also show the messages (or objects) that are passed between the different packages of functionality.

    This detailed activity takes place in the context of the solution effort.

  43. Stakeholder List, Map, or Personas: Stakeholder lists, maps, and personas assist the business analyst in analyzing stakeholders and their characteristics. This analysis is important in ensuring that the business analyst identifies all possible sources of requirements and that the stakeholder is fully understood so decisions made regarding stakeholder engagement, collaboration, and communication are the best choices for the stakeholder and for the success of the initiative.

    Stakeholders are affected by work done to build or modify the process or system under investigation and by the work done through the phases of the engagement itself. They may be included as components or resources in process models. The degree to which they are affected by the current scope of work or are able to exert influence over the capabilities under analysis can be represented by onion diagrams or stakeholder matrices (of which the RACI Matrix is a classic example).

    This technique is definitely part of the engagement effort.

  44. State Modeling: State modeling is used to describe and analyze the different possible states of an entity within a system, how that entity changes from one state to another, and what can happen to the entity when it is in each state.

    A state model describes the conditions or configurations an object or component can be in, the triggers or events that cause the state to change, and the allowable states that can be transitioned to from any other state. Diagrams can show these transitions independent of any other process map or timing diagram or the concepts can be embedded or otherwise combined. In terms of the elements I’ve defined, stations, paths or connections, entities, resources, and even entries and exits can all change state if it makes sense in a given context.

    This work is always part of the solution effort.

  45. Survey or Questionnaire: A survey or questionnaire is used to elicit business analysis information—including information about customers, products, work practices, and attitudes—from a group of people in a structured way and in a relatively short period of time.

    The information gathered can relate to any aspect of work related to the solution or to the engagement.

  46. SWOT Analysis: SWOT analysis is a simple yet effective tool used to evaluate an organization’s strengths, weaknesses, opportunities, and threats to both internal and external conditions.

    These efforts are generally undertaken at the level of the behavior or capability of entire systems, though they can also be about technologies that can improve all or part of an existing system or even the work of one or more phases of an engagement.

    This technique is therefore applicable to both the solution effort and the engagement effort.

  47. Use Cases and Scenarios: Use cases and scenarios describe how a person or system interacts with the solution being modeled to achieve a goal.

    These are used in the design, requirements, and implementation phases of an engagement, to describe user actions to achieve certain ends. The are many ways to describe the qualities and capabilities a solution needs to have, and use cases are only one.

    While use cases are similar in many ways to user stories, they aren’t always exactly the same thing.

    These techniques are applied to describe detailed aspects of the solution.

  48. User Stories: A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

    Like use cases, user stories are an effective means for capturing and communicating information about individual features of a solution. Note that use cases are not to be confused with formal requirements.

    The technique is generally associated with the Agile paradigm in general and the Scrum methodology in particular. They are typically written in the following form, or something close to it: “As a user role, I would like to take some action so I can achieve some affect.”

    While this is a useful technique, I have the (possibly mistaken) impression that it is relied upon and otherwise required far in excess of its actual usefulness. For example, I would disagree with anyone who asserts that every backlog item must be written in the form of a user story.

    Like the use case technique from directly above, this technique is also applied as a detailed part of the solution effort.

  49. Vendor Assessment: A vendor assessment assesses the ability of a vendor to meet commitments regarding the delivery and the consistent provision of a product or service.

    Vendors may be evaluated for the ability to perform any work or deliver any value related to the solution or to the engagement.

  50. Workshops: Workshops bring stakeholders together in order to collaborate on achieving a predefined goal.

    These collaborations with groups of stakeholders can be used to gather information about or review any aspect of work on the solution effort or any phase of the engagement.

Here is a summary listing of the fifty BA techniques and the type of effort they most apply to.

BA Technique Effort Type
Backlog Management Engagement
Balanced Scorecard Engagement
Benchmarking and Market Analysis Engagement
Brainstorming Solution
Business Capability Analysis Engagement
Business Cases Both
Business Model Canvas Both
Business Rules Analysis Solution
Collaborative Games Engagement
Concept Modelling Solution
Data Dictionary Solution
Data Flow Diagrams Solution
Data Mining Solution
Data Modelling Solution
Decision Analysis Solution
Decision Modelling Solution
Document Analysis Solution
Estimation Engagement
Financial Analysis Both
Focus Groups Solution
Functional Decomposition Solution
Glossary Solution
Interface Analysis Solution
Interviews Solution
Item Tracking Engagement
Lessons Learned Engagement
Metrics and KPIs Solution
Mind Mapping Solution
Non-Functional Requirements Analysis Solution
Observation Solution
Organizational Modelling Solution
Prioritization Engagement
Process Analysis Solution
Process Modelling Solution
Prototyping Solution
Reviews Engagement
Risk Analysis and Management Both
Roles and Permissions Matrix Solution
Root Cause Analysis Solution
Scope Modelling Both
Sequence Diagrams Solution
Stakeholder List, Map, or Personas Engagement
State Modelling Solution
Survey or Questionnaire Both
SWOT Analysis Both
Use Cases and Scenarios Solution
User Stories Solution
Vendor Assessment Both
Workshops Both

Here are the counts for each type of effort:

Effort Type Number of Occurrences
Solution 30
Engagement 11
Both 9
Posted in Management | Tagged , | Leave a comment

Unified Theory of Business Analysis: Part One

Defining and Distinguishing Between the Solution Effort and the Engagement Effort

There seems to be a great deal of confusion in describing what business analysts do, since they often seem to be doing such different things. I’ve confirmed this after having taken a number of surveys of business analysts. I’ve also seen close to fifty presentations on the subject, taken a training course, earned a certification, followed a whole bunch of discussion on LinkedIn and elsewhere, and reviewed job ads until my eyes bled. I’ve thought about this subject a lot over the years and the answer has finally become rather clear to me.

I’ve worked through a number of engagements of various kinds. They’ve ranged from small to large, quick to long-lasting, and very ad hoc to very formal. What I noticed is that the smaller, shorter, less formal ones all involved the same activities as the larger, longer, formal ones, it’s just that they didn’t include every possible activity. And therein lies the discovery. I call it the Unified Theory of Business Analysis.

The reason so many BA efforts feel so different is because many efforts either do not include every activity, or because any one BA may only be involved in a limited part of a larger effort. This is true with respect to the multiple phases of an engagement through time, and to the multiple components of a solution’s scope are addressed.

I’m convinced that all of the phases of a full scale engagement are actually conducted during even the most slap-dash, ad hoc analysis effort. However, in many cases the context is so well understood that many of the steps I define in my business analysis framework are addressed implicitly to the point where no special effort is taken to do everything you can do in every possible phase. You could have a big, formal effort with kickoff and close-out meetings for every phase, or you could hear that Dwayne in shipping hates the new data entry screen and why don’t Diane and Vinay shoot down, find out what the confusion is, and put together a quick fix for him. In the latter case the Intended Use and Conceptual Model model phases are obviated and the remaining phases can be accomplished with minimal oversight, time, and fanfare. If an effort is simple enough it doesn’t require the overhead of requirements traceability matrices, change control boards, and a bunch of documentation (though the right people should be involved and the relevant documents and systems should be updated).

This is why things look different to BA practitioners and their managers and colleagues through the phases of an engagement through time, but it’s also possible that BAs will only be involved in a limited part of the solution effort, as I discussed and defined yesterday.

In short, I wanted to introduce this discussion be distinguishing between the solution effort, which is the process of defining and implementing the solution, and the engagement effort, which is the meta-process of managing the phases that support the solution. It may seem like a subtle distinction but it seemed important to me as I prepare for the next part of this discussion.

Posted in Management | Tagged , | Leave a comment

Components of a Solution

I wanted to define some terms and provide some context in preparation for the next few posts. Specifically, I’m describing the components of a solution. A process model is a model of a system that either does exist or will exist, either after it is implemented or after it is modified from an existing system. I’m going to be referring to the work needed to affect the solution itself as the solution or the solution effort over the next few days.

As called out in the diagram directly below, a model is made up of many standard components. I’ll refer to these repeatedly in the descriptions that follow, so I want to start by describing the components here.

  • System (or Model): A system is the entire system or process being investigated. A model is a representation of that system or process.
  • Entity: Entities are items that move around in the system. They can represent information or physical objects, including people. Entities will sometimes pass through a system (like cars going through a car wash) and sometimes move only within a system (like aircraft in a maintenance simulation or employees serving customers in a barber shop). Entities may split or spawn new entities at various points within the system, and can also be merged or joined together.
  • Entry: Entities of go into a system at entry points. Note that the entry can represent an exit point from an external system, and thus a connection with that system.
  • Station (or Process Block or Activity): These blocks are where the important activities and transformations happen. The important concepts associated with stations are processing time, diversion percentage (percentage of time entities being processed go to different destinations when they leave the station), and the nature of the transformations carried out on the entities being processed (if any). A wide variety of other characteristics and behaviors can be defined for these components, and those characteristics (like being open or closed, for example) can change as defined by a schedule.
  • Group (or Facility): A group of stations performing related operations is referred to as a facility. A toll plaza includes multiple stations that all do the same or very similar things. A loading dock that serves multiple trucks works the same way, where each space is a separate station. In a more information-driven setting, a roomful of customer service workers could be represented as individual stations, and collectively would be referred to as a group or facility.
  • Queue: A queue is where entities wait to be processed. FIFO, LIFO, and other types of queues can be defined. A queue can have a defined, finite capacity or an infinite capacity. If the queue has a physical component it might be given physical dimensions for length, area, or volume. A minimum traversal time may also be defined in such a case.
  • Path: A path defines how entities move from one non-path component to another. In logical or informational systems the time needed to traverse a path may be zero (or effectively zero), while length and speed may have to be defined for physical paths. The direction of movement along each path must also be specified. Paths are often one-way only, but can allow flow in both directions (although it’s often easier to include separate paths for items traveling in each direction).
  • Exit: Entities leave a system through exit components. Note that the exit can represent an entry point of an external system, and thus a connection with that system.
  • Bag (or Parking Lot): A bag is a special kind of queue where entities may be stored but may be processed at arbitrary times according to arbitrary criteria. They are used when their operations are not FIFO, LIFO, or some other obvious behavior. You can think of them like parking lots, where the residence time is determined by the amount of time it takes passengers to get out of the car, walk somewhere, conduct their business in some establishment, walk back to the car, get back in and buckled up, get their phone mounted and plugged in, take a swing of their coffee, set the GPS for their next destination, get their audiobook playing, readjust their mirrors, and finally start pulling out. In such a case the car will be represented by an entity that continues to take up space in the parking lot (or bag), while the passenger is a new entity that is spawned or split from the car entity, and then later merged or rejoined back with it.
  • Combined (Queue and Process): It is possible to define components that embody the characteristics of both a station and a queue. This is typically done for representational simplicity.
  • Resource (not shown): A resource is something that must be available to carry out an operation. Resources can be logical (like electricity or water, though they can be turned off or otherwise fail to be available) or they can be discrete, like mechanics in a repair shop. When a car pulls into a station or process block (representing a space in a garage) a mechanic has to go to perform the service. Sometimes multiple mechanics are needed to carry out an operation. Sometimes different specialists are needed to perform certain actions. Discrete resources can be represented by entities in a system. If no, or not enough, resources are available, the the process waits for them to become available, and only starts its clock when they do.
  • Resource Pool (not shown): Resources can be drawn from a collection, which itself is referred to as a pool. There can be one or multiple pools of resources for different purposes and the resources can have different characteristics. There may be different numbers and types of resources available at different times, and this can be defined according to a schedule.
  • Component: All of the items listed above — except the system itself — are referred to as system (or model) components.

That just describes some of the major items I tend to include in process models. Here are some of the others that are possible.

  • Event: Events are occurrences or changes of state that trigger a change to some other component in a system.
  • Decision Point: These control elements govern the movement of entities through the system, either logically or physically. The diversion percentage characteristic described for stations, above, is an example of embedding a decision point into another component. However, decision points can be included in models as standalone components. In my experience they are usually connected by paths and not other components, but that is an implementation detail.
  • Role: This represents a person or group involved in the process. Roles can be modeled as stations or resources, as described above, but they can also be included as other kinds of components, depending on the implementation.

If the process model is itself a simulation there is yet another layer of components can be added. These are meta-elements that control the simulation and its components. Simulations are often called models, although the BABOK reserves the word model for the graphical representation of a system and associates simulation with the concept of process analysis.

  • Editing interface for the system: This allows a user to add, remove or reconfigure components within the system.
  • Editing interface for components: This allows a user to define or modify the operational characteristics of the components. This can include schedules, events, arrivals, and other items, as well as traditional elements like durations, dimensions, and capacities.
  • Operational interface: This allows a user to start, pause, and stop the simulation.
  • Data analysis capability: Simulations are generally implemented to generate a lot of output data. They can also require a lot of complex input data. Integrated analysis capabilities are sometimes included in simulation tools.
Posted in Tools and methods | Tagged , , , | Leave a comment

Combined Survey Results, Updated (March 2019)

With the addition of survey data taken at recent meetups in Orlando and Tampa, the combined results are updated here.

List 5-8 steps you take during a typical project.

These vary, but mostly follow a recognizable pattern, in rough keeping with what the BABOK describes.

  1. Requirements Gathering
  2. Initiation
  3. Testing
  4. QA
  5. Feedback
  6. User acceptance
  1. Requirement Elicitation
  2. UX Design
  3. Software Design for Testability
  1. Identify Business Goal
  2. ID Stakeholders
  3. Make sure necessary resources are available
  4. Create Project Schedule
  5. Conduct regular status meetings
  1. Meet with requester to learn needs/wants
  2. List details/wants/needs
  3. Rough draft of Project/proposed solutions
  4. Check in with requester on rough draft
  5. Make edits/adjustments | test
  6. Regularly schedule touch-point meeting
  7. Requirement analysis/design | functional/non-functional
  8. Determine stakeholders | user acceptance
  1. List the stakeholders
  2. Read through all documents available
  3. Create list of questions
  4. Meet regularly with the stakeholders
  5. Meet with developers
  6. Develop scenarios
  7. Ensure stakeholders endorse requirements
  8. other notes
    • SMART PM milestones
    • know players
    • feedback
    • analysis steps
    • no standard
  1. identify stakeholders / Stakeholder Analysis
  2. identify business objectives / goals
  3. identify use cases
  4. specify requirements
  5. interview Stakeholders
  1. project planning
  2. user group sessions
  3. individual meetings
  4. define business objectives
  5. define project scope
  6. prototype / wireframes
  1. identify audience / stakeholders
  2. identify purpose and scope
  3. develop plan
  4. define problem
  5. identify objective
  6. analyze problems / identify alternative solutions
  7. determine solution to go with
  8. design solution
  9. test solution
  1. gathering requirements
  2. assess stakeholder priorities
  3. data pull
  4. data scrub
  5. data analysis
  6. create summary presentation
  1. define objective
  2. research available resources
  3. define a solution
  4. gather its requirements
  5. define requirements
  6. validate and verify requirements
  7. work with developers
  8. coordinate building the solutions
  1. requirements elicitation
  2. requirements analysis
  3. get consensus
  4. organizational architecture assessment
  5. plan BA activities
  6. assist UAT
  7. requirements management
  8. define problem to be solved
  1. understand thhe business need of the request
  2. understand why the need is important – what is the benefit/value?
  3. identify the stakeholders affected by the request
  4. identify system and process impacts of the change (complexity of the change)
  5. understand the cost of the change
  6. prioritize the request in relation to other requests/needs
  7. elicit business requirements
  8. obtain signoff on business requests / validate requests
  1. understanding requirements
  2. writing user stories
  3. participating in Scrums
  4. testing stories
  1. research
  2. requirements meetings/elicitation
  3. document requirements
  4. requirements approvals
  5. estimation with developers
  6. consult with developers
  7. oversee UAT
  8. oversee business transition
  1. brainstorming
  2. interview project owner(s)
  3. understand current state
  4. understand need / desired state
  5. simulate / shadow
  6. inquire about effort required from technical team
  1. scope, issue determination, planning
  2. define issues
  3. define assumptions
  4. planning
  5. ccommunication
  6. analysis – business and data modeling
  1. gather data
  2. sort
  3. define
  4. organize
  5. examples, good and bad
  1. document analysis
  2. interviews
  3. workshops
  4. BRD walkthroughs
  5. item tracking
  1. ask questions
  2. gather data
  3. clean data
  4. run tests
  5. interpret results
  6. visualize results
  7. provide conclusions
  1. understand current state
  2. understand desired state
  3. gap analysis
  4. understand end user
  5. help customer update desired state/vision
  6. deliver prioritized value iteratively
  1. define goals and objectives
  2. model As-Is
  3. identify gaps/requirements
  4. model To-Be
  5. define business rules
  6. conduct impact analysis
  7. define scope
  8. identify solution / how
  1. interview project sponsor
  2. interview key stakeholders
  3. read relevant information about the issue
  4. form business plan
  5. communicate and get buy-in
  6. goals, objectives, and scope
  1. stakeholder analysis
  2. requirements gathering
  3. requirements analysis
  4. requirements management – storage and updates
  5. communication – requirements and meetings
  1. analyze evidence
  2. desiign application
  3. develop prototype
  4. implement product
  5. evaluate product
  6. train users
  7. upgrade functionality
  1. read material from previous similar projects
  2. talk to sponsors
  3. web search on topic
  4. play with current system
  5. ask questions
  6. draw BPMs
  7. write use cases
  1. document current process
  2. identify users
  3. meet with users; interview
  4. review current documentation
  5. present proposed solution or iteration
  1. meeting with stakeholders
  2. outline scope
  3. research
  4. write requirements
  5. meet and verify with developers
  6. test in development and production
  7. outreach and maintenance with stakeholders
  1. As-In analysis (current state)
  2. write lightweight business case
  3. negotiate with stakeholders
  4. write user stories
  5. User Acceptance Testing
  6. cry myself to sleep 🙂
  1. initiation
  2. elicitation
  3. discussion
  4. design / user stories / use cases
  5. sign-off
  6. sprints
  7. testing / QA
  8. user acceptance testing
  1. planning
  2. elicitation
  3. requirements
  4. specification writing
  5. QA
  6. UAT
  1. identify the problem
  1. studying subject matter
  2. planning
  3. elicitation
  4. functional specification writing
  5. documentation
  1. identify stakeholders
  2. assess working approach (Waterfall, Agile, Hybrid)
  3. determine current state of requirements and maturity of project vision
  4. interview stakeholders
  5. write and validate requirements
  1. problem definition
  2. value definition
  3. decomposition
  4. dependency analysis
  5. solution assessment
  1. process mapping
  2. stakeholder interviews
  3. write use cases
  4. document requirements
  5. research
  1. listen – to stakeholders and customers
  2. analyze – documents, data, atc. to understand thhings further
  3. repeat back what I’m hearing to make sure I’m understanding correctly
  4. synthesize – the details
  5. document – as needed(e.g., Visio diagramsPowerPoint decks, Word, tool, etc.)
  6. solution
  7. help with implementing
  8. assess and improve – if/as needed
  1. understand the problem
  2. understand the environment
  3. gather the requirements
  4. align with IT on design
  5. test
  6. train
  7. deploy
  8. follow-up
  1. watch how it is currently done
  2. listen to clients’ pain points
  3. define goals of project
  1. critical path tasks
  2. pros/cons of tasks
  3. impacts
  4. risks
  5. goals
  1. discovery – high level
  2. analysis / evaluation
  3. presentation of options
  4. requirements gathering
  5. epic / feature / story definition’
  6. prioritization
  1. who is driving the requirements?
  2. focus on what is needed for project
  3. who is going to use the product?
  1. elicit requirements
  2. hold focus groups
  3. create mock-ups
  4. test
  5. write user stories
  1. analyze
  2. document process
  3. identify waste (Lean)
  4. communicate
  5. document plan / changes
  1. meeting
  2. documentation
  3. strategy
  4. execution plan
  5. reporting plan

List some steps you took on a weird or non-standard project.

I’m not sure these responses are too out of the ordinary. I think that once BAs become more experienced they see these are just variations on familiar themes. That said, most practitioners won’t understand this until they actually have that experience. This work is an attempt to illuminate the larger picture for them ahead of time. It is also, of course, interesting to hear what people think is unexpected or nonstandard.

  • Steps:
    1. Why is there a problem? Is there a problem?
    2. What can change? How can I change it?
    3. How to change the process for lasting results
  • A description of “weird” usually goes along with a particular person I am working with rather than a project. Some people like things done a certain way or they need things handed to them or their ego stroked. I accommodate all kinds of idiosyncrasies so that I can get the project done on time.
  • adjustments in project resources
  • after initial interview, began prototyping and iterated through until agreed upon design
  • built a filter
  • create mock-ups and gather requirements
  • create strategy to hit KPIs
  • data dictionary standardization
  • describing resource needs to the customer so they better understand how much work actually needs to happen and that there isn’t enough staff
  • design sprint
  • design thinking
  • developers and I create requirements as desired
  • document requirements after development work has begun
  • documented non-value steps in a process new to me
  • explained project structure to stakeholders
  • For a client who was unable to clearly explain their business processes and where several SMEs had to be consulted to form the whole picture, I drew workflows to identify inputs/outputs, figure out where the gaps in our understanding existed, and identify the common paths and edge cases.
  • guided solutioning
  • identified handoffs between different contractors
  • identify end results
  • interview individuals rather than host meetings
  • investigate vendor-provided code for business process flows
  • iterative development and delivery
  • made timeline promises to customers without stakeholder buy-in/signoff
  • make excutive decisions withoutstakeholder back-and-forth
  • moved heavy equipment
  • observe people doing un-automated process
  • personally evaluate how comitted mgt was to what they said they wanted
  • phased delivery / subject areas
  • physically simulate each step of an operational process
  • regular status reports to CEO
  • resources and deliverables
  • reverse code engineering
  • review production incident logs
  • simulation
  • start with techniques from junior team members
  • starting a project without getting agreed funding from various units
  • statistical modeling
  • surveys
  • team up with PM to develop a plan to steer the sponsor in the right diection
  • town halls
  • track progress in PowerPoint because the sponsor insisted on it
  • train the team how to read use case diagrams
  • translating training documents into Portuguese
  • travel to affiliate sites to understand their processes
  • understanding cultural and legal requirements in a foreign country
  • use a game
  • using a ruler to estimate level of effort to digitize paper contracts in filing cabinets gathered over 40 years
  • work around manager who was afraid of change – had to continually demonstrate the product, ease of use, and savings
  • worked with a mechanic
  • write requirements for what had been developed

Name three software tools you use most.

This is probably the most interesting part of the survey for me. Excel, MS Office products, and collaboration and cummunication products get the most use by BAs, which shouldn’t be surprising. Actual programming tools are almost exclusively the domain of developers, it seems. I’ve done both, but in general there doesn’t seem to be a lot of crossover. The same goes for hardcore use of database tools.

  • Excel (24)
  • Jira (14)
  • Visio (14)
  • Word (13)
  • Confluence (8)
  • Outlook (7)
  • SharePoint (6)
  • Azure DevOps (5)
  • MS Team Foundation Server (4)
  • PowerPoint (4)
  • email (3)
  • Google Docs (3)
  • MS Dynamics (2)
  • MS Visual Studio (2)
  • Notepad (2)
  • OneNote (2)
  • SQL Server (2)
  • Version One (2)
  • Adobe Reader (1)
  • all MS products (1)
  • ARC / Knowledge Center(?) (Client Internal Tests) (1)
  • Basecamp (1)
  • Blueprint (1)
  • Bullhorn (1)
  • CRM (1)
  • database, spreadsheet, or requirement tool for managing requirements (1)
  • Doors (1)
  • Enbevu(?) (Mainframe) (1)
  • Enterprise Architect (1)
  • Gephi (dependency graphing) (1)
  • Google Calendar (1)
  • Google Drawings (1)
  • illustration / design program for diagrams (1)
  • Kingsway Soft (1)
  • LucidChart (1)
  • MS Office (1)
  • MS Office tools (1)
  • MS Project (1)
  • MS Word developer tools (1)
  • NUnit (1)
  • Power BI (1)
  • Process 98 (1)
  • Python (1)
  • R (1)
  • requirements repositories, e.g., RRC, RTC (1)
  • RoboHelp (1)
  • Scribe (1)
  • Scrumhow (?) (1)
  • Siebel (1)
  • Skype (1)
  • Slack (1)
  • SnagIt (1)
  • SQL (1)
  • Tableau (1)
  • Visible Analyst (1)

Name three non-software techniques you use most.

These should roughly correspond to the 50 business analysis techniques described in the BABOK, but a lot of creativity and personal interaction is also in evidence. It’s also likely that more of these items could be aggregated, since they are so close, but for now I’m trying to preserve the original language of the survey respondents as much as possible.

  • communication (3)
  • interviews (3)
  • meetings (2)
  • process mapping (2)
  • prototyping (2)
  • relationship building (2)
  • wireframing (2)
  • “play package” (1)
  • 1-on-1 meetings to elicit requirements (1)
  • active listening (1)
  • analysis (1)
  • analyze audience (1)
  • apply knowledge of psychology to figure out how to approach the various personalities (1)
  • business process analysis (1)
  • calculator (1)
  • change management (1)
  • coffees with customers (1)
  • coffees with teams (1)
  • collaboration (1)
  • conference calls (1)
  • conflict resolution and team building (1)
  • costing out the requests (1)
  • critical questioning (1)
  • critical questioning (ask why fiive times), funnel questioning (1)
  • data analysis (1)
  • data modeling (1)
  • decomposition (1)
  • design thinking (1)
  • develop scenarios (1)
  • development efforts (1)
  • diagramming/modeling (1)
  • documentation (1)
  • documenting notes/decisions (1)
  • drinking (1)
  • elicitation (1)
  • expectation level setting (1)
  • face-to-face technique (1)
  • facilitiation (1)
  • fishbone diagram (1)
  • Five Whys (1)
  • focus groups (1)
  • handwritten note-taking (1)
  • hermeneutics / interpretation of text (1)
  • impact analysis (1)
  • individual meetings (1)
  • informal planning poker (1)
  • initial mockups / sketches (1)
  • interview end user (1)
  • interview stakeholders (1)
  • interview users (1)
  • interviewing (1)
  • JAD sessions (Joint Application Development Sessions) (1)
  • listening (1)
  • lists (1)
  • meeting facilitation (prepare an agenda, define goals, manage time wisely, ensure notes are taken and action items documented) (1)
  • notes (1)
  • observation (1)
  • organize (1)
  • paper (1)
  • pen and paper (1)
  • phone calls and fate-to-face meetings (1)
  • Post-It notes (Any time of planning or breaking down of a subject, I use different colored Post-Its, writing with a Sharpie, on the wall. This allows me to physically see an idea from any distance. I can also move and categorize at will. When done, take a picture.) (1)
  • prioritization (MOSCOW) (1)
  • process decomposition (1)
  • process design (1)
  • process flow diagrams (1)
  • process modeling (1)
  • prototyping (can be on paper) (1)
  • recognize what are objects (nouns) and actions (verbs) (1)
  • requirements meetings (1)
  • requirements verification and validation (1)
  • responsibility x collaboration using index cards (1)
  • rewards (food, certificates) (1)
  • Scrum Ceremonies (1)
  • Scrums (1)
  • shadowing (1)
  • sketching (1)
  • spreadsheets (1)
  • stakeholder analysis (1)
  • stakeholder engagement (1)
  • stakeholder engagement – visioning to execution and post-assessment (1)
  • stakeholder interviews (1)
  • surveys (1)
  • swim lanes (1)
  • taking notes (1)
  • test application (1)
  • training needs analysis (1)
  • use paper models / process mapping (1)
  • user group sessions (1)
  • user stories (1)
  • visual modeling (1)
  • whiteboard diagrams (1)
  • whiteboard workflows (1)
  • whiteboarding (1)
  • workflows (1)
  • working out (1)

Name the goals of a couple of different projects.

  • add enhancements to work flow app
  • adhere to regulatory requirements
  • adjusting solution to accommodate the needs of a new/different user base
  • automate a manual form with a workflow
  • automate a manual login/password generation and dissemination to users
  • automate a manual process
  • automate a manual process, reduce time and staff to accomplish a standard organizational function
  • automate a paper-based contract digitization process
  • automate and ease reporting (new tool)
  • automate highly administrative, easily repeatable processes which have wide reach
  • automate new process
  • automate the contract management process
  • automate the process of return goods authorizations
  • automate workflow
  • automate workflows
  • automation
  • block or restore delivery service to areas affected by disasters
  • bring foreign locations into a global system
  • build out end user-owned applications into IT managed services
  • business process architecture
  • clear bottlenecks
  • consolidate master data
  • create a “how-to” manual for training condo board members
  • create a means to store and manage condo documentation
  • create a reporting mechanism for healthcare enrollments
  • data change/update
  • data migration
  • design processes
  • develop a new process to audit projects in flight
  • develop and interface between two systems
  • develop data warehouse
  • develop effort tracking process
  • develop new functionality
  • develop new software
  • document current inquiry management process
  • enhance system performance
  • establish standards for DevOps
  • establish vision for various automation
  • I work for teams impplementing Dynamics CRM worldwide. I specialize in data migration and integration.
  • implement data interface wiith two systems
  • implement new software solution
  • implement software for a new client
  • implement vendor software with customizations
  • improve a business process
  • improve system usability
  • improve the usage of internal and external data
  • improve user interface
  • include new feature on mobile application
  • increase revenue and market share
  • integrate a new application with current systems/vendors
  • maintain the MD Product Evaluation List (online)
  • map geographical data
  • merge multiple applications
  • migrate to a new system
  • move manual Excel reports online
  • process data faster
  • process HR data and store records
  • provide business recommendations
  • recover fuel-related cost fluctuations
  • redesign
  • redesign a system process to match current business needs
  • reduce technical debt
  • re-engineer per actual user requirements
  • reimplement solution using newer technology
  • replace current analysis tool with new one
  • replace manual tools with applications
  • replatform legacy system
  • simplify / redesign process
  • simplify returns for retailer and customer
  • standardize / simplify a process or interface
  • system integration
  • system integration / database syncing
  • technical strategy for product
  • transform the customer experience (inside and outside)
  • update a feature on mobile app
  • update the e-commerce portion of a website to accept credit and debit cards
Posted in Tools and methods | Tagged , , , , , | Leave a comment

Business Analysis Survey: Round Five

I collected more survey responses at the recent Tampa IIBA meetup, and the results are posted below.

List 5-8 steps you take during a typical project.

  1. listen – to stakeholders and customers
  2. analyze – documents, data, atc. to understand thhings further
  3. repeat back what I’m hearing to make sure I’m understanding correctly
  4. synthesize – the details
  5. document – as needed(e.g., Visio diagramsPowerPoint decks, Word, tool, etc.)
  6. solution
  7. help with implementing
  8. assess and improve – if/as needed
  1. understand the problem
  2. understand the environment
  3. gather the requirements
  4. align with IT on design
  5. test
  6. train
  7. deploy
  8. follow-up
  1. watch how it is currently done
  2. listen to clients’ pain points
  3. define goals of project
  1. critical path tasks
  2. pros/cons of tasks
  3. impacts
  4. risks
  5. goals
  1. discovery – high level
  2. analysis / evaluation
  3. presentation of options
  4. requirements gathering
  5. epic / feature / story definition’
  6. prioritization
  1. who is driving the requirements?
  2. focus on what is needed for project
  3. who is going to use the product?
  1. elicit requirements
  2. hold focus groups
  3. create mock-ups
  4. test
  5. write user stories
  1. analyze
  2. document process
  3. identify waste (Lean)
  4. communicate
  5. document plan / changes
  1. meeting
  2. documentation
  3. strategy
  4. execution plan
  5. reporting plan

List some steps you took on a weird or non-standard project.

  • built a filter
  • create strategy to hit KPIs
  • design sprint
  • design thinking
  • identify end results
  • moved heavy equipment
  • resources and deliverables
  • start with techniques from junior team members
  • translating training documents into Portuguese
  • understanding cultural and legal requirements in a foreign country
  • worked with a mechanic

Name three software tools you use most.

  • Excel (6)
  • Outlook (5)
  • Jira (3)
  • Azure DevOps (2)
  • MS Dynamics (2)
  • MS Teams (2)
  • SharePoint (2)
  • Bullhorn (1)
  • Confluence (1)
  • Kingsway Soft (1)
  • MS Office tools (1)
  • Power BI (1)
  • PowerPoint (1)
  • Scribe (1)
  • Siebel (1)
  • Skype (1)
  • Slack (1)
  • Version One (1)
  • Visio (1)
  • Visual Studio Team Services (now Azure DevOps) (VSTS) (1)
  • Word (1)

Name three non-software techniques you use most.

  • change management
  • coffees with customers
  • coffees with teams
  • collaboration
  • conference calls
  • design thinking
  • development efforts
  • documenting notes/decisions
  • drinking
  • face-to-face technique
  • focus groups
  • interviewing
  • interviews
  • prioritization (MOSCOW)
  • process design
  • prototyping (can be on paper)
  • relationship building
  • sketching
  • stakeholder engagement
  • stakeholder engagement – visioning to execution and post-assessment
  • working out

Name the goals of a couple of different projects.

  • add enhancements to work flow app
  • automate highly administrative, easily repeatable processes which have wide reach
  • automate workflow
  • automate workflows
  • bring foreign locations into a global system
  • business process architecture
  • consolidate master data
  • design processes
  • develop new software
  • establish standards for DevOps
  • establish vision for various automation
  • I work for teams impplementing Dynamics CRM worldwide. I specialize in data migration and integration.
  • improve the usage of internal and external data
  • replace manual tools with applications
  • simplify / redesign process
  • standardize / simplify a process or interface
  • technical strategy for product
  • transform the customer experience (inside and outside)
Posted in Tools and methods | Tagged , , , , , | Leave a comment

Communicating With Leaders

Yesterday I attended the Tampa IIBA’s chapter meeting to see the presentation given by Kara Sundar, titled Communicating With Leaders: Increase Your Productivity and Influence. The presentation was very effective and based on materials from the book Change Intelligence by Barbara Trautlein.

Ms. Sundar described how people with different viewpoints contribute to and shape projects in different ways, based on their individual concerns, roles, and outlooks. Three primary axes are defined, as shown in the first figure below. The three axes are defined as “Head,” “Heart,” and “Hands,” which you can otherwise think of as thinking, feeling, and doing.

Six roles are then defined with respect to these axes as follows. Primary concerns of each role are listed in the bullets and in the second image below.

  • Visionary: Centered on high end of head axis
    • Strategy, Goals, Objectives, Opportunities, Outcomes
  • Champion: Between high ends of head and heart axes
    • Impact, Stakeholders, Benefits, Performance, Success, Results
  • Coach: Centered on high end of heart axis
    • Engagement, Development, Team Dynamics, Buy-In, Clients & Customers, Feedback
  • Facilitator: Between high ends of heart and hands axes
    • Process, Workflow, Evaluation, Learning Plan, Training Material, Documentation
  • Executer: Centered on high end of hands axis
    • Plan, Metrics, Deadline, Testing, Tickets/Tracking, Budget
  • Driver: Between high ends of hands and head axes
    • Plan, Execution, Milestones, KPIs, Decisions, Dashboards, Commitment
  • Adapter: Centered around the origin of the intersection of all aces
    • Essentially a hybrid of all the other roles

The context of the presentation was that different kinds of people approach activities in different ways. Understanding the different possibilities can provide some insight into why your co-workers, customers, and stakeholders might see things differently than you do, and also suggest guidance for bridging those gaps. In that regard it serves sort of the same function as Myers-Briggs Personality Indicators which, whether you like them or not, at least give some appreciation that people can be different and how they might be understood and approached. (This book describes potential MBTI applications in the workplace.) No such representation is going to be perfect, but each can serve as a useful point of departure for thinking about things.

Barbara Trautlein included a radar chart of the prevalence of the outlooks in the general population, which she probably derived from survey data she collected. It showed the occurrence from most to least prevalent to be (roughly) Champion (22%), Coach (20%), Visionary (17%), Adapter (15%), Executer (11%), Driver (8%), and Facilitator (7%). Graphically, this skews up and left on the triangular plot. One might be tempted to observe that more people seem to care about how the work gets done than about actually doing it, but, when Ms. Sundar tried to survey the room, the BA practitioners there skewed hard to the lower right. (I’ve done so much of all these I’ve become an adapter, but I definitely skewed towards the practitioner-doer end of things when I started out.)

I generally like frameworks that try to classify concepts in a useful way, but it took me a while to let this sink in. My original impression was that this classification was the flip side of the Nine SDLC Cross-Functional Areas breakdown defined by Kim Hardy that I wrote about a couple of years ago. Ms. Hardy defines nine team roles in terms of realizing different functional parts of a solution (Business Value, User Experience, Process Performance, Development Process, System Value, System Integrity, Implementation, Application Architecture, and Technical Architecture). These are more the whats of a project, which is contrasted with the schema Ms. Sundar described, which defines the hows. There’s a hair of overlap, but I think the formulations are trying to get at different things. Both, of course, are useful and thought-provoking.

This made me think about my own analytic and procedural framework, which defines a series of iterative phases that guide progress through a project or engagement. My phases are Planning, Intended Use, Assumptions/Capabilities/Risks, Conceptual Model, Data Sources, Requirements, Design, Implementation, Test, and Acceptance. (This can be shortened to Intended Use, Conceptual Model, Requirements, Design, Implementation, and Test.) This framework tries to incorporates the hows and the whats through time. It’s not a stretch to map the Change Intelligence or SDLC Cross-Functional roles to the phases in my framework.

In fact, let’s try it. Not only am I going to try to map the Change Intelligence and SDLC roles to the phases in my framework, I’m going to map yet another set of defined roles to it, based on the roles I’ve served in over the years.

  • Bob’s Framework Phase: Planning
    • CI Roles: Driver, Executer, Coach, Visionary, Champion
    • SDLC Roles: Business Value, System Value, Application Architecture
    • Bob’s Roles: Systems Analyst, Project/Program Manager, Full Life Cycle Engineer
  • Bob’s Framework Phase: Intended Use
    • CI Roles: Facilitator, Visionary, Champion
    • SDLC Roles: Business Value, System Value, Application Architecture, Technical Architecture
    • Bob’s Roles: Systems Analyst, Project/Program Manager, Full Life Cycle Engineer
  • Bob’s Framework Phase: Assumptions/Risks
    • CI Roles: Driver, Visionary, Champion
    • SDLC Roles: Business Value, System Value, Application Architecture
    • Bob’s Roles: Systems Analyst, Project/Program Manager, Full Life Cycle Engineer
  • Bob’s Framework Phase: Conceptual Model
    • CI Roles: Coach, Facilitator, Champion
    • SDLC Roles: Business Value, System Value, Application Architecture
    • Bob’s Roles: Systems Analyst, Product Owner, Discovery Lead
  • Bob’s Framework Phase: Data Sources
    • CI Roles: Driver, Executor, Facilitator, Champion
    • SDLC Roles: Business Value, User Experience, System Value, System Integrity, Application Architecture, Technical Architecture
    • Bob’s Roles: Systems Analyst, Product Owner, Data Collector, Data Analyst
  • Bob’s Framework Phase: Requirements
    • CI Roles: Driver, Executer, Coach, Facilitator
    • SDLC Roles: Business Value, User Experience, Process Performance, System Value, System Integrity, Application Architecture, Technical Architecture
    • Bob’s Roles: Systems Analyst, System Architect, Software Engineer, Product Owner, Project/Program Manager, Full Life Cycle Engineer
  • Bob’s Framework Phase: Design
    • CI Roles: Executor, Coach, Facilitator
    • SDLC Roles: Business Value, User Experience, Process Performance, Development Process, System Value, System Integrity, Implementation, Application Architecture, Technical Architecture
    • Bob’s Roles: Systems Analyst, System Architect, Software Engineer, Product Owner, Project/Program Manager, Full Life Cycle Engineer
  • Bob’s Framework Phase: Implementation
    • CI Roles: Driver, Executer, Coach, Facilitator
    • SDLC Roles: User Experience, Process Performance, Development Process, System Integrity, Implementation, Application Architecture, Technical Architecture
    • Bob’s Roles: Systems Analyst, System Architect, Software Engineer, Product Owner, Project/Program Manager, Full Life Cycle Engineer
  • Bob’s Framework Phase: Test
    • CI Roles: Driver, Executer, Coach, Facilitator
    • SDLC Roles: User Experience, Process Performance, Development Process, System Integrity, Implementation
    • Bob’s Roles: Systems Analyst, System Architect, Software Engineer, Product Owner, Project/Program Manager, Full Life Cycle Engineer
  • Bob’s Framework Phase: Acceptance
    • CI Roles: Driver, Executer, Coach, Facilitator, Visionary, Champion
    • SDLC Roles: Business Value, User Experience, Process Performance, System Value, System Integrity, Application Architecture, Technical Architecture
    • Bob’s Roles: Systems Analyst, System Architect, Product Owner, Project/Program Manager, Full Life Cycle Engineer

This is not the cleanest of exercises as you can see, which is an indication that every role and outlook applies across a variety of activities. Some of the activities I listed on my Roles page are so general or otherwise apply out of context that I didn’t include them here. They are, Tech Lead, Simulation Engineer, Operations Research Analyst, Control Systems Engineer, Field Engineer, and Process Improvement Specialist. The Independent VV&A activity from my Portfolio page indicates that I should also define a role of Test and V&V Agent, since I’ve served in that role in many projects and contexts, even if I haven’t done it in a specialized, standalone capacity in an organization. The Program Manager role should probably be applied only to the beginning and ending phases of individual efforts, leaving Project Managers to handle the details during each one.

Other roles, like ScrumMaster and Scrum Developer can overlap the above roles and phases in different ways. Other functional specialties haven’t been included in these discussions, either. They include roles like Database Analyst/Developer, Graphic Artist, and UI/UX Designer, and perhaps even Business Analyst (I see a systems analyst as being more general). The number of roles that can be defined are potentially endless, which probably contributes to some of the confusion which exists in the practice of business analysis. To that end I’ve been working on a Unified Theory of Business Analysis, which I’ll be writing about in the coming days.

Posted in Management | Tagged , , , , , | Leave a comment

A Simulationist’s Framework for Business Analysis: Round Four

Yesterday I gave my talk at the Orlando IIBA chapter meetup. The updated presentation is here:

https://www.rpchurchill.com/presentations/zSimFrameForBA_Orlando/SimFrameForBA.html

This presentation was a bit different than previous ones because I’ve begun to add some new material dealing with what I call The Unified Theory of Business Analysis. I call it this because the surveys I’ve conducted (previous combined results are here) show that the contexts in which people perform business analysis can vary widely. This effort has been my attempt to get a handle on the practice and communicate my findings to an audience.

Specifically, I’m coming to the conclusion that the reason things look so different to different practitioners is because most people are only trying to solve a limited problem most of the time. My framework describes a process for conducting a full scope engagement from beginning to end, and most people — and certainly most business analysts — typically find themselves involved in a limited subset of such efforts.

Let’s look at a possible map of an entire (small) business or physical process.

Let’s also consider the process of completing an end-to-end process as a whole.

The first question we might ask is How can the 50 BA Techniques from the BaBOK be applied? We can imagine that some techniques are best applied to certain subparts of an operational process and during certain phases in time of a project process.

The next question to ask might be Where do the most commonly used software tools fit? Excel appears to be the most common tool BAs use to compile and manipulate information, while Jira and similar systems are used for communication and tracking. Visio, Word, Confluence, Outlook, and SharePoint are also used a lot by BAs.

Another source of confusion might be that a BA does not always participate in all phases of a project. He or she might be involved only in the requirements phase or the user testing phase or the discovery phase or even in a limited subset of phases. I’ve pointed out previously that all projects and efforts perform all of these phases implicitly, but some may be streamlined or omitted as the size of the effort scales down. The entire process takes place implicitly or explicitly even if any one participant or group only sees a small fraction of the activity.

A further consideration is whether the BA is looking at the function of a part of a process or the characteristics of what will perform that function. For example, the abstract part of a solution might involve calculations to be performed, messages to be passed into and out of a process component, and items to be stored and retrieved. The concrete part of a solution might involve determining the qualities the server must have to carry out the abstract functions with sufficient speed and reliability. That is, sometimes the BA will evaluate what something has to do and sometimes what something has to be.

The point is that organizations exist to provide value, and it takes many different kinds of people to make that happen. Business analysts are generally right in the middle of the action.

* * * * *

I also got a few more survey responses, the results of which are reported below.

List 5-8 steps you take during a typical project.

  1. planning
  2. elicitation
  3. requirements
  4. specification writing
  5. QA
  6. UAT
  1. identify the problem
  1. studying subject matter
  2. planning
  3. elicitation
  4. functional specification writing
  5. documentation
  1. identify stakeholders
  2. assess working approach (Waterfall, Agile, Hybrid)
  3. determine current state of requirements and maturity of project vision
  4. interview stakeholders
  5. write and validate requirements
  1. problem definition
  2. value definition
  3. decomposition
  4. dependency analysis
  5. solution assessment
  1. process mapping
  2. stakeholder interviews
  3. write use cases
  4. document requirements
  5. research

List some steps you took on a weird or non-standard project.

  • A description of “weird” usually goes along with a particular person I am working with rather than a project. Some people like things done a certain way or they need things handed to them or their ego stroked. I accommodate all kinds of idiosyncrasies so that I can get the project done on time.
  • data dictionary standardization
  • document requirements after development work has begun
  • For a client who was unable to clearly explain their business processes and where several SMEs had to be consulted to form the whole picture, I drew workflows to identify inputs/outputs, figure out where the gaps in our understanding existed, and identify the common paths and edge cases.
  • investigate vendor-provided code for business process flows
  • reverse code engineering
  • review production incident logs
  • team up with PM to develop a plan to steer the sponsor in the right diection
  • track progress in PowerPoint because the sponsor insisted on it
  • train the team how to read use case diagrams

Name three software tools you use most.

  • Visio (5)
  • Jira (4)
  • Excel (3)
  • Confluence (2)
  • Google Docs (2)
  • email (1)
  • Gephi (dependency graphing) (1)
  • Google Calendar (1)
  • MS Teams (1)
  • OneNote (1)
  • Version One (1)
  • Visual Studio Team Services (now Azure DevOps) (VSTS) (1)
  • Word (1)

Name three non-software techniques you use most.

  • critical questioning
  • critical questioning (ask why fiive times), funnel questioning
  • data analysis
  • informal planning poker
  • interviews
  • meeting facilitation (prepare an agenda, define goals, manage time wisely, ensure notes are taken and action items documented)
  • observation
  • Post-It notes (Any time of planning or breaking down of a subject, I use different colored Post-Its, writing with a Sharpie, on the wall. This allows me to physically see an idea from any distance. I can also move and categorize at will. When done, take a picture.)
  • process mapping
  • relationship building
  • requirements verification and validation
  • stakeholder analysis
  • stakeholder interviews
  • visual modeling
  • whiteboarding
  • wireframe

Name the goals of a couple of different projects.

  • automate a manual form with a workflow
  • automate the process of return goods authorizations
  • build out end user-owned applications into IT managed services
  • develop a new process to audit projects in flight
  • develop an interface between two systems
  • implement data interface with two systems
  • implement software for a new client
  • implement vendor software with customizations
  • integrate a new application with current systems/vendors
  • merge multiple applications
  • migrate to a new system
  • redesign a system process to match current business needs
  • update the e-commerce portion of a website to accept credit and debit cards

These findings fit in nicely with previously collected survey data.

Posted in Tools and methods | Tagged , , , , , , | Leave a comment

Computer Simulation

I gave this talk on computer simulation at the Mensa Regional Gathering in Orlando on Sunday, January 20, 2019. The slides for the presentation are here.

I give a brief description of the major types of simulation and discuss some applications of each.

Posted in Uncategorized | Leave a comment