SkedPal 2.0 is due to be released later in October. This blog post is intended for SkedPal 1.7.1 users and explains what has changed in 2.0. The new version is totally revamped and redesigned and is significantly different from version 1.7.1.
The first change that strikes one is the aesthetics. There has been a lot of decluttering, and simplification. A minimalist design has been applied as much as it was feasible. The goal was to simplify the operation of SkedPal while keeping its power.
A New Workflow
While the new version is designed to be adopted in almost any workflow, we do have a recommended workflow that will lead to the highest degree of success with SkedPal. There are two fundamental changes in the proposed workflow in SkedPal 2.0:
First, we realized adding new tasks to SkedPal 1.7.1 demanded a significant cognitive load. In particular, determining the priority and due date of a task was not always easy to determine. Priority is a relative term, and deciding if a task is a must-do or should-do depends on the other tasks. In addition, many tasks do not have a due date. And requiring a self-imposed due date up front was too much guess work leading to planning fallacy. The end result was a schedule that was hard to keep up.
In SkedPal 2.0, the only required parameter at the time of entering a task is the estimated duration. The prioritization of tasks becomes a periodic process where one can have a holistic view of their projects and commitments. This is a major improvement over the previous workflow of setting the priority at the outset.
To simplify the process of adding new tasks to SkedPal 2.0 even further, many task details inherit their values from the overlying project. For example, setting Time Maps can be done at the project level, and the tasks in that project do not need to have a Time Map unless one wants to override the project Time Map.
In addition, due dates are required for tasks with a hard due date. To manage planning for tasks that are not time bound, a new process is followed (see below.)
The second fundamental change in SkedPal 2.0’s proposed workflow is the weekly process. An average knowledge worker goes through an enormous amount of interruptions, and shifts of priorities. Fixing a micro-schedule (a detailed hour by hour) too far ahead is usually a recipe for failure. SkedPal’s Fuzzy Planning is designed to offer flexibility, but it’s still constrained by the time frames assigned to the tasks. For example, Fuzzy Planning enables scheduling a task ‘sometime this week’. This is already a significant improvement over scheduling the task at a specific day and time. Nevertheless, it’s still constrained by ‘this week’. If we are to decide on the task time frames at the time of capturing them, we are prone to planning fallacy. In other words, we end up taking in too many tasks for the week. However, if we do this planning in batches, we will have a much more realistic schedule. So, every week you can decide what is in your FOCUS, and schedule your most important tasks. This is called sprint planning.
There are a number of improvements in the technical architecture of SkedPal 2.0. The first one is the ability to work offline using the desktop version. It’s still cloud based and syncs across devices, but when you’re offline, it continues to allow access to all your projects and tasks. As soon as you go online, it will sync with the cloud. Re-scheduling, however, requires online access.
The way tasks are organized are also significantly improved. In SkedPal 2.0, it’s a lot easier to add or amend tasks, organize tasks into projects, and projects into areas. In addition, sub-tasks can be added right below the tasks, and can take their own duration, time maps, etc.
The only drawback of all these major changes is that your data from 1.7.1 will not fully migrate to 2.0. Some manual intervention will be required by you after data migration.
As explained above, the Must-do, should-do, nice-to-do prioritization is no longer a part of task entry process. Also, automatic postponing is removed as it was very hard to ‘automatically’ prioritize and decide what gets postponed. The new process to prioritize tasks is based on a periodic (weekly) evaluation of all projects and tasks. This periodic review is a best practice recommended by the popular GTD methodology.
Nevertheless, there are two types of tasks that don’t need to wait for the periodic review and can go right into your schedule:
- Projects or tasks that have a hard due date. To reduce the risks of missing the deadlines, you might want to add them right into your schedule. After all, the weekly review process is more about projects & tasks that are not time bound.
- The routine tasks also don’t need to wait for weekly review. If you want to go to the gym three time a week, that’s a routine for every week. In the weekly review, you can amend your routines if required, but you don’t have to wait for the weekly review to add your routines to your schedule.
Another major improvement in prioritization is the ability to fine-tune your schedule. Despite all the effort SkedPal makes to create the optimum schedule, there is still room for improvement. And, that can be offset by manual intervention. This new feature is called pinning.
In SkedPal 2.0, projects play a much more significant role. In addition to holding the default Time Map for all the tasks, they can also define how the underlying tasks are scheduled. The sequential mode in projects establishes the much needed dependency of tasks on one another. So, the second task will not be scheduled before the first one, and so on. This was previously only available in sub-tasks.
Handling of Hot Items
The best way to handle hot items is to avoid them in the first place. A lot of changes explained above are meant to prevent planning fallacy and hence reduced hot items. The truth is, however, we can only minimize them, but can never fully eliminate them. So, we have made additional features to alleviate the pains of handling hot items. When you have an item that cannot fit into your schedule, you will have the following options: