The property-approach Griff suggested is one step in your journey. But there is more to it.
You did not tell us anything about the "Process" that you claim gets started; it by itself will take time and resources that may matter a lot. If it is an actual Windows Process, you can forget it right away; Windows can't handle such avalanche of processes. If it is something inside your app, involving a lot of objects, some graphics, whatever, you'd better tell us much more about the application domain.
And whatever it is, you most certainly can't do it without any threading or timers: your urgent code sleeps for one second, hence blocking the only thread that seems to exist in your current approach. And you can't have thousands or even millions of threads at the same time either, even if all of them are sleeping.
If your problem is solvable at all, it is bound to happen along these lines:
1. have a chronological job list;
2. When you start a process, log it (your Console.WriteLine) and somehow add a "job" to the joblist (sorted!); the job consists of executing
z = z log(x);
Crystallize(y);
at a time corresponding to DateTime.Now.AddSeconds(1);
3. have a timer that periodically (say once every msec) checks the job list to see whether something should be done.
Several remarks are due:
1. You didn't tell anything about how the processes interact; if they pass data one to another, you probably/certainly need some synchronization means.
2. Windows timing isn't very accurate. Example: Thread.Sleep(x) really generates a delay that most of the time equals
at least x msec (not exactly x msec, and occasionally shorter!).
3. If
Crystallize(y)
isn't a swift operation, you may have to come up with a threading scheme that spreads the work over a number of threads (a few or tens, no more), and then again (1) will apply here too.
4. And finally, I can't ignore the impression what you are aiming for is well over your head.
:)