The Executive Brief
Writing the title on this one brought back a conversation with a friend from the UK. She was opining that America’s version of English was much more “in your face” than the Queen’s English and used the phrase “kill a project,” as her example.
I argued with her. Mostly out of good, old fashioned patriotism. But the truth is that I did so while remembering an old boss of mine who used the phrase “shoot that project in the head” regularly.
My British friend may have been onto something.
But I digress.
Today’s article is about identifying when it’s time to shut down a project.
As CTOs and CPOs, we’ve all seen projects that hung on well past their shelf life. (Btw, the most common reason for this is the sunk cost fallacy.)
But things don’t have to be this way. This problem is common, but it’s also avoidable. And today we’ll look into the key strategies and tactics to get better at shutting down projects.
But before you dive into it, here are the most interesting bits in technology from the past week.
Bipartisan data privacy legislation has been announced. Of course data privacy bills have come and gone. I find it strange because this is legislation that even some of the largest data brokers have asked for. A law at the federal level would simplify data privacy compliance. On the other hand, there is a non-zero chance that they craft something that makes compliance even more difficult. This is one to keep an eye on.
Meta will require labels for more AI-generated content. It will start labeling video, audio, and image content as being AI-generated when the user discloses the source or they detect ‘industry standard AI image indicators”. The change will take effect later this year. It’s my opinion that we will see more of this. Whether it lasts or goes the way of “No Synthesizers” labels on albums remains to be seen.
Poll of the Week
Let us know how we’re doing! We’re always looking to improve our content, so your voice is important. Take a moment to respond to the poll or leave us a comment.
When to Kill Projects
As a CPTO, how do you know when to kill a project?
I’ve seen many long-running projects that should have been put out of their misery years ago. But somehow these projects end up with a life of their own and momentum continues to carry them forward.
In fact, often the project owners think success is imminent (even though they’ve been thinking that for years).
And that’s just the thing: the project owners aren’t delusional, and these projects aren’t totally unsuccessful. There is just enough success for them to keep going.
So, ROI may be negative. But success isn’t exactly 0 either.
The project owners will explain that the benefits will accrue later. And that stakeholders should be more patient. “It takes time to start generating the benefits," they say.
Or “we can’t quit now, look at how much we’ve spent,” they sometimes resort to saying. And they point to the tremendous amount of work that has gone into the project and all the activity happening at the moment.
I truly love the passion and dedication of these folks.
But then I go look at the financials, and it just seems like they are throwing good money after bad. Even when they come up with a time horizon to get out of the negative ROI hole, it still doesn’t seem likely.
I think it’s because I know they have been asked this same question in the past. And the ROI deadline has come and gone. They counseled patience then too.
That’s when this picture occurs to me:
Do you remember this image making the rounds several years ago?
This image made it to all the popular product management blogs and was used in many a meeting, I’m sure. It’s quite a powerful way to explain the modern Product development approach.
To me, this image is the at the heart of why so many businesses find it difficult to kill a project: without incremental product releases that deliver value to the customer at each stage, it is extremely difficult if not impossible to measure ROI and therefore decide whether to keep a project going or not.
I think many product teams are fearful of articulating “the skateboard” (from the image), so they just focus on building the wheel. Often the rest of the business doesn’t know any better, so they just go along with it.
6 months after the start of the project someone from finance tries to measure the ROI on the wheel and don’t get anywhere. I wonder why? Maybe it’s because the customer doesn’t need a wheel. They just wanted to get from point A to point B!
If teams can follow proper Agile and avoid the idea of building the wheel and instead focus on the skateboard, then the rest of the tactics to measure continuous ROI on projects are pretty easy and will help you decide on a go/no-go.
Key Tips
Create a business case before starting the project; if you’ve already started it build one anyway
Make sure you define the types of Return you’re looking for in the business case (it’s probably not just financial)
Put in regular stage-gates tied into the product releases (each one should drive customer value)
Define how much Return is enough for each stage
Routinely make “go / no-go” decisions at whatever your check-in cadence is based on, whether you’re seeing the return or not
Consistently review the original business case and its assumptions & projections with all stakeholders
Include all stakeholders at each checkpoint: Sales, Finance, Marketing, etc.
Don’t get overly attached to the project’s success or failure, if you need to kill it because it’s not meeting the defined Return thresholds then do it
Equally, don’t be afraid to pivot the project if you discover an alternative successful path
And above all, don’t fall into the sunk cost fallacy trap that so many technology and product leaders do.
Closing Thoughts
If you scope your projects well to deliver incremental value and you follow the tips we suggest, you’ll probably be in a much better position to know when to shut down a project.
Of course, shutting down a project can often involve political considerations. In fact, very often politics plays a major role in knowing when to retire a project. We’ll cover this aspect in a future article.
In the meantime, think about measuring continuous ROI on your projects and the operational pieces you need to put in place to do so.
If you put the right “systems” in place you’ll avoid being like an average leader who lets a project continue well beyond its value delivery cycle.