10) “I did poor academically at school, so I’m going to stay away from complex models, and modeling in general”
I have no analytic claim for this, but I’m going to make it anyway: Your past academic achievement has absolutely nothing to do with your skill as an Ops Research Analyst. In fact, the converse is probably true. I have seen guys who blazed through schools up to the PhD level end up as totally useless on a team, and academic duds who barely survived the process end up as the star player of that same team. Which one do you want to be?
9) “We can’t build a model to do that.”
Telling a manager that their problem is unsolvable gives them few options other than winging it, and also invalidates YOUR value on the team. You are there to give them options. Examine the problem, break it up into manageable pieces, and build something, anything that describes the system. If nothing else just discussing the model that you build will generate a dialogue within the staff that will further understanding of the system and increase staff competence.
8) “We don’t have enough data.”
Repeat after me: “I will never have enough data.” You won’t. Live with it. Fill in the blanks with frog DNA. Do sensitivity analysis on the missing data pieces. Use notional data and convince management to conduct a survey.
7) “The data quality is too poor to make any decisions on model results.”
Once again, you are always going to have data quality issues. A lot of analysts say this without bothering to get into the details of what the quality issues are. Analyze the data for the quality issues and give management specific ways that they can fix them. You’re an analyst, remember? That’s what you do. Meanwhile build your model and analyze the system while acknowledging (analytically remember!) the quality issues.
6) Getting stuck on one type of modeling.
If your thesis was on optimization, or you’ve spent a lot of time doing optimization work, your tendency will be to look at every problem as an optimization problem. It might not be. You need to shy away from the tendency to do that and really examine the problem and literature about similar problems. A lot of time can be wasted on a wrong methodology. One way can be to make a list of all the approaches an Ops Analyst can take, and put you favorite at the bottom. Chances are, by the time you get there you might have convinced yourself to use something else.
5) “I need this piece of software to solve this problem.”
This may, or may not be the case. You really need to examine the capabilities of whatever software package you are going to commit management to investing thousands of dollars on. And when you look at the expense of training a team on the software, it might end up being hundreds of thousands of dollars. First, make sure it can solve the problem. The easiest to use, might be the easiest to break. Next, look at all your other modeling needs and see if it can be used for any of those. Last, look at yourself. Are you biased towards it cause you used it in school? Are you stuck on one package because you don’t want to learn another? Are you too lazy to program it in Excel? If the answer is yes, keep looking.
4) “I need to go to a meeting.”
There is a huge group of analysts that do nothing other than go to meetings and conferences. Keep doing it without producing results and you’ll develop a reputation for laziness and your skills will atrophy. Since you might be the only experience that management has with Ops Research you’ve also just screwed the rest of us as a bunch of lazy fools that waste time pontificating and burning Per Diem. Don’t fall into this trap. Limit your meetings to one a week, and conferences to two a year. Airlines only make money when the plane is in the air, and an analyst only makes money when he’s behind a PC building a model. Meetings are where the plane is broken, and the airline is losing money. You must make management happy by going to some of them, but you MUST also produce results.
3) “Management doesn’t know how to use me.”
Unless the manager is an Ops Analyst, they are never going to know how to use you. This isn’t an adverse reflection on management; it’s an adverse reflection on you. I have yet to be assigned to a staff where there isn’t a huge amount of Ops Analysis work to do. Go out and get attached to a project, if they don’t have one for you when you get there. Look at the company’s processes; the problem areas are modeling opportunities. Listen to what people are bitching about in meetings. Whatever they are complaining about is also a modeling opportunity. If you’re good at this, your dance card will be filled up immediately, and your boss will be screaming that all new work requests for your services need to go through him because you’re so busy.
2) “Management is pushing for me to be a project manager.”
Management might be pushing you into a management role, because you’re not doing your job. Start doing it. If you’re like me, the U.S. taxpayer spent $250k on training you. I suggest you see to it that they get their money’s worth. This is not just about you, but the Ops Research community. A staff’s perception of the community will start and end with you. If enough bad ones are out there, the field will go away.
1) “I need a programmer to do that.”
If you constantly need a programmer for simple data extraction tasks, or to build a k-minimum spanning tree script that can be typed out in a few lines, or an S-Plus script that does some analysis then welcome to your new 2nd job. You are now a programmer. There is almost never the time or the money to go out and hire a programmer to do the day-to-day scripting tasks that come up. You are gonna have to do some of the heavy lifting. I’m not talking about building your own faster than C-Plex solver here, or coming up with a replacement for R, but you are going to have to develop some scripting skills to be really effective. If you don’t want to learn them, you are really limiting your range as an analyst.