Time Management with Trello

I have been using Trello to manage my time, tasks and projects for several months now and it’s the most satisfied I’ve been with any particular tool to date. It’s simple. It’s easy. It’s generic enough to use for almost anything.

Throughout my time using Trello, I’ve developed a framework to implement the processes that work best for me. These processes and habits are influenced and informed by the work of Tom Limoncelli in his classic “Time Management for System Administrators” (go buy it now!). This board is use in combination with a traditional calendar for fixed date & time events.

Are you looking for a simple way to more effectively manage your time? Take a look at my Time Management Trello board template, create a copy for yourself and enjoy the good feels!

Well that was fast!

Not even 24 hours after moving iSight Disabler over to GitHub, the repository has already been cloned twice and received its first pull request. It took me longer to get around to merging the request then that time between creating the repo and the pull request!

I realize that two clones and one pull request is paltry in the high paced world of GitHub and OSS development but I’m still a bit shocked by how quickly the community was able to start contributing once the project was on GitHub.

The iSight Disabler page on techslaves.org will remain up with the legacy download links but all new code/versions will only be available on GitHub. Got an idea to improve iSight Disabler? Clone, fix, pull request, merge and DONE!

Regular Change Windows

I am a proponent of change management (CM). I value the function, even if I sometimes despise the bureaucracy found in typical implementations.

At $work, we follow fairly well established CM process. It’s not perfect and it has bureaucratic elements but it’s well understood and mostly respected. Regular thinking about process improvement has led to critique of the individual elements of the process. Deadlines. Approvals. Communication plans. Success criteria. Change windows.

Let’s talk about change windows. We have a “regular” change window that happens once a month on a particular weekend. This was an IT decision. We decided on a particular schedule and called it the “regular” change window and asked everyone to schedule their changes within that window unless they had justification and approval from management for doing otherwise. The problem is, by the numbers, it is hardly our “regular” change window.

The Numbers

In 2014, just over 89% of our changes were performed outside of the “regular” change window. The trend for 2015 remain nearly identical.

Those numbers mean that we’re (re)negotiating change windows with stakeholders 9 out of 10 times. We’re creating justifications and requiring “off-cycle” approvals 9 out of 10 times. Talk about overhead!

The key to this process failure and resulting overhead is that we haven’t tied change windows to the actual business. We didn’t engage stakeholders to determine when is a good time to make changes for the business. However, in our complex environment doing so isn’t straight forward. We have a multitude of different clients, stakeholders and services. Boundaries often overlap.

Reducing the Friction

We can consider focusing in on major services, identifying stakeholders and establishing regular change windows on a per-service basis. This probably makes sense for the major services but what about the smaller, less visible services? What about services with a single stakeholder? How do we document each change window? How do we enforce changes to a particular service within that service’s specific change window? I don’t know…. but my short-term recommendation is to simply ditch the idea of regular change windows unless we can do them right. Why are we bothering with rubber stamp approvals for scheduling on 90% of changes when we’re going to talk about schedule in CAB anyways? What are we gaining from this?