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.

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 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.

We just discovered Bas de Baar, also known as “The Project Shrink”… well… actually he discovered us. Note the interview he did with Jason recently. He has a lot of great things to say about people and project management and I recommend everyone interested in the subject consider adding his blog to thier RSS readers.

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…

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.