Project Closure

I do a lot of short-term work through Readify, usually somewhere between a 2-3 day estimate or architecture review to a 3-4 month development effort. One of the highlights of that is I get to experience a lot of project kick-off's, and I get to work with some very talented and fun groups of people at our clients. The downside is that I also often have to say "goodbye" to those people.

Earlier this year I spent three months in Sydney working with an incredible team at one of our clients. We were prototyping something that could have been a real contributor to the company's long-term success. Unfortunately, due to a budget reshuffle, our project was suddenly put "on ice". Although we did get to continue the work a month later, at the time we had no idea if we'd be coming back or not. The team had worked hard and had high hopes for the prototype we were building, and feedback had been very positive, so it was disappointing to have to end it.

I didn't want to end what had been a very good three months on a bad note, so on the final afternoon we'd been allocated to "wind up" the project, I threw together a quick slide deck to celebrate the work we'd done. It went something like this:

  • What our iteration plan had looked like, and how far we'd gotten through it, with dates
  • For each iteration:
    • A screenshot of what the application looked like at that time
    • A short list of the goals we'd achieved
    • Quotes from positive feedback we'd received
  • A final quick demo of the working product
  • An overview of each of the major areas of the product
  • Caricatures of the different people who'd been involved in the project
  • Some interesting output statistics, including:
    • How many check-ins we'd done
    • How many lines of code we'd produced
    • How many work items we'd closed
    • How many CI builds and deployments we'd done
    • How many demos we'd given to stakeholders
  • Some interesting input statistics, including:
    • How many litres of coffee we'd drunk
    • How many world cup soccer games we'd watched (we were lucky enough to have a TV in our team room)
    • How much chocolate we'd eaten (somehow we ate through 12.6 kg)
    • How many team lunches we'd had

It was still a disappointing afternoon, but by taking time to celebrate our achievements I think it helped to end on a somewhat positive note. Then of course we hit the pub.

One of the trickiest parts about putting that deck together was gathering the screenshots. It involved digging up old versions of the code or email threads, and wasn't much fun. For my current project, I've started taking screenshots every couple of days of different things. Hopefully it makes the next round of goodbyes a little easier.

A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

27 Oct 2010

I think that kind of 'retrospective' stuff each iteration was something the SDC did (does?) well...although the slides were always a bit too corporate for my tastes.

01 Nov 2010

Great idea Paul, one of the bitter parts of being a developer is those project shutdowns.

FWIW I'm thinking timesnapper could play a role for future project 'journals'?

Patrick Klug
Patrick Klug
01 Nov 2010

I am using timesnapper for this kind of thing as well. This way, I never have to worry about screenshots :)

16 Dec 2010

You could probably just have something that runs post-build on the buildserver, one of the automated gui testing frameworks that also does screenshots, call it the "historical photographer" job, and it could run perhaps somewhat randomly and in such a way that it doesn't interrupt typical project post-build tasks.