arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down RSS star Twitter twitter GitHub white-balance-sunny window-close
Project Closure
2 min read

Project Closure

This is an old post and doesn't necessarily reflect my current thinking on a topic, and some links or images may not work. The text is preserved here for posterity.

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.

Paul Stovell's Blog

Hello, I'm Paul Stovell

I'm a Brisbane-based software developer, and founder of Octopus Deploy, a DevOps automation software company. This is my personal blog where I write about my journey with Octopus and software development.

I write new blog posts about once a month. Subscribe and I'll send you an email when I publish something new.

Subscribe

Comments