Project Planning, and response to Multi-Tasking is Killing Your Business

I met Bruce Henry at an MIT Enterprise Forum event last night. Turns out we're both working on software for project management. Theirs is Liquid Planner, ours is Project Auriga.

I'm a bit skeptical about their statistical approach to project scheduling... I definitely agree with giving estimates in ranges, but how is your approach that different? Aren't you depending on arbitrary guesses by the project manager users, to come up with those ranges and confidence values? I'd love to see how you're addressing this.

Regarding this post: Bruce's Brain: Multi-Tasking is Killing Your Business, my thinking in developing Project Auriga is that few of our projects are big enough to need a large project management system. What we needed is a task management system, a way of preventing any of the dozens of tasks we need to accomplish in a week from slipping through the cracks. And then making sure we're billing the right customer for finishing each one. Yes, we're multi-tasking, quite heavily. But then again, one thing missing from your multi-tasking post was context--you're taking a very project-centric view of work. There are other ways of optimizing work, which we deal with all the time:

• customer-centric
• system-centric

We manage around 25 servers right now. A few of them we use to host customer accounts. When it's time for a security upgrade, we might take our list of Joomla installations, and upgrade each one on a given server. Those tasks cross many customers and projects, but since they're all grouped into one place, we take a system-centric view of this work. So I'm creating a view that makes it simple for system administrators to go down a list and check off systems as they're upgraded.

Another reason to multi-task is that most of our projects have points where we must rely on outside input. Right now we have 3 Zen Cart projects, 3 Joomla projects, 3 new server installs, and 3 custom development projects that are highly active right now. We do a few tasks on one project, throw it over the fence to the customer, and when they've done what they need to do, it comes back to our plate. For example, one of the Zen Cart projects is waiting for the customer to regain control over their domain name so we can purchase an SSL cert and launch. The second one is waiting for the customer to give us a list of products to put into the calendar, and the third is on our developer's calender next week to do a custom payment module. Meanwhile, our ZenCart person is able to work on one of the Joomla projects.

I guess it's because software development is one third of our business, and our development projects tend to be small add-ons or changes to existing code. We're not really in need of full-fledged project management software--we're in need of a system to capture all the little tasks that need to get done, and make sure they get done and billed appropriately. Project Management, for us, is about identifying the specific tasks, dropping them on somebody's schedule, and approving the time spent before billing.

Liquid Planner seems to be about managing uncertainty. I'd love to see how they're attempting to do this--from our discussion last night, my impression is that the project manager estimates a range, and a confidence in that range, and the software then uses statistical calculations to quantify that into a figure to allocate on a calendar. But where does the range and confidence level come from? Isn't this still relying on humans, on experience, on gut instinct to determine? Does this really add a useful tool to help project managers more accurately determine how long a given project will take, or just more numbers and complexity without actually solving the problem?

My assumption is that it takes 12 months to gain a year of experience... Project Managers only learn how to estimate accurately by doing, and mostly failing, at a bunch of projects. Most of our tasks have been done before, we take measured steps into new territory and allow large margins for error. For our developers, tasks get scheduled up to 75% - 6 hours of any 8 hour day. For large projects, the project manager leaves a few days unscheduled at the end of the project, to allow for the inevitable overruns.

For our sysadmins, who always have stuff to do that comes up each day, we schedule tasks at 50% - 4 hours of each 8 hour day. We add meetings, time off, holidays, etc to the scheduling system so that projects get scheduled around those known interruptions.

I had a client suggest that when presenting an estimate, give the high number first--we're wired as humans to listen for the first number and take that as what it's going to cost. Then we can give the factors that might make the project take less time, cost less. Auriga doesn't try to estimate for you--it simply tracks your estimates, and tasks. We put the high number of our estimated range into the system for scheduling purposes, and try to beat it. That's also what goes on the sales order, and unless there's a clear change to the scope, that's the most we bill. Project Auriga helps us know when we're going over on a project, helps define how far along we are on a project, and makes our project management transparent to our customers. But it's no substitute for an experienced project manager--it's just a tool to keep details from falling through the cracks.

While there is plenty of value in having great tools, I've always detested technology that takes more effort to learn how to use than it takes to solve the original problem...