Simulation Expertise through Tours

This past weekend I had the good fortune to be invited to a tour of Ernst Conservation Seeds sponsored by the Soil and Water Conservation Society (SWCS). Ernst is a small company that raises and sells specialty seeds used primarily in seeding conservation areas like wetlands. But more on that in a minute…

One key to success in simulation is your ability to understand the systems being modeled. Education and experience both play an important role in this, but there is something else you can do that expands your knowledge base and is interesting – facility tours.

Facility tours (plant tours) offer a rich hands-on environment. In my experience, most are conducted by a domain expert (often an Industrial Engineer or equivalent) who knows both the facility and how to “speak your language”. Most will take you through the “behind the scenes” parts of their facility. I usually find guides to be both willing and able to explain how things work and discuss both their successes and their remaining challenges. These tours can be an incredible way to experience new things and get great new insights.

Where can you find tour opportunities?

The easiest way to get involved with these types of events and continue to enhance your understanding of systems is to participate in professional societies. The local chapters of groups like the Institute of Industrial Engineers (IIE) and the Society of Manufacturing Engineers (SME) are known for frequent facility tours. But don’t stop there. There are many other professional, industry, and technology groups like banking, healthcare, and plastics that offer tours.

Major conferences often have facility tours available as well. IIE usually has several tours available at their annual conference. Likewise some user groups and educational gatherings from major companies often include facility tours.

Ask your associates working in other companies if they could possibly arrange a personal tour where they work. If you are interviewing for a job, sometimes it may be appropriate to ask for a tour of their facility. And sometimes you can even find public tours like a beer or candy manufacturer (don’t forget the free samples :-)). Or simply get a few people together and organize a tour of your own to explore a topic you are interested in.

Don’t limit yourself to just your area of interest/expertise. Often you can learn even more from tours outside your comfort zone. You might question if I could learn things pertinent to my job by touring a small seed company like Ernst. Not only was it generally interesting, I learned quite a bit about their system as I toured their preparation, sorting and processing. I was particularly interested in their innovative work making biomass into a more effective fuel source (like a process to turn fast-growing native switch grasses into efficient fuel briquettes).

I take every possible opportunity to tour a facility. I encourage you to add frequent facility tours as part of your own continuing education and success in simulation.

Dave Sturrock
VP Products – Simio LLC

Keep Simulation Projects Simple Too

We all have stories about company decisions that make us shake our head. If you have ever worked for a large organization, it may have seemed that some of their decisions were, shall we say, sub-optimal.

For example, one particular organization was using a “home grown” time reporting system that was simple, efficient, and worked well. However upper management felt the need to buy a more sophisticated “name brand” system. Unfortunately it was poorly designed and overly complicated. Rollout required extensive training and retraining to learn the simplest tasks. It was so difficult to use that many employees simply stopped using it in favor of informal arrangements with their managers (who also found it difficult to use). As a result, the company spent a lot of money and wasted a lot of employee time, and in the end they had a system that produced inferior results.

If this was an isolated case, it could be easily forgiven. But I expect most people working for large organizations could cite similar situations. Large organizations often tend to replace simplicity with complexity.

Last week in Keep Simulation Simple I talked about KIS; the Keep It Simple concept of doing just enough to do it well and no more!

I discussed how KIS could be applied to model building, but you can also extend the KIS principle to many other aspects of simulation, especially the tools you routinely use.

For time tracking, you can buy expensive highly integrated software systems like the organization above, or for desk- bound employees you can buy software that will sense or periodically ask and record what you are working on. But the cheaper, simpler and more effective solution is simply using a spreadsheet or paper form and having the employee take two minutes at the end of each day and record time against their tasks for that day. Sure there can sometimes be reason for other methods, but for the majority of us the spread sheet solution is superior.

For project management, choose the simplest tool that will meet your needs. Some projects are complex enough that they need project management software like Microsoft Project or something even better. But in many cases, such software results in a waste of time when a simple spreadsheet could meet your needs. In my experience project management software is often overkill for the types of projects we usually encounter.

In simulation software there is some inclination to buy the most comprehensive software that you can afford. But it is often better just to buy the simplest software that is likely to meet your short to intermediate-term needs. An important caution here – make sure that your software has an adequate upgrade path so that as your needs evolve you can migrate into more feature-rich software without losing your initial investment in software, training, and models.

Stay vigilant for time wasters – they often come disguised as “cool technology” and “time savers”.
Keep It Simple.

Dave Sturrock
VP Products – Simio LLC

Keep Simulation Simple

I mentioned a while back that I am a Boy Scout. OK, maybe my boyhood days are long gone, but I still consider myself to be a Scout. I learned many lessons as a Scout; lessons that continue to serve me well today. One of those is KIS or Keep It Simple.

I remember learning primitive camping skills. Many novice campers would bring too much gear, requiring hauling and storing it, and just in general complicating camp life. The simple (KIS) approach is to bring only what you absolutely need. Many novice campers would also select poor camp sites and then spend time dealing with dampness, bugs, discomfort, safety issues and more. The simple approach is to avoid those issues by selecting a good camp site. Then in both cases, you spend all that saved time enjoying the camp and doing what you came to do. KIS pays off.

KIS applies equally well to many aspects of simulation. When things go wrong, it can often be traced back to too much complexity.

  • How many people are subjected to overly complex management procedures?
  • Are the procedures used for planning and tracking your work making the most effective use of everyone’s time?
  • Is every aspect of your work done effectively?
  • The basic concept of KIS is to do just enough to do it well and no more! Does this mean you should not do your best? No. But it does mean that you should segment your work into small phases and KIS on each phase.

    In model-building for example, let’s say a stakeholder expresses desire for a detailed model for the 10 areas of his system. One common approach is to go off and create exactly what the stakeholder asked for. Unfortunately, this will probably be wrong. A better approach is to pick one representative area, and do a very high-level model of that one area. Then review that model and results with the stakeholder. In most cases, you will both learn a lot and you may jointly decide on a different approach. Then perhaps do a detailed model of that same area or perhaps extend that high-level model to a few more areas. Again you will probably learn something that will change your approach or objectives. For each phase, you want to do the simplest thing (KIS) that will meet the objectives for that phase. In this way, you will minimize any wasted effort and come much more quickly to exactly what the stakeholder needs.

    Let’s consider model-building at a much more detailed level. A common mistake by novices is to build a large section of a model (perhaps even an entire system) all at once. And then you hit “Go” and it does not work. Why doesn’t it work? There are perhaps a thousand possible reasons to investigate. Even worse, there are most likely dozens of small or large problems, each potentially obscuring the others. Verifying and validating such a model is a daunting task. A much better approach is to start by selecting a very small (KIS) portion of the model to build and verify that it works. Then repeat. When a problem is discovered in any new section, it is generally easy to find it because you know it is a result of that latest section just added. Again, “Keep It Simple”.

    Remember, Keep It Simple. Work effectively and exceed your stakeholder expectations one simple step at a time.

    Dave Sturrock
    VP Products – Simio LLC

    We Are Not Making Swiss Watches

    Please bear with me while I mention three apparently unrelated topics.

    I have a very good friend Harry who often offers me advice. Fortunately for me, the fact that I don’t want the advice has no impact on whether I will receive it. 😉 I have to admit that on those rare occasions when I have been accused of expressing some wisdom, it can often be traced back to conversations years ago with Harry. I always admired his ability to “cut to the chase” and identify what is really important.

    For those born into the age of digital watches, it was not too long ago that most watches were completely mechanical with lots of moving parts. Expensive watches were made with high precision and featured exceptional accuracy. Less expensive watches were made to lower tolerances and did not keep time quite as well – every now and then they might need to be slightly adjusted to reflect accurate time. If you really needed to always have the correct time, you would want to have a watch made by the Swiss, since they were world-renowned for their quality. Unfortunately, Swiss watches also commanded a very high price and most people could not afford that luxury. However, most inexpensive watches were still good enough for typical day-to-day use.

    Building models is fun and addicting! When building models it is very easy to get so involved that you forget the big picture. This is equally likely to happen when attempting to get some model detail “just right” or fine tuning an animation to make it more life-like. For example, I once modeled a material handling system where I was helping to evaluate and fine-tune several competing designs. After I had completed the model, I found myself spending hours fine-tuning the animation of AGVs unloading onto the processing devices.

    So how are Harry’s sage advice, Swiss watches, and modeling related? Quite frequently when Harry would find me working on a model aspect like the one above, a typical conversation went something like this:

      Dave: “Arrgh! I can’t get this exactly right.”
      Harry: “Are the results correct and validated?”
      Dave: “Dead-on.”
      Harry: “Can someone look at the animation and understand what is happening?”
      Dave: “Yes.”
      Harry: “Well Dave, you are not making Swiss watches here…”

    This was Harry’s way of bringing me back to focus on what is really important. While everyone wants to have the most realistic model and animation, for the vast majority of projects that level of realism is no more necessary than a Swiss watch. That’s not to imply that shoddy work is acceptable. Shoddy work in never acceptable – every project should be completed at least at the level of detail and quality necessary to meet the project objectives. But even though an extra level of realism is nice, it’s a luxury that most cannot afford. And that is especially true if spending time on the luxuries causes you to neglect the basics.

    In fact, you should apply this concept even more broadly. When a project is not going as well as expected, first look closely to see if you or anyone involved is spending valuable time on things that are not absolutely necessary. If so, refocus on your priorities.

    I urge you to join me following Harry’s advice: Concentrate on the basics first and leave the “luxuries” for later.

    Dave Sturrock
    VP Products – Simio LLC

    Executing a Simulation Project for the Simple Minded

    This week I thought I would step back and offer a somewhat light-hearted summary of some of the things we have covered. Here are five simple steps for executing a simulation project.

    1. Figure out what to model. You can do this by being brilliantly insightful (which you might be), or by just talking to some stakeholders. Ask them questions. How would you use this model? What are your problems? What type of solution are you looking for? Will you invest time in this? Will you make decisions based on this model? Are you going to roll your eyes and laugh out loud once I leave the room? Are you going to tell your spouse about this project over dinner this evening to demonstrate that you indeed do have a sense of humor?

    2. Build something. It doesn’t have to be the world-changing model you devised in step 1, but a close enough approximation. It should do at least one useful thing from the list of game-changing things that’s on the feature-list from #1. Oh, and it should sort of work (even if requiring the assistance of some chanting, prayer and promises to recycle more).

    3. (Option A) Deliver it! Get your project in the hands of users. Even if it’s incomplete and not fully validated. It is possible that everyone that sees it runs screaming in the other direction. Mothers protect their children in its presence. But, get it out there and work like heck to deal with the aftermath of the great steaming heap you’ve unleashed upon the world.

    3. (Option B) Make Perfect, Wait, Deliver it! This avoids the problems with Option A because people will no longer run screaming. But, nobody cares about your project now because everyone is flying around with jet-packs on their back and 16-core processors are embedded in people’s brain as an outpatient procedure. The problem moved on and your solution (however “perfect”) is now irrelevant.

    4. Present. Present. Present. The law of large numbers says that the larger the number of stakeholders exposed to the project (see Step 3a), the more people you’ll encounter with average coordination who will trip and fall when trying to run away from your solution. Some of these people will buy-in while still in a semi-dazed state. Voila! You have happy stakeholders.

    5. Refine. Armed with a few active stakeholders, see what you can learn from them. What are they trying to accomplish? How do they use the model? What do they say between the screams of frustration? Figure out how to lower the pain quickly and treat them gently. During these brief spites of happiness that your stakeholders have, other stakeholders who come into contact with them think “Hey, Joe seems to be happy — even though he’s got this far-away look in his eyes, maybe this model is useful. Let me try it out…” Bing! You have another “happy” stakeholder.

    And the story goes on.

    For the really, really simple minded here’s the summary:
    Decide what to model, complete an imperfect prototype, get stakeholder buy-in, keep improving, get more stakeholder buy-in. Lather, rinse, repeat. SUCCESS!

    Thanks go to Dharmesh Shah of the OnStartups blog who provided the basis for this article. For anyone who has ever been, or wanted to be, part of a startup, you might find this blog interesting and entertaining.

    Dave Sturrock
    VP Products – Simio LLC

    Well – Managed – Agility

    In previous articles we discussed a definition of agility and the potential oxymoron of managed agility. I coined the phrase “well managed agility” as part of the solution. I was asked why I used the word “well” in that phrase. The short answer is that anyone can say they are agile. And anyone can say that they manage agile. But doing both and doing them well is the key.

    Good management in general is a topic I’ll leave for later. Today, I will concentrate on managing the process of change.

    The most important part of managing agility is to have a single person (or a small team that works cohesively) responsible for the agility. Ideally this person, who I’ll call the agility manager, should be knowledgeable and sensitive enough to understand:
    1) What the stakeholders want,
    2) What the stakeholders need, and
    3) The issues involved in delivering the above two items.

    The project demands a lot from the agility manager. It demands the ability to get inside the heads of stakeholders and really understand not only what they want, but what they really need. Sometimes even the stakeholders don’t know what they need until they see it (or miss the lack of it). The agility manager must also understand the issues and tradeoffs on the development side of actually meeting those needs (including deadlines).

    Some common agility challenges include:
    • The system being modeled changes (perhaps the design has evolved, or “assumed” aspects have just come to light)
    • The stakeholder objectives change (date, modeling details, purpose of model)
    • Modeling problems are discovered (modeling or data collection may be more difficult than expected)
    Often changes like these make current plans invalid. Of course the stakeholders want it all and many conscientious modelers will want to say yes to satisfy the stakeholders.

    To do the job well, the agility manager must be someone who understands all the above aspects and who can take the broader view to determine what action best serves the stakeholders? Choices like adding feature A versus doing a more thorough job implementing existing feature B, when you don’t have the time or resources to do both. Or when a project is running behind schedule, is it better to schedule extra effort, remove some features, or postpone the delivery date? Only a very knowledgeable manager can correctly make these decisions by carefully weighing the benefits/rewards of each action.

    Even better, the most effective manager will try to avoid having to make big decisions like the ones above, by instead making correct calls on numerous similar small decisions that arise on a routine basis. In a future installment I will discuss managing the “routine” and some tools and processes to facilitate that.

    Dave Sturrock
    VP Products – Simio LLC

    The Last Lecture

    I am taking a break from the normal simulation topic this week to mention a significant current event – the passing of Dr. Randy Pausch. Dr. Pausch was a tenured professor at Carnegie Mellon University who has become widely known for not only his life’s work, but also his recent activities.

    What is significant is not the event of his death, but rather the celebration of his life. He was a very admirable person and he “retired” in a particularly admirable way. When diagnosed with an incurable and rather fast acting cancer, he chose to spend much of his final time sharing life lessons that he had learned and did so in a very upbeat and inspiring manner.

    Among other things Dr. Pausch gave a very insightful, entertaining, and inspiring talk entitled “Really Achieving Your Childhood Dreams” in which he talked about his lessons learned and gave advice to students on how to achieve their own career and personal goals.

    I was personally very moved by this lecture; enough so that I am using this blog post to urge you to listen to it. It is just over an hour long and I encourage you to set aside the time to listen clear to the end, because even those last minutes are enlightening. This is not new – it was originally presented in September 2007 and has been viewed an estimated ten million times. If you haven’t watched it yet, please do.

    And don’t watch alone… if you have a teen or college student in your life invite them to watch with you – I think you will both find this hour to be very well spent.

    You can find it at Really Achieving Your Childhood Dreams.

    Dave Sturrock
    VP Products – Simio LLC

    Well Managed Agility – Start With No

    Last time we talked about a definition of agility: The capability of being flexible and responsive to changes in the world around you. And I suggested that Well Managed Agility is one part of the solution for the question of “How much agility is enough?”

    Is Managed Agility an oxymoron? It can sound like one. And some people equate agility with a lack of management, a free-for-all. That can be true when agility is taken to the extreme and poorly implemented. But agility certainly can be managed in many ways.

    The first step to managing agility is simply acknowledging that agility can and must be managed.

    I once joined an organization where there was major project in process that was getting later every day. The later it got, the more the stakeholders realized that the originally planned results would no longer meet their needs. So the stakeholders insisted on changes. The organization, who felt bad about the late delivery, almost always said yes in a futile attempt to placate the customers. Unfortunately, the more changes that were accepted, the later the project became. My job was to bring the project back on schedule.

    One aspect to getting a project back on schedule (we will discuss others in future blogs) is learning to say no. In this case I changed the process so that all major decisions, and all communications with the stakeholders, went through me. This was not because I was any kind of an expert. Quite the contrary – I was a novice at the subject matter. But I did know how to get the right people involved to exercise good judgment. And I did have the guts to say no when it needed to be said.

    The salesperson involved was livid – “You CAN’T say no to a major stakeholder.” My response: “Watch me!” The alternative of saying “yes” with the knowledge that delivering is not possible, is just flat out lying to your stakeholders. While no one wants to be told no, I think that most people would prefer an honest “no” to a dishonest and meaningless “yes”.

    As expected, the primary stakeholder was initially angry when he was first told no. But he soon realized that this was the first time he had been given an honest answer. And this was actually the start of what later became a great and very positive relationship. The salesperson also became a friend for the same reason.

    Next time I’ll talk about other steps to managing agility. In the mean time, if you are working on a project that is behind schedule, start practicing the word “no”.

    Dave Sturrock
    VP Products – Simio LLC

    Just Enough Agility

    Agility is the capability to be flexible, responsive, and adaptive to the changes happening around you. When a stakeholder asks you to deliver something you had not planned on, your response is a measure of your agility. But how much agility is enough?

    I was once part of an organization that was extremely agile. Whenever anyone in the organization had an idea, it would send the developers off in a new direction – quite often before they were half done implementing the previous idea. It was like a rudderless sailboat. Although we had an intended course, we never followed it and were instead at the mercy of the wind to see where we were headed that day.

    I have also been in an organization where they wanted detailed plans for two years ahead, and any deviation from the waterfall plan required an “act of God”. In this organization we generally knew exactly where we were going. Unfortunately, we also knew that if and when we eventually got there, we would be in the wrong place. The world never waits. A goal set to satisfy stakeholder needs today will rarely match stakeholder needs two years from now.

    Obviously each of these extremes has its pros and cons. I often wonder why so many organizations seem to live at one extreme or the other. I think neither is the right answer for most organizations.

    So how much agility is enough?

    There is no absolute right answer. Each organization and project will have its own right answer, and even that is likely to change over time. But I believe for most organizations and projects, the answer should involve what I call Well Managed Agility.

    Next time I’ll talk about what I mean by well managed agility and how you can achieve it. In the interim, I’d love to hear about your experiences with agility or lack of agility.

    Dave Sturrock
    VP Products – Simio LLC

    Wood You Simulate?

    I split a lot of firewood.

    I get most of my firewood in 18”-48” diameter logs that must be split lengthwise to about 6” thickness.

    Years ago when I first moved into a house with a fireplace, I started cutting and splitting my own wood. I used to split wood with an 8 pound maul (a maul is like a thick-bladed axe). I frequently had to supplement that with a wedge or two driven in with a large sledge hammer. Over time, I learned to “read” the grain in the wood, so that I could split along natural cracks and save myself some effort.

    A few years later I bought a wood stove to supplement my heating. As my wood demands (and my muscle tone) increased I upgraded to a 14 pound maul. What a difference. Sure it was a lot more demanding to swing, but as my aim improved just about every swing resulted in the desired division of one piece of hardwood into two. Life was good.

    Ten years ago I moved into the oddity of an all-electric house in the cold Northeast and shifted even more of my heating to my woodstove. After a while I started finding it hard to manually split enough wood to keep my house warm, so I bought a hydraulic splitter. Sweet! While it is still a bit difficult to manhandle a 200-300 pound log onto the splitter, once I get it there, the hydraulic ram pretty much takes care of the rest. Sometimes with badly knotted wood, I still have to “read” the wood and be a bit creative at how I direct the splitter to get through it.

    Today while I was splitting some logs my mind started to wander to some parallels between splitting firewood and doing simulation projects.

    Doing it yourself is definitely not for everyone. If you don’t enjoy it, and don’t have the time and skill for it, you are probably best off buying the service from someone else.

    It is amazing what a difference the right tool makes. No single tool is right for everyone. For some jobs, a lightweight tool is perfect. For other jobs, nothing less than a high-end tool makes sense.

    No matter what tool you use, having the good judgment to “read” the problem can make solving it a lot easier. And the more you practice, the better you will be able to determine the best approach to solving the problem.

    Until next time, Happy Modeling!

    Dave Sturrock
    VP Products – Simio LLC