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

    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

    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

    On My Honor

    On my honor, I will do my best
    to do my duty to God and my country;
    To obey the Scout Law;
    To help other people at all times;
    To keep myself physically strong, mentally awake,
    and morally straight.
    Boy Scouts of America – Scout Oath

    I haven’t really thought about those words in a few decades, but it’s funny how they came back to me in an instant. If you were ever a Scout, you probably repeated those words hundreds of times, like I did. These are certainly admirable words to live by. But what does that have to do with simulation?

    On my honor – Make a commitment. Then take it seriously. Or in the words of Jedi Master Yoda “Do, or do not. There is no ‘try.’
    I will do my best – Is “good enough” really good enough? What would happen if you really did your personal best?
    To do my duty – A somewhat outdated concept, that each of us has intrinsic responsibilities and obligations. Or is it?
    To self and company – OK, I took some liberties here. But when considering your specific project commitments, also consider the big picture of what the company (or your stakeholders) really need. And it should never be far from your mind, what do you and your family need?
    To help other people – A team who works together can accomplish so much more than the sum of the individuals.
    To keep myself physically strong – Keep a good balance in your life. Personal fitness takes time, but can return so much.
    To keep myself mentally alert – Some types of wisdom require time to develop, but sometimes “wisdom” can be as simple as thinking things through objectively, along with careful attention to detail.
    To keep myself morally straight – There is no substitute for personal integrity. Sometimes you have to make difficult choices to keep your integrity, but it is always easier to keep than to restore after it has been lost.

    These concepts are valuable in your professional life as well as in your personal life. Think about them from time to time while doing your next project.

    Dave Sturrock
    VP Products, Simio LLC

    Magic Formula For Success – Part 2

    This article continues a brief exploration into how you can be more successful in your simulation projects. (Look here for part 1.)

    Here is a second set of important issues that should be considered.

    Agility – You can count on the fact that what you are modeling will change. If the system itself is not changing, the detailed project objectives will. Use a technique that allows you to stay agile enough to cope with the inevitable changes.

    Solve Problems – Don’t see yourself as just a model-builder. See yourself as a problem-solver. Think outside the box. Recognize opportunities. Don’t simply provide a service, add value.

    Software – Software selection is often difficult, particularly if budgets are tight. Domain-specific or generic? Easy to use or flexible? Established product or state-of-the art technology? Many factors must be considered.

    Know Your Stakeholders – Who is funding the project? Put yourselves in their position and determine what their concerns are and what they would like and need to see from this project.

    Credibility – While simulation provides a degree of objectivity, to many it is still a “black art”. At the end of the day if you don’t have personal credibility, all the backup data possible will not be able to sell your ideas.

    Certainly this was a very brief treatment of only a few key factors to success. Future articles will discuss these and others in more detail.?

    Dave Sturrock
    VP Products – Simio LLC

    The Magic Formula for Success

    Many people new to simulation rightfully inquire how they can be successful. This first article will identify some of the issues associated with simulation projects. Later articles will explore these and other issues in greater detail.

    So, to get started, here are five of the more important issues that should be considered.

    Project Objectives – “Model this” is not a good objective. “Prove this” is not much better. A clear objective is essential to a meaningful project. Hopefully it would include the phrases “evaluate …” and “as measured by …”.

    Know Yourself – What are your strengths and weaknesses? How about those of any other team members who will be involved? Be honest. Then come up with a plan to capitalize on the strengths and overcome the weaknesses.

    Domain, Tool & Process Knowledge – It is not enough to be proficient in a simulation tool. Nor is it enough to have comprehensive domain knowledge of what is being modeled. While having project participants with both of those skills is a prerequisite to success, you also need to know how to conduct a simulation project and deliver validated, valuable results.

    Project Planning and Management – A project that produces results after the decision is made has little value. And an over budget project may be cancelled before completion. You must pay appropriate attention to completion dates and project costs.

    Team/Reviews – Even though “No man is an island”, too often simulation projects are conducted by a single person with little or no team interaction. Find a way to get others involved.

    Look for five more success factors next time. Future articles will discuss these and others in more detail.?

    Dave Sturrock
    VP Products – Simio LLC