Today I’ll show you two different curves, why they’re different, and how you can use one simple visual aid to track your progress and encourage the right conversations.
Make sure you leave a comment to let me know how you’re going to use this in your own organisation.
Video Transcript and Relevant Links
Hey everyone, Danelle Jones here
Curves. Curves, curves curves! Today we’re going to be talking about curves! Super excited. So last week we did a whole conversation about the difference between value and benefits and then this week I promised that I was going to share some work around curves.
So, before we get started, if you haven’t watched the video from last week, it could be super handy to go back and just get your thinking straight around that one, and then come back and do this video as well. The last video is only about 3 minutes long, it won’t take you very long at all.
What I wanted to share today is a concept that I have found really really useful, over and over and over again. It’s this idea of graphing out your cost versus the value that you are delivering for a project. And so using a really simple visual tool, to help you understand whether you’re heading in the right direction, or whether you might want to take a different tact. So I have lots of little post-it notes and cards to share, I’m going to be drawing as we go, so let’s get into it!
So the graph I’m going to draw for you today is super super simple. It’s a graph of value on the vertical axis over time. So this idea that, over a period of time in a project we’re looking to deliver anything up to 100% of the value that we thought we’d get when we started on the project.
This works super well for IT projects but it will also work well for your other infrastructure type projects, it’ll work for a lot of what you do. But certainly in an IT project (sorry I’m going to try and get this on the right side) over time, we’re looking to spend money and so cumulatively we tend to spend in a straight line.
What that means is that, because, if you’re in knowledge work if you’re in any of those industries that are building knowledge or knowledge products – software delivery, those sorts of things – this works almost every time because the large part of your cost base is human capital. You might have some hardware to drop in here there and everywhere, but you can do that in stages and so ideally what we’re looking for is this straight line cost profile.
Now it doesn’t have to be that way, but for the sake of this example we’re going to use a straight line cost profile in each of the graphs.
So we’ve got our cost profile, that’s what we’re looking to spend on the project over time. Now, what does the value profile look like? Well, assuming that we have done our due diligence and we’re going to deliver something that is actually of value to our customers, in a traditional project, the value often looks like a bit of a ski jump, in terms of what you’re actually delivering into production that’s having an impact for people.
Over on this side, we start with a design process, we might do some requirements gathering, we go through a build process, we start to get into testing and at that point we think we might have something that potentially works and so we start to, I guess de-risk and have some confidence that what we’re going to deliver is of some use to us. And then all of the value, comes right at the very end – if you’re lucky. Sometimes that time needs to stretch out a little bit longer. But all that value is delivered in one big chunk right at the end.
Now this is a very traditional project delivery type cycle, what we wanna do is shift that up, so we want to be talking about delivering faster at less cost. We want to deliver more value, more often.
So what we want to be doing is that same cost profile, that same straight line cost profile, but we want to build something that looks a bit more like: an S curve. So that instead of getting all that value right at the end, what we want to do is we’re going to chunk the work down into smaller pieces, that can be delivered independently delivered and every time we drop one of those into production we’ve got some value being delivered.
And so this S curve, actually, is broken down into a whole bunch of pieces of work, that each deliver value, that each deliver something that we can use, that we can test, that we can get feedback from, that we can start to understand whether we’re heading in the right direction.
Pretty simple concept, as you can see, there’s a crossover point so once we start working this way, once we start breaking our work down into smaller chunks, and realigning so that we’re delivering value more early, we reach the crossover point in that cost/benefit graph much much earlier on.
So we might find that we get to 50% of the spend and we’ve delivered somewhere more like 60 or 70% of the value. Maybe we get to 70% of the spend and we’ve got 85, 90% of the value and we’re looking at spending the last 20% of our cash, to get that tiny sliver right at the top.
What this does, when we break work down into small chunks is it gives us pivot points. So that the point that we’ve delivered more value than it has cost us, we might choose that that’s enough. And so we can park that project, go and start to work on something else and not have to worry that we’ve half delivered or that we’re not getting value out of it because we’re tracking this the whole time, we’ve delivered something that is of value into production, it’s actually working for us, we don’t have to wait right to the very end to get it.
So, if you start to look at tracking these types of graphs for your projects, then we get a couple of options right? (it’s going to get me every time) So, if you see a graph that looks like this. What are you going to do? Well if it was my project, I’d be looking at that going “for every dollar that we put in, we’re getting about half a one out, like, that to me doesn’t look right, something’s wrong here.” Do we want to keep spending the money? Maybe we want to spend for a bit longer and see if that value curve starts to kick up, it looks like it might be. Or maybe we just want to cut it now and go you know what, too hard, let’s stop.
If, on the other hand, we see a value curve, that starts to look like this, well, for every dollar I put in, I’m getting more than a dollar’s worth of value out the other end? I’m going to chuck every cent I’ve got at that, because clearly it’s working. That blue line is sky-rocketing, and so I’m going to make a bet that we can put a fair bit more chunk of cash towards that and if we can keep delivering value out of it? Great. And remember at each point that we look at this graph, because we’ve broken our work down into small chunks, we’ve got something that’s actually working in production.
So this is not design, this is not a model, this is not us projecting out our cost savings, this is because we’ve delivered something that’s actually working for customers. We’ve got a skeleton product that’s out there, and people are pre-sold off a landing page, we’ve got a piece of software that’s doing the bare minimum, it’s done, it’s been able to ping a server or potentially play a message down a phone line. We’ve actually got working software, or we’ve actually got a working product, we’ve actually got some tangible measure that we can demonstrate that we are going to deliver value to customers, or that we are in fact delivering value to customers. And the sky’s the limit, we’ve got another place to go, we’ve got more improvements to make that are going to make it a better experience.
So, in summary! We wanna take, our traditional graph, whereby we do a whole bunch of analysis paralysis, we gather requirements, we do a big design, we try and get all of the answers before we start and then deliver all the value, right at the end after we’ve had that huge, huge carriage of financial risk in the project, the whole way through and hope we get something out the other side…
We can shift to, breaking work down into small chunks, bringing value earlier in the piece, to deliver more value more often. And this has a huge benefit in terms of feeling like you’re really building some momentum. And it means that at any point, you could choose to stop that project, repoint those funds elsewhere, go and use them for something else that’s more valuable.
In some cases, we might get 80% of the way through that project and go “you know what, that’s enough”. In other cases – for example we might have a compliance project – we know we need to get to 100%, and even though it’s going to cost us the last 20% of the cash, well, we’re just going to have to do it.
But we’ve got options. We’ve got flexibility. We’ve got the ability to respond to what’s going on in market around us. And for my money, that’s a much much better position to be in.
So. Curves. Have fun!
Now, one last hot tip. Often when I’m doing this work with companies we’ll start with a really really big project and fixate on chunking it down into 10 or 15 little different pieces. The super-super-pro tip? You don’t even have to do that. Don’t stress about chunking it down into tiny tiny pieces and the smallest possible. It’s really easy to fixate on that. If you can take a piece of work, and break it in half, that’s a hundred percent improvement. And if you can take that piece of work, and break it in half again, that’s another, hundred percent improvement.
So don’t stress that you have to go the whole hog straight off. Start simple, take one piece of work, break it in half, you’ve had a hundred percent improvement in delivering more value, more often.
Have a great rest of your day, we’ll see you next week.