Business Abstractions

Abstraction_HeaderThe older I get, the more I appreciate the specificity of language. For years, the skills of the business analyst have been part of my professional workbench. More recently, I accepted the challenge of teaching a course in business analysis for the University of Washington Professional and Continuing Education program. This brought me in contact with a plethora of new tools and techniques for business analysis. It also forced me to sharpen my skill and understanding of those I had been using for years. Imagine my surprise when very late in this process I discovered that I had been using the word analysis incorrectly for so many years.

Strictly speaking, I had not been using the word incorrectly so much as I had blurred the edges of what it really means. I had been using analysis as a synonym for close examination or scrutiny, which is consistent with what Business Analysis is. The discipline of Business Analysis consists of the tasks and techniques that lead people to understand and document how the policies and procedures of a business organization function. Clearly analysis involves such close investigation.

In reality, though, the word analysis is only part of that investigative process. Analysis is the breaking apart of a process, object, or chemical compound into its constituent elements. Equally important to this investigation is the opposite of analysis, synthesis, which is the construction of a process, object or compound from constituent elements. What was learned from analysis must then be synthesized in order to be useful. In essence, the entire discipline is inappropriately named.

We all know that even suggesting that Business Analysis be renamed to a more linguistically correct designation is an intellectual form of spitting into the wind, so I shall not waste my time attempting to do so. Nevertheless, the insight that I gained from the recognition will be useful to me both on the job and in the classroom. The process of examining this insight was itself a small example of analysis and synthesis.

Abstractions such as this abound in our discipline. One of the more profound “abstraction sets” I encountered during my recent academic expedition had to do with the concept of process. A process is a series of steps that, when executed in a particular order, produces a specific result. The preponderance of the effort in Business Analysis examines the workings of and reasoning behind business processes. For our purposes here, consider this business process – the process that is the focal point of our workbench full of tools and techniques – to be our A-level process.

However, in order to apply these tools and techniques to this A-level process, a group of people must step through an organized series of steps. This organized series of steps is also a process, but it is not the process being examined. Rather, it is the process that is performing the examination. This is our B-level process and while it does not resemble the A-level process, the A-level process may have influenced the choice of steps and their order. This is the process that the business analyst facilitates or manages.

Most A-level processes are in some way or another unique depending on the process, the industry, and the specific business rules of the company. A supply chain or product development process within a specific industry (and even for a specific product) may share many similarities, but will undoubtedly vary from company to company. The same is true of the B-level process. The design of the B-level process will also be unique depending on the nature of the project, the process being examined, and the participants. B-level processes may also share similarities, but the subtleties that make each unique are even more pronounced, particularly due to the human elements introduced by the participants. They may represent different departments, viewpoints, or values and all of these differences while important to the final product, make alignment and consensus challenging.

The experienced business analyst or facilitator takes the design of this B-level process very seriously, and typically employs a C-level process to design the custom B-level process. It is at the C-level that very little variation from instance to instance exists. The facilitator will employ essentially the same steps each time, but because each step results in a different answer set, the design of the B-level process will vary from instance to instance. The C-level process analyzes the needs of the A-level process along with those of the participants and synthesizes the B-level process from the analysis output.


For fun, let us add on one more layer of abstraction to this synthesis. This view of business analysis as three levels of process seems to function almost in the manner of sentence grammar. The C-Level functions largely (although not precisely) as the subject, articulating as it does the attributes of the activity (e.g., purpose, stakeholders, constraints) in order to design the B-Level process. The B-Level functions as the verb, performing the action on the A-Level (the object).

What emerges is a high-level model of the business analysis process. This will make it easier to teach the next time around. More important, it gives me a new paradigm for managing my own efforts in the field. Having modeled the three process layers formalizes what I have been doing for years into a more consistent set of steps and options.

As for renaming the discipline itself, I plan to stick to the decision I voiced above. Nevertheless, I could not help engaging in a quick mental search for a more fitting name. About the best I could do was Business Science, but that implied a level of precision not in evidence. I suppose that I will need to be content with the imperfect designation and concentrate on perfection in the process.


Does your organization manage its C-level processes? Can you think of a better name for Business Analysis?



Saved_HeaderIt’s never expected when it happens. It certainly never happens when it’s convenient. You all know what I mean. It’s that moment when the blood drains from your face, your hands turn to ice, and your stomach ties itself in a knot the size of Utah. In the same instant the clock has advanced itself two hours as if by the hand of a roguish time lord. “What fresh hell is this?” you ask yourself, followed by “Why now?” And then you do it. You take the silver dagger yourself and by your own hand administer the fatal thrust. You hit ‘save’ again.

I had awakened in the early hours with an inspiration for a “brilliant” way to conduct a facilitation exercise for the class that evening. It would require a substantial rewrite of the instructions along with the composition of six “Type B opening questions.” What that means is immaterial; suffice it to say that they take time and thought to craft. I spent almost three hours updating the document while watching the clock tick away. I had to be on the road to catch the ferry soon in order to be on time for class. I had literally finished the last word of the document revision and hit save when the words before me on the screen turned to a combination of machine language and Chinese. Recognize the feeling? Vaguely hoping that it was a video issue, I administered the deathblow without thinking.

It was not a video issue. I do not know what caused it, but the file was thoroughly corrupted and unreadable. And it was that second save that was my undoing. What I should have done was a “save as” until I had fully understood what had happened. It was a rookie mistake and I take full responsibility for it. There was simply no way to recreate the content of the document from scratch and then draft the exercise materials before class started. I panicked. Then I remembered that I had a backup on DropBox. Unfortunately, the corrupted version had already replicated to the cloud.

Still, all was not lost. I recalled having read or heard that DropBox keeps all versions of a document for the prior thirty days. Bingo! Once I brushed up on how to find it, there it was: the uncorrupted version I had saved minutes earlier. I was lucky. I had not lost a keystroke. It could have been much worse.

There are several important lessons here. The first of these is to have backups. In this day and age, there is no excuse for anyone not to have offsite storage for all of your documents. Okay, I am using DropBox, and I do so in spite of the fact that it does not support local encryption (another issue for another post). And while I do not use it for anything sensitive, I have begun to look into other options. In the meantime, it is dependable, easy, and supports features that I rely on such as 30-day version storage. There are many options for cloud storage, file synchronization, and sharing. The important thing is to have those synchronized files along with some form of version retention.

I also keep two flavors of local backups. I back up all of my data files (including my virtual machines) to a 4TB external hard drive. Also, because my base computer is a Mac, I take advantage of the Time Machine backup feature. I was saved this time around because of my backups.

Another lesson learned from this episode is that when the technology fails, it is best not to panic. Panic will most likely make a bad situation worse, which it almost did in my case.   Instead, one should step away from the computer for a minute without touching anything, take a calming breath, and then return to methodically identify the scope of the mishap. When I was growing up, there was a safety mantra “Stop, look, and listen before you cross the street. Use your eyes, use your ears, and then use your feet.” Shift a few words around and it is made to order for our Twenty-first Century conundrum: “Stop, look, and think when technology starts to burn. Check the files, then check the dates, before you hit return.”

The final lesson – and this is an old one – is “save as you go.” Normally, I am assiduous about saving a document after every few keystrokes. I am certainly careful to save at the end of each paragraph when I am writing a rough draft. In this case however, I was working in a white heat to get the documents completed before hitting the road and was not being careful. That much was clear when I read the version list on DropBox. It looked as if I had not saved the document a single time since I had opened it. This was also a rookie mistake.

In the final analysis, there is no foolproof way to protect us from ourselves so I suppose it is wise to summon a philosophical and emotional detachment about it all. Nevertheless, the practice of establishing an intelligent and reliable technical infrastructure – particularly when it comes to file backups – while at the same time husbanding good technology practices can take the sting out of these events more often than not. At the end of the day, this incident was a short but brutal reminder for me. It also got me thinking about crucial points of failure in general. That is why finding the jack and the spare tire in the car before driving home from class next Monday is at the top of my to do list to. The route traverses sixty miles of lonely, single-lane country highway and I am driving it after 11:00 PM. After owning the car for six years, I believe I have ridden the wings of fate a little too long already.

What is your backup strategy? Do you have encryption for your cloud storage?



Do It Yourself Business Tools

DIY_HeaderThe older I get, the more analogies jump unexpectedly from random dark alleyways and take me prisoner at gunpoint. Perhaps it’s a function of age; after all, I’m now a card-carrying sexagenarian, which is in no way as fun as it sounds as though it ought to be. More likely it’s just the way my head works, a concept frightening enough by itself to send that analogy scampering back into the darkness if it had a shred of sense. Since it’s unquestionably the height of bad form to anthropomorphize a literary device, I’ll go no further. Suffice it to say that the analogy is here to stay, so perhaps I should explain. First I offer a word of warning; there will be math involved.

Immersion in writing the lecture notes for my business analysis class has already heightened my consciousness for all of the available materials around me. In and of itself, it is a fascinating process of which to be cognizant as I go about learning (or relearning) the subject matter I will teach, along with the requisite teaching techniques. When the stress of interlacing this effort with my day job reduces my productivity to a trickle, I will either head to the piano or to the wood shop to reboot my noggin. It was in the latter venue that the triggering epiphany assaulted me.

For the past two years, I have been moving a lifelong passion for woodworking up to a new level by acquiring some advanced skills. One of these involves woodturning and I had retired to the shop to create a set of drawer pulls. The first step was to make a tool called a “screw chuck” that was going to hold the stock that I would be carving. While I was turning the block of poplar into a perfectly round disk, it struck me that I had made quite a number of tools during the past year. Each was custom made and reusable. And because the process of writing lecture notes was fresh, I saw clearly how many of the business tools I had built over the years were coming in handy in that effort.

We probably all make tools of one kind or another for use in our respective jobs. The question is, how many of us hang on to them? When it comes to tools, I am a packrat. I save everything whether it is from work or for the shop. If it is of any potential use, I categorize it and store it because sooner or later I will need it again. Business tools I have created and kept over the years run the gamut from simple document templates to sophisticated cost-benefit analyses and weighted prioritization tools. This has saved me many times from having to reinvent the wheel.

There is more to the do-it-yourself tool than merely collecting it. The thought process that goes into crafting it teaches one more effectively how the tool actually works, along with other truths about the process for which it is being used. This is as true for the logic behind a kerf jig as it is for the math underlying net present value in a cost-benefit template. In fact, making your own tool is just about the best way to learn because it is not merely the principle that one has mastered but an objectification of the principle. To demonstrate, let us look at these two examples side by side, starting with cost-benefit. Both explanations are a bit technical, but demonstrate the point clearly.


Cost-benefit Analysis
In a cost-benefit analysis, one seeks to understand the net of costs and benefits (cash flow) expressed in some common measurement (usually a currency such as dollars) of a project or product over a specified period of time. In other words, add together all of the direct and indirect costs of a project over x years and subtract those from the financial benefits of the project over the same time period. But there is a catch. One hundred dollars in cash flow today is worth more than the same amount a year from now. This is due to factors such as inflation or what that capital might have earned had it been invested (opportunity cost). Thus, a true cost-benefit analysis looks at future cash flows discounted into today’s value (present value). Moreover, later years are weighted less heavily than earlier years as uncertainty increases.

Now, you could just pop some numbers into a spreadsheet and use the spreadsheet’s functions to do the heavy lifting for you, but where is the fun in that? Instead, let us build our own. The formula for Present Value (PV) is:

CB_EquationAssume that you have a project that will take two years to complete and you want to look at the cost-benefit over five years. This year is year zero, next year is year one, and so forth. Your director of finance has informed you that the discount rate is six percent. Rather than use the spreadsheet function for PV, I have manually input the above formula into cell B11 as =B9/(1+$B$5)^B7 where cell B9 is the cash flow for year zero, $B$5 is the discount rate, and B7 is the time index (year number). I then copy that formula into cells C11 – G11. Net Present Value (NPV) is then the sum of the six PV values in the analysis. In this case, benefits outweigh cost.

CB_GridWhat you learn by building the tool from scratch in this way is a better understanding of how Present Value is driven exponentially year over year. For me, this also demonstrates the importance of how the passage of time impacts negatively the return on investment as well as how the heavier weighting is given to the earlier years where the cash flows are in the red.


The Kerf Jig
The kerf jig is used to create the “perfect” lap joint using a standard table saw blade. A lap joint is made by making a wide cut (dado) halfway through two pieces of wood and assembling them to look like this:

Lap_joint2There are several ways to do this including mounting a dado stack (a composite wide blade created by “stacking” together a set of blades). The challenge is always to have the width of the cut precisely equal to the width of the piece of wood you are fitting into it. The wood worker must also take into account the width of the saw blade when making this kind of cut. (I told you that math is involved.) Enter the kerf jig. It guarantees a perfect cut every time.

The kerf jig is a very simple device and easy to make. It consists of two blocks of wood: one fixed and one that slides. A knob secures the slider. As you can see in the next photograph, when the end of the slider is precisely even with the end of the block, there is a gap left. This gap is precisely the width of the saw blade.

Kerf_Jig_Closed1Imagine now that you are going to make this cut. You have two pieces of wood, piece A and piece B. You are going to cut the dado in piece A first, so you insert piece B into the jaw of the jig and set the slider as shown.

Insert_work_piece0The gap is now the precise width of the cut you want to make. At the opposite end, the distance between the end of the slider and the end of the block is equal to the precise width of the desired cut minus the precise width of the saw blade.

Kerf_Math1Then using a cross cut sled (another DIY tool) you align the saw blade with the inside end of the cut, add the jig using the long side (block plus slider) and clamp a stop in place. The sled (see picture) gives you a way to clamp a stop block to something that moves through the cut. It also allows you to move the stop block, the jig, and the piece of wood you are working on through the cut together.

First_Cut2After you make the first cut, turn the jig 90 degrees so that that the short length is against the stop. Butt the wood piece against the jig and make the second cut. Remember that the distance between the first cut and the second is the desired width of the cut less the saw blade.

Second_Cut2The saw blade cuts on the outside of that distance, adding itself back in. All that is left is to cut out the center material.


By now, you may begin to appreciate the value of the do-it-yourself tool. Sure, I could buy a kerf jig online somewhere, but why would I do that? The jig I made cost virtually nothing since I made it from scrap wood in the shop. And because I now have a hands-on understanding of why it works, I will make fewer mistakes when I need to make a complicated set of lap joints (e.g., a wine rack). Similarly, having used the PV formula directly in my template instead of relying on a built-in function, I not only have the underlying concept more clearly in mind, I also will be able to teach it more effectively.

The business analyst in me likes this contact with the inner workings of things, the visceral connection to the underlying “why” and “how” of tools. I delight in how the underlying math of both tools reveals something about the nature of the processes being performed. Also, I love the correspondence between these very different business tools. In the end, it is a good thing that the analogy took me hostage, don’t you agree?

Do you make your own business tools? Do you save them?


By the way, if you are curious about the tools in the title photograph, they are from left to right a feather board, the kerf jig, a hand-held starter bit for hollowing out bowls or cups on a lathe, a screw chuck, and a push board for a table saw. All of these tools are sitting on a cross cut sled.



Gouge or Skew?

Gouge_or_Skew_Header“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”    — Robert Heinlein, Time Enough for Love

The quote above has come back to me several times over the past few weeks as I write the lecture notes for a class on business analysis that I will soon be teaching. This is Heinlein’s definition of the “competent man” as articulated by his character Lazarus Long. That name alone conjures competence and longevity to the fertile mind, don’t you think? Say it out loud: Lazarus Long. At any rate, the reason that this particular passage has come to the front of my mind is because as I prepare for this class, I have come to realize what a model of generalization business analysis really is.

The program director recruited me to teach the class about five months ago on the basis of my background both in business analysis and meeting facilitation. It was perhaps more the latter qualification that mattered because that is the focus of this class, the final one in the certificate series of three. In addition to my facilitation and group management knowhow, however, is the need to bring together the tools and techniques taught in the prior two classes into a final pretty package and tie it with a bow. Ignorance is bliss; I agreed to the gig.

Reality is a brutal teacher. Having been a reasonably competent practitioner of these skills for twenty years is one thing. Teaching about them is quite another. First, there is a professional framework that must be observed (IIBA or the International Institute of Business Analysis). Second, there is a variety of tools and techniques with which I need to be at least modestly conversant but have neither heard of much less used. Third, one picks up habits both good and bad along the way without giving them much thought. Given these impediments, the challenge of sitting down and crafting course content might be enough to dissuade one from teaching altogether if it were not for all the new knowledge.

But what really comes out of the process that harkens back to Heinlein is the variety of skills and tool sets available to the business analyst, along with the variety of different skills to master. There are modeling techniques for both business processes and systems. There are business architecture frameworks. The successful business analyst must be articulate both verbally and in writing, and must be both intensely logical and highly intuitive. He/she must be able not just to lead a meeting, but also to facilitate a dysfunctional group toward agreement. How much like the competent man this begins to sound.

But here is where the true rejection of specialization comes in. In the Heinlein passage there are several examples of stated opposites, for instance, “cooperate” and “act alone,” or “take orders” and “give orders.” The implication is that one must be prepared for most situations and be capable of both extremes. In other words, just because there is a plethora of modeling languages available does not mean that one necessarily needs to be expert in all of them. Rather, one needs to know enough about them to be able to choose the one that is appropriate for the situation. And even then, any of several might work so one needs to be able to choose the one that will work best for oneself. For instance, in twenty years of performing business analysis for a variety of organizations, I have never needed to use UML (Universal Modeling Language) or IDEF0 (never mind, it is an acronym within an acronym). I have found Business Process Model Notation (BPMN), Context Modeling, Fact Qualifiers, and Entity Relationship Diagramming to be a completely sufficient toolset. Had I ever worked for a defense contractor, such might not have been the case. By the way, for those of you who are unfamiliar with the terms and acronyms, don’t worry. I do not give tests.

A wood turning video I watched recently demonstrated the same truth in sharp relief. The craftsman filmed it as a training guide for wood turning beginners (such as myself) to learn how to hollow out the inside of a cup or bowl on the lathe. Rather than assert that “this is the tool” and “this is how to do it,” he acknowledged that there are many ways to go about it and many different tools that could accomplish the same end depending on individual skill level and comfort. Within the framework of key facts about the nature of a block of hardwood spinning at 1000rpm or more on a lathe, either a gouge or a skew chisel could work equally well in hollowing the vessel. An “outside in” or an “inside out” approach is equally acceptable as well. The secret is to practice with the tools that you do use until you are competent with them, gradually adding new instruments and techniques as you progress in ability and knowledge. The expert wood turner is competent with many techniques. Our discipline is no different.

There is yet another aspect of business analysis that resonates with the Heinlein quotation. This is the fallacy that the business analyst must be a business expert – that is, a specialist. I would expect a good business analyst to be experienced and knowledgeable in business, but not necessarily at the level of an MBA. On the contrary, I would expect an outstanding business analyst to be broadly educated and widely skilled because the role calls for active listening and profoundly acute pattern recognition. The tools and techniques help us, but they are no replacement for the analyst’s perceptions and experience. It is the same skill (or art) that comprehends an analog between a skew chisel and UML, that is able to perceive that the goose one man sees and the beaver another man sees are in reality the opposite ends of the same platypus. Add to that the ability to help each man adjust his point of reference sufficiently to recognize the fact and you have the competent business analyst. Rather than an expertise in one area, the role requires competence in many.

While I have taught many one-day classes over the years, they have all been on focused topics for individual clients. This is my first time teaching a full-length course in a University classroom which means that I am newer to it than even my wood turning. Ten classes of three hours in length translate to a tremendous amount of material to prepare and organize.   And while I have been reading and studying and writing for months, I have as yet to “turn out” a single product. That will come in a few weeks. In all events, I look forward to the new ideas and insights that will come from working closely with twenty other active minds for thirty hours (600 mind-hours!). I have no idea as to what shape might emerge from this virgin block of wood stock, but I do know that it will add additional dimension for any competent man. Stay tuned.

What qualities does your organization look for in a business analyst? Do your practitioners employ a range of tools and skills?