In terms of guidance, the detailed answer is to get my 2012 book on query tuning. The more general answer is to capture the wait statistics before and after you run your process, several times. Use sys.dm_os_wait_stats. You can query it before and after the process runs and it will tell you what the system is waiting on. That helps you understand the issues. Then, you can also capture query metrics using (since you're in 2008) trace events (if you were on 2012 or felt more confidence, I'd suggest using extended events, they're generally safer than trace events) to see which queries are using which resources. You can correlate that to the wait statistics and work on the queries that are causing the most waits. Work basically involves looking at the queries for common code smells, execution plans for issues with indexes & statistics and more code smells.

And, it does sound like you might be hitting statistics issues. It's possible your statistics are out of date (auto update of statistics is a good thing, don't turn it off unless you can prove, beyond doubt, that it's causing you problems) because the auto update is fairly conservative (500 rows modified + 20% of the number of rows in the table before an update fires). You can try running UPDATE STATISTICS WITH FULL SCAN against the tables or indexes used by your queries to see if that addresses the issue.

Hopefully that's helpful.