Archive for the ‘General’ Category

Keep Simulation Simple

Monday, August 25th, 2008

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

    Executing a Simulation Project for the Simple Minded

    Sunday, August 10th, 2008

    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

    Saturday, August 2nd, 2008

    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

    Wood You Simulate?

    Monday, July 7th, 2008

    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

    Making the Date

    Monday, June 30th, 2008

    It is rarely pleasant to miss a deadline, and sometimes it can be downright career-limiting. Last week, we talked about some problems that contribute to missed project dates. Now let’s explore some solutions.

    Step 1 – Objectives and Specifications

    We have already covered the importance of project objectives and specifications. Of course setting those objectives requires knowing your stakeholders and getting their involvement. In this and other articles I use the term stakeholders to represent the set of people who care about this project. It could be your customers, your manager, people who work in the systems being modeled, or others.

    Step 2 – Creating a Project Plan

    When creating a project plan, two adages come to mind.

    “Expect the Best; Plan for the Worst”

    I think it is fine to be an optimist and hope, maybe even expect, that things will go well. But I don’t count on it. I don’t base my plan on optimistic assumptions. I like to start with what seems to be a reasonable estimate, then double it to account for all the things that I know will go wrong. This may seem like “padding” but the objective is to determine an achievable schedule. I have seldom, if ever, found what seems up front to be a “reasonable” schedule to actually be achievable in the end due to the large number of unknowns in a typical project.

    Of course you can always spend more time up front studying the problem to reduce the risk to an acceptable level and possibly improve the accuracy of your estimates. But by that time the project has often become irrelevant because the decisions have already been made. Time estimates are always a guess and always wrong, so find a method that works for you and move on.

    “Under Promise, Over Deliver”

    To me this means be conservative. I try to avoid over-committing and, when possible, avoid sharing my optimistic intentions. For example, while I may have every expectation of creating a compelling 3D animation, I might only guarantee 2D animation or simple 3D animation. Or while I might intend to model some secondary applications so that I might explore some potential system improvements, I would not guarantee that in the project specifications.

    In fact, my project specifications usually include three categories:
    Guaranteed Deliverables – No matter what happens, the project is not considered done without them.
    Likely Deliverables – I intend to complete these, but if things go poorly, they may be cut. Often the stakeholders do not even know this list exists, depending on their tolerance for flexibility.
    Wish List – In the rare instance when the project goes exceptionally well, I implement tasks from this list. This list never makes it to a public project plan.

    This approach provides me some flexibility to:
    a) Avoid disappointing the stakeholders in case the project goes poorly, and
    b) Retain the opportunity to delight the stakeholders if the project goes well.

    What Comes Next?
    These first two steps are just the start of a project. In future articles I will discuss prioritization, agility, communication and many other topics that contribute to making the date and making a successful project.

    Until next time, Happy Modeling!

    Dave Sturrock
    VP Products – Simio LLC

    On My Honor

    Monday, June 2nd, 2008

    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

    Monday, May 12th, 2008

    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

    Monday, May 5th, 2008

    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

    Success in Simulation Introduction

    Monday, April 28th, 2008

    Welcome!

    We will be using this space to help each other become more successful in our simulation projects. We will be sharing information and initiating discussions that will prove interesting and helpful to both experienced and novice simulationists.

    When I say “we”, it is because I cannot do this alone – I need active participation from the user community. Your comments, topic suggestions, and article submissions are welcome.

    This blog is not about any particular product, nor is it intended to be in any way commercial or sales-oriented.

    Success in Simulation is available to all simulationists in industry, service, military, academic and other application areas, as well as anyone who wants to become a simulationist or who just wants to learn more about simulation. While I intend to focus mainly on discrete event simulation, articles on the related fields of agent-based modeling, system dynamics, and emulation will also be included.

    The articles will be intentionally be kept short for a quick read, and hopefully most will be written in an informal style for easy reading. I encourage you to subscribe to the RSS feed so that you will automatically receive new articles as soon as they are posted.

    Dave Sturrock
    VP Products – Simio LLC