How do you schedule tasks in a project?

How do you decide what tasks to schedule first: the complex ones or the easy ones? the short ones or the long ones? the risky ones or the sure-shot ones? Most often, this task sequence is determined by hard logic, soft logic, or some other external constraints. However, how do you decide when there are no such contraints?

If we look at the risk driving the project lifecycle and scheduling, then it is natural to expect high-risk tasks being tackled at the start just so that we are systematically driving down risks in the project and achieve higher certainty levels as we get close to the project. However, it seems inconceivable that someone will cherry-pick the easy tasks first and leave all high-risk ones for the end! Clearly, that is setting up the project for a grand finale of all sorts!

Project SchedulingCould complexity be a good measure then? What will happen if we take high complex tasks first? Surely, that will lead to tackling some of the most difficult problems first, and there might also be a high level of correlation between complexity and risk. So, taking this approach is also likely to significantly lower a project risks. However, not all tasks are created equal. It is likely that high-risk tasks not the longest, so while the project makes appreciable gains in lowering the risk, but doesn’t make a whole lot of progress.

Agile approaches, Scrum in particular, rely on driving the tasks that make biggest sense to the customer – tasks that deliver maximum value to the customer. However, there is no guarantee that this will help lower the project risks, or manage the schedule better. Similarly, Kanban helps manage tasks but doesn’t really spell out how they should be scheduled.

So, what is the best approach?

I read an interesting blog, The Art of the Self-Imposed Deadline, where I specially liked this one from the blog post:

3. Avoid the curse of the “final push.” Scope and sequence a project so that each part is shorter than the one that precedes it. Feeling the work units shrink as you go gives you a tangible sense of progress and speeds you toward the end. When you leave the long parts for last, you’re more likely to get worn out before you finish. Besides, if you’re “dead at the deadline,” those other projects you’re juggling will stagnate.

This seems like a very practical suggestion – often the tendancy is to ‘cherry pick’ while scheduling the tasks – we tend to pick up tasks that are favorite to people, or appear to be easier to take up. However, very often, we end up taking more time, and project gets delayed. If the tasks are scheduled such that big/complex tasks are scheduled first, that might mitigate lot of risk pertaining to last-minute issues (could be due to underestimation, or integration issues, etc.). However, I am not 100% sure that purely scheduling tasks on “longest-task first” basis is the best policy to lower risks in a project. Shouldn’t we be using a combination of top-risk items that are longest?

I haven’t used this approach yet, but seems like something to try. How about you – what’s your favorite way to schedule tasks?

6 thoughts on “How do you schedule tasks in a project?

    1. Tathagat Varma

      Right. That said, one might be able to reduce the number of things that are getting piled up towards the end. By procrastinating, one might suddenly face a deluge of activities to be done within what might appear to be an unreasonably short time, but by planning and scheduling better, one might be able to reduce such number, even if a 100% elimination sounds like wishful thinking.

  1. Palash Gupta

    Scheduling tasks in a Project – Certainly there is no single approach which works always and Risk based sequencing is one which is quite successful. Following are some more factors, which can be considered to decide relative weights associated with different activities to facilitate effective scheduling.

    1. Dependency: Independent activities which have other activities dependent on them need to be considered while assigning the weight. Activities which are on critical path deserve high weight. Interestingly critical path is always changing and lapses in monitoring the dynamics can prove the scheduling wrong.

    What-If scenario analysis helps in understanding affect of project dynamics on the activity duration and sequencing.

    2. Resource: Whether it is day-day life or the project execution, one always faces the dual constraints of limited resources and limited time. Requirement and availability of the critical resources (H/W, Critical Human Resource etc.) at different time slots needs to be considered while assigning the scheduling weight.

    I remember how my mother used to cook food in her kitchen using the available limited resources. The art lies in how different activities were sequenced to minimize the waiting time by ensuring the maximum/optimal usage of the limited resources viz – Gas stove with two burners, 1-2 pressure cookers, 1-2 frying pans etc. She will cut the vegetables first and will put the curry and cooker (Dal + Rice) on the two available burners, by the time these two are getting ready; she will prepare the Floor dough, to be ready for preparing Chapatis.

    Above example throws light on the fact that the sequencing should facilitate the optimal usage of the available resources and parallel execution of activities which are on the critical paths (Fast Tracking). However a project execution is much more complex and unique than the routine cooking and risk of rework needs to be actively managed in case of Fast Tracking.

    3. External dependencies need to be weigh based on criticality as many of the times they are non negotiable and related activities need to be assigned with higher weight. e.g. Supplier’ schedule and his capacity constraints, Integration with other S/W & H/W, availability of certain raw material in a particular season, Opening/Closing of certain transport channels in/for a specific period, deadlines of government policy enactment and many more…

    4. Interestingly urgency (immediate deadline) of the task also pushes its weight up.

    e.g. Your project has hired a consultant or an equipment with the limited time period and same needs to be returned back, One of your team member is serving the notice period after his resignation and needs to be relieved, A S/W license is getting expired, Critical team member who holds niche expertise is going for long leave and many more of them…

    5. Another factor is unanticipated events, Unknown-Unknown Risk or what I call as H/W interrupts, activities which enjoy absolute priority and weight. Critical defect reported by customer directly from field is one of such example.

    I think railways experience it in day-day life as they assign absolute priority to some trains over other trains according to different categories, Express, Fast, Superfast etc.

    6. In case of availability of multiple scheduling options even lower cost of a particular activity sequence can play an important role to increase its weight. Many of the times activity under consideration can be divided in multiple sub activities and then only required ones can be scheduled at priority and rest can be later.

    Theoretically all activities and their sequencing should be in alignment with the project shared vision and the relative focus on the triple constraints.

    Interestingly to maximize the efficiency, activity scheduling should
    (Lean concepts) eliminate or minimize –
    Over production, Waiting time, Movement of employees & work products, Unnecessary or incorrect processing, Delays between steps in a process, Delays caused by waste and rework and Delays caused by large batch sizes.
    Or as per the Agile manifesto scope definition and sequencing should facilitate –”Maximizing the amount of work not done”.

  2. Anuj Magazine

    This post took me back to Mark Twain once said- “If the first thing you do each morning is to eat a live frog, you can go through the day with satisfaction of knowing that that is probably the worst thing that is going to happen to you all day long.”
    “Frog” here is a metaphor for the task you find ugly but it needs to be done.
    The feeling of successfully completing a complex task definitely gives the human beings all necessary endorphins to keep moving forward but we dont live in an Ideal world. Often in practical scenarios, it is not possible to complete or even attempt to commence the complex task at the start of the project, primarily because any complex task will usually depend upon successful completion of many prerequisite tasks, which may not be very complex to achieve.
    I feel that proper sequencing of task (by understanding the prerequisites and future deliverables) is all more important that trying to attempt to eat the frog right-away.

Leave a Reply