Organization is a big deal at Iron to Iron. One of our founding principles is to be as efficient as possible without degrading quality in the least. We do that using a formulated process in conjunction with a toolset that assists us with our tasks. One of our solutions is activeCollab, a self-hosted Web application that helps us manage our projects. If you’re familiar with Basecamp, activeCollab is a piece of software similar of Basecamp you’re able to host on your own server as a way of not paying a monthly overhead. Without going into too much detail or design zealotry, we’ve used activeCollab for some time now and are pleased with what it helps us achieve concerning day-to-day organization and communication.
We feel that project management software is an essential ingredient for succesful client work. Email is sloppy, phone calls are inconvenient, and people in general (ourselves included) are both forgetful and disorganized. Project management software for us is a shared email client, calendar application, and notification center that leaves responsibility up to the people using it.
We’re very up front in conveying our perception of activeCollab to clients through explaining the role we see it filling throughout the project. Unsurprisingly, clients have sometimes resisted wanting to stray from their familiar (and forgiving) email communication policy, but we’ve heard “the email excuses” far too often to let that slide. If a client insists on not using activeCollab, we’ll go out of our way to copy and paste their emails as new threads in activeCollab and repeat as necessary. It may sound distrustful, but it’s not. We simply want to remain accountable and organized and having a public space to do so is one of the only ways to accomplish that.
Project Management software is only as useful as you make it. There are tons of features in activeCollab that we haven’t fully utilized yet. For example: Checklists & Milestones. Checklists are mostly self-explanatory, but to elaborate: activeCollab allows you to create any number of Checklists with Tasks assigned to people within them. Additionally, you can create Milestones in the system as well. They facilitate the creation of date-based checkpoints within your project to help ensure you’re on schedule to meet any deadlines that have been put in place.
While these features are well and good on their own, activeCollab has some bits of helpful UI scattered throughout that reference these items and give you an overall feel for the progress of the project as you’re perusing the submitted content.
Trouble for me personally arrives when you have other (possibly better or preferred) systems for keeping track of what’s left to do and when you’re going to do it. In that case activeCollab and therefore your team nor your client, have any idea how far along you are with the tasks at hand. I’ve been struggling with how to better utilize activeCollab to not only give Kevin a better overview of where I’m at with tasks (and vice versa) but possibly most important: the client as well.
In my case the particulars surround a daily ingrained pattern of using OmniFocus for (personal) task management, and comparing that to using activeCollab for business (public) purposes. I realize that this entire article can be responded to with a simple suggestion of ditching OmniFocus in favor of using the centralized (likely Web app) system I’m after, but I digress.
OmniFocus is The Collector
I’m a long time user of OmniFocus and at this point it’ll be a frozen day in h-e-double-hockey-sticks before someone prys it from my cold, dead fingers. I really enjoy the workflow that comes with the GTD process and it’s helped me to be targeted with my time. I’m sold on it being a native application especially given the fact that I use it in slightly different ways depending on whether I’ve got my computer, my phone, or my iPad.
I’m at a crossroads though: is it better for only me to know everything about what I’m working on by sticking with my very personal and personally preferred system, or better to foster an essential ‘team’ aspect of a project. Naturally team cohesiveness is more important than selfish preferences. There’s got to be a way to accomplish both, right?
Single method of capture
They key point here for me is to ensure that OmniFocus remains the one stop shop for me to brain dump into an Inbox. It’s the essence of GTD and one of the core reasons I feel that it works for me. activeCollab could accomplish this, but OmniFocus handles both my business and personal tasks so I wanted the activity of recording something to be second nature and require no prerequisite conditions to be met. I don’t want to have to conciously decide “this is a business related task, enter it in activeCollab” or “this is a personal task, OmniFocus it is”.
Further, using something like activeCollab for brain dumps doesn’t make as much sense. I can sit with OmniFocus for a half hour and think about anything and everything I’ve got to get done without worrying that there’s any sort of permanence to my submitting an action. With activeCollab things are designed differently, you add a task and it’s meant to stay there until it’s done. It’s much less for “note taking” if you will.
With an established Inbox routine, it goes without saying that at any given time my Inbox could have a number of items that should be listed in activeCollab. How should that be handled? Managing two separate lists is completely counterproductive and they’d rarely (if ever) mirror one another.
My goal with task management is to remain accurate to the real-world circumstance surrounding the progress of a project. Checking off 23 tasks within a minute or two of one another because I was only keeping track of their status in OmniFocus doesn’t help anybody, it just floods inboxes with notifications from activeCollab. A flood of notifications are much less likely to be read, resulting in frustrated clients asking questions that should have been answered by notification emails and is therefore now frustrating you.
One way to go solve this issue would be to assign a Context of activeCollab when entering the item into OmniFocus. From there, when I clean my Inbox I can simply enter the task into activeCollab, remove it from OmniFocus, and be on my way. It’s a bit more work, but it leaves us with focused task lists. You’d need to include this step into your workflow, but you should be conciously reviewing your Inbox at periodic intervals anyway.
The biggest problem here is not being able to use OmniFocus to manage the completion of projects and therefore get an overall view of everything I’ve got to get done all at once. That would require a hybrid of switching between OmniFocus and activeCollab in an effort to gain a more high level picture of overall progress.
Additionally, instead of a flood of ‘success’ notifications, clients may receive a flood of new Task notifications, but in this case project management systems usually only send emails to those assigned to a task, removing the liklihood that numerous emails would be sent to a client (or co-worker) as you were migrating from OmniFocus into activeCollab.
activeCollab is The Communicator
The one thing OmniFocus doesn’t do well is be a team player; it wasn’t designed to be and honestly it shouldn’t be expected. That doesn’t remove this problem from my day-to-day workflow, though. In order for a system like activeCollab (or even Basecamp) to work effectively, it needs to be the hub of communication and it needs to be used consistently. The minute other tools are used is the minute the project changes course and opens the doors (wide) to miscommunication opportunities, even internally.
It’s important for me to keep in mind that the core issue is not that of communication in general, but communication of tasks. Do all tasks really need to be communicated? Personally I don’t think so. I try to keep a detailed log of what I need to do insofar as breaking down my workflow schedule on a per-screen basis. I don’t think Kevin or my client need to know that the markup for Page X has been completed, at least not during the initial bulk development cycle.
They are interested, however, in the completion of the dev site as a whole for example. At that point there’s a reaction to be made on their part; there’s something to see, something for them to do. To that point it doesn’t sound like the issue is as big as I’ve made it out to be, but it in a way comes back to the progress aspect, the communication of that progress.
Keeping these tasks communicated allows the team to get an instant gauge as to how far along the project is and intermediary notice surrounding whether or not a milestone will be hit. Of course there are nuances in how long one task will take versus another, but that comes down to your style of recording tasks in the first place. If you’re one to have “front end development” be a single task versus breaking things down further, this gauge will be completely useless to anyone but you who is actually doing the work. In essense you’re defeating the concept of a ‘progress meter’ anyway. When it comes to Milestones you should have enough of a grasp on your task list to determine whether or not your to-dos will be complete in time.
It’s tough for me to draw yet another line between tasks that should be completed versus those that don’t need to be. That’s the point at which I tell myself I’ve overcomplicated the issue as a whole, but I can’t stop thinking about it.
But what about Issues/Tickets?
To me, there is a significant difference between a Task and an Issue (or Ticket). A Task is something in the pipeline, yet to be started. An Issue is something that needs to be changed in an existing system. Tasks are created internally while Issues can also be created internally or submitted externally by the client.
Enter in yet another piece to the puzzle: GitHub (or version control in general). A number of our projects are hosted on GitHub, and their Issue tracking is a stellar feature in my opinion. In particular I’m a huge fan of commit messages being linked to specific Issues. The trouble therein lies with access to GitHub to submit the Issue in the first place.
I’m not going to request that a client sign up for GitHub in order to submit Tickets. They’ve already got an activeCollab account, and explaining the purpose GitHub would require an explanation of version control which leads down a rabbit hole of absolute worthlessness for a client. For our purposes, clients will be instructed to enter Tickets into activeCollab. Those Tickets count towards overall progress on a project in activeCollab, and it just makes sense for the Ticket Inbox to be there.
The only hope for an automated solution here is GitHub integration within activeCollab. It doesn’t make sense for me to copy over client submitted activeCollab Tickets into GitHub Issues, else we’re again dealing with the (destined to fail) management of two separate systems. Until GitHub is integrated, Issues will need to be left out of the mix to an extent. It’s not a deal breaker for me, as the Issue integration provided in GitHub is unique to them and not essential to a client service workflow in comparison to an open source project.
Luckily, activeCollab has it’s own Ticket management solution which I think will work well given the circumstance of it already being integrated into the software we use with our client and not needing to explain yet another system for them to learn and use. Tickets are something that can be managed in activeCollab and the act of logging in daily will remind me there are things to do for a particular project.
Chances are a Ticket will generate any number of tasks for me (to use in OmniFocus) that don’t make sense for the client to see anyway. That will allow me to see the Ticket notification, input the necessary tasks in OmniFocus, and when completed mark the Ticket as Resolved in activeCollab for the client to be notified.
At this point, I’m not quite sure where the solution lies
All this to say, I still don’t think this is a truly effective system, there’s room for improvement. I obviously don’t have a strong direction to take from here, so I’m opening it up for discussion in the only way I know how. I could be completely in left field with this circumstance I see as an issue and I truly hope so, I just can’t help but to feel like project management software could be doing so much more for us with not much more effort on our part.
The ‘obvious’ solution is to establish some sort of sync between OmniFocus and activeCollab where things simply happen IMAP-style automagically. I didn’t emphasize that much primarily in my outlining of the problem because I quite simply don’t see it being a reality for me any time soon. Continuing, I feel the issue is more generalized than that for me. Just trying to wrap my head around what would be involved in keeping two very complex and separate applications in sync for a very specific purpose doesn’t seem like an appropriate (even potential) solution at this point.
I can’t help but see this entire article as a brain dump of something that’s pestered me for some time, and as you can see I still have trouble articulating just what gets under my skin, but I’d love to see this problem solved or expunged as a uniquely personal issue of mine.
I think the core concept here is defining what truly needs to be communicated with a client through the life of a project. That can further be broken down in comparing the initial (and vastly longer) work period during initial design and development of a project to the testing, launch, and maintenance phases. Perhaps that’s the line to draw and the mark simply needs to be made, I can’t say for sure at this point. But I’d love to talk more about it.