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.

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.

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.

So, I stumbled across this quote by Sir Francis Bacon (you know, the guy who invented the scientific method) regarding the relationship between doubt and certainty.

If a man will begin with certainties, he shall end in doubts;
but if he will be content to begin with doubts he shall end in certainties.
- Sir Francis Bacon

It got me thinking because I this happens all the time in projects. And you know what happens when I start thinking… blog post. Yeah.

Oh yeah.

I want to talk about estimation, but first I want to talk about beer and wine. Specifically, the act of opening beer and wine bottles.

For about 2.5 years, we kept our bottle opener in our junk drawer, all the way across the kitchen from the refrigerator and pantry. And for 2.5 years, every time we opened a bottle (which was pretty often), we walked across the room to open it, then back again for a glass.

Then one day, I had a true lightbulb moment. I should keep the bottle opener in the silverware drawer! It’s right next to the fridge, right next to the glasses, even right next to the trash can. Think of the time it will save! Think of the convenience! Wow. Things in the kitchen have been better ever since.

How does this relate to estimation, you ask? Well, I had the same lightbulb moment when I was first introduced to the concept of ranged estimation. For years, I’d used single-point estimates like the rest of the world, hardly thinking a thing about it. I’d take a guess, pad it a bit for safety, enter it, and forget it.

But when I first got to actually USE LiquidPlanner (about nine months ago now) and build a project plan in it — and enter my estimates in ranges — suddenly a whole new world of project scheduling opened up for me. Estimating in ranges is actually considerably easier than estimating with single-points. After all, we think about time in ranges for most uncertain things in life.

With LiquidPlanner, I can see at a glance the best-case and worst-case scenarios for completing every task. For every project, I get a statistically-correct schedule. Now that I’ve tasted ranged estimation, I never, ever want to go back to single-point estimation. Not when there’s a better way.

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.