Business Cases

A business case is essentially a cost-benefit analysis of taking a given course of action. Actions may include embarking on new projects, acquiring resources or other organizations, making non-routine purchases, adopting new methods, entering partnerships, seeking new lines of business, and so on.

A business case may be constructed just like any other project, except the implementation and test phases aren’t part of this named effort. That is, you do everything you would normally: identify the problem, figure out what’s going on, identify needs, assess risks and constraints and assumptions, and design potential solutions. If the benefits of the solution outweigh the costs, either at all or by some specified margin, then the course of action is pursued.

The BABOK describes the process this way:

  1. Need Assessment: This defines some capability or improvement that may drive a benefit to the organization.
  2. Desired Outcomes: This is a description of the benefits realized, which can be expressed in terms of time, cost, or quality (or features).
  3. Analyze Alternatives: This is where you assess the costs and benefits of one or more potential solution approaches. This corresponds to the design phase of any project (possibly in conjunction with the conceptual modeling phase).
    • Scope: This is where the size and boundaries of the proposed effort are determined. These define what will and will not be included in the analysis. It also helps analysts choose where to break larger problems down into smaller and more manageable ones.
    • Feasibility: This analysis determines whether something can (practically) be done at all. This can be done from a technical or logistics point of view, but the major overlap is with the various financial analyses.
    • Assumptions, Risks, and Constraints: I include this in my larger list of project activities, and near the beginning, but I don’t include it in the streamlined, stylized diagram of my framework. That’s because it isn’t really a standalone activity, but takes place in potentially every phase throughout the entire engagement.
    • Financial Analysis and Value Assessment: This often involves a full cost-benefit analysis expressed in financial terms, but many judging and scoring systems can be used. For example, a weighted multiplicative system can allow alternatives to be compared both directly by feature and personally by perceived importance.
  4. Recommend Solution: Choose the best option – or not to proceed at all.
Posted in Tools and methods | Tagged , , | Leave a comment

Prototyping

Prototyping is the act of mocking up some aspect of an envisaged product or capability in order to asses its suitability, acceptability, or performance. It is usually applied to product design, but can be used in many different contexts for both internal and external customers. Successive iterations of a prototype, either as throw-away one-offs or through evolutionary modifications, help determine whether requirements have been properly expressed and understood, the item can be manufactured efficiently or at all, contains all desired functionality, is comfortably usable (ergonomics), is understandable and intuitive, and so on. Prototypes may be physical objects, systems, arrangements (or layouts), environments, or procedures.

Prototypes can be used in proof-of-concept exercises, to determine whether the desired outcomes or effects can be achieved. A form study prototype can be used to evaluated fit and finish, manufacturability, ergonomics, material requirements, and other things. A usability prototype may be used to examine user interactions and comprehension. A visual prototype can bee used to assess how an item looks in terms of its visibility (potato peelers with potato-colored handles are more likely to be thrown away with the peeled skins, which may or may not be a good thing depending on your point of view) or appeal. A functional prototype is used to see how things work.

Methods of prototyping include the following:

  • Storyboarding: This allows investigation of the order, location, appearing, and arrangements of things and events. Movies are often storyboarded before production begins, but the technique can be applied to any series of events.
  • Paper Prototyping: This involves the creation of one or more drawings, which may be done to any degree of accuracy or scale, to see how things fit together and build shared understanding.
  • Workflow Modeling: This describes the flow of operations, decisions made and criteria required to make them, execution brances and diversions, and so on. They are often defined as flowcharts.
  • Simulation: Objects, and systems can be simulated when it is too expensive, time-consuming, or dangerous to build and exercise them in the real world. A wide variety of simulation techniques may be employed for this research (e.g., different kinds of analog, continuous, discrete-event, and hybrid simulations).
  • Physical Models: When in doubt, build something real and see how it goes.

Examples of prototyping:

  • Wind tunnel testing: This is applied to air and ground vehicles and also structures both singly and in groups. Water-borne vehicles are similarly tested in large tanks.
  • Flight simulators: These can be used to test physical performance characteristics of aircraft and also operational procedures.
  • Full-scale functional prototypes: Entire cable channels and museums are devoted to all the crazy flying aircraft that have been produced to explore various ideas and capabilities.
  • Ergonomic studies: Hand-held objects are often studied and designed with a keen eye toward comfort, usability, and safety.
  • Simulations of border crossings are used to understand ongoing issues and the effects of proposed changes, and also in the process of designing and building new ones.
  • Architects often build building models and landscapes out of foamcore and cardboard so customers can viscerally understand the look and feel of a proposed structure and its environment.
  • Building Information Systems (BIMs) like Revit are used to specify the design of a building and its fixtures and infrastructure in great detail. This supports defining bills of material, construction order and requirements, skills needs for all the different components and systems, site preparation and staging, and so on.
  • User Interfaces for computer software can be mocked up using tools like Balsamiq, Visio, or UI-builders included in different programming products. They make involve greater or lesser degrees of working functionality.(/li)
  • The command module simulator was famously used to identify a procedure that allowed the Apollo 13 spacecraft to be safely shut down and restarted, which allowed the crew to make it back home safely against long odds.(/li)

It is important to note that prototypes may turn up unexpected causes and effects, but also might not. Many lessons have had to be learned the hard way. You can’t test for effects you don’t know even exist. Remember the (first) Tacoma Narrows Bridge, the Hyatt Regency Walkway Collapse in Kansas City, and the failure of the railroad bridge that led to the formation of the Order of the Engineer.

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

Business Capability Analysis

Business capability analysis is the process of evaluating a many aspects of a business’s ability to accomplish defined goals and support and develop its staff and customers. It seeks to create a consistent rubric for conducting repeatable analyses that allow participants to compare businesses, analyze strengths and weaknesses, and identify and effect improvements.

The analysis process involves the creation of capability maps. The figure below shows what the relevant areas of evaluation are and how they might be scored.

The figure illustrates that the analysis involves value to the customer and to the business, identified performance gaps, and different kinds of risks. Since there are so many possible considerations to analyze, as will become apparent, the technique keeps the scoring simple. There’s not much point in trying to define the difference between a six and a seven on some arbitrary scale (much less a 67 versus a 73), so high, medium, and low is more than sufficient to guide effort to obvious areas of improvement.

Risk can be analyzed with respect to the business (its market functions, reputation, relationships, and financial status), technology, the organization (its people, environment, and function), and the market (the overall state of that industry or segment). See further discussions of risk here.

An organization’s capabilities can be identified and examined based on any breakdown of operations and capabilities. They should be relevant to what the organization does and places emphasis on. When comparing organizations, it’s a good idea to do so using comparable hierarchical breakdowns.

The BABOK’s examples provide some solid guidance in this regard. It identifies major areas of inquiry including the organization, the ability to conduct project analysis, professional development, and the quality and structure of management. Those areas can all be broken down into sub-considerations. Under organizational analysis, we might consider capability analysis, root cause analysis, process analysis, stakeholder analysis, and roadmap construction. Note that these examples are all rather BABOK-y, which is fine, but do not feel bound by these specific areas of examination. Use ones that work for your specific situation. While it’s always good to be able to have an internal analysis capability, and the BABOK provides a great roadmap for it, sometimes you need to be more specific. If you run a distribution business, for example, you might examine your tracking, scheduling, routing, and dispatching capabilities.

Finally, you can create grids that show all the high-level areas of inquiry on one axis and their sub-areas on another, so a high-level overview of a wide variety of activities can be had at a glance. Some patterns may be obvious, and sometimes you might just want to address individual pain points.

I say quite often that I have never used the technique, though it strikes me as being valid and I can clearly see the utility. I have done the equivalent analyses in a lot of different ways. Like many of the fifty BABOK techniques, it’s a place to start, an organized and consistent way of doing something. It may or may not be the right way for you to approach any particular analysis, but it’s good to be aware of it. Someone thought enough of it to create it and find it and derive value, and it might turn out to be the exact thing you need!

Finally, note that you should not be bound by drawing out the situation for each major and sub-area of concern as shown in the figure above. Use any method of expression that works. You can just as easily create a spreadsheet or table that shows the relevant scores in different grid boxes (an X or solid shading in the relevant H/M/L column), by letter (H, M, or L) or word (High, Medium, or Low). Any of those can be color coded. Use what works for you and in any way your customers and colleagues can understand.

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

TWSL Series 15: Why Use Business Analysts and Their Techniques?

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 Tech Series 02: Three.JS and WebGL

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

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

TWSL Series 14: Business Analysis Techniques from the BABOK

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 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