The mechanism of progress

For me, time entry was always a trudging misery. Searching for the tab that held our flavor-of-the-month time tracker app, set the time, then the project manager tab, then back to time tracker. Copy-paste the task reference for the synchronization folly, type in a description that nobody would ever read, hit 'save' then head back to the task board for the grooming phase.

Oh, the grooming. Shoving tasks around on a board, marking them done or blocked or assigned or dropping them into this lane or that. A myriad of choices, often lock-stepped so that ... god forbid ... you pushed something into production BEFORE marking its been tested and validated. Machinery grinding, emails flying, teeth gritted, all because somebody thought a spiderweb tapestry of execution flow would solve problems instead of constantly triggering them.

With a new line on the invoice, I wind myself back into whatever the heck I had put on pause to write it. Next hour of work means another time entry, tedium repeated day after day because that's the job.

It doesn't have to be this way...

Happy was the day I realized, it didn't have to be so meaningless.

Instead of accepting the hamster wheel of time tracking, I decided to create AbleTime. I wanted the friction reduced to a minimum, for the effort that I did put in to mean something. No more duplicated descriptions across multiple applications, no more hidden text that somebody out there on the team might find useful. No more dozen different communication channels that everybody uses only one of, so I have to use all of them!

A mechanism of process

Why not let every task that receives an hour ... respond?

Take for instance TPA-328 "Customer Account Ledger". It is sitting quietly in a 3-day range where the PM placed it a week ago. JaneG's icon smiling on its leading edge. Jane gets to it a day early, registers her first 2 hours, and on cue it slides back a day, anchoring itself to this new reality without being told to (the ghost bar tells us it is so). Jane finishes a day early too, and that last hour she logs closes the task. TPA-328 is now a closed 2-day task on the timeline, the chip showing she only used 6 hours of the 10 hours estimated. Notifications have gone out to Samantha and Wahe, because TPA-328 was the parent of their pending tasks, and they are now free to work on TPA-329 and TPA-330.

Jane's happy too, because she didn't have to touch TPA-328 once.

That is a process earning its keep. Jane logging an hour was no longer the first in a long number of steps that involved grooming tasks, context switching, sending notifications and making sure the whole mad exercise was synchronized properly. One action, many follow-ons orchestrated by the reality that action imposed.

Plan or no, the result is the same.

In the example above, TPA-328 was put on the Timeline as a "planning" artifact. A project manager placed it there, set dependencies, probably built out the whole project. The thing is, in AbleTime that is an extra step. Even if TPA-328 had just been a task sitting on the Flow Board (our automated version of a Kanban), that first hour would have placed it on the Timeline itself. Same with TPA-329/TPA-330 when they got their first time entries.

Planned or not, the Timeline will draw itself based on the hours applied, because they represent the "reality" of the task. There's nothing to groom, because the task is rendering the effort.

Making it mean something

Time entry will always be a bit tedious, a bit distracting. What we did is try and remove most of the friction and frustration. This is only one part of it ... more on the other bits later!

Beyond easing the friction, comes the benefits that follow. The Timeline and Flow Board taking care of themselves. The entire team being able to see where everybody is at, all the time. Those descriptions are no longer hidden away, but available for anybody who has an interest in TPA-328 and every other task knowing what happened, where it landed, and what comes next.