R.P. Churchill.com

What do we mean by state?

We commonly think of the states of matter as solid, liquid, and gaseous, and we know that these are dependent on temperature. For water at — atmospheric pressure — we refer to these states as ice, liquid water, and steam, but every substance can assume the same states, even though they may do so at very different temperatures (and pressures). If we know the temperature, pressure, and specific volume of a substance, we also know (something about) its specific energy, and that uniquely defines the state of the substance.

Other states of matter are possible, with plasma being probably the best known. You can think of plasma as the next hottest state above gaseous, but where the electrons have too much energy to remain in orbit around their nuclei. You can think of the Bose-Einstein condensate as a “fifth state,” the next coldest below solid, where none of the particles have enoough energy to hold together as atoms. These states and many others are described in this Wikipedia article.

The behavior of the substance depends on its state, and the state of the substance depends on other characteristics, which are not themselves states.

States in Object Models

If we think of water as an object, it can have many characteristics. It can have the properties of temperature, pressure, specific volume, and specific energy (define three and the other item is defined as well, with some complications we won’t go into, mostly having to do with quantities of substance existing in multiple states simultaneously in various conditions of saturation). We specify a mass or particular volume of water to instantiate a particular object, as opposed to describing something abstract.

From these pieces of information we know what state (or sometimes states) the water is in, and then we know how it will behave. In object oriented programming, an attribute is a variable defined within an object that can take on different values. Most of the attributes in this example of a particular volume of water are independent. The state of the water is dependent on other attributes of the water. Other actions, then, are allowed, disallowed, or otherwise governed by the derived state.

State for Systems and Business Analysts

Entities can move through, move within, or remain stationary within a process, and they can change states in any of those situations. A state is a variable condition an entity can be in that affects its behavior. An entity (or object) can have multiple attributes that each reflect different possible states. Let’s look at some examples.

Here I use the term “entity” in a more general sense than what is labeled in the diagram above. For this discussion, an entity can enter, move through, and exit from a system. Think of documents being handled in a business process. An entity can also move within the system but never enter or leave, as in the case of an airport shuttle car. Stations, facilities, queues (and bags) all remain stationary, but can be entities in this sense as well. All can have different characteristics that can define states.

States of entities are defined to determine what actions can and should be performed and what decisions can be made. States of entities in systems can be defined in as many ways as your imagination can dream up — as long as everyone understands them. Here are some examples of states and how they can be defined:

• A customer’s monthly payment status can be defined by whether payment has been received by a due date or, if payment is late, how long overdue the payment is. Different actions will be taken depending on the time of full payment, partial payment, passing defined thresholds of lateness, and so on.
• Multiple pieces of information might be required to make certain decisions or take certain actions. States can be defined to describe the ability to make the decision or take the action based on the disposition of all of the required data items.
• Different actions may only be supported when operations are open. Operating hours can determine open/closed states, thermostat settings, availability of certain resources, and so on.
• States can be defined by quantities. Stocked items may need to be reordered or replenished when quantities fall to or below defined levels. A vending machine must know when it has received enough cash, coinage, or electronic payment to complete the sale and dispense product, and also give change or cancel the interaction and reassume a waiting state if appropriate.

State Models

A state model defines:

• The possible states an entity can be in: Any attribute can be a state that can have multiple values, all of which must be defined. An entity can have many different attributes that each define multiple states.
• The sequence of states the entity can be in: An entity (or attribute of an entity) in a given state may not be able to arbitrarily transition into every other state. Rules for defining what is possible must be defined. This can be done using tables, diagrams (see below), or other means.
• How the entity changes states: All actions associated with transitioning into and out of each state must be defined.
• The events and conditions that cause the entity to change states: The mechanism(s) causing states to change must be defined. Sometime an event will change a state directly, and at other times an event must scan other information to determine whether a state change has occurred.
• The actions permitted or required by an entity in each state: Some actions may not be allowed if an entity is in certain states. Other actions must be performed if an entity is in certain states. The latter may happen when the state transition happens, while the entity is in the state, or before the entity is allowed to transition out of that state.

The figure below is a kind of state transition diagram that shows which states can be transitioned into from which prior states, and also the relative probability of each transition’s occurrence. Many types of state transition diagrams, tables, and other descriptions are possible.

It’s Tricky (h/t Run DMC)

A system as complicated as an aircraft can have many different attributes which each define a state. States can be defined in relation to other variables, and even based on other states. The diagram above shows just a small subset of attributes which may describe an aircraft and the states it may assume. What questions does the figure bring up in your mind?

These states and actions can become very, very complicated, and great care may need to be taken with language and definitions. The analysts, customers, implementers, testers, and reviewers may need to work very closely together. Analysts should be keenly aware of this complexity and ensure that the right conversations are had and the right questions are asked and answered.

Reviews are about examining some output or artifact for quality and agreement. I primarily think of this process in terms of my framework, as shown in the figure below, but many contexts are valid. In my framework, review means building up the relevant work products in each phase and having them reviewed by the customer and reworked by the solution team until they are accepted and approved by all participants. I often talk about how the framework involves continuous iteration within and between phases, and this is always based on different kinds of reviews.

Here’s how review tends to work within each phase. For clarity the activities are described from the point of view of an external solution team developing something for a customer, but it should be understood that the line between the solution team and the customer can vary from sharply defined (I spent most of my career functioning as an external vendor or consultant) to nonexistent (internal groups can analyze and develop solutions for their own problems).

• Intended Use (Problem Definition): The team helps the customer ensure they’ve identified the problem and purpose correctly.
• Conceptual Model: The team documents the results of its discovery and data collection processes, and then the customer verifies that the team has achieved accurate and complete understanding of the customer’s processes and vocabulary.
• Requirements: The team elicits requirements from the customer and collaborates to ensure that the most complete and accurate possible list of both functional and non-functional requirements is generated.
• Design: The team proposes a design and the customer decides whether to approve it or not.
• Implementation: The team implements the designed solution with input and continuous review by the customer.
• Test (and Deployment and Acceptance): The team and customer complete different kinds of verifications and validations.

The customer ultimately provides the final approval or non-approval for each phase. Part of the iteration between phases involves updating the Requirements Traceability Matrix to ensure consistency horizontally between phases and logical consistency vertically within the Design/Implementation phases. Multiple individual iterative create-and-review processes may take place, serially and in parallel, within each engagement phase (that is, the figure above is a stylized, simplified representation of the overall process). Imagine everything that must be going on in an engagement involving multiple teams in a SAFe environment, as shown below.

The Scrum framework incorporates two explicit review activities. In the Sprint Review, the team describes and demonstrates the latest work increment for the customer. In the Sprint Retrospective, the team (without the customer) reviews its own working methods during the just-ended sprint. It should be understood, however, that all of the other kinds of review are still taking place.

Conducting a review involves defining the objective of the review, choosing the techniques to be used during the review, and selecting the participants in the review.

The following review techniques (named and described in the BABOK) can be used (among others).

• Inspection: This is a formal process of reviewing some or all work products to determine whether they meet defined criteria.
• Formal Walkthrough (Team Review): These are typically performed to review the methods and behavior of internal teams.
• Single Issue Review (Technical Review): This is a formal review, often involving a specific technical aspect, of one outstanding area of concern.
• Informal Walkthrough: This is a fairly informal process of reviewing an item and soliciting feedback from a small number of participants.
• Desk Check: This informal process drafts an outside participant to perform the review.
• Pass Around: In this process, many people review the item or items and offer feedback, usually one after the other.
• Ad hoc: This can be any type of informal review by any type of participant.

Can you think of any additional review techniques?

Finally, the BABOK identifies the following roles. An author creates a work product or artifact. A reviewer is anyone who looks at the work product or artifact and offers feedback or approval (or non-approval). A facilitator is a neutral participant who guides a review process for others. A scribe documents the actions and results of the review.

Like the balanced scorecard technique I described yesterday, I view the business model canvas technique as a way to get analysts to look at organizations in a different way. It is used fairly commonly (though I had never seen nor heard of it prior to encountering that materials in the BABOK). It seems to me to be a tool more appropriate for higher-level officers in an organization to gain a readily accessible and somewhat standardized view of its activities, purpose, and effectiveness. That said, it’s not that business analysts cannot or should not be involved with.

While the technique seems to be primarily intended to review organizations from within, to determine the best ways to deliver value, it occurs to me that the technique could also be used to evaluate multiple organizations in a consistent way. This would provide an efficient way to compare and contrast their most salient characteristics.

This technique is well known enough that many templates and tools exist for creating them. Here is an example from the Wikipedia entry on the technique:

The canvas contains nine sections (some versions apparently list seven), labeled per the following list, which can be filled with any kind of information that communicates in a way that all participants understand.

• Key Partnerships: What external organizations and resources, if any, enhance the organization’s ability to meet its goals?
• Key Activities: Primary activities that deliver value to customers in terms of value-add (customer willing to pay), non-value-add (customer not willing to pay), and business non-value-add (customer not willing to pay but required for other reason).
• Key Resources: Physical, financial, intellectual, and human.
• Value Proposition: What the customer pays you for (also, their cost vs. their benefit).
• Customer Relationships: Acquisition and retention, personal vs. impersonal, in-person vs. automated, etc.
• Channels: (All) Modes of interaction with the customer.
• Customer Segments: Identifying and addressing through different needs, profitability, channels, and relationship modes.
• Cost Structure: For understanding of how to manage and improve.
• Revenue Streams: All the ways to generate income and fees.

I have never explicitly used this technique, but I have certainly examined problems, systems, and opportunities from all the perspectives contained within it. This is true of many techniques described in the BABOK. I often note that every formalized technique or analytical framework is just an organized way of getting you to do what you should be doing anyway, if you were particularly experienced, creative, or thorough. I further frequently note that all described techniques can be and are criticized. While these techniques can inform and clarify the thinking of an experienced practitioner, less experienced practitioners have to start somewhere, and this is an interesting technique for directing analysis to many important considerations.

As someone who has studied economics for much of my life, and especially in the last two decades, I appreciate that economics is the study of choices made under conditions of scarcity and that, contrary to many people’s impressions, those choices do not always involve money. It may be similarly tempting to evaluate all business (or organizational more generally) activities in terms of money, but the balanced scorecard techniques forces the analyst to look at other areas. A monetary value can be placed on every activity, sure, but you have to drill down through any layers of cause and effect to see what they might be.

The balanced scorecard explores a business or system across four dimensions:

• Financial: Inspiring analysts for look at considerations other than finance does not mean that it doesn’t need to be considered. After all, if an organization or a process continually loses money, it won’t be around for long. (Accounting, by the way, along with the recognition that one of the three functions of money is to serve as a unit of account, is one of thee great discoveries of humankind.)
• Learning and Growth: This encompasses employee training, corporate culture, and all manner of innovation and improvement. It can even involve training the customers. Improvements in financial performance can result in tracing back through all activities to see how the effect the ending outcomes.
• Business Process: This involves measuring the performance of people and processes internally, and customer satisfaction externally.
• Customer: This dimension focuses of the customers’ needs and satisfaction.

There is some overlap between those ares, but the point is to get analysts to focus on each area, specifically.

Analysis of each of those dimensions involves:

• Objectives: What is the organization trying to accomplish?
• Measures: How can the organization determine whether it is succeeding?
• Targets: These must be expressed in terms of things that can be measured (in theory). TQM defines “quality” as adherence to requirements (i.e., a result either meets defined standards or it does not.). This attempts to turn continuum problems into discrete (yes/no, pass/fail) problems.
• Initiatives: What activities will the organization take to improve or maximize performance within each dimension?

It may helpful to construct a table, but since multiple objectives, measures, targets, and initiative can be defined for each dimension, that’s probably overkill.

Again, this isn’t a method I’ve ever explicitly used. As the BABOK notes, it does not take the place of other types of absolutely necessary forms of analysis. I believe it’s main utility is to inspire analysts to consider things from different points of view.

I once had the insight that most of the stuff in the training materials for my Scrum certifications was kind of beside the point, but that flipping through the three slim notebooks of course notes one morning every couple of weeks might help keep some ideas fresh in my mind. Reviewing the list of fifty BABOK techniques may serve a similar purpose.