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.

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.

Without further ado…

If you build software for a living, you surely have eaten these words at least once. My last major utterance was about two years ago when I said to Jason and Bruce, “How hard can it be to build a project management tool that doesn’t suck?”.

I said it about the time we had just finished sending the top 80 people in Expedia’s technology group through estimation training at Construx. The training was based on work by Steve McConnell and later published in his book, Software Estimation: Demystifying the Black Art. If you are a software professional, this book is required reading. Go buy it now, then come back here.

What we discovered is that almost any team, from buttoned-down waterfallers to die hard Scrum fans, can improve their game significantly by doing just one thing: they need to stop using single point estimates (eg. 10 days) and start using ranged estimates (eg. 5-15 days).

Ranged estimates rock because they acknowledge and capture the uncertainty that exists in our projects. If you don’t capture uncertainty, it will lurk like a silent killer in your projects; as we like to say around here, you can’t manage what you can’t see.

This idea of estimating in ranges caught on quickly at Expedia, and you can probably guess what happened next. Teams ran to Excel, because “how hard could it be to build a task list that uses ranged estimates?” It unfolded the way building project management tools in a spreadsheet always goes - a happy start that turns into a slow agonizing death as some poor soul gets stuck trying to maintain a beast of a spreadsheet for the whole organization. You get a tool that does not scale, is hard to use, and nobody trusts. It also turns out that you need something a wee bit more powerful than Excel to do probabilistic scheduling in real time.

So, how hard can it be to build a radically new scheduling engine and drop it into a breakthrough interface that treats project management as a social application? Uhmm… pretty hard. It took us 14 months from concept to V1.

Please enjoy LiquidPlanner for free during our public beta and let us know what you think. We love feedback and if you happen to find a problem, we’d be happy to fix it in 5-10 days (give or take).

Charles.

p.s. My deepest and sincere thanks go to the LP team for making V1 happen: Adam, Asha, Barney, Bill, Brett, Bruce, Bryan, Christa, David, Jake, Krishnaveni, Liz, Marisa, Melinda, Murat, Rob, the team at Cypress Consulting, and of course my co-founder Jason.