Beethoven deafness posed a challenge to have fluent conversations with him. His trick was to use conversation books, where you had to write your part and he would then answer verbally. These books have survived until today, and provide insights into… well, we have to guess his part of the conversation. But anyway.

Although I am not deaf, I want to share one page of my socialchat-conversation book that contains just my tweets and not the tweets of my colleagues. The topic this week: A guide to closing down a project. You can read topdown, but might need to fill in some impulses from other participants. I hope it still makes sense. Enjoy!

BTW_ Beethoven finished all his symphonies – Schubert did not.

• Discussion Point 1) Have you ever worked on a project after it has lost momentum?(eg lost a sponsor, or where it’s obvious it’s a dead end) How did you maintain morale?
• The first part of the question is easy to answer: yes. I guess I have no problem with my motivation because I am always involved in several projects at the same time. If one project loses steam, I can refocus myself to work more in others.
• Some projects don’t have a sponsor. And they are not the worst. You really try to bring them forward b/c your are deeply convinced about what you are doing. Although, these are never the main projects but some smaller ones.
• Moving onto Discussion Point 2) Any tips on how to close off the project? Has anyone successfully handed off a project to be supported by another org?
• wiki documentation (always a good idea) and TOI presentations (transfer of information) to the engineering team, who takes over.
• This is even more important if you hand-over to yourself in the future. Then you need to pick up the game maybe a year later without starting from scratch. I call this ‘freezing a project’
• A party is also a good idea to close a project in order to finish it and turn around the heads for the next one. Celebrate success, or have a postmortem to do it better next time.
• you can call a postmortem also ‘lessons learned’
• There is an EOL (end of life) phase in the product life cycle.
• 3) Has anyone any experience with the ‘Wither on the vine’ approach (eg Nokia is using this approach with Symbian)?
• wither on the vine (British, American & Australian literary):= if something withers on the vine, it is destroyed very gradually, usually because no one does anything to help or support it
• ‘wither on the vine’ does not sound like a good management style. More like the lack of good leadership. Wasting nerves, money, and losing customers.
• You cannot ride a dead horse. It’s dead already, stupid! Though, it needs some experience and stance to recognize such a situation, and courage to react accordingly.
• well, if the systems continue to run fine… Do they have a migration plan for the customers and just need to ‘entertain’ their customers until the new system becomes available?
• I do not know it it is done deliberately and consciously. But I think it is better to manage the expectation of the users&customers rather than having rumors spread by the competitors.
• google for for ‘software train wrecks’. e.g. 10 Signs Of Coming Software Train Wreck
• And one for the road if you go off-track — this is the presentation that I just had in mind — Scott Berkun about Saving Design Train Wrecks 

Scott Berkun at BayCHI: Saving Design Train Wrecks