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

Project Objectives and Specifications – Driving your Customer to Success

Most projects start with a concrete deliverable date, but often only a rough idea of what will be delivered and only a vague idea of how it will be done. But as the old saying goes “If you don’t know where you are going, how will you know when you get there?”

To start with, I’ve learned over the years that you need to know your stakeholders. Who is funding the project? Who is using the model and its results? Put yourself in their positions and determine what their concerns are and what they would like to see from this project. What is the real motivation for this project? How will they measure success? After all, they are the passenger(s) and it’s their desired destination.

You need clear objectives as early as possible. In order to help find out what these are, you must ask these questions:

  • What do they want to evaluate or hope to prove? Short, concise goals are best.
  • What is the model scope? What system aspects must be considered?
  • How much detail is anticipated for various system aspects?
  • What input data do they anticipate being used and what is its availability?
  • How much experimentation will be required? Is optimization required?
  • In what form do they want results (detailed numbers, summaries, graphs, textual analysis, …)?
  • Do they want animation, and if so how will it be used? Animation for validation is often quite different than animations presented to a board of directors.
  • TIP: One way to enhance early clarity is to create a mockup of the desired final reports. Doing this as part of the specification phase can clarify many aspects of the project. Possible questions to ask would include: What items do they want to see? What alternatives should be compared? What statistical measures are they comfortable with?

    Getting lost before you even turn over the engine?

    Sometimes the desired project clarity is not there at the beginning. If this is the case, you are just fooling yourself if you plan the entire project including deliverables, resources, and date. Lack of early clarity is a key indicator that a project should be done in phases. I have found starting with a small prototype often helps clarify the big issues. Based on those prototype experiences, you might find that you can do a detailed plan for Phase 1 and a rough plan for any subsequent phases.

    An alternative approach is to start by doing a full functional specification. Some organizations spend the first 5-10% of anticipated project effort creating a functional specification. Your functional specification should describe all of the objectives discussed above in enough detail that the project approach and effort can be accurately estimated. While this effort may seem high, it generally pays off in a more robust, predictable project and deliverables.

    I plan on sharing more about functional specifications in a future blog. Until then, Happy Simulating…

    Dave Sturrock
    VP Products – Simio LLC

    Prove This

    On my second professional model, now that I thought I was an expert 😉 , my manager came to me and said “Prove this…”. He had the very common situation where an associate wanted to make a major investment, but could not convince upper management. This is a perfect application for simulation – a model can provide objective information on which to base such a decision.

    This was a much better situation than my first experience. This time I had a motivated, involved stakeholder. I had a clear objective. I had important meaningful work. Life was good.

    For a while.

    Until the model started to “dis-prove this”. Experimentation led me to believe that other alternatives might be better. I told myself that I must be wrong. I double checked but I could not find any errors. Then my boss and the stakeholder told me I was wrong. I triple checked but I could still not find any errors. Life was no longer so good.

    What went wrong?

    We started with the result. When I set out to prove a conclusion, I put my integrity at risk. The best I could hope for was that the model actually “proved” what they wanted. A typical client reaction to that situation is an empty “I already knew that!” feeling and the perception on his part that I provided very little value. Worse is when the model contradicts their conclusion. It does not support a “known fact“. In that case, stakeholders might think I am incompetent or that simulation offers no value.

    But the worst case of all would have been if the model disproved what the stakeholder wanted, but I kept “fixing it” until it supported their conclusion. My client may be satisfied, but do you think he will ever bring me real work? Unlikely. I would have just proven to him that a model can be made to produce whatever result you want, and that my integrity is low enough to do that.

    When similar situations arose later in my career, my responses were:

      –I will be happy to evaluate that situation for you, but I cannot promise what the results will be.
      –If what you really want is just a supporting statement, I cannot provide it without objective criteria on which to base it.

    While the above does not always create good will, it does allow me to keep my integrity. As much as I hate to admit it, intentionally misusing a model to create invalid results is often easy. Integrity is often the most important thing that you and I can provide as simulationists. A simulationist without integrity should look for another line of work.

    Dave Sturrock
    VP Products – Simio LLC

    Model This

    When I first started modeling, my boss came to me and said “Model this…” and then proceeded to describe an area of the plant that he thought “might benefit from having a model”. Unfortunately there were no specific objectives beyond that.

    To me, a new simulationist, that sounded like an ideal project. Nothing to prove… Nothing specific to evaluate… No one waiting on specific results (because none were asked for)… It even sounded like a good opportunity to learn how to model. But it was not.

    “Model this” generally results in a useless project. A waste of time. Without clients or clear objectives, I could not know what to model. Without clear objectives, I had little motivation to learn how to model tricky situations; I instead tended to bypass them to work on aspects more fun or interesting. In fact, for the same reason I often did not even recognize modeling challenges, so I never learned to deal with them.

    Moreover, when it was all done, what did I have to show for my time? Perhaps a cool-looking animation. It probably did not have many aspects of reality to it. Reality is driven by close interaction with the stakeholders – oops, I did not have any of them. Why should anyone waste his or her time sharing domain knowledge with me, when I was basically just modeling for fun?

    And worse, after I “finished” the model, I was overconfident of my modeling skills – after all, I modeled everything I set out to model, right? Of course I was never forced to really verify and validate against the real system, so I never really had any idea how good the model really was.

    Avoid “model this”. Always push for clear project objectives. More on that next time.

    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