The Before and After shot

Leave a comment

One way to show change on a project is with the Before and After shot.

before

after

You might do this if you inherit a project and you discover it’s bigger than the sponsors originally thought. Or after doing an inception deck and you discover some stuff that was originally missed.

The nice thing about this picture is it’s highly visible or colored. Red can mean new, or bigger than we thought. And the new number at the bottom quickly quantifies the difference and hopefully resets some expectations about what this project is going to take.

War story – Resizing projects

4 Comments

Sometimes you inherit undersized projects. It’s not your fault. You weren’t there for the original estimate. But it’s your baby now and you’ve got to set expectations.

I had to do that recently. I suspected the project was bigger than it looked (thankfully we hadn’t started yet). I did an inception deck with the team and all the sponsors, and lo and behold – it was bigger than anyone expected.

I had to deliver some bad news.

Here is a sanitized form of the letter where I explained to the sponsor why the numbers were what they were, and why the team didn’t feel like it would be safe to go with the lower more aggressive numbers.

Hi Mr. Smith,

After sitting down with the team, and going over the estimates, the team’s best guess is that XXX Project is in the neighborhood of:

325 – 490 days with a strong feeling towards the higher number.

estimates-as-range

I asked the team if there were areas we could simplify, cut back on, or reduce size in, and was cautioned against the lowering the numbers.

The fact that it is:
– A cross cutting project (lots of stakeholders)
– Distributed team (x3 cities)
– There is no in-house expertise
– Many first times (never done x, y, or z, etc)

tilts the team towards believing this project be slow, with a good chance of surprises along the way.
It’s big. And the team feels there is little risk in finishing early ahead of schedule.

Let me know if you’d like to get together to look at options on how best to present this number and how we should proceed with the budget and schedule.

Jonathan

Actual vs Original Estimate

original-estimate

actual-estimate

Unpacking it

There’s a lot going on here (and a lot of missing context and background behind the project). Don’t worry about that for now. Here is what I wanted to share:

1. Estimates as a range.

Even though the original estimates were in days, I like showing stakeholders than when we first give estimates, we don’t really know upfront how long things are going to take (see Cone of Uncertainty).

By showing the estimates as a range, I convey that sense of uncertainty, and it’s a nice lead into Agile planning where I explain how I will soon be able to tell him the exact date.

2. Why the higher number.

This project was about as risky as they get. It was cross company, brand new work with no inhouse expertise, spread across three cities. Nothing in this project was going to go fast, and I needed to alleviate the fear that by some chance the team might finish early and not need the extra funding.

We owe it to our sponsors to be as transparent and visible with regards to where these guesses come from. So I always try to frame it in ways they understand.

3. Actuals vs Estimate.

This project missed a lot of important stuff first time round. That’s why those boxes are red. They represent new stuff (or scope). I like highlighting this and making it really visible, so people can see and feel the size difference. On some ThoughtWorks projects we would use bubbles to actually represent the size to make it feel even more visceral. But you get the point.

That’s it. I just wanted to share this letter/email. I find when writing these it’s best to be clear, simple, and straight to the point.

It’s never fun. But it needs to be done. Bad news early is the Agile way and the sooner you let your sponsor know their project is in trouble the better.

Good luck!

The NOT list

Leave a comment

Imagine two of your best friends are about to go on a blind date but each was wildly different expectations around how the date is going to go.

Unless you or someone steps in a resets some expectations someone is going to disappointed.

What if instead of proceeding as if everyone was on the same page, you step in and lay down some grounds rules BEFORE the big night. Specifically, you make it clear certain things are off the table.

Now before the date even starts both parties can decide is this date is even worth pursuing.

That’s the idea behind the NOT list. A clear, simple, unambiguous way to set expectations around what you are not going to be doing on your software project.


The NOT list

The NOT list is about making it super clear what’s in (and even more importantly out) of the scope of your project.

IN the big rocks we need to move on this project.

OUT stuff we are going to ignore. It’s off the table.

UNRESOLVED things we still need to figure out. Ideally would move these to IN or OUT before the project begins.

This doesn’t mean the scope isn’t going to change, or we aren’t going to discover things along the way. It’s simply a stake in the ground that says: “No matter how bad things get, if we do these xyz we are going to be OK.”

With a solid NOT list in hand, story writing now becomes a breeze.
You and your team can focus only on the really big rocks and forget everything else.

To learn more about the NOT list, and nine other questions you’d be crazy not to ask at the start of your project, check out the Agile Inception Deck section of The Agile Samurai.

%d bloggers like this: