I’ve seen a couple of posts about project lifespans recently. The subject’s come up through work a few times too.
Avoiding abandonment
First up, Keir Winesmith blogged about SFMOMA’s three 18 three approach:
Put simply, when you are planning and budgeting a new digital initiative, don’t treat the launch date as the end date. The launch date is the beginning of three 18 three:
- spend the 3 months after launch testing, iterating and updating the experience
- at 18 months, plan to replace (or at least refresh) the content of the experience – this will take money and time
- at 3 years it’s time to replace (or at least refresh) the hardware, the infrastructure or possibly the whole thing
I like the sound of that. Anything that gets people to think about longer-term repercussions while still in the planning stage is a good thing.
Could/does this rule out small, short-term, experimental projects? I dunno, maybe this isn’t meant to apply to that kind of thing.
The one thing I thought was missing from this was any mention of when and how a project might be wrapped up (before the three year point, anyway).
Flicking the ‘off’ switch
Which is when I came across a post by Christina Xu called Your Project Deserves a Good Death which contains this:
What does a Do Not Resuscitate look like for your organization? How can you help yourself remember the hard, important choices when things get complicated? Make an imaginary plan for what you would do if you had to shut everything down or step away tomorrow. Chances are, planning for the end will dislodge something important and true about your project’s life, as well.
Which pretty much summed up what I was thinking. She also does a nice breakdown of the various ways that projects can end up fading away. Check out the further reading links too.
So…
It’s really rather simple:
Short-term project: the close-down is an important part of the project, so write up an exit plan when you’re in the planning stage.
Longer-term project: plan to spend time and money on further development throughout the project lifespan and have an exit plan (to be revised as necessary if the project evolves), with a way to recognise when that plan should be put into action.
Pretty obvious, right? I wonder how many projects would look different if this was done more often.