Working Smarter : Process Design

What do Shooting Down Enemy Airplanes and Solving Business Problems Have in Common? - Part 2

Aaron Stannard — Wed, 09 Sep 2009 15:04:00 GMT

Introduction

As I indicated in Part 1 of this post, there are similarities between solving the fire control problem and solving business problems. The basic problem and the basic process are almost exactly the same: hitting a moving target and the absolute necessity of having a running or continuous solution in order to do so. The easiest way of comparing the two is via a civilian version of the flowchart used in Part 1 (see Figure 2).

Got Problems?

There is no shortage of targets (i.e., problems) in the civilian world. Unlike the military, very little time is spent waiting around for the action to begin. In the civilian world, action is ongoing.

Prioritize & Select

There are always more problems to be solved than there are resources available to devote to solving them. As with targets, business problems must be prioritized and then selected. As with targets, the level of threat posed might be one criterion for setting priorities. Return on investment (ROI), that is, the ratio of the payoff of solving the problem against the cost of solving it might be another. Regardless of the criteria used, business problems, like targets, must be prioritized and selected for resolution. In a word, they, too, must be “targeted.”

Define, Measure & Monitor

This is the counterpart or equivalent of “acquire and track” with respect to a target and here is where a great many civilian problem-solving efforts go astray. Business problems are rarely defined (i.e., isolated, located and articulated); they are more rarely measured in terms of their costs and the benefits of solving them; and, rarest of all, business problems are hardly ever monitored on an ongoing basis so as to know at all times their status, their costs, the benefits of solving them and the effects actions taken are having on them. Making matters worse, problems are often asserted at the executive level, wrestled with at the middle management level and actually tackled at the line management and workforce level – all with very little two-way communication and even less mutual understanding.

Figure Out What to Do (Continuously)

Just as with the fire control problem, a solution to a business problem must be determined. And, just as with the fire control problem the solution must be kept current. Business problems are not fixed, static math problems with fixed, static solutions. When it comes to solving business problems, it is not so much a matter of coming up with a solution as it is a matter of making sure your solution keeps up with the problem.

Solving business problems is a matter of crafting an intervention, of changing things in one or more places so as to have the desired effects as measured somewhere else, often on the bottom line. In a Gun Fire Control System (GFCS), the solution is configured by a computer designed and built for that purpose. In a business, solutions are configured by people, and the solutions they configure vary with their skills, experience, biases and the problems themselves. So, if the heart of a gunnery system is the computer, the heart of a business problem-solving system is people. Moreover, instead of solving just one kind of problem, which is all that is expected of a GFCS computer, people must tackle and solve a wide range of problems. They are general problem solvers.

Got a Solution?

In a GFCS, the computer operators can tell if the computer has a solution to the fire control problem. Making that call with respect to business problems isn’t nearly as easy. If a solution is an intervention, a course of action intended to bring about certain effects, it’s important to understand just how the planned course of action will indeed produce the desired effects. If the linkages between the course of action you’re contemplating and the effects you’re seeking aren’t clear, you probably don’t have a solution.

Obtain & Assign Resources

Just as the gunnery officer on board ship cannot take a target under fire unless and until the ship’s guns have been released to his control, it is often the case that managers who are working business problems will require more and different kinds of resources than they ordinarily have under their control. There is, then, a requirement to obtain and assign resources to roles, tasks and responsibilities that must be fulfilled in order to solve the problem at hand. Frequently, this requires making a case for those resources.

Take Action

Taking action in a business setting is not a simple matter of loading and firing the guns (although it often looks that way and “hip-shooters” can be found in just about every organization). The actions necessary to solve important business problems often entail complex, multi-layered courses of actions – interventions that must be orchestrated and coordinated over time (often long periods of time). And, just as is the case with the fire control problem, these solutions, these courses of action, these interventions, must be kept current, which is to say they must be kept aligned with what is an ever-changing problem situation. Too often, I fear, we are guilty of solving the problem that was, not the one that is and certainly not the one that is about to be.

Assess the Effects

This should be an easy, almost automatic step but, unfortunately, it isn’t. This is because, as noted earlier, we often fail to adequately define, measure and monitor the problems we set out to solve. Were we to do so, noting the effects of our actions would be comparatively simple. Instead, we push measurement and assessment to the back-end of the process and there it languishes for want of interest and resources. Consequently, instead of a steely-eyed assessment of the effects of actions taken, what frequently happens is that those in charge declare victory; they announce that the problem has been solved and all concerned move on to whatever situation is now center stage.

Results as Desired?

As the preceding item suggests, this decision is often made in a de facto manner, the consequence of declaring victory. Successes are claimed, failures are buried and the problem is swept under the rug until such time as it resurfaces, often bearing a new label and just as often being made the target of old solutions also bearing new labels. But, if the decision is an honest one, the problem either has been solved (or affected to an extent such it is no longer a priority) or it remains a focal point for action. Again, the importance of maintaining a “running” solution is apparent.

Summary & Conclusions

As I asserted at the beginning of this two-part post, I am convinced that much of what I know about solving problems I learned as a Fire Control Technician (FT) in the Navy. The lessons I learned go well beyond the Fire Control problem itself. I also learned to troubleshoot complex systems, a form of problem solving known as “fault isolation” and which lies at the heart of the much-vaunted Kepner-Tregoe approach. The two most important lessons I learned are these:

1. Problems are dynamic and solutions must be dynamic as well; moreover, solutions must keep pace with the problems they are meant to solve;

2. All problems are embedded in some larger structure and the solution to the problem lies somewhere in that larger structure.

Can what I learned be passed along to others? I think so. I’ve tried to do that with many of the articles I’ve written about problem solving, solving problems and an approach I call “Solution Engineering.” I hope others find this post and my other articles helpful in honing and otherwise improving their own problem solving skills.

Click here to read Problem-Solving Lessons Learned in the Navy, Part 1.

About the Author: My name is Fred Nickols. I am a writer, an independent consultant and a former executive. Visual aids of one kind or another have played a central role in my work for many years. My goals in writing for SmartDraw’s Working Smarter blog are to: (1) provide you with some first-rate content you can’t get anywhere else, (2) illustrate how important good visuals can be in communicating such content and (3) illustrate also the critical role visuals can play in solving the kinds of problems we encounter in the workplace. I encourage you to comment on my posts and to contact me directly if you want to pursue a more in-depth discussion.

What do Shooting Down Enemy Airplanes and Solving Business Problems Have in Common? - Part 1

Aaron Stannard — Fri, 04 Sep 2009 15:04:00 GMT

Introduction

Surprisingly, the answer to the question in the title of this post is “A Lot!”

Shooting down an enemy airplane is done by a weapons system that solves what is known as “the fire control problem.” What I learned about solving the fire control problem while serving in the Navy has been of great value to me in solving the kinds of problems I have encountered in businesses and other organizations during my civilian career as a consultant and executive. The central point I’d like to make in this post is as follows:

Most problems encountered in organizations are dynamic. They are, as people so often say, “moving targets.” There is not and can never be a static solution to a dynamic problem. The first lesson to be learned from the fire control problem is this: to hit a moving target requires a continuous or “running” solution, one that is regularly updated to reflect the current situation. Dynamic problems are not “defined” and then “solved.” Instead, the definition of this kind of problem evolves over time as does its solution. Dynamic problems must be measured and monitored, just as targets are tracked. If you do not approach dynamic problems in this fashion, you are likely to solve the problem that was, not the problem that is.

Solving the Fire Control Problem

With the exception of stationary targets ashore, the basic problem to be solved is that of hitting a moving target, of putting a projectile or some other explosive device where the target will be – and to do so from a platform that is itself in motion. The calculations involved in performing this feat constitute what is known as “the fire control problem.” The flowchart in Figure 1 illustrates the basic process of taking a moving target under fire and, if all goes well, of destroying or disabling it. A guided tour of this process follows.

Got Targets?

A target might be a convoy, an ammo dump, a bridge, a road, a concentration of enemy troops, an enemy ship, an enemy aircraft or even a missile. Except in actual combat or during training exercises, there are no targets. But, once the fighting starts, numerous targets present themselves.

Prioritize & Select

Owing to the presence of multiple targets offering varying degrees of threat it is necessary to select the target to be taken under fire. This typically happens as a consequence of prioritizing targets based on the degree of threat they present – to your ship or perhaps to some other ship or assets you are trying to protect. You can’t take all targets under fire simultaneously; you must choose.

Acquire & Track

Once a target is selected or “designated” the task at hand is one of acquiring and tracking the designated target. The component of the Gun Fire Control Systems (GFCS) that serves this tracking purpose is the fire control radar. Once acquired, the target’s position and movement can be monitored and tracked. This information is fed to another component of the GFCS, the GFCS computer.

Solve the Fire Control (FC) Problem (Continuously)

The target is moving, the ship is moving, the deck of the ship is rolling and pitching and, in the case of a piloted aircraft, the pilot doesn’t want to be greeted by a projectile and so the target is frequently taking evasive action. Figuring out where the target will be and calculating gun orders so that when the gun is fired the projectile will intercept the target is the job of the GFCS computer. Most important, it maintains a “running solution” (i.e., it solves the fire control problem on a continuous basis). Static solutions won’t do. Everything involved is changing continuously and the solution must keep pace. Otherwise, there is no hope of hitting a moving target.

Got A Solution?

Once the solution stabilizes, the gunnery system is ready to do its job.

Bring the Guns to Bear

The gun mounts can be swung out, matched up with the orders being sent from the computer and the guns can be placed in automatic. Everything is ready.

Commence Firing

Assuming the target being tracked is still the priority and the solution to the fire control problem is being maintained, the guns are loaded and the command to commence fire is issued.

Assess the Effects

Basically, this is a matter of determining if the bullets hit the target or, in the case of projectiles with proximity fuzes, if they came close enough to the target to detonate and do enough damage to make the target no longer of interest. In any event, the effects of firing on the target must be determined.

Target Destroyed?

If it’s been destroyed, you can cease firing, look for and take under fire other targets or, if there are no more targets, you can simply cease firing altogether. But, if the target has not been destroyed or sufficiently damaged to render its threat of less consequence than other targets, you will keep firing and that entails ensuring that you still have a solution to the fire control problem. The target might have broken track and you will have to reacquire and track it, then solve the fire control problem again (and keep solving it) so as to take the target under fire again.

The Civilian Version: Solving Business Problems

Guess what? Things aren’t all that different in the civilian world. There, too, the targets of interest are often moving targets. Change permeates everything. And, as is the case with the fire control problem, the rate of change is a critical factor. As I was to learn to learn when I entered the civilian sector, the process of solving business problems has a lot in common with the process of solving the fire control problem. In the next portion of this post, we’ll look at some of those commonalities.

Click here to read Problem-Solving Lessons Learned in the Navy, Part 2.

How to Make a Good Decision Every Time

Aaron Stannard — Fri, 23 Jan 2009 19:42:00 GMT

I have to make lots of decisions every day. I have to pick headlines, edit copy, schedule certain pieces of blog content, decide how to best accommodate other units in the company, and make tons of other decisions. I’m sure most of you are in the same boat.

The decisions that are the most time-consuming are the ones I have to make regularly, sometimes several times per day—like how to handle emails from customers. I have to forward the email to customer service, answer it myself, or sometimes kick it up to the product development team if it’s a good suggestion. These routine decisions aren’t time consuming because they’re hard to make; they’re time consuming because they’re important and need to be given my full attention.

Define your decision-making process

Like all productive people, I want to get things off of my desk as quickly as possible. One thing I’d like to do is handle these routine decisions more quickly—it would also be helpful for other people on my team who need to make the same decisions to handle those as quickly as possible. So what did I do?

I started making decision trees to help automate and streamline my decision-making process for routine decisions. Take a look at the decision tree that I made for handling the occasional customer emails that I receive via the feedback form on Working Smarter:

What does this thing allow me to do?

What this decision tree allows me to do is:

Map out all of the possible factors that I have to account for in my decisions;
Pre-determine all of the likely outcomes for a decision;
And determine the process at which I arrive to my decisions.

Essentially this is a decision-making process, illustrated in graphical format. Now for something as simple as answering a customer’s email, I wouldn’t need a decision tree because there really aren’t that many possible outcomes or possible factors.

When should you use a decision tree to streamline your decision-making process?

You should use a decision tree when:

You have to factor a large number of items into your decision;
You have a large number of possible outcomes resultant from your decision;
Or you have a team of people who need to be able to replicate your decision-making process.

My example of replying to customer emails is pretty simple—you probably wouldn’t need a decision tree for it. However, if I had to make a more complicated decision like determining whether or not to add a new feature to our product, then a decision tree would be quite helpful.

Actually, that’s a pretty good example – on Monday I’ll publish an in-depth post which will show you how to build and use a decision tree from top-to-bottom using that example.

If you want to try making your own decision tree then download a free trial of SmartDraw.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Stop Reinventing the Wheel

Aaron Stannard — Fri, 15 Aug 2008 13:02:00 GMT

Imagine this scenario: It’s 2008, you're a multinational coffee conglomerate named Starbucks; your business is in a crunch and you have to start closing stores.

You can't just close down any store—you have to close down the stores that are in close proximity to another Starbucks or stores that were never great performers to begin with. If you close down the wrong store you can end up losing a lot more business than you anticipated, so each closure has to be carefully considered. What do you do?

Have your regional managers act by the seat of their pants without any direction (chaos)?
Develop a standard way to close suitable store locations / sell off assets and subsequently train your regional managers to follow this process (order)?

The decision is not hard—you're going to want to develop a standard way, a process, to handle this routine. Your work should always be a process!

"Reinventing the Wheel" Happens Every Day

A big multinational company like Starbucks doesn't reinvent the wheel—a business can't reach that kind of scale if every employee has to do everything by the seat of his or her pants. But what about smaller organizations?

A lot of private individuals and small organizations suffer from the "reinventing the wheel" problem - every time someone has to handle a new task, he or she does it by the seat of his or her pants a few times and sticks with whatever kind of, sort of worked best. Most people aren't given any processes or any context to work from—instead they're thrown a bunch of old documents and told to make it happen.

All of the specialized knowledge used by former occupants of that position, their cumulative specialized knowledge being "the wheel," has to be reinvented every time there's a personnel change in many organizations.

Most people don't even consider the possibility of formally defining a process, and as a result, a lot of man-hours are wasted engaging in low value "invent the wheel, again" activities. This wastes money, wastes time, creates frustration, and ultimately hinders you from being as efficient as possible.

An Example: New PR Guy

Let's say you have only one PR person and he leaves your company, so you move a person in your organization away from sales and put them into a public relations role—you believe they can do it based on how well they've represented the company to potential customers, so you hand them over some materials from the last PR person, run them through a cursory training course, and send them off. Did you tell your new PR person how to write a news release? How about how to send the news release over a press wire? Most managers would answer "No - they can figure it out." And that's a problem.

Most managers figure that the new PR person will take a few days to figure things out but after that, he or she will start trucking along with his or her new PR responsibilities. What the managers don't take into account are the costs of letting all of the previous PR person’s experience go to waste!

All of the specialized knowledge needed to conduct PR for the organization takes years and years to master, but it all goes to waste as soon as one person leaves and another steps in because no one bothered to build a blueprint using process - and that's the essence of "reinventing the wheel."

All of that time your new PR person has to spend perfecting and mastering his or her new responsibilities is wasted time—the last person already figured that stuff out. By not taking the time to document and define actual business processes for your company's PR, you've doomed them to spend a lot of their time figuring everything out from scratch again.

How to Stop Reinventing the Wheel

Every organization that's ever wanted to scale has already figured out how to step reinventing the wheel: invent it once and show everyone else how to use it! You stop inventing the wheel by defining business processes—that's how it's done!

Flowcharts are an obvious, intuitive tool for defining processes. As long as you do ANYTHING to try and capture your organization's routines into processes, you'll be better off when it comes time to assign new responsibilities or hire new people. I'll be posting more about using capturing and formalizing business processes when we return from the weekend.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

My UX Process

joshua — Thu, 13 Mar 2008 17:58:00 GMT

6 Steps of a UX Design

My fascination began when I watched a video of Alan Kay explaining the PARC user interface during a Stanford lecture. That was 4 years ago now, and for the last 2 years I have worked hard to improve the usability of SmartDraw. My work flow looks something like this:

Collect the facts and brainstorm
Make a static rapid prototype
Perform an initial test with a small number of people
Pick 2 designs that get best feedback and create interactive prototypes
Test 2 designs with current users and non-users
Review results and create spec for the developers

Your process may differ from mine, but regardless of the workflow there is one common breaking point; people. When it is just you, you don't have to worry about communicating or delegating. You just do want you know to do and get it done. The moment you introduce marketing, sales, support, and executives into the mix, the need for communication (and therefore process) becomes imperative.

When communication becomes imperative, I find that graphics get the message across better than text. A bullet list always seems to lose some of the connections found in "brainstorming", and a paragraph never paints the picture of a new UI or website the way a rapid prototype does.

Communicating Through Images

We have all heard the phrase "a picture is worth a thousand words," and we use prototypes and wireframes to make our ideas tangible. So why on earth do we resort to lengthy explanations and bullet points when we need to communicate with others? Each step in my design process includes some kind of graphic as part of the process and process is really just a form of communication right? Try rewriting your process in terms of a graphics, mine would look like this:

I encourage you to try replacing some of your bullet lists with graphics. You will be surprised at how much easier it is to communicate. The next time the head of sales wants to know when "feature A" will be completed, show him a static prototype and a project chart displaying the time frame. Or the next time you need to explain the spec changes to an engineer so they can write the code, try a mind map and state diagram. If you use graphics, you will spend less time explaining, get less frustrated, and get more done.

Collect the Facts and Brainstorm using Mind Maps

Every time I approach a UI problem, I start with a mind map and do a little brainstorming. In the center I write the problem I am tackling. For this example the problem is connecting objects with lines.

For every variation of the problem add a topic which connects back to the core problem. Here I add a new topic for connecting steps in a process and a manager to a subordinate.

The variations could come from user test results, tech support issues, feedback from sales agents, anything that represents a problem related to the central idea. When you can't think of any more variations, begin adding sub-topics off each of the problem variations. These sub-topics could be a solution, a bit of research, a customer suggestion, personal ideas; anything that provides a solution for the connected problem variation. I add sub-topics for a new connector tool, a hyperlink to a user test I did, and a comment made by the support manager.

Once you have mapped the problems and solutions, look for commonalities. Are there solutions that appear more than others? Can a solution for one be a solution for another? That is what I look for, a couple of solutions that I can mock-up in a rapid prototype or wire frame. For this I would spec out using the keyboard to add shapes, and create a couple of prototypes for how it might look on the screen. If I had done this in a bullet list it would look like this:

Problem = Connect Shapes with lines
- Problem Variation 1: Connect a manager to a subordinate
  - Several HR managers have asked if we have keyboard shortcuts for adding shapes.
- Problem Variation 2: Connect steps in a process to one another
  - User Test
  - Could users use the arrow keys to connect shapes?

The bullet list works ok when you have a very small number of variations. In the real world you could have 10-15 variations, which would translate into a 4-5 page bullet list. Not exactly optimal, wouldn't you agree?

Screencast: Real-World Process Documentation Example

Laurence — Tue, 26 Feb 2008 13:34:00 GMT

In this screencast, Mark Sulzen, CIO of SmartDraw.com, walks us through documenting a typical process. His team recently implemented an update to the reseller order path and planned it out using SmartDraw.

A First-Grader's Guide To Business Process

Laurence — Wed, 21 Nov 2007 18:17:00 GMT

Have you ever tried to describe your sales process to a potential investor or new hire? Or tried to explain the why it rains to a child? The communication concepts are the same.

The water cycle is a process just like any other. Its cyclical nature and multiple inputs/outputs create quite a challenge to teachers and parents alike. To truly understand the water cycle requires knowledge of physics, chemistry, geology, meteorology, and more. Try explaining the details of sediment transport to a young child, or anyone else for that matter, to understand the concept of futility. The beauty of the process diagram is that it abstracts away those minute granular details in exchange for conceptual clarity and mass appeal. This is not coincidentally its downfall as well. Any trained scientist would surely cringe at this oversimplification. For the sake of communication, though, we have to remember that we are talking to first-graders...I mean businesspeople.

An investor isn't going to have time to go into the details and complexities of your sales pipeline. He or she wants a quick overview of the process and the bottom line. A new hire in the sales department, similarly, needs a firm grasp on the overarching sales strategy. I'm not saying to treat these people like children but you should leverage the ability to quickly and powerfully summarize your business (and life) processes, using clear visuals, to help you communicate.

The Two-Second Sales Pitch

Laurence — Fri, 16 Nov 2007 13:29:00 GMT

Could you deliver an effective sales pitch in two seconds? In the business world (and some would say everywhere else as well), our lives are a series of interrelated sales pitches. Whether it's convincing your boss to fund a new project, selling directly to a customer, or proving that you can complete the saltine challenge, everyone needs to have an effective sales strategy. For a moment, let's forget all the complicated systems, 10-step programs, and business-school-inspired models. If all you had was two seconds, your pitch would undoubtedly be a variant of "I/you/we should do [action x] because of [reason y]". Assume you are selling to someone who isn't just going to "take your word for it" and requires an explanation. After all, you wouldn't walk into your boss's office and ask for a raise because you feel like it (although if you would, please email me your company's information right away).

In order to provide an effective explanation, you must anticipate what the person you are pitching to wants. In the case of your boss, he/she wants higher profit (just a guess). Knowing this, you walk in confidently, look your boss straight in the face, and exclaim "You should give me a raise because I contribute to higher profits for the company!" Your boss stares back at you and says "Show me". Uh-oh. Clearly there's not enough time (you already used 1.5 seconds) to explain the details of your impact in your department and improvements on the product. The truth is, your boss doesn't really understand exactly what you did, so why bother explaing the details? In some cases you can daze your audience with facts. In two seconds, though, there's not enough time. When you need that initial impact, nothing beats visualization. It's no coincidence that all fast food menus have a picture of the food item with the price underneath it. How accurate those visuals are is another story...

How easy is it to follow the dollar bill in the example on the left? Eliminate the anxiety of your audience and help them out with directed visuals. You tell them where to look and they will do it.