June 23-26, 2013
INFORMS Healthcare 2013
October 6–9, 2013
2013 INFORMS Annual Meeting
June 10-14, 2013
Predictive Analytics World
September 8-14, 2013
2013 ASE/IEEE International Conference on Big Data
“Data science begins with data. Nothing gets built without data. Data science continues with science. Accurate, persuasive and effective prediction requires patterns. The process of discovering that pattern is science. Any product worth building requires a reliable pattern to exist in the data.”
– Christopher Berry, co-founder and chief science officer of Authintic, in his article on recommendation engines in the current issue of Analytics.
Analytics Section of INFORMS NewsInnovative Applications in Analytics Award
The Innovative Applications in Analytics Award, sponsored by the INFORMS Section on Analytics, recognizes creative and unique developments, applications or combinations of analytical techniques used in practice. The prize promotes the awareness of the value of analytics techniques in unusual applications or in creative combination to provide unique insights and/or business value.Read More
Special ArticlesBig data paying off for big companies
A new research report, “Big Data in Big Companies,” describes how 20 large firms benefit from big data projects. Report co-authors Tom Davenport of the International Institute for Analytics (IIA) and Jill Dyché of SAS, the leader in business analytics, explore how these companies have deployed analytics to generate value from their big data assets.Read More
Special ArticlesContinuing education courses for analytics professionals
The Institute for Operations Research and the Management Sciences’ (INFORMS) Continuing Education program will offer its first two courses this fall. These intensive, two-day, in-person courses will provide analytical professionals with key skills, tools and methods that can be implemented immediately in a work environment.Read More
Seven Suggestions for Successful Solution Startups
For systems analysts, getting off to a good start on any project is crucial.
A point-by-point guide for launch.
By Jerry Banks (Left) and Ken Musselman (Right)
Throughout our careers, we have found ourselves working from certain principles that have served us well. We share these managerial guidelines to provide the systems analyst with an appropriate and hopefully helpful grounding. We concentrate on the start of a project for we have found that making a good start goes a long way toward having a successful finish. The principles are presented here in outline form so the analyst can consider them point-by-point and refer to them easily as the need arises.
1. To finish strongly, start strongly. Take the following actions when starting a new project:
a. Introduce the team that will be working toward the solution of the problem. Give a very short summary of each team member’s qualifications, experience and the role that each will play. You can say something humorous about some or all of the members. But, don’t make that the focus of your introduction. It’s not necessary to discuss failures that individuals have suffered.
b. Be aware of team member limitations. No one can, nor should, do it all. Instead, strive for a representative balance of responsibilities among the team members depending on their strengths and need for development. This will require making choices and changing what is not working.
c. Explain why the study is being conducted. People may be quite concerned that the study is being done. Will it eliminate their position or change their work function with which they have become so comfortable? There may be rumors about the purpose of the study and what its impacts might be. Dispel the rumors; tell the truth, even if it might have a negative impact.
d. Confirm the objective. This complements the previous guideline. Instead of dwelling on what is not the intention of the study, tell the customer what it is. A complete success is unlikely without a clear and common goal. Write it down! The team needs to be properly aligned from the start; unless everyone knows what is expected and is reminded of it, they have little chance of accomplishing it. People contribute more if they understand what the intention is.
2. Crisp at the beginning, crisp at the end. Crispness is enhanced by making sure that your objectives have the following characteristics:
a. They need to be precise. For example, don’t say, “Our objective is to improve communication.” That’s too general of a concept. Make the objective more specific, such as, “We want to decrease customer complaints by 10 percent from the last quarter of the current year to the first quarter of next year.”
b. They need to be achievable. If you make the goal so vast that it can’t be achieved, it will be virtually meaningless and will undermine the spirit of the team before they even start. Don’t say, “We want to end lung cancer.” We certainly wish for that to happen, but in many years and billions of dollars spent, it hasn’t happened yet, and likely won’t over the course of your project.
c. They need to be understandable. Upon reading the objective, it should make sense to every team member. If the objective is, “We want the Type II error to go below 8 percent,” that may or may not have any meaning to the team. What is a Type II error? What does 8 percent represent? What is the error rate now? By what date is this to be accomplished?
d. They need to be measurable. Avoid words that are subjective. For example, “We want to have a substantial impact on the percentage of defectives.” What is substantial? What is a defective? For what product or class of products? Over what time period?
e. They need to be communicated…repeatedly. Team members can easily forget the specifics of a goal statement. Hence, repetition is needed. Moreover, by keeping the goal in the forefront, team members work harder toward its achievement.
3. Control expectations at the outset, exceed expectations at the finish. This can be accomplished by taking the following actions:
a. Temper expectations at the start, or they may become outlandish at the end. If expectations aren’t managed early on, the customer might begin to have many erroneous ideas about what might be accomplished. These ideas tend to grow as time passes.
b. Make sure that the customer knows the boundaries of the investigation, what’s included and what’s excluded. The model should be large enough to answer the questions asked. It shouldn’t be any larger than that. For example, in modeling the assembly of automobiles, it was noticed that the seats, among other components, arrive just-in-time from an external firm. Should the seat manufacture be monitored? The answer is that it depends on the questions asked.
c. Confirm the timeline. There are two elements to an expectation – a “what” and a “when.” The best solution is of limited or no value if delivered after the time needed. Gain the customer’s support by clearly laying out the project plan. Armed with this road map, the customer is in the best position to support the course of action and its timing. If the timeline is not regularly confirmed, a late completion is more likely. Team members must be reminded of what is on the “front burner.”
d. Don’t agree too readily; put your foot down. There is a tendency among younger analysts to accept every challenge. But, some requests are completely out of line. Usually, they are beyond the scope of work. Or, they may be technically difficult. Accept what is in the agreement, or what might be an alternate. But, add-on tasks each have a time requirement, and when all of those additions are made, there may be surprises about what the analysts have accepted as the amount of work to be performed.
e. Continuously monitor and manage. Midcourse corrections should be anticipated. An analyst doesn’t have enough knowledge and foresight to get it totally correct from the start. Expect change; nothing runs as smoothly as expected. This doesn’t mean to paralyze your progress for fear of all that might go wrong. Rather, it means to manage change. Be quick to curb unrealistic ideas, yet be open to value-add adjustments. Learn to stay flexible, for it is the best antidote for change.
4. Manage the project by managing the people. Consider the following:
a. Maintain control of the flow of meetings by following an agenda. An agenda is useful for several reasons. First, if it’s on the agenda, it’s more likely to be covered during the meeting. Second, extraneous topics are less likely to be raised if they are not on the agenda. Third, the most important topics can be covered earliest so that the meeting is less likely to end prior to their discussion.
b. Respond to any questions that are raised. Listen to each question and respond factually. Don’t sugarcoat your response. The truth always emerges. It is better if it comes from the solution providers.
c. Moderate the customer’s concerns. If there are concerns raised, discuss them. Some may be legitimate, some may not. Throughout the discussion, inspire trust. This, in the end, will give the customer the confidence to act on the recommendation.
d. Respect the customer’s time. Listen attentively to the issues that are raised, but move on once consensus is reached. To the customer, how you run meetings foreshadows how you will run the project.
5. To get good answers from the customer, ask good questions. Consider these suggestions:
a. Prepare. By preparing your questions in advance, you are less likely to omit something important, and your questions will tend to be more logical and targeted. The questions can be organized so that each topic is fully explored before moving to the next one.
b. Attempt to answer the questions yourself. Can you comprehend how to logically answer the question? It’s not as important that you know the correct answer as it is that the question makes sense. If you were asked, “What is the distribution of time between failures of a machine,” how would you answer it? What definition of terms do you need? Under what conditions is the measurement made? Is the distribution what is desired, or will the clock times of failure and when the machine is running again be sufficient responses?
c. Ask lots of ‘what if’ questions. This shows the customer that you are really thinking seriously about their problem. What if the SKUs are placed in the wrong bin? How will the correction be made? What activities occur when a machine goes down? Who is responsible for taking action?
d. Avoid asking questions that can be answered by a “yes” or “no” response. Don’t ask if SKUs are ever placed in the wrong bin. Ask what causes this to occur. What are the consequences of an occurrence? You want the process to reveal information, not preclude it. Thus, be attentive to not just the answer, but also your question.
e. Don’t upset the customer by putting them on the defensive.
i. Bad: “Why did you store those incoming pallets in the mixed pallet makeup area rather than the racks?” Your tone is accusatory!
ii. Better: “How do you decide where to store incoming pallets?” Here you are asking for information, which is a much better approach.
f. Ask the customer to predict the solution. This is not an attempt to get the final answer as much as it is to gain early insights and establish value. The exercise actually serves several purposes. First, it determines whether the customer has the same alternatives in mind as you. Second, the customer knows more about the system than anyone else. You will definitely learn something from the responses. Finally, it establishes a baseline of thought. In the end, should the solution turn out differently, the exercise legitimizes the project’s value. If the solution turns out the same, the team needs to explore why there was no knowledge gain.
6. Don’t approach the assignment with preconceived ideas. Follow these suggestions:
a. Be a good systems analyst. Maintain your skills. Read case studies. Read the literature. Learn about new software and its applications. Attend technical conferences.
b. But, be a better listener. You can learn a lot by listening to the customer. Allow them to transcend your thinking. They often hold the secret to success. It’s unlikely that any individual will be able to explain the entire system. So, you will have to meet with many individuals. Take adequate notes that will enable a more complete understanding of the system later.
c. Give the customer a chance to explain. Don’t lecture. This is not the time to prove your worth. Listen to the customer. Avoid putting words in the customer’s mouth. You are looking to draw out facts and encourage participation. A successful solution starts with a complete understanding of the problem.
d. Solve the customer’s problem, not yours. As the saying goes, “If you only have a hammer, you will see every problem as a nail.” So, you need a comprehensive tool kit to ensure that you work on the right problem.
e. Don’t leap to conclusions. Go through the entire process of analysis before deciding on the solution. Don’t make premature judgments. State the problem, determine what others have done to solve this kind of problem, collect data, analyze the problem, then, select the best alternative and implement it. Importantly, include the customer in this process. Selling the solution is done in concert with the customer, not apart from the customer.
f. Avoid criticizing the customer’s response. If you violate this, the customer is eventually going to stop responding to you. And, the customer may brand you as fault-finding so that no other customer member responds to you.
7. Lay out a good pathway for communication. We suggest the following:
a. Get everything in writing. If it becomes necessary to verify some part of the understanding concerning the assumptions, solution procedure, data or selected alternative, you had better have it in writing. Oral records are useless, and recall is prone to error, advertently or inadvertently. Writing everything down also confirms to the customer that you are listening.
b. Provide a project road map. The customer needs to see the entire project plan laid out in advance. This helps the customer know when resources will be needed and for what purpose. With projects, people don’t like surprises.
c. Make the customer a part of the solution team. If you do this, the customer becomes your advocate. If you don’t, the customer can quickly become an obstructionist.
d. Plan on having lots of interactions. Have frequent meetings, many milestones and early deliverables. Results are sold all along the way, not at the end.
e. Let the customer know. In the spirit of good communication, if a problem ever arises during the project, inform the customer. Don’t withhold some negative aspect of the solution for fear of the reaction. The customer will be even angrier if the issue is disclosed too late to deal with it.
The guidelines given above have worked well for us. And, they have worked for a long time. They should work for you as well, but perhaps there are cultural differences in where you operate and where we operate that necessitate some refinement. Therefore, our final bit of advice is to adjust accordingly.
We might not have thought of all the advice that could be given. If you can think of something else, let us know, and we will do our best to publicize it widely.
Jerry Banks holds the title academic leader at Tecnológico de Monterrey in Monterrey, México. Previously, he retired from the faculty of the School of Industrial and Systems Engineering at Georgia Tech in Atlanta, Ga., and then he was senior simulation technology advisor at Brooks Automation. He may be contacted by e-mail at email@example.com.
Ken Musselman is the strategic collaboration director for the Regenstrief Center for Healthcare Engineering at Purdue University. He also currently serves as the immediate past-president of the Institute of Industrial Engineers. For more than 30 years, he has actively consulted in the design, monitoring, planning and scheduling of healthcare and manufacturing systems through business activity monitoring and response, simulation and advanced planning and scheduling. He may be contacted by e-mail at firstname.lastname@example.org.
1. Musselman, Ken, “Guidelines for Success,” in Banks, J. (Ed.) “Handbook of Simulation,” John Wiley, New York, 1998, pp. 721-743.