Closing down a project - what are the key things to do?

Question

It seems probable our client will cancel the project we've been working on for 15 months.

It's possible (although not very likely) that it will get restarted at some point.

We've also extended our company's product in several areas while doing this. Other project teams may need to make similar extensions, and we'd like them to be able to make use of what we did.

So, what are the key things to record for posterity, so that a future team (which may include different personnel) can learn from what we've done?

This is slightly different from what to record for future maintainers, since people will probably arrive with little/no familiarity with our project, and will probably not have any extended involvement with it.

So far, we've worked on collecting information about each major feature/extension - so there's one place to look for requirements, pointer to the source code, test cases, etc, and are adding some narrative on key design points/decisions etc.

What else should we be doing and capturing, while the project team is still together?

Answer 1

I know this isn't very specific. But for every major decision you made about design or choice of technology, be sure to record "why".

This helps a lot further down the track especially if the people working on the project in future are not the same as the original team.

Answer 2

Make sure you save your repository, or some representation of each file's history. It's really useful, coming into something with no knowledge, to see how it evolved, and when certain features (or bugs) were introduced.

Answer 3

This should be done not onyl if the project will be closed down but also as a clean project finish. As you can read in project management literature there's a project closing documentation, which would give a an outsider the possibility to dife into the project. So your task is not very uncommon.

First of all create a dedicated place for the projects sourcecode, maybe browsable with a browser, so the barrier to look into what your team has done is very small. Also make sure that your documents (architecture etc) are available. After this you can start to write a project experience wiki, where you link certain artefacts in a clean and traceable manner. Perhaps with a wikipage for very hard problems you encountered and the solution. If you've got this, it should be very easy for others to take advantage in your knowledge about the project.

Answer 4

You might want to look at the following post: What's your Post-Mortem meeting format?

Whilst it doesn't cover everything you want, it's probably a good starting point.