Working Smarter : Decision Trees

What Happens When the Top Dog Leaves?

Rich — Fri, 01 May 2009 18:45:00 GMT

Departing employees can have a tremendous impact on an organization if it is not properly prepared and equipped to handle it – especially if the employee is one of the “Top Dogs.”

How the departure affects your productivity

Ready or not, a whirlwind of a ride may await you unless you have done some basic preparation. No matter if you are the receptionist, or the next senior level manager to serve as the interim leader during the transition, you will be affected in some form or another. Your time will be divided exponentially due to the acquisition of new tasks, and the learning curve those tasks will require. In addition, your “usual” activities may get pushed somewhat to the background and can get overlooked if you are not careful.

Projects, tasks, and decisions may proceed more slowly if you are not prepared. So, what can you do to keep moving forward with a full head of steam? Document your responsibilities.

Begin by documenting all that you do, all that you are responsible for prior to the shift, and everything you take on during the transition. Document all of your projects, tasks, and decisions that you are involved with to standardize and organize them.

Once you have accomplished this you will be in a better position to organize and delegate some smaller oriented tasks out to your team. You will also be able to properly communicate expectations and how things are to be handled during the transition. This will also allow you to be able to bring the new “Chief” up to speed more quickly once the vacant role is filled.

How the departure affects general functions and processes

Does your business run on people and anecdotal information? Meaning, do things happen when the “top dog” says it should, and how it should? If so, you may find that company processes, projects, tasks, and management decisions will grind to a halt upon the departure of this person unless you get the processes and projects documented and systematized. When you move in this direction, you will find that you are not completely dependent upon people for the processes and projects to move forward, but more on a system that works and functions nearly independently and therefore managed by its people.

For example, say the departing leader has a specific decision making process proven to be successful (shown below) as to which projects are pursued, and which are not. Wouldn’t it be helpful to know what that process is, and refer to it during the transition? Of course it would. So acquire the information and create easy to understand visuals, like decision trees and flowcharts that serve as reference guides for you to be able to make good consistent decisions and keep progress moving in a forward direction in the same manner prior to the leader’s departure.

Click here to see a larger version of this visual.

The final task is how you communicate this back to your team. The repurposing of projects and tasks can be an emotional proposition for some as time and energy may already have been invested, so you will need to clearly communicate the reasoning behind any changes. The remedy? Share your visuals like the one above so that they understand how specific processes and decisions are made. The more transparent the process and decision making is, the more on board your employees will be about the procedures. Also, you avoid the same previous problem of having only one person with the understanding of the company “knowledge bank” and you forge trust and team communication amongst everyone.

The personnel of the organization are the most impacted when there are departures, and if processes and other pertinent information are stored anecdotally within only a few people then everyone feels the pain – including you. Take the time to document, organize, evaluate and communicate your processes, projects and decisions to keep your organization stable.

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

How to Build a Decision Tree

Aaron Stannard — Mon, 26 Jan 2009 15:45:00 GMT

In my last post, I told you about how you could use a decision tree to automate decision-making processes, thereby making it faster for you to arrive at decisions and make the outcomes of those decisions more consistent. In this post, I’m going to show you how to actually build a decision tree using an example from the last lesson.

We need decision trees and decision-making processes for “regular decisions” – decisions which occur several times throughout a given period of time. A good example of this kind of regular decision is the decision to add a new feature to a product or service, and that’s the example we’re going to use today.

Example Decision: “Should we add a new feature to our product?”

Step 1 - Begin with the First Key Question

The ultimate question in this example is “should we add a new feature to our product?” We have to produce a “yes” or “no” answer that is consistent with our market positioning, needs of the customers, and our product design aesthetics.

So the first question that we need to factor into our decision making process is our customers – if an insignificant number of our current customers or easily accessible prospective customers would be willing to use this feature, it might not be cost-effective for us to implement this feature. Thus we begin this decision tree with the simple question, “Did our customers request this feature themselves?”

We also include all of the likely answers to this question, which in this case are simply “yes” and “no.”

Step 2 – Ask the Next Level of Key Questions

We now have two paths in our decision tree:

The feature was requested by customers
Or the feature was not requested by customers.

Features that have been requested by customers are going to be considered with a different set of criteria than features that were not requested by customers. So I’m going to represent that on my decision tree by asking two different sets of follow-up questions:

Next we provide some answers to these questions.

The concept of paths here is important—remember those “choose your own adventure” books that you read when you were a kid? Your adventure ends in a different way depending upon the choices you make as you read the book. A decision tree is a graphical way of depicting those different choices and outcomes—each decision you make moves you along a new path.

Step 3 – Keep Asking Questions until You Have Enough Information to Make Some Decisions

At this point in the decision tree, we’ve considered whether or not customers recommended the feature themselves, why customers would want to use the feature if they didn’t recommend it themselves, and how many customers actually made the recommendation for this feature.

We really still do not have enough information to arrive at any decisions for any of these paths at this point, because we still don’t know how expensive it would be to implement the feature in the case of customer-recommended features. And we don’t know how many people would use the features which were not suggested by customers. Let’s ask those questions next.

I decided that it would be easier to figure out the “feature requested by customer” path since the decision tree was starting to get a little big; I simply hid the right-hand side of the decision tree.

Now we’ve reached a point on the decision tree where we are able to arrive at some solid decisions:

If thousands of customers have requested this feature and it’s easy (cheap) to implement this feature, we should do it.
If only a few customers have requested this feature and it’s not easy (expensive) to implement this feature, we shouldn’t do it.

These seem like reasonable outcomes thus far. For the remaining undecided part of this “feature requested by customer path” we will need to ask and answer a few more questions.

The next question we ask for both of the undecided cases is “could this new feature attract a lot of potential new customers?” Obviously this is a question that might take a while to answer; in fact, it would probably take some market research to answer the question. But, nonetheless, it is the next key question that must be addressed in the decision-making process for adding a new feature to a product.

By now you get the idea—you need to simply keep asking questions until you reach a point in all branches of your decision tree where you feel that you can make a consistently good decision.

And that’s all there is to it. If you have to make regular decisions all the time, developing a formalized decision process (akin to standard business processes or sales processes) is well-worth the time and trouble.

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

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

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.