When starting a simulation project, one of the more difficult things to do is estimate the expected time required.  If you are part of an internal group, this is critical to the usefulness of a model.  If it is not ready in time, the conclusions may be moot.  Decisions will need to be made and often those decisions will not be postponed while waiting for a simulation to be completed.  As a consultant, our profit is usually tied to our ability to estimate.  On long term projects, it may be possible to provide an hourly rate and work as part of a team.   While this allows your profit margin to remain in tact, your ability to estimate well and deliver models on time will dictate whether or not you get the next project.

So what are the issues?  I have an acronym that I use when looking at a project to determine the time required.  I need to look at the F-A-C-T-S

F- FOCUS

Why are we building this model?  What questions need to be answered and what questions do NOT need to be answered.  It is easy to assume that the model needs to do everything.  In a rush to make the end customer happy it is easy to say, “I can model anything”.  While it might be true, this leads to complicated models that take too long to build, too long to change, and ones that are not nimble enough to be part of a team decision making process.  Use a rifle approach to defining the scope of the model, not a shotgun.  Be clear with the end customer that the model is designed for specific purposes.   Its like designing a car.  You are not going to bolt a trailer hitch on a sub compact at the last minute because you have decided you want to tow a boat.  If they need an SUV model, decide that early on and let the customer decide.

A - Assumptions

I am not referring to the assumptions that are made as part of the model building process.  Once a project begins you can collect cycle times and understand how decisions are made.  I am referring to project level assumptions like - “the timing on this project is tight” or “animation is important” or “there are a lot of variables to test” or “we want to have a scripted video file as an output” or “we have complex 3D data that needs to be filtered and included in the project”.  These are game changing expectations that the customer has.  You need to ask as many relevant questions as you can.  These can be very generic questions but they will strike at the heart of why the model is being built and what will be considered a successful outcome.  Even if you write a scope that says the model will not do X and not do Y, the customer’s satisfaction will win out in the end.  For the most part they do not know what is easy and what is difficult to model.  It is common for customers to assume that all their changes are minor.  You need to tell them up front what will be difficult to change later so they can make decisions about how the model will be used.

C- Confidence

Confidence in the model to be built.  Have you built or supervised the building of a model like this in the past?  If not, you better leave some time for the unknown.  The first time I build a new type of model, I add 20-30% to the time for the unexpected.  It is hard enough to deal with the changing landscape of a typical engineering project.  This time is useful for researching the most effective way to model a particular aspect of the system or simply for extra model verification to be sure that the new model you built is functioning correctly.

T - Training

Does the end user want to use this model later?  Does the model need a friendly interface to make is accessible to others?  Are you supervising someone else building the model?  Do you need training on a specific aspect of the software that you have not used before?

S- Software

Does the model need to be built in a specific software package?  What version of the software?  Have you used that specific version of the software?  Do you know what bugs are published for that specific version?  Is there a reason to lobby for a different software package?  How fast will experimentation run?  Will the animation requirements place an undue burden on the software?  Do you have the proper hardware to run the model in the allotted project schedule?

In summary - interview the customer to find out what they know about the project.  Treat it as an interrogation without the bright lights.  Your organization and methodology will give the end customer confidence that they have placed the project in the right hands.