|The stupid question is the question not asked|
I had this problem few years ago with a job scheduling software and I managed it!
I used following principles, I think some of them could also apply for your case:
1. Instead of trying to understand the code I tried first to understand what it was doing.
In fact by quickly evaluating the nr of code lines, the techniques used and the style of coding I saw that it was impossible to understand the code in a finite time.
2. I prepared myself dummies to simulate less important modules (in this case the scheduled jobs). In this way I got a substantial easier complexity to manage.
3. When I had to change something I took just whole functions away and rebuilt them new.I studied only poorly the code,instead I concentrated my efforts more in understanding the requirements.
Because who says you that existing procedures are really implementing correctly the required functionality?
4. I was testing a lot, and I took care to optimize test runs.
But finally I can only say to you: