A Simple Discrete-Event Simulation: Part 90

This evening I attended the DC IIBA Meetup on the subject of process mapping, which is obviously an area in which I have some experience. Since I’ve reached a natural break in writing about pure business analysis subjects I’m going to revisit the discrete-event simulation framework, with my first goal being to add a few demos that illustrate some variations that are possible. To that end I’ve been reviewing the existing code and the to-do list and see that I need to add the following sub-item to the list of abstract processes to support:

  • Include ability to represent entities that remain in the system and only change state during the simulation run, rather than entities that merely pass through the system from an entry to an exit. These should be referred to as resident entities. The items might change color or include one or more text labels reflecting their current state (since multiple characteristics may drive several state characteristics in parallel, with multiple state variables making up synthetic state variables of other kinds), or move among locations (components) to represent state (assuming resident items).
  • Include the ability to easily replicate groups of components representing the state of items that remain within the simulation, if that method is adopted. Alternatively, make the resident entities move through a common set of state-representation components.

These capabilities support modeling of items like aircraft in operation and maintenance simulations. They remain within the system at all times while parts may enter and leave the system.

The item defining pools of resources was originally meant to represent staff that performed certain functions, though they could also represent specialized equipment. An example of how this works is to imagine pools of mechanics that are available to service aircraft. This can get quite complex, but lets work from a simple example to something more complex. Aircraft require a continuing series of scheduled and unscheduled maintenance activities over time, and each one requires a certain number of mechanics for a certain duration. If a group of aircraft simultaneously require service actions that require more mechanics than are available, then the service requests will have to be queued and answered in some kind of order. That is, mechanics will complete a service on one aircraft, return to the pool, and when enough mechanics are back in the pool to fulfill the next service request, they are dispatched to do so.

The next complication is to consider the queue of service events and identify opportunities to service the requests out of order to take advantage of opportunities to complete services requiring fewer resources (e.g., mechanics and time) while waiting for resources to become available to service a larger request. Imagine a group of four aircraft and six mechanics. One aircraft requires a service involving four mechanics for three hours. Another aircraft then requires a service that requires a service involving eight mechanics for two hours. The second service cannot begin until the first one is completed and the mechanics return to the pool. Now imagine a third service request involving two mechanics for thirty minutes. We might check to see if this one can be completed while the first service is still underway, so the mechanics can be used closer to their full capacity. (I would call this an opportunity service after the idea of an opportunity move the Level 1 engineers worked out for transfer of slabs in two-line tunnel furnaces at Bricmont.) The calculations involved can get quite complicated but you can see where this is going.

Another complication beyond that is that there are several groups of mechanics to service different parts of the aircraft, each subject to the same limitations. By itself this isn’t a problem but there are cases where more resources are required to complete an action than there are resources of the needed type available. That is, there might be a service that requires seven airframe mechanics in a situation where only five are assigned. In these cases the system pulls mechanics from other specialty pools to provide the necessary help. Sometimes the main work is performed and supervised by the relevant specialists while other workers just stand around and hold things and move things and run tools under direction. In that case there has to be logic that determines which supplementary pools to pull from.

Another concept to add is the idea of consuming supplies or parts. This requires the ability of logically merging entities. In an assembly process we might have a main assembly moving along an assembly line and having parts added to them from pools of parts from other processes and locations. Chaining pools of parts together can model a supply chain, and various sizes of those pools can be investigated to determine their optimum size and configuration. Pools of part can be treated like queues that might be reloaded in bulk rather than one entity at a time. Additionally, we might consider adding parts to larger assemblies based on custom configurations. This is true of automobiles being made with different options and military aircraft being fitted with different equipment in order to perform different missions. In other cases we might want to split elements off from a moving entity, as we do in the bag object, which can be thought of as a parking lot where vehicles park and their occupants get out and go through their own process. These ideas suggest two more items to add to the to do list.

  • Include ability to merge entities together. (This is somewhat similar to an AND gateway, a diamond with a plus symbol, in BPMN.)
  • Include a flow-through pool component that acts like a queue component but which can potentially be loaded in bulk. The object may also send a request for replenishment when the supply declines to a specified level. There should be signals and warnings based on definable quantity thresholds.

I’ve added the new items to the project page.

Posted in Software | Tagged | Leave a comment

Domain Knowledge Acquisition

I’ve touched on this subject briefly before, but I wanted describe it more directly. The simplest definition of domain knowledge, for me, is: what you need to know to create and apply effective solutions in a specific situation. Acquisition, of course, is the process of gaining that knowledge.

If that seems vague it’s because we have to understand what “situation” we’re actually working in when crafting a solution. When I implemented FileNet-based document imaging solutions for business process re-engineering efforts I might have been working across several competencies at the same time, but what did I actually have to know to do the job?

  • Process Mapping: This comes in two parts. The first involves understanding a process through discovery and data collection. You have to be thorough. You have to be pleasant and engaging to get people to tell you everything you need to know. You have to recognize the important information when you hear it. The second is creating the requisite documentation using some method, which these days more or less always involves knowing how to use one or more complicated software programs. You may or may not need to know how to do that yourself, but someone on your team does.
  • Business Case Analysis: This could also be called Cost-Benefit Analysis. It involves calculating the difference between the benefits of a proposed change and the cost of implementing it. If you can do these calculations in terms of money it makes things easier, but other factors may be involved. If the costs and benefits are readily identifiable it takes less expertise to run the numbers, but more complex assessments may take additional experience and even entrepreneurial judgment.
  • Document Analysis: For a process that involves many thousands of pieces of paper a day it’s important to be able to classify them and identify the relevant information on them. Our customer had developed an ingenious manual filing system that collated the arriving documents into custom-made folders that clasped the received documents in three easy-to-thumb-through collections so they were able to give us guidance on the sorting system they used. Without this guidance we would have had to do a lot more work to understand the documents and create our own sorting criteria.
  • Document Imaging Systems: The FileNet system included hardware components for scanning documents and then storing the images (using a robotic system of removable optical disk cartridges that automatically optimized the storage locations of the cartridges to minimize the travel time of the robotic mechanism based on the frequency of access of the items stored on them), and a WorkForce software component that ran on a network of PCs connected to a central server that contained the database information on each perspective customer and each employee, as well as links to the related documents.
  • Computer Programming: General: Implementers had to come to this work already knowing how to program computers. The FileNet WorkFlow language was obscure enough that it was never the first language anyone learned.
  • Computer Programming: FileNet WorkFlow language: When I used it the WorkFlow language was a loose combination of Pascal and BASIC with special functions to interface with the dedicated scanning and storage hardware, document and item queues, and mainframe access terminals. FileNet was in the process of creating a version called Visual WorkFlow that allowed the programmers to graphically define parts of the flow of documents, information, and work items within the system, but I never saw that in action.
  • User Interface Design: This is a whole field on its own, with a lot of specialized knowledge. By the time I worked on this I had been programming user interfaces graphically and in text for a number of years. I had even written my own text-based, mouse-driven windowing framework several years before. The basics aren’t that difficult to learn and can be picked up in a couple of weeks of initial training.
  • Database Schema Design: This is also a field that can get as complex as you’d like, but schemes for most applications are pretty simple; it’s what you do with the data that makes it work. The FileNet system used an Oracle back end, but the WorkFlow programmers didn’t need to know anything about Oracle per se to make use of its capabilities.
  • Mainframe Data Interfacing: There are many ways to get computers to talk to each other but this one was unique–it used a process called screen scraping.
  • Automated Microsoft Office Document Creation: Some Microsoft (and other) products included the ability to be manipulated by other programs using an interface protocol called Dynamic Data Exchange (DDE). Using this capability required an understanding of the controlled product, content management principles, and programming in general.
  • Medical Records Processing: This is a potentially huge field by itself. It includes considerations like security, procedure coding, and the use of specific medical language. If something isn’t understood then intelligent questions have to be asked. Our customer had a process for this, where questions were written up for certain files and routed to specialists who would call the physicians for clarification. (Since the people making the calls were not trained doctors themselves the people they called would sometimes get highly annoyed.)
  • Insurance: Disability: The insurance field covers many specific areas, and disability is just one type of insurable risk.
  • Insurance: Underwriting: The decision to grant insurance coverage to a potential customer, and the rates to charge, are the result of a complex process of evaluation and calculation. The cost of underwriting and servicing a new pool includes the cost of evaluating whether to grant coverage to every pool whether they are accepted or not.
  • Insurance: Actuarial Calculations: A major component of providing insurance is the ability to evaluate the occurrence rate of specified outcomes across large populations. The training required to do this work is extensive, and requires up to ten individual certification exams and a heavy mathematical background.
  • Insurance: Investment Portfolio Management: Insurance companies must manage a lot of capital as it’s being held against the need to pay benefits over time. My father was a fixed income institutional investor for decades. That specialty has a lot of overlap with what I do and requires a similar personality type.
  • Insurance: Claims Processing: This involves several components including communication, submission and reply processes, bank transfers, tax considerations, procedure and condition coding, and so on.

It should be clear that knowledge of some of these subject matter areas was required to automate the paper-handling aspects of the re-engineering process, especially as that project was handled in two phases. In the first phase we primarily used the skills of process mapping (with light data collection) and business case analysis and to a lesser extent our experience with document analysis and document imaging systems. Once we won the right to do the implementation the detailed computer skills came into play. It might have touched on supporting user processes (like the scoring of individual files and pools thereof) during the implementation phase, where screens had to be designed and calculations supported that allowed the underwriting department to perform its evaluations. In those cases the investigators and implementers can learn what they need to know from the subject matter experts they’re working with. The important thing to recognize is that for the most part the process mapping we did involved processes that anyone could analyze and understand. It required exactly zero special knowledge or training to understand how pieces of paper were received, collated, moved, and reviewed, so the real domain we were operating in wasn’t insurance, per se, it was document processing — which was our area of expertise..

This is relevant to me when recruiters and companies ask for specific domain knowledge. I think they often view the problem too narrowly in terms of industries. Some skills, like discovery, data collection, process mapping, and process improvement (in terms of the arrangement of steps) translate to any situation, as I believe I have more than demonstrated. Other skills, like actuary science, thermodynamics (and calculus), and specific elements of computing, are more specialized and are far more difficult to learn from subject matter experts on the fly. Many situations fall in the middle of this spectrum. For example, I knew nothing about border operations when I started analyzing and simulating them, but I had all the general skills I needed to understand and analyze them. Did I get better as I gained more experience and had seen dozens and dozens of ports? Sure, but that didn’t mean I couldn’t hit the ground running.

Domain knowledge is acquired in two major ways. One is through specific skills training and industry experience. The other is through being able to learn from subject matter experts on the ground. If the business or process analysts are sharp, communicate well, and can establish good rapport with such SMEs, they can implement solutions under the guidance of the SMEs with the proper feedback and direction. I discuss this feedback here. The effort is always cooperative, and learning how to learn from and engage with your customers is critical.

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

Advanced Manufacturing Process Integration Ideas

I’ve seen a lot of different things over the years and they cannot help but suggest possibilities for ways things can be done in a more streamlined, integrated way. Of particular interest to me has been the many novel ways of combining ideas and integrating ideas to enhance the modern manufacturing process. It’s weird because many of these ideas are in use in different places, but not in all places, and there isn’t any place that uses all of them.

Let me walk through the ideas as they built up in chronological order.

My first engineering job was as a process engineer in the paper industry, where I used my knowledge of the many characteristics of wood pulp and its processing to produce drawings and control systems for new plants, perform heat and material balances to help size equipment to achieve the desired production and quality targets, and perform operational audit to see if our installed systems were meeting their contractual targets and suggest ways to improve quality of existing systems (I won a prize at an industry workshop for best suggestions for improving a simulated process). I started writing codes to automate the many calculations I had to do and used my first simulation package, a product called GEMS.

I traveled to a number of sites in far-flung parts of the U.S. and Canada (from Vancouver Island to Newfoundland to Mississippi) and met some of the control system engineers. I didn’t quite know what they did but they seemed to spend a lot more time on site than I did. I also met traveling support engineers from many other vendors. The whole experience gave me a feel for large-scale manufacturing processes, automated ways of doing things, and how to integrate and commission new systems.

My next job involved writing thermohydraulic models for nuclear power plant simulators. I used a Westinghouse tool called the Interactive Model Builder (IMB), which automated the process of constructing fluid models that always remained in the liquid state. Any parts of a system that didn’t stay liquid had to be modeled using hand-written code. I was assigned increasingly complex models and, since time on the simulator was scarce and the software tools were unwieldy, I ended up building my own PC-based simulation test bed. I followed that up by writing my own system for cataloging all the components for each model, calculating the necessary constants, and automatically writing out the requisite variable and governing equations.

I envisioned expanding the above systems to automatically generate code, and actually started working on it, but that contract ended. Ideally it would have included a CAD-like interface for making the drawings. Right-clicking on the drawing elements would allow the designer to set the properties of the elements, the initial conditions, special equations, and so on. The same interface would display the drawing with live state information, and the elements could still be clicked to inspect the real-time values in more detail. From a magazine ad for a Spice simulation package I got the idea that a real-time graph could also be attached to trace the value of chosen variables over time, right on the diagram.

My next job was supposed to be for a competitor of Westinghouse in the simulator space. I went to train in Maryland for a week and then drove down to a plant in Huntsville, AL, where I and a few other folks were informed that it was all a big mistake and we should go back home. I spent the rest of that summer updating the heating recipe system for a steel furnace control system.

My next job was with a contracting company that some of my friends at Westinghouse had worked for. Their group did business process reengineering and document imaging using FileNet (which used to be an independent company but is now owned by IBM). While doing a project in Manhattan I attended an industry trade show at the Javits Center. During that day all of the exhibits game me the idea that a CAD-based GUI could easily integrate document functions like the FileNet system did. Instead of clicking on system elements to define and control a simulation, why not also click on elements to retrieve and review equipment and system documentation and event logs. Types of documentation could include operator and technical manuals, sales and support and vendor information, historical reports, and so on. Maintenance, repair, and consumption logs could be integrated as well. I’d learn a lot more about that at my next job.

Bricmont‘s main business was building turnkey steel reheat furnace systems. There were specialists who took care of the steel, refractory, foundations, hydraulics, and so on, and when it came to the control systems the Level 1 guys did the main stuff PLCs and PC-based HMI systems running Wonderware and the like. As a Level 2 guy I wrote model-predictive thermodynamic and material handling systems for real-time supervisory control. Here I finally learned why the control system guys spent so much time in plants (and kept right on working at the hotel, sometimes for weeks on end). I once completed a 50,000-line system in three months, with the last two months consisting of continuous 80-hour weeks. I also learned many different communication protocols, data logging and retrieval, and the flow of material and data through an entire plant.

Model-predictive control involves simulating a system into the future to see if the current control settings will yield the desired results. This method is used when the control variable(s) cannot be measured directly (like the temperature inside a large piece of steel), and when the system has to react intelligently to changes in the pace of production and other events.

The architecture of my Level 2 systems, which I wrote myself for PC-based systems and with a comms guy on DEC-based systems, looked roughly like this, with some variations.

This fit into the wider plant system that looked roughly like this:

The Level 1 layer was closest to the hardware and provided most of the control and operator interaction. The Level 2 layer incorporated supervisory controls that involved heavy calculation. Control room operators typically interacted with Level 2 systems through the Level 1 interface, but other engineers could monitor the current and historical data directly through the Level 2 interface. Operational data about every batch and individual workpiece was passed from machine to machine, and higher-level operating and historical data was passed to the Level 3 system, which optimized floor operations and integrated with what they called the Level 4 layer, which incorporated the plant’s ordering, shipping, scheduling, payroll, and other functions. This gave me a deep understanding of what can be accomplished across a thoughtfully designed, plant-wide, integrated system.

I also maintained a standardized control system for induction melting furnaces that were installed all over the world. That work taught me how to internationalize user interfaces in a modular way, and to build systems that were ridiculously flexible and customizable. The systems were configured with a simple text file in a specified format. While I was maintaining this system I helped a separate team design and build a replacement software system using better programming tools and a modern user interface.

My next job involved lower level building controls and involved mostly coding and fixing bugs. It was a different take on things I’d already seen. I suppose the main thing I learned there was the deeper nature of communications protocols and networking.

My next job, at Regal Decision Systems, gave me a ton of ideas. I built a tool on my own to build models of the operation of medical offices. I learned discrete-event simulation while doing this, where up to that point I had been doing continuous simulations only. I also included the ability to perform economic calculations so the monetary effects of proposed changes could be measured. The company developed other modeling tools for airports, building evacuations, and land border crossings, some of which I help design, some of which I documented, and many of which I used for multiple analyses. I visited and modeled dozens of border facilities all over the U.S., Canada, and Mexico, and the company built custom modeling tools for each country’s ports of entry. They all incorporated a CAD-based interface and I learned a ton about performing discovery and data collection. Some of the models used path-based movement and some of them used grid-based movement. The mapping techniques are a little different but the underlying simulation techniques are not.

The path-based model included a lot of queueing behaviors, scheduling, buffer effects, and more. All of the discrete-event models included Monte Carlo effects and were run over multiple iterations to generate a range of possible outcomes. This taught me how to evaluate systems in terms of probability. For example, a system might be designed to ensure no more than a ten-minute wait time on eighty-five percent of the days of operation.

I learned a lot about agent-based behaviors when I specified the parameters for building evacuation simulations. I designed the user interfaces to control all the settings for them and I implemented communications links to initialize and control them. Some of the systems supported the movement of human-in-the-loop agents that moved in the virtual environment (providing a threat or mitigating it and providing security and crowd control) among the automated evacuees.

At my next job I reverse-engineered a huge agency staffing system that calculated the staffing needs based on activity counts at over 500 locations across the U.S. and a few remote airports. I also participated in a large, independent VV&A of a complex, three-part, deterministic simulation designed to manage entire fleets of aircraft through their full life cycle.

The main thing I did, though, was support a simulation that performed tradespace analyses of the operation and logistic support of groups of aircraft. The model considered flight schedules and operating requirements, the state and mission capability of each aircraft, reliability engineering and the accompanying statistics and life cycles, the availability of specialized support staff and other resources, scheduled and unscheduled maintenance, repair or replace decisions, stock quantities and supply lines, and cannibalization. The vendor of the programming language in which the simulation was implemented stated that this was the largest and most complex model ever executed using that language (GPSS/H, the control wrapper and UI was written in C#). I learned a lot about handling huge data sets, conditioning noisy historical input data, Poisson functions and probabilistic arrival events, readiness analysis, and more.

More recently I’ve been exploring more ideas about how all these concepts could be combined in advanced manufacturing systems as follows.

Integration Ideas

  • A common user interface could be used to define system operation and layout. It can be made available through a web-based interface to appropriate personnel throughout an organization. It can support access to the following operations and information:
    • Real-time, interactive operator control
    • Real-time and historical operating data
    • Real-time and historical video feeds
    • Simulation for operations research and operator training
    • Operation and repair manuals and instructions (document, video, etc.)
    • Maintenance events and parts and consumption history
    • Vendor and service information
    • Operational notes and discoveries from analyses and process-improvement efforts
    • Notification of scheduled maintenance
    • Real-time data about condition-based maintenance
    • Management and worker dashboards on many subjects
  • Information about the items processed during production can also be captured, as opposed to information about the production equipment. In the steel industry my systems recorded the heating history and profile of every piece of steel as well as the operation of the furnace. In the paper industry plants were later to adopt this kind of tracking (which is more difficult to do because measurements involve a huge amount of manual lab work) but they treat the knowledge like gold and hold it in high secrecy. Depending on the volume of items processed the amounts of data could get very large.
    • Most six sigma data is based on characteristics of the entities processed. This can be collated with equipment operating data to determine root causes of undesirable variations. The collection of this data can be automated where possible, and integrated intelligently if the data must be collected manually.
  • Model-predictive simulation could be used to optimize production schedules.
  • Historical outage and repair data can be used to optimize buffer sizes and plan production restarts. It can also be used to plan maintenance activities and provision resources.
  • Look-ahead planning can be used to work around disruptions to just-in-time deliveries and manage shelf quantities.
  • All systems can be linked using appropriate, industry-standard communications protocols and as much data can be stored as makes sense.
  • Field failures of numbered and tracked manufactured items (individual items or batches) can be analyzed in terms of their detailed production history. This can help with risk analysis, legal defense, and warranty planning.
  • Condition-based maintenance can reduce downtime by extending the time between scheduled inspections and also preventing outages due to non-graceful failures of equipment.
  • Detailed simulations can improve the layout and operation of new production facilities in the design stage. Good 3D renderings can allow analyses and support situational awareness that isn’t possible through other means.
  • Economic calculations can support cost-benefit analyses of proposed options and changes.
  • Full life cycle analysis can aid in long-term planning, vendor relationships, and so on.
  • Augmented reality can improve the speed and quality of maintenance procedures.

The automotive and aircraft industries already do many of these things, but they make and maintain higher-value products in large volumes. The trick is to bring these techniques to smaller production facilities producing lower-value products and in smaller volumes. The earlier these techniques are considered for inclusion the more readily and cheaply they can be leveraged.

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

Follow-up: A Way To Use Jira for Everything?

Today I continue yesterday’s discussion of ways to implement an RTM and my framework using Jira, except this time I want to talk about using Jira for every phase of an effort and not just for implementation and testing.

Given the figure below, which depicts my approach for reviewing the findings and outputs of each project phase with the customer before moving on, and also going back to previous phases to add concepts that might have been missed to support new items that were identified in the current phase, so complete two-way linking of all items is always maintained, I might ask why all items in every phase might not be handled in Jira as action items. There are a couple of possibilities.

Spawn New Issues from Post-Functions

An example of this was given in the course, where completed implementation items automatically spawned test items in a separate project. This is accomplished by specifying a post-function that creates a new issue during a transition of the existing issue, usually to a Done state, though it doesn’t have to be to a Done state. Indeed, it might be better to have it not be a transition to a done state. Instead, it might be a good idea to let the spawned issue or issues run to their own completion and then have them activate a transition to Done for the initial issue in some way.

One problem with this approach is that Jira doesn’t seem to include a create new issue post-function natively, although this capability appears to be available as an add-on from multiple vendors. An additional problem would be that there might be a problem with spawning multiple follow-on issues in the next phase from a single existing issue. A final problem is where to create the newly spawned issues. Do we put them in a new project? Do we create them in a separate swim lane? Do we create them in the same Jira project at the same level but with a different phase label?

Another approach is to add an ending transition for each item where it is sent to a specific team member (or subgroup) that is charged with creating the required follow-on issues manually. That requires a high degree of auditing by management personnel (ScrumMaster, Project Manager, or Transition Specialist).

It’s also possible to create sub-tasks, though I don’t think those flow across different phases very well.

Where Do We Put Newly Created Issues?

As asked above, where do we put issues from each phase of an effort? My framework defines seven possible phases, though that can be modified somewhat (for example, the Conceptual Model Phase could be split into a Discovery phase and a Data Collection Phase, while the Acceptance phase might be omitted).

If we put all of the items into a single project on a single board we’d have to identify items in each phase using some kind of label and then use a filter to view only the items we desire in each phase. This is a lot of work and does not provide much awareness across a whole project. That said, trying to show everything in a whole project might get pretty crazy.

In short, I think it’s probably simpler to manage items up through the design stage in separate-but-linked documents, with items possibly referenced in an overarching table of some kind, and handle the implementation and test operations as individual items within Jira workflows. This is how we operated on a large IV&V project I worked on for quite a while. The team managed an overarching document that included several intended use items while referring to separate documents for the requirements and conceptual model, along with a boatload of other materials. A separate development team tracked their own activities through implementation and test using one or more external work item management tools. Artifacts from those were referenced in the overarching tabular document.

When To Keep Things Simple

The foregoing discussion applies to efforts of a certain size and formality. Smaller efforts can be run on a more ad hoc basis using whatever techniques you’d like, including Scrum. In this case the discovery and conceptual phases can be folded into the requirements and implementation phases, and requirements and To Do items can be dumped right into Jira and processed from there. Managing a full RTM imposes a nontrivial cost, so you should be sure to incur that formal overhead only as it’s needed. It’s still a good idea to write out formal requirements, discoveries, and As-Is/To-Be diagrams and documents if possible.

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

Jira and Confluence for RTMs and My Framework

I finally finished the Udemy course on Jira and Confluence. As I watched each section of the course I thought about how the capabilities of the two products can be used to represent Requirements Traceability Matrices, and furthermore how they could be used to do so for my project framework.

My framework includes the idea of linking one-to-many and many-to-one between columns going from left to right (beginning of project to end) and, as I’ve thought about it in detail over the last week-plus, I see that it might also include the idea of linking items in non-adjacent (non-successive) columns. Might. I’ll be clarifying that going forward. Anyway, the framework is best represented using a graph database, which is a bit out of the ordinary, as I’ll explain.

Since the ultimate representation I have in mind is complicated, I’ll describe a simple representation and slowly add complications until the end goal is reached.

Start Off Doing It By Hand

Let’s start with a fairly simple project and describe how I would manage it manually. Since I’ve usually done this in combination with building simulations of some kind we’ll build on that concept as well.

The intended uses describe how the solution will be used to solve identified business problems. Imagine there’s only a single item to keep it simple. Give it a code of A-1.

The items in the conceptual model are identified though a process of discovery and data collection. These define the As-Is state of a system. Label these items B-1 through B-n. Each is linked to intended use item A-1. These can be stored in a document, a spreadsheet, or a database, but picture the items written in a document.

The items in the requirements address how to represent and how to control each conceptual model item. These define a path to the To-Be state in an abstract way. Label these items C-1 through C-n. Each item is linked to one of the conceptual model (B-) items, such that every B- item is linked to a requirement. Those describe the functional requirements of the solution. Non-functional requirements are listed with labels C-n+1 through C-x. They do not have to link back to conceptual model items. Imagine these items are written in a document.

The items in the design describe the proposed ways in which the solution will be implemented. These represent the To-Be state in a concrete way. The items must include the details of the implementation process. Label them D-1 through D-x. Each item is linked to one of the requirements (C-) items, such that every C- item is linked to a design item. Imagine these items in a document as well.

The implementation items are tracked as they are assigned and worked on. They should be labeled E-1 through E-x and each should be lined to a design (D-) item such that all of the design items link to implementation items. These items can be listed in a document.

The test items are labeled F-1 through F-x and are linked to implementation (E-) items such that all E- items are linked to test items. These items can be written in a document.

The acceptance items are labeled G-1 through G-x and are linked to implementation (F-) items such that all F- items are linked to acceptance items. These items can also be listed in a document.

That description may be tedious and repetitive but it gives us a place to start.

The first wrinkle we might introduce is to include all of the items in a single document in an outline or tabular form. It gets unwieldy as the number of items grows, so another idea would be to include the items in a spreadsheet, where we can combine the features of an outline and columns, and where the rows can be viewed easily even as they grow wider.

Test items are interesting because there are so many different forms of them. There are many types of automated and manual tests and there are a number of software systems that track the items and generate reports. Such systems can be used to supplement the written forms of the previous items. Such systems usually support labels that fit any scheme you like. Specialized tests that aren’t tracked by automated systems can be tracked in written form. The more subjective tests that rely on expert judgment are most likely to be tracked in writing.

The virtue of keeping everything in writing like this is that intended uses, conceptual model items, requirements, and designs can be maintained as separate documents and possibly be managed by separate teams. The labeling and cross-linking have to be performed manually by one or more people who have a solid understanding of the entire work flow.

Enter Jira (and Confluence)

Here’s where we get to Jira and Confluence. The simplest way I can think of to integrate Jira into the RTM process is to use it to store the status of implementation items only. This means that the items in columns A through D, or the intended use, conceptual model, requirement, and design items, can stay in there separate documents. The design items can be written in such a way that they define the work to be done by the implementation agents. They can be written as user stories, epics, tasks, or sub-tasks.

These items can be given custom workflows that move items through different kinds of evaluations. They follow all the rules for writing effective descriptions, including definitions of done, and so on. This works well for different layers of testing. For example, a software item’s definition of done may include requirements for integrated tests. There might be a code review step followed by a manual test step. A custom workflow could handle many situations where multiple test (F-) items are mapped to each implementation (E-) item. They could handle the parallel definitions of tests in a written document of test items by walking the implementation items through a serial test process. Subjective tests could be run as a separate step for some items.

Why not use Jira for tracking items from phases before implementation? I can think of a few reasons.

  • The items walk through all phases and cannot therefore be conveniently viewed in the context of each phase. That is, it’s not super easy to see all of the items together in their context of, say, the conceptual model. This objection can be overcome by including a custom field with the relevant text, and then using JQL (Jira Query Language) functions to list and sort the information in those fields as desired.
  • It’s difficult to capture all of the one-to-many relationships that are possible advancing through the phases left to right. This can be overcome somewhat for testing as described above but it breaks down trying to span more than two of the other phases (e.g., concept-to-requirement-to-design). Capturing many-to-one relationships wouldn’t be a treat, either.
  • Each item in each phase may require a lot of documentation in terms of text, data, history, discussion, graphics, and so on, so trying to maintain all of that through multiple phases seems like it could get out of control in a big hurry.
  • Most of the material I’ve seen on Jira is in the context of handling action items. Implementation and test items are actions to take, but it’s harder to think of earlier phase items in that way. Up until the implementation phase the items serve more as background for the work to be done. I suppose you could create implementation items like, “do discovery” and “collect data” and “write requirements,” but those items don’t yield a traceable list of individual items unless the context is understood.

The latter concern leads to a major issue that needs to be discussed.

Waterfall vs. Agile

It might sound like my framework, with its need to do a lot of upfront elicitation, conceptualizing, and requirements gathering, forces you into more of a Waterfall mode. Agile, by contract, promises to let you begin doing meaningful work almost right away, starting from a small core of obvious functionality and progressively elaborating to a complete, thorough, nuanced solution.

Waterfall, at its worst, involves a huge amount of planning with the idea that most of the analysis is performed at the beginning, so that the implementers can go off and do their own thing and all of the pieces will automagically come together at the end. We know from experience that that way lies madness. Plenty of projects have failed because the pieces do not come together at the end and even if they do, the lack of interaction with and feedback from the customers means that the developed system might not meet the customers’ needs very well — or at all. This can happen even if the initial customer engagement is very good, because customers might not know what they even want to ask for in the beginning, and lack of ongoing interaction denies them the opportunity to leverage their specialized experience to identify opportunities as the work and refinement progresses.

Agile techniques in general, and Scrum techniques in particular, are intended to maintain customer engagement on the one hand, and ensure the implementation team always has something running and it continually revisiting and working out integration and release issues. Agile and Scrum at their worst, however, assume that you don’t need to do much upfront planning at all and you can just start building still willy-nilly and hammer into shape over time. We used to call that cowboy coding and it was seen as a bad thing back in the day. Putting a shiny gloss of Scrum in it doesn’t fundamentally change the fact that such an approach is broken. (It also means that querying would-be hires about Scrum trivia items to gauge their knowledge entirely misses the point of how work actually gets done and how problems get solved. Good thing I’m not bitter about this…)

I could go on and on about how Agile and Scrum have been misused and misunderstood but I’ll keep this brief. The truth is that the approaches are more reasonably viewed on a continuum. It isn’t all or nothing one way or the other. You’re crazy if you don’t do some upfront work and planning, and you’re also crazy if you don’t start building something before too much time has gone by. What are some factors that change how you skew your approach in on direction?

  • The scope and scale of the envisioned solution: Smaller efforts will generally require less planning and setup.
  • How well the problem is understood: If the analysis and implementation teams already understand the situation well they will generally require less planning.
  • The novelty of the problem: If the problem is recognizable then the amount of planning will be reduced. If it takes a long time to identify the true problem then much or even most of the work will involve upfront analysis.
  • The novelty of the solution: If a team is adapting an existing solution to a new problem then the amount of upfront will will be reduced. The team can start modifying and applying parts of the solution as discovery and data collection proceed. If a novel solution is called for it’s better to wait for more information.
  • The planned future uses of the solution: If the solution is going to be used for a long time, either as a one-off or as the basis of a modular, flexible framework (i.e., a tool) that can be applied over and over, it’s a good idea to devote more effort to analysis, planning, and setup. If the effort is to keep an existing system afloat for a while longer, a quick implementation will do, if it’s appropriate. Note that it’s possible to develop a flexible tool or framework over numerous engagements, slowly developing and automating parts of it as consistent, repeating elements are identified. This may be necessitated by funding limitations. Building and using tools imposes an overhead.
  • The quality of the desired solution: Every effort is constrained by the iron triangle of cost, quality, and time, where quality may be expressed in terms of features, performance, robustness, maintainability, and so on. Put a different way, you can have it fast, cheap, or good: pick two. At the extreme you could have it really fast, really cheap, or really good: pick one! The space shuttle had to be really good (and they still lost two of them), but it was really not fast and really not cheap.

There’s some overlap here but I’m sure you can recall time when you faced the same decisions.

In simulation in particular you pretty much have to understand what you’re going to simulate before you do it, so there might be a lot of upfront work to do the discovery, data collection, and planning to understand a new system and adapt a solution. However, if you already have a solution you merely need to adapt to a new situation, you can jump in and start customizing to the novelties almost as soon as they’re identified. I’ve worked at both ends of this spectrum and everywhere in between.

Roughly speaking, if you have to do a lot of upfront work the effort will tend toward Waterfall, though within that you can still use Agile and Scrum techniques to do the implementation, guided by the customer’s impression of what provides the most business value first and the implementer’s impression of what is technically needed first.

If you have reasonably well-understood problems and solutions, as in handling ongoing bug fixing and feature requests for an existing system, and where you are operating mostly in a reactive mode, the effort will tend toward a Kanban style.

For efforts that are somewhere in the middle, where there is a balance between planning and execution or discovery and implementation, the preferred m.o. would tend toward Scrum. Interestingly, teams sometimes use Kanban approaches in this situation, not because there are being strictly reactive, but because they are using Kanban as an effort-metering approach for a team of a fixed size. In those cases I’m thinking that the cost or scope or time would have to be flexible, and this approach might not work for a firm, fixed price contract with an external client.

People’s impression of management techniques, specifically regarding Waterfall and Agile/Scrum/Kanban can vary strongly based on their own experience. They may tend to think that the way they’ve done it is the only or best way it should be done. They may also regard the body of knowledge surrounding Scrum as being very rigid and important to follow closely, although I view the whole thing more as a guideline or a collection of techniques rather than holy writ. I pretty much figure if you’re treating Scrum procedures as holy writ you’re doing it wrong. That said, I am not saying that an appreciation of the context and application of the generalized ideas is not helpful or necessary.

I’ll also observe that the context of Scrum and Kanban is pretty limited. If I look through the training materials from the certification classes I took a while back I can argue that a significant amount of material in those booklets is general management, professional, and computer science stuff that doesn’t have much if anything to do with Scrum or Agile. In that regard the whole movement is a bit of a fraud, or at the least an overblown solution looking for a problem. This is why the initial champions of the technique have more or less moved on.

As for me, I’m fond of noting that I’ve been doing Agile since before Agile had a name, even if I hadn’t been doing explicit Scrum. I always started with discovery and data collection to build a conceptual model of the system to be simulated or improved. I always identified a flexible architecture that would solve the problems in a general way. I always built a small functional core that got something up and running quickly that was then expanded until the full solution was realized. I always worked with people at all levels of customer organizations to get ongoing feedback on my understanding and their satisfaction of the solutions’ operation, look and feel, accuracy, functionality, and fitness for purpose.

I finally note that, especially for the product owner role, the ability to perform relevant subject matter analysis, apply industry expertise and business judgment, the ability to communicate with all manner of specialists from users to managers to line operators to technical teams, and the ability to create and understand solutions are all far more important than any specific knowledge of Agile, Scrum, Jira, or any related technique or tool. Relative to understanding and being able to work with people and technology to solve problems, Agile and Scrum are trivial. This is especially true is other strong Scrum practitioners are present.

For example, the product owner role will sometimes be filled by a senior manager of a customer organization or internal competency, while a ScrumMaster will be a member of a vendor organization or a different internal competency. In these cases the product owner might be an expert in the business needs and be able to work with knowledgeable members of the solution team to groom the backlog in terms of business value, but that individual might not know a thing about the details of the proposed technical solution, how to do DevOps, how to write code, how to run a Scrum ceremony, or whatever. Such an individual would be guided by the ScrumMaster to get up to speed on the Scrum process and by specialists on the technical team(s) to work on the solution elements themselves. Like I said, every organization will treat these functions differently. Ha ha, I guess I should do a survey of the expected duties and capabilities of the expected Scrum roles are to illustrate the wide range of different approaches that are taken. It was highly illuminating when I did this for business analysts!

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

Pittsburgh IIBA Meetup: Do You Think You Are a Good Listener? Let Us Surprise You!

This evening’s talk at the Pittsburgh IIBA Meetup was about communication skills. Although there was some discussion about conveying messages the emphasis was on how to receive them. Both are important to business analysts. BAs must provide context for what they’re trying to elicit so they get what they want, but they must be patient enough to receive the information effectively as it’s offered.

There have been times when I’ve done this really well in my career (and in my life), and times when I’ve done this less well. Some reflection on my own has made me aware of my worst behaviors so I won’t ever repeat them but, as in many things, if I want to keep getting better in an area it helps to be thinking about it. In order to get better at something one has to be continuously (and purposefully) engaged with the material, so this talk was good for that engagement.

I’ll post a link to the presentation materials if and when they’re made available. In the meantime I’ll share a link to an online listening skills evaluation that was included in the slides.

The speakers shared a lot of insights into things to do and not to do, many of which I’d seen before and a couple I hadn’t. I’ve gotten to know one of the speakers a little bit and told her about something I learned in a leadership school in the Army, though it’s a common concept. When I saw it it was called, simply, a “communication model.” That’s not super descriptive, but the idea is easy enough to grasp:

  1. What the sender thinks was sent
  2. What the sender actually sent
  3. What the receiver actually received
  4. What the receiver thinks was received

It seemed to me that many of the concepts described in the talk reflected different aspects of this communication model. How to send clearly, how to prevent and resolve misunderstandings, how to maintain strong engagement so all parties are incentivized to keep working until mutual understanding is achieved, how to ensure that you understand what the speaker is saying and not confirming what you want to hear, carefully setting ground rules and defining terms, overcoming certain barriers, and more were all discussed. The speakers and audience members shared numerous personal stories and observations relating to these ideas, and I found the entire session to be productive.

There are many technical aspects of discovery and data collection processes but they can’t be executed effectively in many cases if they aren’t conducted in an environment with good communication and strong, supportive engagement.

Finally, the speakers mentioned the classic Dale Carnegie book, How to Win Friends and Influence People, which I’ve linked before and highly recommend. To that I’ll list a handful of other books I’ve read on related subjects. This may seem a bit longhaired but interpersonal skills are as important for technicians and analysts as they are for anyone, and perhaps more so.

Feeling Good Together by David D. Burns.
The Five Love Languages by Gary Chapman.
Emotional Intelligence by Daniel Goleman, Ph.D.
Conversation Confidence by Leil Lowndes.

Posted in Management, Soft Skills, Tools and methods | Tagged , , , | Leave a comment

A Simulationist’s Framework for Business Analysis: One More Update

So I’m working my way through the Jira course and I finally came to a clear understanding of a special case I’ve been trying to clarify.

For the most part the processes of discovery and data collection result in the creation of a conceptual model. The requirements for what must be addressed (included), modified, or eliminated in the conceptual model get written up in a straightforward manner from there, and the design, implementation, and test items follow.

There was an extra step when I wrote thermo-hydraulic models for nuclear power plant simulators at Westinghouse, and that’s what I’ve been trying to classify. I think it ultimately doesn’t matter how I define it, the point of this isn’t to define a rigid, formal framework, the point is to have a flexible framework that helps you get the work done.

At Westinghouse the discovery process involved a review of drawings to identify the components of the plant that needed to be simulated to drive and be controlled by every item on the operator panels. That was performed by senior engineers in conjunction with plant personnel. The data collection process involved a trip to the plant to record all the readings and switch settings at steady state, followed by a period of researching more plant documentation to determine the dimensions and operating details of all the equipment for each system and the state of the fluids within each part of the system. This involved a lot of calculations. The requirements were for a system that generated I/O behavior for every control panel item that was within one percent of plant values at steady state and within ten percent during transients, so they were straightforward also.

So far, so good, right? Here’s where it gets trippy.

The solution involved writing first principles simulation code based on the differential equations that described the behavior of the fluid in each system. The same procedure followed for electrical models. Therefore the solution involved two steps: defining all of the required variables and governing equations, and then implementing them in code.

The issue I’ve been having when remembering all this was how to think about the write-up of the equations. In some ways it’s a conceptual representation of the plant systems, so it can be thought of as part of the conceptual model. In other ways it’s a guide for what’s required for the implementation, so it can be thought of as a specific part of the requirements. In still other ways it’s the result of a creative solution process so it’s part of the design. The architecture of the system is definitely part of the design but also part of the implementation.

I’ve been picturing the equations as part of the conceptual model, but on review they seem more properly to be part of the design, and so my confusion is potentially resolved. You may see this differently, and you’re welcome to do things your own way as your situation and impressions guide you.

Many sources (for example see here and here) inspired and informed my idea of a conceptual model, but my definition and usage applies for my framework only.

* * * * *

As an aside I can tell you that defining the governing equations and implementing them in code are very different problems. I’ve thought the hole in Westinghouse’s otherwise thorough and professional management and tracking process involved not having enough review of the methods for implementing the identified equations in code. There was a really good review process for the write-up of the equations, but there was never a review of the proposed implementation methods. The modelers were mostly left to do their best and their codes would simply be tested to see if they worked. Given the experience of some of the senior staff, including this review step might have saved a lot of wasted effort.

When I observe that I’ve seen things done well and less than well, and that my interest is always in helping organizations support things that work and avoid things that don’t, I’m often thinking of this episode. The oversight was subtle and it took me a few years to identify what was missed.

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

A Simulationist’s Framework for Business Analysis: An Update

While continuing to work through my Jira course with an eye toward using it in conjunction with a Requirements Traceability Matrix, I’ve been thinking about the context of how the work actually gets done.

I’ve discussed the content of the RTM in quite a lot of detail, but I haven’t talked too much about how the items in it are generated and linked.

The intended uses, or business needs, are identified by the customer or through an elicitation process. It will often happen that the needs identified by a customer will be clarified or added to by the analysts through the elicitation process and follow-on activities.

The items that make up the conceptual model are identified during the discovery process and characterized through the data collection process. Note that the conceptual model and requirement phases may be combined. Alternatively, the conceptual model phase may be combined with the design phase instead, where discovery of the elements needed to address the identified requirements takes place.

The items that make up the requirements are identified based on the items in the conceptual model and additional elicitation. If the project involves building a simulation then building all of the processes and entities in the conceptual model would obviously be a requirement. I write separate requirements for each item so they can be tracked and tested more accurately. Additional requirements have to do with how the solution is to be implemented and managed (non-functional requirements), items that are to be added beyond what is specified in the original conceptual model, and specific items that will address the identified business needs. Items that are going to be removed from what is described in the original conceptual model must be listed, too.

The design items are linked to requirements in a fairly straightforward way. That said, a really good discovery and design process will decompose a system to identify many common elements. A good design will incorporate generalized elements that flexibly represent many specific items in the conceptual model. A discrete-event simulation might include a general process element that can be readily customized to represent numerous specific processes at a location. For example, one could create separate simulation objects for primary inspection booths, secondary inspection booths, mechanical safety inspection slots, customs inspection dock spaces, tollbooths, and so on at land border crossings, or one could recognized the similarities between all of those facilities and implement a single object type that can be modified to represent any of them. This approach will make the implementation more consistent, more modular and flexible, easier to document, easier to build and maintain, easier to modify, and easier to understand.

The implementation items describe what is needed to instantiate the elements of the design.

The test items are linked directly to the implementation items. All links between phases (or columns) can be one-to-many or many-to-one, but the relationships between implementation items and their tests are the most likely to be many-to-one (going left to right or from each implementation item to many tests). This is because many different kinds of automated and manual tests can be performed for each element of the solution. The types of tests can be performed at different levels of abstraction as well. Automated verification tests can be created in large numbers to check individual operations in detail. Validation tests based on expert judgment might be more subjective.

The acceptance items are generally derived directly from the tests. If all the tests pass, then acceptance should be guaranteed. It is therefore very important to properly and completely identify all of the tests and their acceptance criteria when working through a project.

These descriptions may seem obvious but I wanted to describe them explicitly to make sure the understanding and classification is clear. Using Jira or other approaches is a very specific process and we have to have clear language and definitions going forward.

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

Requirements Traceability Matrix (RTM)

One of my favorite tools to use during any project, but particularly for software projects, is the Requirements Traceability Matrix (RTM). I’ve discussed this in presentations I’ve given on the framework I use for performing business analysis (and project management to a lesser degree), but I wanted to take some time to take about using the RTM in detail.

The purpose of the RTM is to make sure that all requirements map to business needs and that all of the requirements get fulfilled and accepted. People have done this sort of thing for years (decades… and longer) using punch lists and other techniques, but the RTM has a specific structure.

I’m going to describe its usage in terms of the framework I use but you can use any series of steps with any names you’d like. The most basic set of steps you can probably identify is Business Need, Requirement, Implementation, Acceptance. The framework I use consists of these steps: Intended Use, Conceptual Model, Requirements, Design, Implementation, Test, Acceptance. The conceptual model part has to do with describing the As-Is state of an existing system, but if a new system is being constructed there might not be an existing system to work from, and there may or may not be a need for a conceptual model.

Here’s a graphical representation of what a Requirements Traceability Matrix might look like, based on the workflow I use:

The idea is that every item in every column (step of the workflow) maps to at least one item in the previous and subsequent columns. That is, every item in the conceptual model maps to a business need (the intended use), every requirement maps to an item in the conceptual model, every element of the design maps to a requirement, every element of the implementation maps to a design element, every test item maps to an implementation item, and every acceptance item maps to a test item. The relationships can be one-to-many and many-to one in either direction, but the relationship is typically one-to-many going left to right.

An exception to the idea that items always have to map in both directions is that non-function requirements elements do not necessarily have to map back to items in the conceptual model or intended use. That said, the use of specific hardware and software elements may be driven by identifiable business needs, but other aspects may not be. For example, deploying operations to Amazon Web Services may be part of an explicit organizational strategy, but ensuring that a solution is modular, flexible, and maintainable may be just good practice. You can think of these ideas however you’d like.

You may notice a few dashed lines going back to question marks in the diagram. These show that if you identify something that’s needed part way through the process that doesn’t obviously map to an existing item in the previous step of your workflow, then that may indicate that you need to add something to that previous step.

Finally, the items at the bottom represent free-floating project methodology requirements, if they exist. They’re kind of like non-functional requirements in that they don’t address what the solution does (functional requirements), or what the solution is, but how the steps should be carried out. For example, we wrote procedures for collecting data at land border crossings at one of the companies I worked for. Another example may involve writing automated tests for implementation items when using test-driven development (TDD).

Let’s talk about all of the steps one by one.

The intended uses, essentially the identified business needs, describe the high-level operations the organization needs to accomplish in order to serve its customers. Examples include making decisions on whether or not to provide insurance coverage for a given customer, allowing a customer to place an online order, and allowing customers to request slots in a schedule.

The conceptual model is an abstract representation of a system. It may include entities, stations, operations, and transformations. The representation may take almost any form. In my work these representations have included diagrams, equipment lists, and equations.

The requirements describe the elements and operations that most be addressed in the solution. They describe the concepts that must be represented and the means of controlling the relevant operations.

The design describes the proposed elements that will make up the solution.

The implementation items are the specific pieces of work, in terms of objects, repositories, and processes, that need to be made real to construct the planned solution.

The test items are intended to address each element of the implementation.

The acceptance items are approved when each of the tests are shown to have been passed.

Once we understand what goes into a requirements traceability matrix (which is sometime shortened to requirements trace matrix), we can think about how we actually implement and use one.

The simplest way is to write it out in text, for example in Microsoft Word. They can be written in outline form but the key to linking items is to give some sort of alphanumerical label to each item so they can refer to each other.

A large VV&A project I did involved a 200-plus page document in three sections that had a trace matrix as part of its content. We embedded tables for each of the three identified intended uses, and each table mapped all of the implementation items to the requirements. There was no step for conceptual model and all of the test information was included in a separate, standalone bug-tracking system. The acceptance criteria were addressed in several different ways.

Remembering that testing involves both verification and validation, we see that there might be many different test items linked to the various implementation elements. Verification is meant to determine whether things work operationally. Do elements of the user interface cause the expected actions to occur when they are activated? Do calculations provide the expected results given specified inputs? Can certain types of users access certain screens? These kinds of tests are easier to automate and have more objective criteria for correctness. Validation is more subtle. It is meant to determine whether the implemented solution properly and sufficiently addresses the business need (the reason the solution was implemented in the first place). The criteria for validation might be very subjective, and might have to be determined by expert judgment.

It’s also easy to imagine doing an RTM in Excel, using an outline format, though it might be difficult to make such a resource available simultaneously to a large group of users. A relational database implementation with a dedicated user interface may also work, and that’s what I’m thinking about specifying.

I’m also thinking specifically about how to use Jira in a way that is compatible with the idea of an RTM, since I’m working my way through a Udemy course on Jira right now. I’ll let you know how that goes in subsequent posts.

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

Data Collection: Characterizing a Process

Having discussed the process of discovery yesterday I wanted to go into detail about data collection today. While discovery identifies the nouns and verbs of a process, data collection identifies the adjectives and adverbs. I’ve listed a bunch of ways to do both in this post on the observation technique, but here I’ll take a moment to describe how the collected data are used.

Data may be classified in several ways:

Continuous vs. Discrete: Continuous data can be represented numerically. This can include real numbers associated with physical dimensions, spans of time, amounts of energy, and intrinsic properties like hardness or pressure. This can also include counting variables that are usually integers, but not always. Discrete data items have to do with characteristics that aren’t necessarily numeric, like on or off, good or bad, colors, and so on. Interestingly, some of these can be represented numerically as discrete or continuous values. On/off is typically represented by one and zero (or boolean or logical), but color might be represented by names (e.g., blue or gray) or combinations of frequencies or brightness (like RGBA values).

Collected as point value or distribution: A point value is something that’s measured once and represents a single characteristic. A hammer might weight sixteen ounces and the interior volume of a mid-sized sedan might be 96.3 cubic feet. An example of distributed data would be a collection of times taken to complete an operation. Both continuous and discrete data can be calculated as distributions. A distribution of continuous data could be the weights of 237 beetles, while a distribution of discrete data could be the number of times an entity goes from one location to each of several possible new locations. A sufficient number of samples have to be collected for distributed data, which I discuss here.

Used as point value or distribution: Data collected as single point and distributed values can be used as point values. Single-to-single is straightforward but distributed-to-single is only a little more complicated. If a single point value is derived from a set of distributed values it will typically capture a single aspect of that collection. Examples are the average value, the mean, minimum, maximum, standard deviation, range, and a handful of others. Data used as distributed values must be collected from a distribution of data samples. There are a number of ways this can be done. Mostly this has to do with whether an interpolation will or will not be used to generate values between the sample data values.

Given a two-column array based on the table above (in code we wouldn’t bother storing the values in the middle column), we’d generate a target value against the column of independent values, identify the “bucket” index, and then return the associated dependent value. In the case of the table above the leftmost column would be the dependent value and the rightmost column would be the independent value. This technique is good for discrete data like destinations, colors, or part IDs. If the target value was 23 (or 23.376) then the return value would be 30.

It’s also possible to interpolate between rows and generate outputs that weren’t part of the input data set.

The interesting thing about data used as a distribution is that only one resultant value is used at a time. There are two ways this could happen. One is to generate a point value for a one-time use (for example, the specific heat as a function of temperature for steel). The other is to generate a series of point values as part of a Monte Carlo analysis (for example, a continuous range of process times for some event). Monte Carlo results ultimately have to be characterized statistically.

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