Crunching schedule

Time is one of those mediums that we are still trying to fully comprehend. That time is relative is now a common fact in the scientific world. But this relativistic approach doesn’t help the business world, because businesses exist in the lack luster speed experienced in every day life; the time dilation and compression experienced at speeds approaching speed of light is never experienced. Businesses are always trying and struggling to get things done on time, time forms one of the basic tenets of business operations and getting things done on time is not a luxury, rather, it is a necessity in today’s competitive world. Since time needs to be under control and time is a rather wild beast to tame, most entrepreneurs will just do with having some control over time, which is where schedule management makes it debut.

Scheduling is just one of the many facets of time management, but there was a time, when they were one and the same. As time management is one of the most important aspect of project management, there was a short tumultuous period when scheduling was even considered to be equal to project management. Of course today, such simplifications are now known to be not true; so having a Gantt chart printed and pasted on the wall for everyone to observe isn’t enough to convince people that a project is in fact being managed.

Gantt charts have been the preferred way to represent tasks that require specific tasks needing to be done to achieve a goal. They also visually showcase an important fact of management, that there is a plan to begin with. Stick with achieving the vision in the Gantt chart and the project will finish according to the plan. Seemingly. Because Gantt charts ignore many aspects of management, such as scope, stakeholders, KPIs, finishing a project according to the plan may not result in the goal originally perceived. And that is if tasks finish on time, as scheduled, in the first place. They rarely do.

We live in a convoluted world. Because of which, schedules rarely finish ahead of time and tend to be delayed. Consider these facts

• It’s been shown that experienced workers try to finish tasks as late as possible because their superiors would otherwise expect them to hand in tasks of similar scope, as early as possible. If Bob can finish a task in 3 days with minimum effort and in 2 days with maximum effort, than its likely that Bob will finish the task in 2 days and wait an extra day to report back or just apply minimum effort anyway. We are inherently lazy and rarely devoted to a cause. Bob isn’t being a bad worker, he just represents the average human

• Schedules are initially designed with a little wiggle room. Scheduling is an art, not an exact science. While preparing schedules, expert opinions are usually asked for and during baseline schedule preparation, no one is going to be prepared for the worst case scenario, which is tasks having the least amount of time possible to be done. No, at that time during schedule preparation, all tasks have the best case scenario applied to them: time to actually complete the task with minimum effort AND some wiggle room, added with best intentions so that tasks are not delayed.

These two things lead to projects taking longer than they actually should. Over confidence by Bob lets tasks slip from the schedule and confidence on the schedule by the superiors allows workers to freely experiment with the wiggle room that is included in the schedule. Delays are therefore inherent.

So what should we do when delay is inevitable. Collect all the delayed tasks regularly and amend the schedule, right? Show that the project is consistently being delayed to stakeholders, right? What if the end date is not something in your control, what if say for example, your crazy CEO has stated publicly that something will definitely finish by the end of year and that something happens to be your project? Enter schedule compression

Schedule compression is a relatively broad term, applicable to any method used to shorten the schedule of work left in projects. Here is short overview of those methods

Adding resources

This is the tried and tested method when things are not getting done on time. While using this method, one should be aware of the Brooke’s law; adding more manpower to late projects makes it more late.

Outsourcing

The easiest way to deal with project failing to finish on time is to outsource a chunk of the work to a third party; to subcontract. This also means that risks associated, such as risk of not finishing on time, is also transferred. Which could help save some face on the short run. By transferring this work, people who were initially planned to carry them out, can also be used elsewhere.

Overtime

When adding resources to fasten the project is not an option, the other way to achieve the same effect would be by making available resources work extra. Not an appealing idea but also the default fallback for most businesses. Extended use of this method results in loss of productivity.

Core project team

Businesses have teams working in projects, which is to say, doing the technical works in many projects. These teams are often multitasking, companies rarely hire workers to work on a single project. But when a project is running late, multitasking has to be foregone, because multitasking makes people unproductive. Forming a team focused only on the project can help tasks finish faster

Fast tracking

This method involves looking at the logic of the problem at hand. The problem of course is the project and how to finish the tasks. If all the tasks to achieve the project outcome are achieved, a network of tasks can be obtained, showing which tasks need to occur before others can follow. Gantt charts are a basic representation of these networks. Then, when observed, it can be seen that of all the possible paths from the starting tasks and ending tasks, there are routes which determines the overall project duration. These routes, called critical paths, normally occur sequentially; one after the other. Fast tracking involves trying to rearrange the critical paths so that some tasks can be carried out in parallel.

Critical chain

Critical chain project management (CCPM), differs from normal critical path project management, because the latter doesn’t assume resource dependencies, rather, it assumes technical dependency alone. CCPM also differs on the way it assumes the wiggle room idea talked about earlier. Instead of adding slack at the end of tasks arbitrarily, CCPM insists on use of 50/50 activity time; a time duration that shows equal possibility of finishing tasks and not finishing task. Instead of adding wiggle room everywhere, CCPM recommends adding sufficient wiggle room to critical places of the critical chain, which is similar to the critical path explored earlier. These wiggle room, is called a buffer. Research shows that the summation of individual buffers in CCPM are less than the summation of the wiggle room added to tasks in the critical path method, which means CCPM results in projects being finished faster

Scope reduction

Projects exists on three fundamental aspects: time, cost and quality. When importance is given to one, of the other two aspects or both aspects have to be altered. Scope reduction is a common approach to dealing with projects that absolutely have to finish. This is the ultimate white flag, to know that certain parts of the project cannot be attained.

Quality compromise

Similar to scope reduction, quality can also be forgone to achieve a quicker completion period. It is rarely used though as the gains rarely balances out the losses and depends on the type of works that need to be done to complete project tasks.

This article was initially posted on the blog I contribute to at Rules of Knowledge