TWSL Series 13: Artifacts Needed to Understand the Full Story

Today I gave this webinar for the Tom Woods School of Life Lunch and Learn Series. The slides are here.

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

Organizational Modeling

Organizational modeling is a technique for representing the functional, operational, or physical structure of cohesive groups of people. The most common way of doing this is by using organizational charts or “org charts.” The traditional way these are shown is as some kind of hierarchy, but other methods of representation are possible.

One of the big issues when organizing a hierarchical structure is defining a taxonomy, and that involves making decisions on which kinds of divisions will take precedence. I touched on an aspect of this when I discussed my attempt to classify all my Lego pieces when I was about fourteen. The major ways hierarchies can be defined are by function, product line, type of customer served, and the like. These all prioritize on similar criteria but in a different order.

The chart above includes a lot of standard elements. I worked for this company from 1994 to 2000 and had a fabulous time (but also got very burned out). The main hierarchy is based on a president and two VPs, a bunch of departments and layers of managers arranged under them (occasionally sharing functions like drafting), and special functional groups and individuals attached and reporting where needed.

The other major way organizations might be models is in matrix format. In this case, different entities will report to two different types of managers, each with different concerns and responsibilities. For example, one axis of control (think of items in the rows of a grid) might be concerned with different product lines, while the other axis of control (the columns in a grid) might concern itself with different job functions needed to make up teams. Another possible axis can be defined for specific projects and programs. This is always a trick to get right, and the problem of responsibilities without authority often arises.

The representation below is of the type of air defense artillery unit I used to work for. I served in several different positions during my time in the service and learned a lot from each one. I’ve included a rough representation of vehicles in the unit, but as I think about it I’m certain I’m leaving some out of the representation for the headquarters platoon to the right. The three platoons to the left all included four self-propelled Vulcan air defense cannons (long since retired), an APC from which the platoon leader commanded the platoon, and a jeep for the platoon sergeant. There are actually standard symbols for representing different kinds of military entities, one of which is linked here.

Organizational charts can be as varied and complex as you’d like, and a decent amount of humor can be associated with this idea. Try an image search on the internet using the words funny org charts to see some clever examples.

What most organizational models have in common are the following elements.

  • Model type: functional or matrix as described above
  • Roles: titles and duties with different people and groups hold and perform
  • Interfaces: connections between groups and entities along which information and materials can be exchanged
  • Charts: boxes show entities and groups, lines show reporting and other relationships
  • Influencers: formal and informal sources of information, power, and sway within the organization
Posted in Tools and methods | Tagged , , | Leave a comment

TWSL Series 12: Management Observations and Agile Deep Dive

Today I gave this webinar for the Tom Woods School of Life Lunch and Learn Series. The slides are here.

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

SWOT Analysis

SWOT is an acronym for Strengths, Weaknesses, Opportunities, and Threats. The basic idea of this analysis is straightforward, but the decisions and actions can be as complex as can be imagined.

Much like the Important vs. Urgent grid, this technique involves identifying items in two opposing pairs, and then analyzing them in a grid as shown. It is generally performed to assess the state of an organizations readiness from multiple points of view. It may be thought of as an organized way of taking stock and preparing for the future. It may be applied to any time scale and across part of all of an organization, ranging from individuals to projects to departments to divisions to the entire organization.

Strengths are things an entity or capability does well and tends to support successful outcomes. They are contrasted with weaknesses, which are things an entity does less than well or does not do at all.

Opportunities are elements in the eternal environment that may be exploited for gain or success. These may include new technologies, mistakes by competitors, general economic tailwinds, and other factors. Threats, by contrast, are factor that pose challenges to the organization. They may include new strengths realized by competitors, new technologies, general economic headwinds, regulatory changes, and so on.

Care should be taken to ensure the analysis is thorough on the one hand, but targeted to the situation of concern on the other. Additionally, some elements will be obvious, especially with respect to opportunities and threats, while others may be more subtle or diffuse. Brainstorming lists of strengths and weaknesses can be a useful approach but again, make sure they are applicable.

Upon performing an analysis in any quadrant, the organization or entity can make plans to develop new technologies, advance proposals, team with other entities, purchase supplies, set aside extra finds, purchase or modify insurance, enter or exit markets, modify dividends, offer or repurchase equity or bonds, open or close locations, acquire other organizations or sell out to others, and so on. The possibilities are endless.

One unexpected form I’ve seen this take is a capability analysis performed by one of my former employers. They surveyed all the employees to list the skills they had and the types of analyses they could do, and the senior managers tried to identify opportunities they could go after by leveraging those capabilities. In the parlance of a SWOT analysis, this was an example of an SO strategy.

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

TWSL Series 11: BA Overlaps with Other Practice Areas

Today I gave this webinar for the Tom Woods School of Life Lunch and Learn Series. The slides are here.

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

Use Cases and Scenarios

Use cases may be thought of as packages of instructions or actions taken by an actor when interacting with a system. The actor does not have to be human, and the system does not have to involve computers or IT. That said, since use case analysis arises from UML, which itself comes out of systems analysis and it’s kissing cousin software engineering, it will not be uncommon to see this technique used in the design of software.

Let us consider an individual pulling into a gas station. The person may want to buy snacks, use the restroom, or purchase gas. Use cases provide a way to represent those activities.

We know the customer wants to purchase gas, and we also know the customer has to pay for the gas and then pump the gas. Each activity can be made up of many different steps, and these can have alternative paths, including error paths.

The following is an example of a use case. Many references, including the BABOK, will show human actors as stick figures. For some reason, which probably involves an affront to motherhood and small fuzzy kittens, Visio chooses not include a stick figure as a native drawing element.

A use case diagram will have some standard components.

  • Name: The name of the activity undertaken by the actor (generally involves a verb). For this example, let’s look at the item titles “Bug Gas.”
  • Goal: Desired end state of the activity. In this example the goal is to have added a certain amount of gas to the car’s gas tank.
  • Actor: Entity (human or otherwise) that initiates the action in pursuit of the goal. Here the customer is a person who arrived with the car.
  • Preconditions: Any aspect of the system or environment that must be true in order for the action to begin. Some possible examples are that the gas pump is working, there is gas in the underground storage tank that can be pumped, and that communications with the payment processor are working.
  • Trigger: Even that begins the flow of actions. The actor may initiate the process presenting a payment card to the pump, which will make it ready to dispense gas. Alternatively, the actor may go to an inside teller and arrange payment there, which will activate the pump.
  • Flow of Events: The sequence of steps or occurrences undertaken by the actor and system to achieve the desired goal. You can imagine long sequences of events involved with completing payment and actually putting gas into a receptacle.
  • Post-conditions or Guarantees: Any aspect of the system or environment that must be true when the activity is complete. In this example, the gas will be dispensed, a receipt will be offered, and the pump will reset to a non-enabled state. Additional effects are possible.

Some of these items are made clear by looking at the diagram, but others are not. This is one of many reasons why I have never used them, even though I have described, designed, implemented, and tested these items in numerous ways.

The flow of events can be represented as a flowchart with as many branches as endpoints as are needed. It can also be written out as a list of text items or in any other way that provides clarity and understanding.

Use case diagrams include two other bits of nomenclature which are useful. These involve the concepts of including and extending actions or groups of actions.

The include relationship seems more understandable. It allows individual sub-actions to be bundled up and reused so they do not have to be repeated. For example, many individuals may service a vending machine, and each may undertake a wide variety of actions. However, they each will have to open the machine at the beginning of the process, and then close the machine at the end. So if we create separate use cases for the open and close activities we can have nice little package of activities that can be reused. That said, a weakness of this technique is that the timing is not necessarily clear.

I’m not entirely sure I have a complete grasp on the extend concept. I believe is it intended to show that other, complete and self-contained packages of actions can be added to an activity. So, if you are going to buy gas, you absolutely must pay for the gas and pump the gas. However, if you visit a gas station, you may do a lot of different things. One of those may involve buying gas, but that isn’t necessarily required. I’m actually not even sure I’ve drawn the arrow in the correct direction.

While this technique isn’t my favorite, it is a standard part of the UML oeuvre and a lot of people do use it.

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

TWSL Series 10: Permutations and Traceability

Today I gave this webinar for the Tom Woods School of Life Lunch and Learn Series. The slides are here.

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

TWSL Series 09: Testing and Acceptance: Verification, Validation, and Acceptance (VV&A)

Today I gave this webinar for the Tom Woods School of Life Lunch and Learn Series. The slides are here.

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

Risk Analysis and Management

I don’t strongly feature the subject of risk analysis when I talk about my framework, but that doesn’t mean it isn’t accounted for or present. I usually build up my framework like this:

Risks and Impacts appears with Assumptions and Capabilities in the first outline. The reason it isn’t presented as its own phase is because this work really should be happening though every phase in many different forms, and my formulation is meant to provide practitioners with the improved situational awareness that comes from understanding how the phases are truly different. That said, these concepts are called out early because the sooner they are considered, the better.

The practices of project management, Lean Six Sigma, and business analysis both have a lot to say about risk, but the BABOK only obliquely addresses the costing side of things. One thing the project management oeuvre considers, for example, is a way to compare risks by multiplying the cost of the unanticipated or unwanted outcome by the percentage change they will occur. The BABOK includes this idea, but not for evaluating which projects to pursue. Outside of that, however, the practices are mostly similar. (So, should we make the next version of the BABOK even thicker by expanding this section with a lot more detail, especially given the IIBA’s posture of never being prescriptive?)

The first step in dealing with risk is identifying them. Some will be known, some will be unknown, and some will be of indeterminate or variable severity. More information is always preferred, and one way to identify risk is the follow the techniques I recently discussed for the proactive parts of root cause analysis (e.g., FMEA and generally being thorough when examining all parts of existing and new systems and the environment in which the engagement is conducted). Leverage your organization’s policies, lessons learned, and people for all possible insights, and research common occurrences and practices in your region and in your industry. Your organization’s insurers may have further insights to offer.

Risks come in may forms. They can be based on things occurring once, multiple times, or not at all. Events and consequences may map one-to-one, one-to-many, and many-to-one, so be thorough.

Once risks are identified they should be maintained and tracked in a risk register. It should include information along the lines the example in the BABOK.

  • Risk Event or Condition: description of the potential situation that may have to be addressed
  • Consequence: what happens if the event occurs or situation arises
  • Probability: how likely the situation is to arrive (percentage or something like high / medium / low)
  • Impact: the cost of effect if the situation arises (cost, time, materials, people, contract (scope & quality), reputation, or legal explicitly or high / medium / low)
  • Risk Level: rough amalgam of probability and impact
  • Risk Modification Plan: how the occurrence should be handled (see below in this article)
  • Risk Owner: name and contact information of party in charge of managing the situation
  • Residual Probability: as above but residual
  • Residual Impact: as above but residual
  • Residual Risk Level: as above but residual

There are five classic ways to manage risk.

  • Avoid: The risk is either entirely prevent or plans are changed so the risk cannot possibly occur (at least in a way that will effect the plans).
  • Transfer: The impact of the risk is moved to or shared with a third party (e.g., an insurance company, but could also involve other kinds of teaming).
  • Mitigate: Steps are taken to reduce the probability of the situation arising or, if it does arise, reducing the effects or impact of the situation.
  • Accept: Deal with risks as they occur, or do nothing at all.
  • Increase: Not all risks are negative. Some are positive, and in those cases it may be best to load up on more risk in hopes of a big payoff.

Risks should be reviewed and plans updated at intervals. Some risks are reasonably well understood and quantifiable through actuarial analysis performed on voluminous historical data, known weather patterns in combination with geography, prevailing conditions in industry and economy, and so on, but others are less predictable. The bottom line is to prepare for the expected and to expect the unexpected.

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

Sequence Diagrams

Imagine a network with the following representative elements. Many external and internal workstations, mobile devices, and pieces of equipment exchange information with an internal system of servers and capabilities.

Now imagine that some of the internal servers provide a number of services where sending them a message results in them returning a package of information that can be made use of, while simultaneously causing some kind of (desirable) internal side-effect, such as a new or modified entry in a data table. This kind of distributed, stateless architecture is called a microservice, and they are usually bundled to provide groups of small, related functions that cause a related set of desirable side-effects.

Now imagine a group of external applications that make a series of calls to a given server, to evoke a series of related actions, in a system like that depicted in this block architecture diagram.

Given these description, now ask what is known about the order in which these operations usually take place.

The answer shouldn’t be, “not much,” even if you had published descriptions of the information and format of the messages sent and the answers received.

The answer should be, “nothing.”

There are a lot of ways the order of operations could be listed. They could be written out as a series of instructions in a document or a use case. The order could be left undocumented so the various capabilities could be used as seems appropriate for each application. Or, customized ad hoc representations could be made up as shown in the next figures. The first shows a routing diagram that implies timing, while the second shows an order of operations overlaid on a block architecture diagram.

However, there is a fairly standard way these can depicted, and that is by creating a sequence diagram, an example of which is shown next. These grew out of the Unified Modeling Language (UML) practice that developed within systems engineering. It is often, but not exclusively, used in computer science, and I refer to it in various of my presentations.

These diagrams show operations in time from top to bottom, and also show different components from right to left that house operations. Each object is represented by a lifeline, which is shown as a dashed line that descends from an object box, examples of which are shown in gray along the top. An “X” on an object’s lifeline, placed just below the last activation box, indicates that the object goes out of existence (or is otherwise deallocated or destroyed). Activation boxes are shown in brown (note that any colors can be used for any elements), and show the span of time during which the item is acting with respect to the process depicted. They extend vertically along the lifeline. The top of the box shows when the object becomes active, and the bottom of the box shows when the object becomes inactive. If an object is called upon to act more than once, multiple activation boxes can be placed along a single lifeline.

Control is passed to different objects by passing messages. In most cases, as in microservice architectures, messages are actually passed using some kind of communication channel, but many means of passing control are possible. For example, a function call may have parameters and may result in values being returned, but they may both be in a single unit of code that doesn’t involve any kind of “over-the-wire” communications.

Note that two kinds of messages can be passed. Synchronous messages are shown with filled-in arrows (like those in the figure above), and represent operations where the sender may not carry out any operations until a return message is received (or a local time-out procedure is potentially invoked). Return messages are shown as dashed lines and with open arrows. Messages can all contain information of various kinds and in any quantity. The simplest messages will indicate requests and acknowledgements with no other information. Asynchronous messages are shown with open arrows and indicate that the sender may perform other operations while waiting for a reply (or that a reply may not even be expected or needed).

The BABOK shows only the most basic elements of a sequence diagram, but many more can be used. There are methods for depicting logical branches, self messages, recursion, and more, and you are invited to research other sources for more information.

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