We’re getting into full swing here at LiquidPlanner. The application is pretty solid, there are a few features we’d like to add (aren’t there always), but for the most part it is ready for prime time. So we’ve been beating the bushes to get some of our better beta customers to sign up to actually give us money. This is a big thing. While people are willing to put up with quite a bit when using free software, if they’re willing to pay for it that really says something.

But there’s one thing that’s been bothering me during my conversations with folks about what they want from a project management tool. They are looking for a new tool because their projects are out of control, late, over budget, under scope, or… well… let’s just say that if there is a way that things can go wrong someone somewhere is experiencing that particular flavor of train wreck. Almost uniformly what they want is a tool that they buy, turn on, and magically their problems are solved. They want a silver bullet.

There are no silver bullets.

No tool or piece of software can make you more efficient or better at what you do unless you change the way you do it.

This isn’t some great revelation. I’m certainly not the first to say it. It continues to amaze me how many people say, “Our projects are not running as well as we’d like so we want a tool to help and we don’t want to change anything.”

If you don’t change your behavior then things will stay the same. A good tool helps you (and your organization) understand what needs to change. A good tool shows you the effects of any changes you undertake. But notice, the tool doesn’t do the changing, you do.

When I was a kid I was into ski racing. No really, this is relevant so just stay with me.

Anyway, I knew I had a problem with starting my turns too late. I knew it because my coach said so and my times were slow and not improving. Then one day a better tool showed up. The coach brought a camcorder up to the hill.

He would record us coming down through the gates. At the end of our run we would watch the recording right there. And then we’d go up and do it again.

I swear to you that I was faster within the first two runs. I could see what I was doing and get nearly instant feedback. I made more progress in that two hour session than I had made in a month of the coach telling me what was wrong.

But the camcorder did not make me faster.

It wasn’t the tool, but rather the change in my behavior that made me faster. If I had said, “Just give me a tool that will make me faster but I don’t want to change the way I ski at all” the coach (and I suspect all of you) would have laughed at me.

Project management software is like that though. People are always looking to the software to adapt to their pathological, dysfunctional ways of executing projects. They don’t want to change the way they do projects. If you don’t change the way you’re doing things you will continue to have the same level of success (or lack thereof).

There’s a great list of 50 reasons not to change that sums up just about every one that I’ve ever heard. Thanks to Raven for pointing this out to me.

In the process of building our online project management software I got to thinking about what online has to do with project management. The fact that LiquidPlanner is multi-user and web-based creates a whole new set of interactions that go way beyond what desktop project management software does and has to cope with. For starters it acknowledges that project management is a social activity.

It comes as a surprise to some folks that I say project management is a social activity. They typically think of it as something done with software to generate schedules, or with change management tools, or with budgeting tools; they think of it as something technical. Tools like Microsoft Project and its online clones were born from standalone desktop software and so they’re firmly rooted in single-user behavior. In fact, they only place a thin veneer of multi-user functionality on top of the Gantt chart and guesstimate paradigm. In effect they deny that project management is a social activity.

But project management is about people making commitments to other people to work with still other people to get something done or built for perhaps some other people. Project management is about people. If that’s not social then I don’t know what is!

Still the tool set that most people work with does little to get folks to work together in a productive little mini-society. When you have one project manager controlling the scheduling tool and workers being held accountable to wild ass guesses that were made by someone who “used to do this job 15 years ago” and who “really knew how to get things done back when things were hard” you are not going to get one big happy family. The tools strongly affect the culture of the project team.

Being an online tool for project management unlocks and brings to the surface much more of the social interaction that you see inside of projects. There are people out there that just don’t “get” why you build something like this as a web-based application. They are absolutely correct in thinking that maybe you don’t need your single user text editor as a webapp. But then the thinking stops there.

It is like saying, “I don’t understand why Facebook is on the web, it should be stand alone desktop software so it performs better.”

Sure, the data transfer and the user interface would perform faster. But perform better? Perform what better? Perform social activities better? Gimme a break!

These folks think that we’re just reinventing the MS Project wheel on the web.

But we’re not. We’re building social software to enable healthy projects.

That means LiquidPlanner needs to be on the web (not just passing data over the internet). LiquidPlanner needs zero installation barriers so anyone can use it to actively participate in project management. LiquidPlanner needs this for the same reason that any social application needs it; because it is the lowest barrier way to get good social interaction.

All of which comes from simply acknowledging that we’re building social project management.

On Monday I attended an Executive Breakfast put on by Construx Software. Steve McConnell, renown author of books like Code Complete and also one of our advisors, discussed the “10 Deadly Sins of Software Estimation.” Not surprisingly, most of the audience chuckled knowingly after each “sin” was read aloud. And even as one of the few non-developers at LiquidPlanner, I found many parallels to the stuff that goes on in marketing projects I work on.

The very first sin actually struck quite a chord: Confusing Estimates with Targets. It’s not uncommon that people use the word “estimate” when they really mean “target,” or maybe even “commitment.” Here’s the kind of dialogue that goes on quite often in project meetings.

Project Manager: “Chris, how long do you think it will take you to make that change?”

Chris: (on the spot) “Umm. Hmm. Maybe four days? Maybe six?”

Project Manager: (scribbling away) “Great, gotcha. So Tim, how long will it take you…..”

Wanna bet that the PM wrote down four days next to that task? Wanna bet that Chris didn’t really think about what he might be signing up for when he “estimated” that task?

Say you have a project that needs to be completed by June 1st — that’s your target date. What do you do next? Do you create a work breakdown structure, estimate your tasks, and hold your breath that the schedule says you’ll finish on time? If not, do you go back in and reduce all your estimates, just so your dates match up?

That kind of habit seems to be a pretty clear recipe for failure. By clearly separating estimates from targets or commitments in your project plan, you can set expectations up and down the chain. If your schedule says you’ll run over, you can have a real conversation about cutting features, adding resources, or maybe even the need to plan for overtime. (In LiquidPlanner, we use “promise dates” (denoted by the diamond symbol on your schedule) to set targets, and ranged estimates to create schedules that capture uncertainty.)

Managing project schedules is really about the iterative process of bridging the gap between the target date and the estimated completion date. Kudos to Steve for bringing to light the fact that this is more than a semantic difference.

We’ve launched dependencies!

Last night the team stayed up late making sure that the update to the site went smoothly. This morning our users were greeted with dependencies. This is a big deal for us as we were getting quite a few requests for dependencies. In fact, several people asked us why we launched without dependencies. I thought I’d take a minute to talk about that.

I have a love/hate relationship with dependencies. When we designed LiquidPlanner we realized that when you put all of your tasks in priority order you just don’t need that many dependencies. The reason being that if Task-A needs to be done before Task-B you just drag it up above Task-B and (provided they’re assigned to the same person) Task-A gets scheduled before Task-B. So if you slice your big projects up into small enough pieces (say by doing Scrum with one month sprints) then the whole “need” for dependencies just gets a whole lot less urgent.

We have been using LiquidPlanner to plan our internal work since about April 2007. It is now a year later and we have added dependencies, but we never really missed having them. In fact, one thing that dependencies do is make your project plan brittle. They make it hard to alter the plan without breaking a dependency or messing something up. That is not to say that the project can’t change easily, just that the project plan cannot. This is kind of an artificial penalty for updating your plan to reflect changing reality.

I am all for moderate use of dependencies to build project plans. But I think that products which demand that you put a bunch of dependencies in place in order to get a halfway sane plan have trained many project managers to bad habits. They’ve become addicted to dependencies. And the more you use dependencies to solve your scheduling problems the more brittle and hard to maintain your project plan becomes.

So before you add that dependency ask yourself, “Do I really need this?”

Because if you can just prioritize the work earlier then you’ll end up with a schedule that is much more flexible and resilient to the change that inevitably occurs when a project plan meets reality.

I first heard the phrase “eat your own dog food” while doing some vendor work for Microsoft. Although I’m not sure why — none of the development teams I worked with used Visual SourceSafe, perhaps because it was an acquisition product. I also never saw a PM pull up a Microsoft Project plan on their laptop. More on that later.

Although I like to think of it now as steak tartar, we’ve been eating our own dogfood at LiquidPlanner from the beginning. I wish I had screen shots of some of the scaffolding UI that we had early on. Thanks to our uber-talented development team, it made a quick evolution to what you see today. This philosophy of also developing for ourselves has uncovered hundreds of opportunities –some we’ve responded to, and still others we’ve had to leave on the table for a while.

Deciding what to do next is sometimes tough. The night before our public beta launch at DEMO, my colleague Jake Gordon nailed it when he said, “We’ll know tomorrow what we need to work on tomorrow.” You gave feedback, we listened, and as a result, task dependencies will be in our upgrade to version 1.1 later this week.

I have to be honest – for a while, dependencies had fallen from the table to the floor. I’ll explain why as I beg you to consider carefully what you wished for and use the power of dependencies wisely.

Most of us on the development team have been forced to use or have willingly tried to use Microsoft Project at some point. One of the things we identified early on as a negative about the user experience was dependency maintenance. Because resource leveling sometimes behaved in unpredictable ways, hard coded dependencies were used to force logical scheduling. And Microsoft Project gave you an abundance of choices for types of dependencies, such as “finish -n,” where task B cannot start until task A is “n” days from completion. These types of dependencies falsely present themselves as reliable. In an uncertain world, you can’t always say that task A will finish in exactly 15 days, so how can you be certain that task B needs to start 5 days before task A finishes? For that matter, how can you say for certain that task B needs 10 days of lead-in time? Uncertainty is cold-hearted like that. The dependency above is actually not solving the real problem. It’s likely that task A needs to be decomposed further, because task B is dependent on some component of A.

Another issue with direct dependencies occurs when you need to move a chunk of work out of one project and into another. This is common for all types of projects. Just because you want to wait to do the fancy garden landscaping doesn’t mean you don’t want to do it at all. You’ll get around to it. Maybe just do the brick patio this go around. So you move that task or set of tasks into your project folder for Q4′08 … but if you have dependencies with items back in Q2′08…. I think you can see where this is headed. My prediction is you will next ask for a way to quickly delete all dependencies.

We honestly never missed direct dependencies in our development work, but we realize that we are only one data point. The automatic resource leveling / implicit ownership dependencies just worked in our case. In our small agile development team, we frequently are not working on our top task. We also don’t spend any significant amount of time moving items around in priority to reflect what we are working on. The idea is that even if you are context switching between three tasks, you still only actually work on one at a time and it all comes out in the wash. So if Jake needs something from me, he nudges me and then just works on the first task that’s not dependent on what he needs from me and life goes on. When we level set at mid-sprint, those items at risk are noted, adjustments are made and development proceeds. At the end of sprint, a decision is made as to the readiness of the whole feature.

We’re initially launching with simple Finish – Start dependencies. I can’t say for certain if more complicated forms of dependencies are on the table or not. It’s ultimately you who will tell me.

What is it about that number?

Next week, LiquidPlanner will be presenting at the Under the Radar conference in Mountain View. And just like at DEMO 08, we’ll have exactly six minutes to pitch the company, the product, and the business opportunity. (By the way, look closely at the rotating banner ad on the DEMO site to see a shot of Charles and Bruce in their on-stage glory.)

The audience? Press, investors, analysts, private companies, and other service providers. We’ll be sharing the “Work Together” session with our friends at blist as well as Cozimo and SlideShare. We’d love to meet you if you’re attending.

We have been asked frequently if LiquidPlanner can be used for tracking the small stuff as well as the big stuff. The answer is most definitely, YES. In this post, I’ll share how our team incorporates software bug tracking into our software development process.

In LiquidPlanner, projects are organized in order of priority; the higher something is in the list, the higher the priority of the work in the project. We use an Agile methodogy called Scrum that groups development work into one month projects called sprints. We use a project to model each sprint (i.e. Sprint 11 is higher priority so it gets scheduled before Sprint 12).

We also create sub-projects (prioritized buckets) for bugs and features, as well as some supporting buckets for untriaged and rejected bugs…

The cool thing is that now we are capturing a complete set of the work (features + bugs) for each sprint and we have one system to manage the process. Note that our team likes to prioritize bugs over features; this aligns with our principle that quality is more important than expanding the scope of the product.

Having separate containers for bugs means you can get analysis on bugs, features, or both by selecting the container of interest…

Having bug containers set up as projects is really useful. I’ll show you what I mean using the image below.

First, when we enter bugs we start the title with “Bug:” this allows us to find them easily with search (eventually we will put this kind of tagging into LP as a feature). We also estimate our bugs. Whoever enters the bug takes a best guess at how long it will take to fix and assigns it to the person likely to own it. The bug automatically gets a yellow flag telling the owner that someone else estimated it and they should confirm the estimate/owner.

We use categories in LiquidPlanner to manage functional areas so we can do things like keep track of the “bugs” in the “grid control.” Here is that that looks like…

Putting it all together, we have a system where our bugs are completely integrated with our project workflow and prioritization processes. The bugs are organized by feature and by sprint; when we lose track of specific bugs we can use the search feature to find them again.

Of course we also attach comments and documents to each bug, including repro steps…

We like having a lightweight bug tracking process integrated with our project management process because it gives us a better picture of our capacity/schedule, keeps us from accumulating bug debt, and lets us spend less time on process and more on getting things done.

It’s time for our bug triage meeting, gotta go.

“Round here, we eat our own dogfood.”

“You, uh… what?”

Interviewing for my job with LiquidPlanner late last summer, I was feeling a little over my head. I’m relatively new to the software industry and was meeting with really smart people who have years and years of software experience. And now they were talking about eating dogfood?!

What they were really referring to, of course, was using LiquidPlanner to build LiquidPlanner. And now, with a few months at the company and a successful product launch under my belt, I know why this is so unique, and so valuable.

There aren’t many industries in which you can use the very product you’re developing to inform the development process. Doing so has enabled us to find bugs before our users do, to test new features, and to see how changes to the UI appeal to different users. Not only are we capitalizing on the value of our product but we’re improving it at the same time, a very tasty proposition.

People who know me know that I like to have a plan, but I’m the first one to stray from it. This may seem like a strange contradiction or worse hypocrisy, but here’s my justification: if everything goes according to plan, the best outcome is limited to your initial imagination.

I’m not willing to settle for our “initial” imagination because routinely our best ideas come mid-stream during the project. If you are doing work where creativity counts and innovation is part of the formula, you might find that giving that creativity more room to breathe in your plan makes good sense. A great way to do this is with ranged estimation. We usually talk about a ranged estimate (e.g. 5 days – 20 days) as a way to capture uncertainty but it is also a great way to give room to possibilities in your schedule as well. Once you’re willing to admit that you can’t figure it all out up front, this gets easy, just ask your team to make the ranges a bit wider for things they have lingering and nagging thoughts about. You can always narrow it when you get closer but now you’ve left a bit of room.

With all this room in the schedule, why plan? Planning keeps us from getting lost and helps us stay focused on delivering business value. In our team’s case, that value is not always what we set out to do; sometimes it’s better because we didn’t follow the plan.

Of course because LP is flexible and eats changes for breakfast, our plan was smart enough to follow us.

Without further ado…