15
$\begingroup$

When working on an optimization project, what is the typical time division (in percentage) between the various tasks that you have to work on:

  1. Problem understanding/definition (figuring out what is to be optimised, what are the relevant constraints, etc...)

  2. Interfacing of the data needed to solve the problem (getting the data from a database, a plain file, etc... into the application)

  3. Determination of the actual solution method to be used to solve the problem (am I going to solve it using a MIP solver or a heuristic, which neighbourhoods am I going to use, which valid inequalities could help me)

  4. Implementation of the solution method

  5. Re-working 3-4 to get better performance

  6. Visualisation of the resulting solution

$\endgroup$
  • 7
    $\begingroup$ YMMV, but for me: Overwhelming majority of time spent dealing with/trying to get around political BS, stovepiping, stonewalling, we're not changing the way we've done it the last fifty years, etc. All the stuff you listed is trivial by comparison. $\endgroup$ – Mark L. Stone Jun 21 at 20:14
  • 2
    $\begingroup$ To the (drive by, as they have not left a comment) downvoters, i think soft questions such as this can be among the most informative and useful. $\endgroup$ – Mark L. Stone Jun 21 at 20:17
  • 2
    $\begingroup$ @MarkL.Stone Would love to read a full-tilt answer from you! $\endgroup$ – David M. Jun 21 at 23:49
  • $\begingroup$ @David M. if I gave it, I'd probably break my all-time cross site SE record for downvotes. $\endgroup$ – Mark L. Stone Jun 22 at 1:01
  • $\begingroup$ I am tempted to answer: 120% of the time is spent on data. $\endgroup$ – Marco Lübbecke Jun 22 at 21:26
13
$\begingroup$

Personal experience, very rough estimates, these will obviously vary from person to person and from project to project. I have added a few significant items that weren't in the original question and tweaked one of the others.

0/ Making the case to clients and gatekeepers that we should adopt an OR solution ~ 10%.

I work in a government agency where part of my job is looking for ways to help other people do their job better/more efficiently.

Despite stereotypes of government, my co-workers have been pretty receptive to change. But anything I propose is likely to require a significant investment of time and money on their part, and if it doesn't work they have to live with the consequences. So I need to get through various approval/endorsement processes.

This will undoubtedly be a bit different for people working in areas like private OR consulting. But going by the presentations I've attended, client engagement is a significant issue for most OR projects. Even if the Big Boss thinks your project is the best thing since sliced bread, if the operational staff who have to use it and the IT staff who have to help build it aren't supportive, it's likely to die.

1/ Problem understanding/definition (figuring out what is to be optimised, what are the relevant constraints, etc...) ~ 30%

Big messy complex systems. My last project required learning large amounts of macroeconomic theory just to understand the problem. Inevitably translation is required to reach a common understanding of what the requirements really are.

2/ Interfacing of the data needed to solve the problem (getting the data from a database, a plain file, etc... into the application) ~ 10%

This would be significantly higher if I had sole responsibility for the data wrangling, but generally I can hand most of that off to other people.

3/ Determination of the actual solution method to be used to solve the problem (am I going to solve it using a MIP solver or a heuristic, which neighbourhoods am I going to use, which valid inequalities could help me) ~ 10%

Most of the problems I've worked on aren't complex in terms of OR theory (just as well, given how little I know of the theory!) and it's preferable to solve with one of the tools we already have available than to spend months trying to get new software products etc.

4/ Implementation of the solution method ~ 5%

Usually, once I understand what the requirements are, coding them is pretty straightforward, with only a few that are challenging.

5/ Re-working 3-4 to get better performances ~ 5%

6/ Visualisation and diagnostics for the resulting solution ~ 10%

I've edited this from your original question, because non-visual diagnostics can also be important here. This one is quite variable - in some problems we can just recycle visualisation/diagnostic systems that already exist, in others we have to come up with new ones.

7/ End-user training and documentation ~ 10%

So we can hand the OR solution over to end-users without needing to be there every time they use it.

8/ Project management and admin ~ 10%

Planning work in order to meet deadlines. Reworking the plan when deadlines or circumstances change. Risk management. Coordinating with the IT team whose job it will be to integrate our solution into corporate systems. Software procurement. Finding staff to work on the project with me and coordinating their work (which can sometimes be more work than just doing the thing myself!) Communicating with stakeholders to keep them up to date on project progress. Probably some other things I've forgotten.

$\endgroup$
  • $\begingroup$ Very organized. (+1) for adding in the communicating the solution and training aspects. $\endgroup$ – SecretAgentMan Jun 21 at 23:54
  • 2
    $\begingroup$ @SecretAgentMan Highly recommended for anybody who likes taking holidays and doesn't like taking work calls in the middle of them! $\endgroup$ – Geoffrey Brent Jun 22 at 3:29
6
$\begingroup$

I personally don't have the relevant experience in working on a project for a third party user. My experiences that I am going to itemize in the following are all about my work on my own projects. (So eventually some of the steps in previous answers may not be necessary when you work on your own project.)

1) Understanding the problem at hand and defining the variables and constraints by carefully investigating the inputs of the problem and the expected outputs. (30%)

2) Modeling the problem considering as many details as you can by using an available modeling language (can be AMPL, Pyomo, ...) (30%)

3) Getting the first solution and checking the reasonability of small instances. For example, if you have a transportation problem with 1000 nodes, a smaller size problem can be considered with only 10 nodes (10%)

4) Solving bigger problems and trying to modify the code in terms of solving time. (20%)

5) Visualizing the results and comparing them to the benchmarks, if any (5%)

6) Putting the necessary comments in the code, because it's going to be used later. (5%)

$\endgroup$
5
$\begingroup$

As @GeoffreyBrent said, it differs from project to project and from person to person and I agree with all of his 9 points. I just modify points 4-6 for a different flavor.

Iteratively doing the following > 50%

  • Implementation of the solution method for the problem at hand
  • Debugging (lots of it)
  • Check with the users for feedback and whether there are any requirements (constraints) that should be adjusted
  • Update the problem at hand

Deliver the solution ~ > 10%

Almost always, this is more than just handing over the code, some reports, and some visualization of the results (if needed). The user may need to have a GUI or a web-interface or an executable of some sort. In cases that you are dealing with simpler or more straightforward OR problems (or shorter projects, if you will), this step can, in fact, take the majority of the time.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.