We Are Not Making Swiss Watches

August 16th, 2008

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

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

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

The Last Lecture

July 27th, 2008

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

July 20th, 2008

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

July 13th, 2008

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?

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

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

Missing the Date – Arriving Late to the Party

June 21st, 2008

How many times have you shown up late to an event? Perhaps something came up at the last minute. Perhaps you encountered road construction. Or maybe you just failed to think ahead. Sometimes it all works out. But sometimes you miss something important – like your sister’s wedding vows or your child’s big performance.

In an earlier article, we talked about the importance of project planning and management. Although there are many aspects to success, let’s concentrate on the completion date for the next few minutes. A project that produces results after the decision is made has little value. And a project running over budget due to lateness may be cancelled before completion. Success requires appropriate attention to completion dates.

Late projects are a chronic problem in all types of software development. Let’s start by exploring some of the causes of lateness.

Expectations – Planning the Journey

In software development the constraints of Date, Resources, Features, and Quality are well known. You can specify or mandate any one, two, or possibly even three of those factors, but if you try to mandate all four, you will almost certainly fail. For example, I can say I want all features completed with high quality, in 90 days, but then I have to be prepared to allocate resources as necessary. Or if I want it done with a maximum of 3 people, then I must be prepared to slide the date or other constraints. These same aspects apply to most simulation projects – perhaps substituting the word Comprehensiveness for Features and the phrase Validation/ Verification for Quality.

Since many projects start off in an urgent, budget-constrained status, management often tries to mandate all four constraints. But can I really specify all four constraints (e.g. all features completed with high quality, in 90 days, with a maximum of 3 people)? NO – not unless I have started with a very loose schedule (unlikely with an urgent project). I have generally found that attempting to do so will just mean that I will have no idea, until near the end, by how much each of the constraints will be missed. Note I said “by how much”, not “if”. As the anticipation of missing the date approaches, the pressure will increase at all levels to “cut corners”. Then, to save the viability of the project there is often a last-minute attempt to add resources to “save the date”, but that attempt is usually too late to have much impact.

Road Construction Next Million Miles

Assuming that we have reasonable expectations up front, what are some of the other problems that can hijack the schedule?

Objectives – Poor project objectives, as we discussed last week, is a huge potential problem. If you start with a missing or inadequate functional specification and a poor understanding of project, it is unlikely that you can develop a realistic project plan.

Optimism – I like to be guided by Murphy’s adage “Anything that can go wrong, will.” Many people think that it is safe to base their project estimates on “reasonable” effort estimates. But “reasonable” often becomes highly optimistic when adjusted by real world situations.

Stakeholder Involvement – First of all, you need to know who your “customers” are. If you are working for a large organization it might be difficult to determine who all the people are who have a stake in your project. If you are a consultant, this may be a bit easier. But after you identify them, the stakeholders must be involved. If they are not involved then you may be missing the important resources and information, and your project priority may suffer.

Skills – We are all smart, resourceful people. We all like to believe that we know, or can quickly learn, whatever we need to know to complete the project. But quite often there are many things we don’t know. And even more dangerous, there are things that we don’t even know that we don’t know.

Of course there are many other areas where you could go wrong – I’ll talk about them in future blogs. For now, maybe give some thought to these concepts and in a future blog we will talk about dealing with this first set of pitfalls.

Happy modeling!

Dave Sturrock
VP Products – Simio LLC

Project Objectives and Specifications – Driving your Customer to Success

June 11th, 2008

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