I've recently tried to import some source from Gmail, and save it as a text file in Eclipse, but discovered an encoding issue that seemed strangely undocumented online.

When I was trying to save the imported source, I would receive an error message:

"Some characters cannot be mapped using 'Cp1252' character encoding".

It turns out that Gmail is using a wider spread of encoding than usual websites. Simply click on File-> Properties -> Text File Encoding -> and select another encoding format until you hit the right one. In my case it was UTF-8.

Then eclipse will save it!

Several major online events have been rolling along in the press recently, two of which are particularly 'landmark' in their influence on the internet, and net morality in general.

The first is the Pirate Bay court case in Sweden. This has been an ongoing court case for several months now, and wherever you stand in terms of the piracy argument it could have large repercussions for both sides of the fence. The Swedish court recently found the four defendants guilty (http://www.guardian.co.uk/technology/2009/apr/17/the-pirate-bay-trial-guilty-verdict) but seemed to give them a verdict that is wholly out of sync of what they were originally pushing for. So it appears more of a token gesture than crippling blow to the Pirate Bay.

The other point of contention that seems to be gathering momentum at the moment is a Goldman Sachs complaint site. www.out-law.com (http://www.out-law.com/page-9944) rounds up the article nicely here. The gist is that a disgruntled investment banker has started a blog http://www.goldmansachs666.com that is aimed at highlighting the evils of Goldman Sachs. Obviously they have taken offence at this, and decided to sue. The argument they have seems quite weak to me, they are arguing that his site may be confused for actually being affiliated with them. This is partly due to the domain name, and the fact that all the content is Goldman Sachs related.

There have always been controversial domain registrations for nefarious or otherwise purposes, but in this case it appears that neither side is willing to back down, and with the public perception of banks being pretty dim at present it will be interesting to see if this opens the floodgates for public online criticism or slams them shut in their faces.

Often a project's success is measured by whether or not it was successfully delivered, and if the release was relatively painless.

People see the finish line of a project and start making compromises or try to expedite the project delivery, as they can see that the end is in sight. It is this race for the finish that can compromise a projects completion.

In my experience one of the most important parts of the project life cycle is the Post Implementation Review. It is also the most often overlooked part of the project for the reasons mentioned above, or indeed omitted altogether if a company isn't used to accurately measuring the success of a project in more in-depth terms than 'did it go live successfully' (Which is the poorest measure of success).

Essentially this process answers the question "Did we manage to deliver what we set out to do". It tries to accurately gauge whether or not the business case for a project has been met, and if not, where the shortfalls are.

The Post Implementation Review is an ideal opportunity to validate several aspects of the project, and feed that data back into your PM process to the benefit of future projects.

It can be as basic as a simple document asking several basic questions, such as:

1. What of the initial business objectives did we meet?
2. What did we learn from this project?
3. What was different than expected?
4. Were there an unexpected issue during the project.
5. Would we manage any elements of the project differently if repeated?
6. How do our initial estimates relate to our actual delivery timescales?
7. How did we manage the unforeseen?

Several important sets of data should be included in it though, for example if you have any sort of estimation and/or time tracking process this is the ideal place to correlate that data with the actual project time frames as you now know exactly how long it took to deliver the project. This is an important step in refining your estimation analysis, and can greatly improve the accuracy of future projects. After all what is the point of time tracking a project, if you don't actually match up the estimated figures to the actual figures.

This is also a good opportunity to examine the release management process implemented, and assess whether all potential risks to the project and the existing infrastructure were accurately foreseen. This is easily answered by a brief comparison against any release documentation you may have, as you should quickly be able to see if any risks highlighted in that were minimized.

It is also a very good opportunity to explain and release shortfalls to interested shareholders. Often if a project misses a deadline, or is badly implemented it is never actually explained to the business why. They simply assume that there was a problem. By explaining here you are keeping them informed, and on-side. By explaining that here you are also documenting it for future projects.

If you did not see a risk that affected your projects release this time, then surely it needs documenting and a greater level of understanding about it reached for next time. In this way you have a more complete picture of your overall architecture.

Just because a project has been released it does not mean you cannot learn anything else from it, often it is entirely the opposite. Haste to proceed onto the next project can often cause this step to be skipped entirely, but once you have tried it a few times its value will become more than apparent, both as a project analysis tool, and a vehicle for shaping real process change inside the business.

I will include a template at the bottom of this article that I have found useful in the past. Hopefully this brief explanation will give you the incentive to look at introducing a Post Implementation Review into your projects.

An example Post Implementation Review document.