One of those things you'll alway hear me say is that "you've got to eat your own dogfood".

For the non-tech industry people among you, the saying means that you need to use the products that you create. Only then will you appreciate the pain points your customers have with your product.

I have been dogfooding Ticket Agent for some time. While the app is far from complete, it's definitely in a state where I have been using it to manage the development of itself.

Dogfooding the app has resulted in many user experience (UX) changes, many of which should improve the product.

In my main web site, one of the big pieces of software I mention that I use is Fogbugz. Fogbugz is an excellent bug/issue tracking app that is designed for and used by software developers. In my mind, it is leaps and bounds better than JIRA, the main player in the market, but that's just my opinion.

I use Fogbugz a little differently than most of Fogbugz' customers. I use it as a services/work management tool, which it easily handles, but isn't its most optimal use. I am almost at the point where I can stop using Fogbugz completely, and replace it with Ticket Agent. That's a huge step for me.

I also mention on my main web site that I use Evernote quite religiously, but about 20% of the content I store in Evernote doesn't really belong there, but is there because it's convenient. I should be moving that content over to Ticket Agent some time soon.

So no matter what happens in terms of Ticket Agent's success, I think I'll be happy that I've built a tool that truly scratches my own itches, and is something that I'll be proud of.

A big chunk of the back end has been written. The hard part, believe it or not, is the front end, which I have begun development in earnest.

I have this love-hate thing going on with Gantt charts. In small-to-medium sized engagements, my experience is that they're a nice pre-sale showpiece that get tossed for an Excel spreadsheet once execution begins.

Why is that? I tend to think a couple of things are at play.

First, Gantt charts look great at the outset, as you get a nice visual overview of the work at hand. The problem is that maintenance of the chart becomes a major piece of overhead as the inevitable scope changes make their way into your project. Clients don't like to pay extra for a high priced PM (keep in mind, smaller services firms don't have project coordinators to do the monkey work) to be making changes to a Microsoft Project file. Project Managers don't like to be bogged down with time-consuming trivial edits to the Project file, when there are more critical day-to-day issues to tackle. In other words, it's a lose-lose maintenance situation.

Second, Microsoft Project files, with their Gantts, become hard to consume once the project starts. As one Project Director once told me, they're "too hard for the client, and you always end up going back to passing spreadsheets back and forth." Someone I know was recently working with his client's "seasoned" project manager on a plan, and that project manager had absolutely no clue how to use Microsoft Project. Exchanging Project files can be a pain, especially if someone is using an older version. Excel, on the other hand, is ubiquitous and everyone knows how to use it.

So these two points explain why Gantts are not on the near-term feature roadmap for Ticket Agent. If anything, it might show up as a reporting option, but unlike many other SAAS work management tools, it's not an integral piece of the puzzle. This is a philosophical thing. I'm not trying to create a "me too" product. Contrary to how Microsoft does things, a piece of software can't be everything to everyone. There are many excellent Gantt-based SAAS solutions, I'm not trying to go after that market.

Ticket Agent is designed to be a "back to basics" project management for small-to-medium sized projects. You aren't expected to be a PMP/PMBOK type of person to run the project. You have projects, deadlines, and units-of-work (i.e., tickets) that need to be completed. Ticket Agent will help you create those status reports that you hate creating on a weekly and monthly basis.

So it's been a while since I've last posted. A long while. It's been intentional.

As some of you may know, I've been working on an app, tentatively called Ticket Agent. I'm hoping to make this a widely available SAAS (software as a service) application for work management.

I'm quite aware that the work/project management space is a crowded one in the SAAS area. The most dominant player is probably 37signals' BaseCamp. It's an excellent product. Ironically, listening to their audio version of their book Rework inspired me to build my application. It's been an application in my head since maybe 1998, and I never got around to building it.

Some history: Many, many years ago, I worked on a Web 1.0 product like Basecamp but a little too far ahead of its time. We released it as a free and rentable multi-tenant product, but this was in 1998, and the idea of SAAS barely had any traction. Needless to say, the product got killed, and that was the end of it.

So I've been fleshing together Ticket Agent over the past few months, and of course, there have been bumps along the road. It started off as a LAMP stack app (Linux/Apache/MySQL/PHP for those not in the know) and has evolved into a Ruby on Rails / NoSQL (MongoDB) app along the way.

The major platform pivot resulted in me wanting to take advantage of the cloud services available, and the change to a NoSQL database was driven by the idea that I didn't want to be saddled with database schema migrations every time the data model changed. Perhaps I'll talk in more detail about my database decision in a future blog post.

In any case, back to the app. The application is a "ticket" based application (hence the name). While most people will associate tickets with an issue or bug tracking app, I took the philosophical view that a ticket is the best way to assign a unit of work to a team member.

I mean what's the real difference between a ticket and a task other than the ticket number? Not much, really.

Being a ticket-based system, however, isn't the differentiator for the application. This application is designed to scratch an itch I've had working on and running projects. The primary problem I've had is status.

I hate compiling team member status reports into client status reports. I've used various systems, including BI tools like Cognos, but there was always just a little too much work involved with that. Add to the fact that most consultants hate doing status reports themselves. So then as a manager, you're stuck cracking that whip chasing people down for status reports and then spending time compiling them into reports that your clients can consume. Not fun at all.

But it's not just project status that's an issue. Here are some of the time consuming status items that a typical project manager needs to keep up on (in no particular order):

• Where are my team members today?
• What are my team members working on today?
• What is the progress of what my team members are working on?
• What are the upcoming deadlines (or milestones) for my company?
• What is the status of all of my active client projects?
• Which of my team members are best using the Ticket Agent application?

The last point is a little interesting. As with any application, end user adoption is an issue. You could have the most usable system, but people may still not use the system. I have a solution to help address this, but it's a "secret sauce" idea that I'll hold back until closer to release.

From a design perspective, my goal is to make the application feel more like a GTD (Getting Things Done) application than your typical project/task management solution.

Well that's all I have for now, but I'll finally start posting more regularly to let you know how development is going.