We are a week behind our original target release date but we are pretty happy with the sprint. Assuming nothing comes up with our final testing, the new code will be available by this time next week.

Of course we use LP for managing everything. Above, you see our workspace showing the total work for the release (features, bugs, operations, and loose ends).

Let’s see what we can learn from the work trending:

Some of the obvious stuff is that we pre-loaded the sprint for over a month before starting work. Remember these graphs show total work in the project containers. That takes us to the first peak at which point we were overloaded and red flagged. We had the planning meeting, cut scope and then started working on the sprint (green part).

For this next part, it helps to understand the Cone of Uncertainty. If you don’t know about this, I recommend you take a minute to follow the link to the Construx site. Here is the short verion: its a way to think about what should happen to uncertainty as you work your way through a development process:

Laying the Cone of Uncertainty on our actual results is interesting. Anything stand out? Perhaps that big surge of scope creep in the middle?

It’s exactly what it looks like. We added work when we were not supposed to, we under-estimated a couple of things, and we didn’t plan enough time upfront for working on bugs found during the sprint. Heck we rode the whole sprint with those red flame icons staring at us in the face. We had to make a few cuts and work a few weekends, but at least we had full optics and a lot of fun the whole way.

Anyway, you’ll have the new code soon. Here is a peek at one feature, the new bulk add:

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.

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.

I’ve been doing a little bit of usability testing recently and stumbled on Morae from the folks at TechSmith. They’re the same folks that make Camtasia and my favorite piece of utility software SnagIt.

Now I’ve sat through a couple of usability studies in my time at Expedia but I never really thought through how the heck you go about capturing and scoring all the feedback that you get during a usability session. I’ve gotta say, Morae has completely exceeded my expectations for things like ease of use and intuitive interface. I guess one would hope so since they do make usability testing software.

The general idea is that you write a simple set of tasks that you want the user to try to perform. Then you record several people doing them (or trying to). The recorded files can then be pulled into a manager application that helps you score how the easily the users performed the tasks. You can also get timing information about how long it took them to do the tasks and a whole buncha other automagical data capture like mouse movements, clicks, keystrokes, pages viewed, time between inputs, etc.

There’s more data there (fo’ free!!) after recording a session than I’d ever know what to do with (okay, I exaggerate, I’m a total data junkie). But you get the idea.

Anyway, I have nothing but good stuff to say about this thing. The tool itself is so cool that I’m actually looking forward to doing some more usability testing.

One word of warning; Watch the demo videos! I’m not kidding, you’ll miss a good half of the awesome that is this product if you don’t. While the basic stuff is pretty self-explanatory, there’s all kinds of features for tagging parts of the video of the session and for scoring how the user was coping with your application (or whatever) that you’ll totally dig once you figure them out. And the videos really help get you up and running fast.

Well, I’m off to SXSW this week. If you’re going to be down in Austin feel free to look me up in the SXSW member directory and hit me up for drinks. I’m buying, but you’ll have to sit through a 20 minute LiquidPlanner usability test.