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.
