Fogbeam Labs The FogBlog

In our last post we talked a lot about how important Capability Cases are for Information Technology professionals on either side of specifying a software system. But what we didn't do was go very deep into explaining exactly what Capability Cases are. At least one reader was put off by our jumping straight into the rationale for Capability Cases without defining them (and perhaps some other terms) first. Posting on Hacker News, user hiccup said:

I'm having a hard time cutting through the business buzzwords to understand what these capability cases are. Seems like a standard Waterfall design methodology used by big consulting companies.

OK, heavy stuff, but we hope to correct that here.

First, to the point about "business buzzwords", I would say that there are no "buzzwords" in the previous post. That is, in the sense that a "buzzword" is a word which exists only to tap into some sort of faddish sensation and which conveys no actual meaning. What there is - perhaps in excess relative to some audiences - is a lot of technical jargon from the business world. Anyone not familiar with Porter's Five Forces model or SWOT Analysis might have found some bits to be a bit cryptic. This is one of the dangers of creating a mechanism which is designed to bridge the chasm between two "worlds" which have radically different technical jargon. Anyone not versed in both sets of lingo will find the literature on the topic to be a tough slog.

As it turns out, this "bridging" notion is the strength of Capability Cases, with the caveat that anyone who intends to master this technique must expend a little bit of effort to learn jargon, techniques, and skills from areas in which they may not currently be well versed. This is, perhaps, also a weakness of Capability Cases, as the technique demands its practitioners have at least a certain baseline of knowledge from both the "IT world" and the "Business World".

With that said, let's start, then, with explaining what Capability Cases are and a bit more about the methodology behind them. First, as stated in the book, a Capability Case is "the case for a capability". Succinct, but not very enlightening without talking more about what a "capability" is, and without defining "case" more clearly in this context.

In this context, when we talk about a "case" we mean something like "justification for" or "argument for". This is the way the word is used when someone says "make your case for X" or "what's the business case for Z"? It could also be thought of as somewhat akin to the "cases" or "case studies" that are used in business school. So, a "Capability Case" then is a detailed explanation, from a business perspective, justifying the development of a technological solution using a set of capabilities.

This now leads us to the question of "what do you mean by capability"? The authors of the CapCases book put it this way "By Capability we mean the potential to deliver business functionality". Wikipedia defines Capability thusly: "Capability is the ability to perform actions". When we talk about a "technological capability" then, we are talking about technology which enables some action or function which has business value. An example of a Capability might be "placing orders and checking out online using a web browser" or "full-text search across an array of disparate document repositories".

So how exactly do Capability Cases work to bridge the IT world and the Business world? First, a practitioner of this approach works to identify the problems or challenges confronting the business, using one or more well known techniques drawn from business analysis and strategic planning: Porter's Five Forces analysis, SWOT Analysis, Value Stream Mapping, review of Key Performance Indicators or perhaps the use of a Balanced Scorecard or Strategy Map.

Once a problem or challenge has been identified, the next step is to identify candidate capabilities which could be used to address the problem and build a solution. An example problem might be something like "Revenue is declining and our sales people are spending too much time managing routine orders from existing customers, which cuts into their ability to prospect and build new business". Once a succinct problem has been identified, the practitioners begin to review technological capabilities, which can include existing capabilities developed within the firm, capabilities which can be acquired in the form of pre-existing COTS or F/OSS packages, or non-existing capabilities which would need to be developed from scratch.

And it is at this intersection point that a firm truly needs staff who can walk - at least partially - in both "worlds", business and IT. To map the capabilities to the problem, and identify the most reasonable solution is the real work of capability cases. Once candidate cases are identified, a "solution story" can be constructed, which walks through a scenario involving the various actors, and explains how the capability leads to a solution to the problem at hand. A fully fleshed out Capability Case detail how one or more capabilities will be deployed to address the identified problem.

Now, to hiccup's earlier point about this sounding like a "Waterfall" methodology: Nothing about using CapCases implies the use of a waterfall approach! You certainly can - and should - iterate through the development of the CapCases which lead to the commissioning of a project to implement a solution. One could think of the use of Capability Cases and the associated methodology as corresponding, roughly, to the inception phase of the Unified Software Development Process. This technique is also entirely compatible with Agile principles and could either front-end the initiation of a project using, for example, Scrum, or the analysis and review and development of the Capability Case could become a part of the ongoing Scrum process.

Of course, the preceding discussion is focused on a scenario where a firm identifies a problem internally, and sets out to commission a technological solution to the problem. But I also argued last time that this technique is important to vendors, such as ISVs, as well. How can this be?

Simply, an ISV should develop "canned" or "cookie cutter" Capability Cases which illustrate how the capabilities provided by their products are used to address commonly encountered problems in their target market. The cases can be used to salespeople to help inform their earliest contacts with firms they are attempting to sell to (you could think of a canned Capability Case as a "job aid" in Solution Selling terminology) and can be used as part of an educational marketing initiative. If your capabilities are new and exotic enough that many people will not be familiar with them, a strong Capability Case will help demonstrate the value of your wares. And, of course, a canned Capability Case can serve as the starting point of a more detailed analysis, tailored to suit a particular customer, as the exploration process continues.

It should also be possible to talk about composing Capability Cases, and assembling more sophisticated cases at higher levels of abstraction, which are made up of less sophisticated cases, joined together. It should also be noted that naming your Capability Cases is important, as this gives you a vocabulary with which to converse at a higher level of abstraction. Of course, the case for a single capability may simply reflect the name of the capability, but a case which contains multiple capabilities, or a compositional case, may have a more illustrative name.

So, hopefully this goes helps lift some of the confusion around this powerful tool. Capability Cases are a powerful tool, and developing a deep understanding is not something one can gain overnight. We highly recommend that anyone interested in learning more go and read the seminal book on the topic, and - if you have further questions - contact us. Please don't hesitate to leave a comment here, and consider following our Twitter feed for the latest news and updates from Fogbeam Labs.

Join the Hacker News discussion.