By Peter Bell

The Importance (to us) of Project Tracking

The idea behind the theory of constraints is that it can often be helpful to look at a business as a "value stream" - a set of tasks that are performed that add value to your clients. And that at any given point in time there is a single limiting constraint that if you lifted it, would improve the business the most. Think of a water pipe. If you want to pump more water through a pipe without having to increase the pressure, you need to find the narrowest part of the pipe (the obstruction) and widen it. Widening the wider parts won't increase the flow - you need to find the primary obstruction and lift it. Then you will have a better flow and will find a new primary obstruction that you can work on lifting. Similarly with a business, you look at which part of the value stream is currently at full capacity or otherwise stopping your business from being able to increase the quantity of projects you're undertaking and if you remove that limitation, that is the most efficient way to increase the efficiency of the business.

Every business will have a different limiting constraint at any point in time. For a software consulting company it could be things like their capacity to sell projects, spec them, build them or test them. For us, where we often have 20-30 projects live at any given time, the limiting factor is project tracking . . .

For most consulting businesses with a relatively small number of relatively large projects, project tracking (being able to easily see and manage the status of projects) is important, but it isn't usually critical. However, because we handle a large number of projects, we probably spend almost as much time in switching costs (getting up to speed with projects each time we need to touch them) as we do in actually servicing them (the unintended consequence of the servicing being so efficient). I also find that often a project where we're waiting for input from a busy client can fall between the cracks for a while, and we seldom have a really good sense of exactly where we are at with all outstanding projects at any point in time. It's also been known for us to not invoice a project on completion and we have no really good metrics of things like our lead times from quote to spec, spec to build, build to deploy and other interesting metrics from a lean perspective.

One of the things I'm thinking about right now is a system which is somewhat flexible (to support different project types), but that allows us to easily describe and implement automated workflows for projects so we can do things like track the amount of time clients were waiting for us and the amount of time we were waiting from them, so that we can automatically have reminder emails sent out to contacts (us, partners and clients) if they have outstanding tasks, and so we can automatically go through check lists when comps are delivered or when a site is about to be launched to make sure we don't forget to do any of the things (like purchasing and setting up secure certificates) that could slow down projects. I'm also thinking of adding automated invoicing to the system and the ability to see financial reporting such as amounts invoices, projects won/lost, etc to give a better ability to track the leading financial indicators and to more accurately set targets to help us to achieve future financial goals without having to spend time building such reports by hand.

Of course, I'd also want such a system to act as a central repository for client communications, client sign offs, project assets (comps, graphics, etc) and the like to provide a "one stop shop" for all information related to client projects (and aggregate reporting on a partner level).

Anyone else been played with building a system like this? Any thoughts/experiences? Would you like a system like this? What would YOU like in a system designed to improve the efficiency of building web apps? Any input appreciated!

Comments
It seems like this is a common theme. We (Savvy) have gone over and over about how to deal with it. There are some good project trackers, but they don't do time tracking. Or they are usable for only a small number of projects in a given year (not built to effectively manager more). Some are hosted solutions which not all can use, so people build their own or plan on building an OS one that never sees the light of day. On top of this having an issues tracker would be great! And the ability to identify if the client has prepaid for issues or if they are to be billed or it is gratis. Not a requirement for many, but a big deal for software companies.

I have found http://projecttracker.riaforge.org/ to be pretty handy but no time tracking at the moment.

http://www.vertabase.com/tour_manage_report.html Vertabase has a hosted solution (CF based) though I haven't used it. In fact they are hosting a BOF CFML future at Max http://www.vertabase.com/blog/your-ideas-for-the-f...

As for the invoicing, I am skeptical. It would be handy to see what has invoiced and not invoiced. What has been paid or not paid and how old. But I would expect that invoicing actually comes from quickbooks or some other system.

The toughest part for me is timesheets. I hate them but they are needed to track hours, and as you have mentioned in past posts track estimated vs actual. Did that CSS change really take that long??? etc. Having an AIR app on the desktop to help track that would be super, and I think some of the company solutions are going in that direction now.
# Posted By joshua cyr | 10/28/08 9:49 AM
Yes, between 1999 and 2007, I built and expanded and grew such a system for a small custom web app shop. Great idea, and from what I see out there you can't really cover all the necessary bases with most of the off-the-shelf packages. We tracked sales leads through requirements gathering, then spit out actual PDF proposals from the requirements, and then we tracked time against the projects and even the requirements, triggered billing reminder emails (invoices were created in QuickBooks), and captured constant project status all the way through deployment and maintenance. In addition, we attached full file management for creative and project resources as well as fully interactive message boards per client and per project, which allowed threads to include both client posts and internal-only discussions even in the same threads. All these data points could then feed a customizable dashboard for each user (developers wanted to track different changes in the system than account execs, etc).

Last but not least, we built a full IMAP client into it (CF consuming Java sendmail ftw) and allowed incoming emails in anyone's mailbox to be quickly converted to a calendar appointment, a project task, or even a message board thread, which really cut down on the whole "who has that critical email from so-and-so client??" thing.

Highly recommend such an approach, particularly for situations where many projects are in process at one time, which is exactly what we had, too.
# Posted By Jason Fisher | 10/28/08 10:33 AM
@Joshua, Agreed. Tried a bunch of systems. Not yet got what I wanted. Agree the AIR piece would help.,

@Jason, Yep - this is the direction I'm going in as I see the ability to use such a current system could be a competitive advantage and therefore something that you wouldn't want to outsource/use off the shelf.
# Posted By Peter Bell | 10/31/08 8:26 AM
@Peter,

We simply started with Client > Project > Status. That was right when we started to hit that "I can't keep this all in my head" stage. Over time, we added Requirements > Tasks, and then with Tasks, why not also Appointments (both were Calendar events). Once we had tasks, it was easy enough to add Time Tracking, and once we had Projects it was easy to add Message Boards to every project and client ... etc.

Basically, because project management and development are so clearly flow-driven, it was fairly effective to allow the management framework to grow organically as the "next big need" arose. Best of luck with getting started :)
# Posted By Jason Fisher | 10/31/08 8:47 AM
@Jason, Thanks - it's something I've played with a number of times and have started on specifying a number of tyimes, but I think this time I'm actually going to get it finished up as it's really going to help with scaling the business. As you said, doesn't need to be BDUF mega project - just a feature, and then another one - kanban style.
# Posted By Peter Bell | 10/31/08 9:05 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.