The idea of a critical path doesn't make much sense unless you understand the idea of a path. The concept of a "path" involves picturing the many ways you can get from one event) to another in a project. Here's a picture of an abstract project with all the sub-paths.
Allowing for the directions of the arrows, I count seven possible paths that will take me from Event 1 to Event 6. Here's how I counted them: (The numbers represent the Events along each path. Thus. from Event 1, I can go to either Event 2 or 3. From Event 2 I can can go to either Events 3, 4, or 5 etc. Along the way, I do tasks (activities) that take the time indicated.)
4 6
3 4 5 6
5 6
2 4 5 6
5 6
1 4 5 6 3 5 6
Although there are seven possible paths, the one that takes the longest (#2 above) is the critical path through the network. Of course this assumes that no event can start before the activity leading up to it is complete. In the real world, a network would have many more events and activities. However some connections between events might not be possible or likely.
If you try to do even this simple network by hand, you'll agree with me that a CPM program is worth its weight in computer chips.
We'll deal with just the start times for simplicity. Finish times have the same considerations.
ESe = the earliest start time for an event
LSe = the latest start time to reach an event without delaying the project
To compute the ESe for each event, take the largest sum of the times leading up to an event plus the ESe of all event from which those tasks emanate.
Notice how the "1" in ES1 matches up with the "1:" in Time 1:2 for the ES2 case. The pattern continues throughout the computations. What this implies is, for example, that Event 3 can't start before the third time unit, namely the time it takes to complete both Tasks 2:3, 1:3 and 1:2.
LSe are the times an event muststart if the whole project is to stay on time. To calculate LSe's you start at the end and work toward the beginning, looking for the smallest difference between the latest start time of an event and the times for tasks on paths leading away from the event.
Note that the activities on the critical path have 0 slack time. One of the activities in the sample network even has a negative slack time which means that it should probably be started 1 time unit earlier.
Nowadays, a project manager can almost forget about all the hairy and mistake-laden calculations of slack time. Many of the higher end PM tools do this automatically or upon demand. However, there is something to be said about going through the arithmetic by hand, at least once, just so you get an appreciation of what the PM tool is actually doing for you. On the other hand there's also something to be said for not doing all the computations by hand. All the work of running the numbers gives more importance to the CPM network. If anything happens to delay an activity along the critical path, the manager would need to refigure all the slack times and perhaps discover a new critical path and make the necessary adjustments. Rather than do that, many project managers tended to be "whip-cracking tyrants". Nowadays, recomputing the numbers is a minor task. With the appropriate PM tool, it even allows the manager to play "what if" and look for better ways to reorganize a project. This is especially true if the project has hundreds or thousands of activities.