Monday Feb 21, 2011

SocialChat: A guide to closing down a project

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 

Wednesday May 06, 2009

Sun VDI 3 UX Story - Power of the Web

Each and every of my endeavors starts with an index page. A title, a logo, some ideas, related info, more stuff added over time, a log, and sooner than later the thing becomes a substantial project. This approach worked out fine for me for almost 1 1/2 decades now. First in the GoLive team in the late 1990s, where we developed a WYSIWYG web editor. Then the intranet for StarOffice' user experience team. And today I am still using GoLive to create and write on web pages for my projects.

All this is along the lines of the original vision of Tim Berners-Lee and Robert Cailliau to create a read/write web. Some time has passed, and their vision never came true. At least not in a way that could be called elegant or straight forward. Instead we see a cyber-landscape of wikis, blogs, microblogs and other social software that empower "users" to "generate content." Wrong perspective _BTW.

For the VDI project I've changed my habits a little. I set up a blog internal to Sun and start with a blog entry, a tag, some ideas, related info, more stuff added over time, and sooner than later the thing becomes a substantial project. The advantages are the same as in the early web zero-dot-nine days. I do not have to spend extra effort in communication, while colleagues can see what is happening and can provide feedback.

Here is a screenshot of my internal blog at Sun:

Tags are assigned to all entries, and the resulting tag cloud provides quick navigation for the blog. Concept diagrams, design sketches, and even photos from whiteboard scribblings are stored and shared on the blog. Other content like wiki pages are linked, as well as classical intranet pages for stuff that does not easily fit here.

I am not blogging. I say it again, I am not blogging. I just use the internal blog as a low key content management system; and that approach has proven to be useful for me and the team I work with.

>> VDI UX Story: Part 1: Concept Workshops | Part 2: User Research || To be continued...



« July 2016