You'd think having strong technical skills (i.e., being able to build a concrete simulation model to show results) would be the key to ensuring a successful simulation project. Although you couldn't succeed in a simulation project without these skills, experience shows there are many other factors crucial to success that don't directly involve the construction of the model.

 All too often I've listened to the complaints of people who do simulation modeling: "This model clearly shows the return on investment. I can't understand why we don't implement the results" or "Management must be blind to ignore the model results. It must be a political decision." When we first run into this obstacle during implementation, we try to "market" the results. Somehow we think that if we show the results differently, or tell more people, everything will suddenly turn around. However, technical people often lack strong marketing skills, and the results of trying to sell the project are usually dismal at best. It really doesn't matter how good a job we do in constructing the simulation model or how convincing the model results are; if nothing gets implemented as a result of our work, we may have wasted our time. The primary reason a simulation-modeling project fails in the implementation phase has less to do with the actual model than with organizational dynamics. If we want to truly succeed in our simulation projects--meaning get results implemented--then we need to plan for common implementation obstacles from the very beginning.

Selling a Simulation Project to Your Boss If you've ever heard your manager say, "Maybe we'll take a look at that later" or "There's just no time for that right now," don't worry, you're not alone. All too often, what could be very successful projects are thwarted before they even begin by a manager who just doesn't see their value. Simulation projects sometimes fall into that category.  Your chances of selling a simulation project to even the least technical (or most suspicious) boss will be greatly increased with some careful planning and a little forethought. Here are a few tips designed to help you persuade your manager that the time is right:   Simulation is a means, not an end. Don't focus on the technical specs of a particular tool or on the details of how simulation works. Instead, concentrate on what you'll get out of a simulation analysis: Bottom-line profit is always a good starting point.   Speak your boss's language. Some managers are comfortable with the technical language that abounds in any simulation textbook, but if your boss isn't of that ilk, don't use the tech-speak. Phrase your proposal in terms that nontechnical managers understand.   Use the tool effectively. Most good simulation packages provide "live animation" of your processes. This imagery can be extremely effective for selling your boss on a simulation project. Make the most of it.   Build internal support. Appeal to your most forward-thinking colleagues. Building internal support can swing your boss's opinion--especially if your supporters are key players within the company.   Make the most of what you have. The data you need for a simulation project may already be sitting on someone's hard drive. Emphasize how you'll be maximizing your current investment in data collection.   Propose a solution, not a tool. Just because your chosen software has a twin x1 booster with an AA interface doesn't make it a good investment. Keep in mind that your boss will approve your proposal not because your chosen tools are technologically impressive but because they can help solve a problem that costs the company money. About the author Mathew Greenfield is vice president of sales and marketing for ProcessModel Inc. ( www.processmodel.com ). Selecting the Right Simulation Software Selecting simulation software can be an overwhelming endeavor. However, you can make a more rational decision if you have a framework in place to help organize your thoughts. This is not an exact science, and there's no single perfect methodology. Nevertheless, the following approach has led to successful results and can be readily applied in your organization:  Determine the high-level objectives of your simulation project. Identify and list alternative simulation packages that can achieve those objectives. As a starting point, you may wish to refer to one or more publications that feature periodic reviews and assessments of simulation software.  Contact the vendors for the candidate software packages and ask them to send an information package. Ask them what their packages are generally used for and request references and case studies for projects similar to yours. Based on the vendor information, weed out those packages that are obviously technically deficient, incompatible with your hardware or intended for other uses or that exceed the budget.  Develop a comprehensive list of desired software features and compile these in a questionnaire. Identify these features by talking to experienced simulation modelers and vendor technical representatives and by researching industry journals, applicable Web sites and books on the subject of simulation. The questionnaire should also request hardware requirements.  Send the questionnaire to potential vendors and ask them to verify whether their packages include the requested features. Encourage them to elaborate on any deficiencies and to identify alternatives for meeting the desired objectives.  Designate which requirements in your questionnaire are absolutely crucial to the success of the project. Assume that a candidate software package must possess these to satisfy your needs. Review the vendor responses and discard those packages that do not directly or indirectly meet your requirements. However, keep an open mind, because there's often more than one way to accomplish modeling objectives.  Many of the vendors will provide a demonstration package. However, it can take a lot of time to learn each surviving package sufficiently in order to make a rational choice. It is probably more efficient to ask each vendor to construct a demonstration model. These can often be viewed over the Internet or in a hands-on demonstration with a sales representative. Your goal is to get a feel for how the packages work.  Perform a business case analysis to determine the relative life cycle costs of the surviving candidates. In addition to the initial package cost, this analysis should account for the costs of training, software support and upgrades, and necessary hardware upgrades. Several key inputs must be established in order to complete these estimates, such as the life cycle length and the number of users requiring software and training.  Compare the qualitative pros and cons of the surviving candidates. Here you can account for specific features that you consider advantageous, but not necessarily essential. You can also take into account your impression of the level of service that each vendor offers, as well as the potential risks or concerns regarding a particular company or their package. By now, you have had numerous discussions with the surviving vendors. How responsive have they been? Have they listened to you and taken the time to understand your needs?  Choose your package from the list of surviving candidates based on the life cycle cost analysis and the comparison of qualitative pros and cons. It is wise to avoid making the final decision strictly on the basis of cost. Rather, let the cost guidelines help you decide between alternatives that are otherwise equivalent or to determine if the relative increase in capability between two packages is worth the corresponding cost increase. Don't be afraid to use your instinct in the decision-making process.  There is no perfect selection and it is generally better to select a viable package and get your project underway than to spend several additional months in the evaluation process. Consider your first model(s) as a prototype. Even if you decide to switch software packages later, your organization will have dramatically raised its understanding of simulation and reaped its benefits.   About the author Scott Sutherland is a principal consultant in PricewaterhouseCooper's Washington Consulting Practice.

Obstacle one

 Before any simulation project begins, it is critical to evaluate whether simulation is even the right tool to use. Although simulation is the best tool for many projects, we all know that no one tool solves all problems, and using the wrong tool can do more damage than good.

 So how do you know when simulation is the right tool for your project? The appearance of any one of three key indicators makes simulation a potentially good choice. The first indicator is complexity. Very complex systems are hard to visualize, analyze and explain. Simulation allows a very complex system to be systematically represented and resultant data more easily analyzed. The second indicator is variability. Variability includes variance and randomness, as when arrival times fluctuate, processing time varies, or there are multiple ways a process can be completed with varied resources and constraints. The third indicator is interdependency, which is difficult or even impossible to represent in a process without simulation. If your project is very linear with no real complexity, variability or interdependency, then a static tool like a spreadsheet might easily meet your needs, but the presence of all three indicators makes simulation crucial for a project.

 It's important to take the time to educate those involved in the project on the tool you're using and the reasons it should be used. Too often, those who see an animated simulation for the first time are impressed with the graphics but don't understand the statistical power of the tool. If you're asked to perform a simulation project and find as you begin questioning the project objectives that the project's purpose is simply to provide an impressive animation to convince management of a proposal and has little to do with the data, you're probably in a bad situation. By the same token, you may be dependent on others for data to feed your model, and as with any computer application, the old adage "garbage in, garbage out" applies here. If the people providing the data don't understand the significance of the data they're providing or how it will be used in the model, you may find your model producing a less-than-desired effect. Take some time at the beginning to educate those involved in the modeling effort. It will save you more time later on and improve your model accuracy.

Obstacle two

 You should always "begin with the end in mind," as Stephen Covey would say. In other words, start your requirements analysis of the project by looking to the end of the project. What are the project goals and objectives? What are the measures critical to project success? Are there technology or system interface issues to consider? Once you have clearly identified project goals and objectives, you can then begin sizing the project. What are the project boundaries? Within those boundaries, what are current constraints, resources and interdependencies? Define the project in detail and document it. A well-defined project avoids confusion and rework later on, but more important, it helps manage expectations and resource commitments. Your model may be a great piece of work, but if you missed the target on expectations, you will probably not see the fruits of your labor implemented.

 A good way to ensure that you've considered all project aspects is to create and document a project management plan. This plan should include project definition, roles and responsibilities, project schedule, project risks and mitigation strategy, communication plan and the model creation process.

 Because the modeler is usually dependent on others for the data to feed the model, it's also important to establish project roles from the beginning. If there's any ambiguity about who is to provide what data, you may find halfway through the project that everyone is busy with their daily jobs and they all think that someone else was providing you the information. And even though management fully supported the project from the beginning, you cannot seem to find management oversight to review the project to date and provide guidance. Halfway through a project is not the time you want to be sorting out who's responsible for which pieces of the project. It's best to specifically identify, by name, responsible parties for various aspects of the project before it starts gaining momentum.

 Although there are benefits to gathering the model data from individuals, many times you can save time and improve accuracy by conducting a cross-functional workshop. By assembling the key people involved in the process, you can quickly bring all of the pieces of the project to the table, reach consensus on how the process works, document the details, and walk away with a fairly good model. However, you have to be careful when using this approach to ensure that the "right" people attend this workshop and the group is facilitated to keep the meeting brief and productive. Take the time to learn which key people should attend the workshop. You don't want to hold a workshop with the majority of participants thrown in at the last minute with no idea about the project be-cause the primary people were suddenly too busy. Having the wrong people attend is usually just a waste of everyone's time.

 Creating a realistic project schedule is critical, but maintaining flexibility is the key to success. When you plan your project schedule, don't do it in a vacuum. Remember that you are probably dependent on others for information. By including those key people in your planning process, you will be a great deal more likely to gain their support and create a much more realistic timeline. And although a better-planned project usually leads to smoother execution, very few projects are ever executed exactly as planned. Therefore, managed flexibility, achieved by means of project risk and mitigation analysis, becomes critical in executing the project.

 Too often we hit an obstacle in the middle of a project and must stop all progress to identify the problem and its cause, get the right people together to figure out how to address the problem, and then execute a mitigation plan. This labor-intensive effort often delays the project schedule. However, many times we know the potential execution pitfalls before starting a project. Rather than ignoring these risks and hoping they don't interfere with project progress, identify them and create a mitigation strategy for each risk. For example, perhaps you're concerned that the data you'll need may not be readily available in the current organization's database. You would identify this as a factor that could risk completing the project on schedule. A mitigation strategy--an alternative course of action to overcome an obstacle-- might be to use subject matter experts' best estimates if the data isn't available. If plan B becomes necessary, you won't lose any time implementing it because everyone has already agreed to it. By identifying the project risks from the start and creating a mitigation plan for each, you can avoid obstacles that would otherwise delay completion.

 As with any project, it's much easier to get active participation from people at the beginning of a project than it is to get their involvement months into a project. Enthusiasm wanes as time goes on, and other priorities pull at these resources. You have to find ways to keep the synergy alive with your project. The best way to do this is by implementing a strong communication plan, keeping the project visible to them. The more you can keep project progress visible to team members, the better you will keep their involvement. One easily accessible means is using a Web site or your corporate intranet site. Routinely update the site with new information: Post the current schedule, publish meeting agendas and minutes, and post draft models and data collected thus far. Even use the Web site to collect the data, validate and verify model structure and data elements, and coordinate on important issues.

 Although modelers may live in the project night and day, it's important to remember that multiple team members may only be involved on the periphery of the project. It's easy for part-time team members to lose sight of the project's "big picture" if you lack a formal model-creation process for their reference. For example, one team member might be supplying the arrival data for a purchase order. If that member doesn't understand how that data is going to be used and how much a small variance in the numbers can affect the model results, the data's accuracy may not seem that crucial. Your model-creation process should include details about all of the major phases of the project, the people to be involved at which points, the means for translating the data into a model, the method for verifying and validating the model, and the method for generating and presenting the results.

Obstacle three

 Technical people usually don't enjoy marketing their model results. However, with a little proactive planning and some effort at the beginning, you can avoid the post-marketing fiasco and better ensure project implementation. The biggest obstacle to project implementation involves the organization's dynamics--it's imperative to gain buy-in from the "right" people early in the project to ensure implementation. So, who are the "right" people? At a minimum, they include the process owner and the cross-functional team. The process owner is the person who has the authority to change the process. Too often teams form to attack a problem and put forth a great deal of their time and effort forming a solution only to have it shot down when they take it to the process owner for approval. If you include the process owner on the team and involve that person in the project development, any solutions formed are already approved before you finish. However, having the process owner onboard is not enough if you don't also include the cross-functional team, that is, the people who must live with the process changes. The process owner may love your model results and see the return on investment only to do a 180-degree turn during implementation when the people who must live with the results resist. Sometimes that's where organizational politics come into play. A manager may not be willing to risk the approval of the people involved to implement the solution. If you have proactively involved these people throughout the project and they are also onboard with the solution, implementation is a breeze.

 Many of us must struggle to balance our purely technical skills and our softer "people" skills. Unless you're already one of a group of modelers managed in a pool of a large corporation, you probably struggle with this balance on a routine basis. It's not easy for many technical people to develop these skills, but it's often critical for the success of your simulation projects. A little extra time and effort spent pursuing the "softer" side of your project will save you time, frustration and money in the end. It's an investment worth making.

About the author

 Sarah Aust is a senior consultant with ProcessModel ( www.processmodel.com ). She has 10 years of experience leading cross-functional teams in organizational development, computer simulation modeling and business process reengineering. She has also developed and taught many courses on process improvement. With a career founded in the U.S. Air Force, Aust has continued to apply her industrial engineering skills to many consulting jobs for the Army and Navy, resulting in large cost savings and organizational improvements. She has a bachelor's degree in mathematics from Bowling Green State University. E-mail her at saust@qualitydigest.com .