R.P. Churchill.com

My first engineering job was as a process engineer in the paper industry, where I designed and analyzed large industrial systems that ran this…

through this…

to make this…

We can break the system down (or build it up) like this…

using components like this…

and this…

which can further be broken down like this…

…into as much detail as you’d like to get into.

When tracking items through an engagement…

they can be decomposed as requirements are more elaborated and defined.

Remember that RTMs must crosslink horizontally across phases and vertically to define the logical, hierarchical relationships of the solution elements.

Here is a high level example of a hierarchical breakdown of a large system. Imagine this being rotated ninety degrees counter-clockwise and plotted vertically in the RTM shown above.

These two views can be merged as follows. (See full discussion here.)

If a system can be described by known equations, each term can be analyzed in terms of identifying every possible effect that could make any individual variable larger or smaller, and also considering terms that may drop out entirely. The first equation is explicit and formal while the latter serves as more of a mnemonic.

This diagram shows the flow of calculations in a large spreadsheet, which is just another form of very long equation.

Behaviors and decisions can be analyzed down to very low levels.

Process models can be analyzed from the top down…

and from the bottom up. Multiple operations can take place within a location, station, or subprocess…

and those can be broken down in exacting detail.

Large systems can be broken down to understand contexts and details. Each element in the diagram below is its own, highly complex entity involving the work of multiple creators and integration of a myriad of materials and technologies.

Analyzing all aspects of a systemic capability, potentially across multiple products, can highlight commonalities and differences, and can help identify opportunities to plug gaps, regularize techniques, increase modularization, and so on.

This type of diagram is a common tool to perform root cause analysis. The categories of the “ribs” could be remembered using 5 Ms and an E.

Employing many different modes of decomposition gives many possible perspectives and insights. This helps ensure that analyses will be thorough and robust.

The BABOK identifies the following categorizations on the subject, many of which are discussed above. Please consult the relevant section of the BABOK for further details.

1. Decomposition Objectives
• Measuring and Managing
• Designing
• Analyzing
• Estimating and Forecasting
• Reusing
• Optimization
• Substitution
• Encapsulation
2. Subjects of Decomposition
• Business Outcomes
• Work to be Done
• Business Process
• Function
• Business Unit
• Solution Component
• Activity
• Products and Services
• Decisions
3. Level of Decomposition
• Per the examples above, decomposition can continue down through as many levels as make sense for a given analysis.
4. Representation of Decomposition Results
• Tree diagrams
• Nested diagrams
• Use Case diagrams
• Flow diagrams
• State Transition diagrams
• Cause-Effect diagrams
• Decision Trees
• Mind Maps
• Component diagram
• Decision Model and Notation

This BABOK technique involves creating something that allows investigation of one or more aspects of the solution being developed. This creation can be physical, in the case of mock-ups meant to illustrate a concept or explore ergonomics or test a subsystem or plan manufacturability, or abstract, in the case of diagrams or storyboards or process descriptions or user interface designs.

Prototypes can be produced as throw-aways, which means they are only temporary creations. How many ventures started from drawing on a napkin in a restaurant? They can be functional, which means they actually perform at least some aspect of the end solution. Many famous examples of these can be found in museums, up to complete experimental aircraft. A series of prototypes can be created as the proposed design evolves over multiple iterations. Think of all the prototypes made to test the thousands of items needed for the moon landings.

They can be used to demonstrate a proof of principle or proof of concept. These are created to explore the new applications of tools, technologies, discoveries, or arrangements. Sometimes the tools or technologies are being used for the first time by anyone, but usually they are just used by teams to test fitness for the present purpose, or to demonstrate that the team can use them. A coworker of mine built a mock-up of a novel walking mechanism for a steel reheat furnace — out of cardboard, pipe cleaners, and toothpicks. It allowed all viewers to quickly grasp its simplicity. Moving the walking carriage by hand inside the outer shell clearly demonstrated that a simple mechanical movement could robustly and reliably achieve the desired results in a harsh industrial environment.

Prototypes can be created to explore the usability of solutions by their intended customers, including of software GUIs and physical interfaces on things like consumer electronics. GUI mock-ups can be created with varying degrees of functionality and visual appeal using tools like rapid builders (Borland’s GUI tools were terrific for this), Balsamiq, Visio, or whiteboard drawings. The original computer mouse was made of wood.

Some prototypes test the visual aspects of a proposed solution, including color, arrangement, font size and shape, and other visual cues. Examples include signage, warning labels, product packaging, and industrial design. Some clever (read: cynical and slightly evil) manufacturers realized that making potato peelers with brown handles made users more likely to throw them away with their potato peels, so they would have to buy more more!

Functional prototypes allow testing the operation of a proposed solution in whole or in part. Think of docking ports on spacecraft, or of computer algorithms.

Models and simulations are a potentially powerful, and also potentially complex form of prototyping. One of my past companies used a version of my suggestion for its advertising slogan: “We do it a thousand times so you do it right the first time.” These can involve 3D models, process models, visual models, and so on.

Prototypes can be used in every part of the engagement and product life cycle.

Financial analysis comprises a number of considerations and methods. They all begin by assigning costs to all germane capital, fixed, and variable items in the existing state and in the future state, and also considering expected revenues. Some of the accounting is straightforward, but other analyses require time value of money (TVoM) calculations.

I often quip that my family has produced four generations of economists (or at least financial professionals) and that as a mechanical engineer and programmer I’m something of a black sheep. However, that background led me to take a course in engineering economic analysis in the spring semester of my freshman year in college, back in 1981. I also spent the following summer working as a customer service rep for a mutual fund run by my father’s company, Federated Investors.

Time value of money calculations come in many variations, but they all involve series of revenues and payments at an interest rate. One of the most important of these calculations is for present value. This is applied because (under a normal situation where interest rates are positive) money in the future is considered less valuable than money today, which is why interest rates in such calculations are called discount rates. For projects that may involve expenditures and revenues over long periods of time, these must all be converted to present values to determine whether the project makes sense. Interest rates may be different for revenues and expenditures.

Here are some specific elements that come up (many are listed in the BABOK, but not all).

Capital Costs: These are one-time costs for items needed to support the new process. They can include physical plant, machines, tools, IP licenses, software, and one-time services.

Fixed Costs: Ongoing costs that occur at regular intervals, whose magnitudes either don’t change or change at predictable rates. These can include salaries and benefits, rents, utilities, ongoing license fees, regular consumables, insurance premiums, scheduled maintenance, regulatory fees, and so on.

Variable Costs These are costs that occur at irregular intervals or that can be different over time. These can be incurred due to market and regulatory changes, natural disasters (even if covered by insurance), unscheduled maintenance, accidents, and more.

Revenues: These are the projected income amounts over future intervals of time. These can never be known for sure in advance, although estimates may be more accurate to the degree that future conditions are expected to resemble past and current conditions. Projections of future revenues are ultimately up to the entrepreneurial judgment of the owners and managers of the organization. I’ve seen such judgments be very successful and fail completely. Consider the difference between Steve Jobs’ launching of the iPhone, iPad, and Apple Watch, the demand for which could not actually be known (and also the Palm/HP Pre smartphone, which you probably don’t remember for a reason), and the decision to place a new drug store in a growing neighborhood with well-understood demographics.

Value Realization: This is essentially present value of all future forms of income, but it should also include non-financial aspects of value. Examples of the latter are improved employee engagement and morale, reliability, and organizational reputation (although economic values can be assigned to those things).

Cost of the Change: These are the transition costs associated with the installation of or transition to a new process. This is especially germane when transitioning from an existing process to a new (modified or improved) process. It isn’t really germane when a new process is being implemented when it’s not replacing an existing process.

Total Cost of Ownership (TCO): This represents the cost to acquire a solution over its entire life cycle, including capital, installation, ongoing, and retirement costs. Some solutions have a known life expectancy, but in other cases an upper limit will be placed on the duration of the analysis. If the investment doesn’t pay for itself within something like three or five years it will not be undertaken. The actual duration will depend on the nature of the investment.

Cost-Benefit Analysis: This is the present value of the projected benefits minus the present value of the present costs for the proposed endeavor. In theory the benefits will be greater than the costs. The relative cost-benefit (and risk) or pursuing different projects is a major criteria in selecting projects to execute. Efforts should be made to identify and include all relevant costs and benefits in any such analysis.

Return on Investment (ROI): This is expressed as a percentage as the benefit minus the cost over the cost or

ROI = (Total Benefits – Total Cost) / Total Cost

Net Present Value (NPV): As mentioned previously, this is expressed as the present value of the benefits minus the cost of the investment (present value of total cost).

Internal Rate of Return (IRR): This is yet another way to determine the relative worth of pursuing different projects. It is the interest rate (or the discount rate) at which the project would be expected to break event (have a NPV of zero). Projects with a higher IRR are preferred. Companies will sometimes specify a hurdle rate that represents the minimum IRR they expect to realize on an investment.

Note that the nominal interest rate is the published rate that is actually in effect (for the given situation, duration, and so on). The real interest rate is the nominal rate minus the rate of inflation. Real interest rates can be negative, which should be an unusual situation. All of the foregoing calculations should be performed using the real rate of interest, while remaining mindful that both nominal interest rates and the rate of inflation may vary, and sometimes by a lot. I lived through the double-digit interest rates of the 1970s and 80s, and many countries have experienced far higher rates over time. I suspect that we are currently moving into a period of much higher and more volatile interest rates here in the United States.

I’ve written simulations that incorporate costs and revenues for each element, that allow me to determine whether certain scenarios were supportable or were good investments. I did this while working for a customer that gave me average numbers to work with. Customers will often want to keep such information close to the vest for reasons of competitiveness and privacy, so you may need to develop tools that let then enter the correct values and run the analyses on their own.

As a final aside, some interesting work is currently being done on the origins of interest that go beyond the pure time preference of individuals.

I’ve touched on the idea of lessons learned a few times previously, but here I’d like to address the idea directly and explicitly, as part of the Tampa IIBA’s ongoing review of the BABOK, specifically the techniques listed in chapter 10, during its weekly online certification study sessions.

Per the BABOK,

The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases.

I like this definition because while lessons learned is often thought of as something you only do at the end of an effort, it’s really something you can and should do whenever it make sense. In the following figure I show my framework for managing engagements to develop solutions for customers. It involves iterating within and between phases to ensure proper understanding, thoroughness, completeness, correctness, and internal logical consistency are achieved in every phase and for every item. However, this process does not — or at least should not — occur only with respect to the solution.

Business analysts, along with all other team members and stakeholders, should be mindful to review and improve the way they work with and communicate with the customer, and also how they work with and do things within their internal teams. This also iterative process may involve different participants in different phases of an engagement, but the iteration within and between phases remains. Note that the Project Management framework specifically talks about establishing and revisiting things like stakeholder relationships, communication, cost, quality, risk, and so on. Business analysts should certainly be cognizant of these ongoing issues as well, and many of them are addressed by the BABOK, although often in a different way.

Looking at the specific case of Scrum, we see the Sprint Review and Sprint Retrospective being conducted at the close of each sprint. These represent not only a review of the work itself, but also of the methods of working with the customer and within the internal team, respectively.

Note that the traditional sprint diagram above only includes the items on the right hand side of the diagram below, which shows how all of the six phases of my framework are incorporated into the ongoing process. This is important because product backlog items (PBIs) don’t just magically appear from the ether. Someone is doing the work to identify, prioritize, and refine them, and one of the main practitioners is the business analyst, who is often considered to be a standard team member in the Agile/Scrum framework.

The bottom line is to be looking for ways to improve everything you do, in every context, with every contact, at all times. Everything that happens can be a lesson learned.