As a data specialist, my process is probably somewhat different.
First I need to figure out which servers and which databases I need to be accessing, since just one server might have up to 150 different databases on it and we have 30 or more different servers each of which has different databases, this can take some time.
Since our product is highly different depending on the client even when they share some of the databases, I may need to review some procs and SSIS packages to see exactly where things are stored for that client. I may research some similar work for other clients especially if this is a new client or a task I know we have done in a slightly different customization for someone else. This may lead me through the morass that is our Source Control system, since each client team stores things differently (It's so much fun sometimes being a shared resource!). I may investigate if our standard SSIS imports and exports can be leveraged for this client or if I need to do custom development. Luckily for me, I have in-depth knowledge of our database and can name out of memory about 95% of the tables and databases I need to use for any particular task and can usually figure out the others in less than an hour. Takes a longer for a client I haven't worked with in a long time or one I've never seen. I may spend a day or more with the application developers trying to figure out how we are going to store stuff that the imports need to import and the reports and applocation need to display that is specific to that client alone. For a huge, complicated client, we (the application develoeprs and teh database developers) may spend a couple of months figuring out the database design before we go our separate ways to work on the actual development.
If I am going to be writing complex reporting SQL or exports, I will start by identifying which chunks of data I need in a series of comments. Those will then become the CTEs that will feed to my final large query (it is not unusual to have source queries that take hundreds or thousands of lines of SQL code and ten or 15 different CTEs). In those comments I will note some specific business rules I will need to implement. If it is complex enough, I will write a tech spec that will tell me exactly where each field I need to get is stored. That reduces the time to actually create the complex SQL a good bit.
For Imports, I do a quick import of any new file to a staging table, just to see what is in it (you don't really want to open a 20 million record file directly!). Then I scroll through the data deciding what kind of information is in each column (Often not what they told us would be in it either in terms of actual columns or type of data) and what problems might be in the data. Then I run a lot of ad hoc queries to get an idea of what I might find, especially where there are too many records to really scroll through a big percentage. Once I have seen the file and the data problems it might contain, I sketch out a line of attack often on a whiteboard. Then I usually start with either building a parent package to run our standard imports (using the parent package to massage the data into a from the child package can accept when what they send doesn't match our specs for the standard pacakage (which happenes about 98% of the time) or building a separate import if the client will have unusual business rules and the standard package won't work.
In general I usually spend much more time preparing to write code than actually writing code. Once you really know what you want and have a solid design, development time is usually much less.
Of course when the project is a relatively simple - fix this bad data that got entered into the database (Either through bad data entry or incorrect data sent in the import file), I usually just start writing SQL. Because I know the database structures so well, I can construct the adhoc SQL to fix a serious data problem very quickly.
