R.P. Churchill.com

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

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.

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.