Don’t Waste Your Time with a Functional Spec

Recently I was called in as an independent third party in a dispute between a modeler and a stakeholder. The stakeholder said “I have significant experience in both my application and modeling and I know what I want, but I am not getting it.” The modeler said “I have been modeling for 30 years and I know exactly what the stakeholder needs, but he just won’t listen to me!

It was obvious that they weren’t communicating well, but not so obvious why two such highly experienced people were at such odds. So my first question was “What was written in the functional specification?” You might guess the answer … “What functional specification?

My second question was “Well then, what did the contract say?” The answer again was unfortunately along the lines of “I’ll give you $x to model this” (refer to a recent blog of mine on this topic).

So in hindsight it is pretty easy to see where the misunderstanding came from. They had not agreed on model scope, approach, animation, units of measure, or even basic modeling objectives! Of course that leaves lots of room for experienced professionals to interpret the problem in totally different fashions and end up with totally different approaches to the problem.

Many people think that doing a functional specification (FS) is a waste of time. But a FS is rarely extra work. Rather it is work that must be done at some point and if it is done early it can have tremendous positive impact on project success. A FS is almost never a waste of time — even if the project is cancelled as a result of the FS, it is better to have “wasted” a few hours on the FS, rather than to have wasted significantly more time on the project before enough was learned to cancel it.

So who was right? I don’t even need to discuss the technical merits. In my perspective it comes down to two things:

1) A modeler who embarks on a journey with little clue where he is heading (an FS) is setting himself up for failure. An experienced modeler should know better.
2) While it is certainly the responsibility of the modeler to attempt to educate and persuade a client of the best approach, ultimately the customer is the one who decides if the project is successful, not the modeler. So in the end, the customer is always right.

Happy Modeling!

Simulation Stakeholder Bill of Rights

The people who request, pay for, consume, or are affected by a simulation project and its results are often referred to as its stakeholders. For any simulation project the stakeholders should have reasonable expectations from the people actually doing the work.

Here I propose some basic stakeholder rights that should be assured.

1. Partnership – The modeler will do more than provide information on request. The modeler will assume some ownership of helping stakeholders determine the right problems and identify and evaluate proposed solutions.
2. Functional Specification – A specification will be created at the beginning of the project to help define clear project objectives, deadlines, data, responsibilities, reporting needs, and other project aspects. This specification will be used as a guide throughout the project, especially when tradeoffs must be considered.
3. Prototype – All but the simplest projects will have a prototype to help stakeholders and the modeler communicate and visualize the project scope, approach, and outcomes. The prototype is often done as part of the functional specification.
4. Level of Detail – The model will be created at an appropriate level of detail to address the stated objectives. Too much or too little detail could lead to an incomplete, misunderstood, or even useless model.
5. Phased Approach – The project will be divided into phases and the interim results should be shared with stakeholders. This allows problems in approach, detail, data, timeliness, or other areas to be discovered and addressed early and reduces the chance of an unfortunate surprise at the end of a project.
6. Timeliness – If a decision-making date has been clearly identified, usable results will be provided by that date. If project completion has been delayed, regardless of reason or fault, the model will be re-scoped so that the existing work can provide value and contribute to effective decision-making.
7. Agility – Modeling is a discovery process and often new directions will evolve over the course of the project. While observing the limitations of level of detail, timeliness, and other aspects of the functional specification, a modeler will attempt to adjust project direction appropriately to meet evolving needs.
8. Validated and Verified – The modeler will certify that the model conforms to the design in the functional specification and that the model appropriately represents the actual operation. If there is inadequate time for accuracy, there is inadequate time for the modeling effort.
9. Animation – Every model deserves at least simple animation to aid in verification and communication with stakeholders.
10. Clear Accurate Results – The project results will be summarized and expressed in a form and terminology useful to stakeholders. Since simulation results are an estimate, proper analysis will be done so that the stakeholders are informed of the accuracy of the results.
11. Documentation – The model will be adequately documented both internally and externally to support both immediate objectives and long term model viability.
12. Integrity – The results and recommendations are based only on facts and analysis and are not influenced by politics, effort, or other inappropriate factors.

Note that every set of rights comes with responsibilities. The associated stakeholder responsibilities are discussed as part of the Simulationist Bill of Rights.

Give these expectations careful consideration to improve the effectiveness and success of your next project.

Dave Sturrock
VP Products – Simio LLC

Professional Development

The annual Winter Simulation Conference (WSC) starts two weeks from today. Initially as a practitioner and then later as a vendor I have attended over 20 of these conferences in addition to dozens of other similar events. WSC is just one of many events that you could choose to attend. But why should you attend any of them?

All such events are not identical, but here are a few attributes of WSC that are often found in other events as well:

Basic tutorials – If you are new to simulation, this is a good place to learn the basics from experienced people.

Advanced tutorials – If you already have some experience, these sessions can extend your skills into new areas.

Practitioner papers – There is no better way to find out how simulation can be applied to your applications than to explore a case study in your industry and talk to someone who may have already faced the problems you might face.

Research – Catch up on state-of-the-art research through presentations by faculty and graduate students on what they have recently accomplished.

Networking – The chance to meet with your peers and make contacts is invaluable.

Software exhibits and tutorials – If you have not yet selected a product or you want to explore new options, it is extremely convenient to have many major vendors in one place, many of whom also provide scheduled product tutorials.

Supplemental sessions – Some half and full day sessions are offered before and after the conference to enhance your skill set in a particular area.

Proceedings – A quick way to preview a session, or explore a session that you could not attend. This serves as valuable reference material that you may find yourself reaching for throughout the year.

I think every professional involved in simulation should attend WSC or an equivalent conference at least once early in your career, and then periodically every 2-3 years, perhaps rotating between other similar conferences. If you want to be successful you have to keep your skills and knowledge up to date. And in today’s economy, a strong personal network can be valuable when you least expect it.

I hope to see you at WSC in Miami!

Dave Sturrock
VP Products – Simio LLC

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

    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

    Making the Date

    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