In the UK this weekend it was a bank holiday, and my partner's birthday, so we set off to a local(ish) amusement park, called Alton Towers.

There is a rather handy map that you are given when you buy your tickets, and you are ushered through the front gates to be surrounded by souvenir shops and restaurants. After walking through a few areas of trinket sellers and the usual teddy merchants I began to notice how everyone was being 'funnelled' into handy areas of commerce. It is very subtly done, but to get to any of the themed areas of the park you have to pass several eating establishments, and child friendly games, where you can win stuffed animals that will never fit in your car.

Combine that with the idea that any ride you go on is surrounded by similarly themed merchandising opportunities, and once you have managed to damage all your internal organs from being shaken around 360 degrees, the exit to each ride is through a shop. You actually have to exit the queue to leave the ride by going through a shop.

This has to be one of the best most direct examples of meticulously plotting of the customer journey that I have ever seen. In most wire framing and spec analysis meeting it is always a consideration how an end-user is going to travel through your site. Usually you give them easy access to a variety of options so that they find using your applications hassle free, and painless. Rarely ever do you so carefully craft a path through your application as I witnessed in Alton Towers.

It was certainly an interesting comparison between the real-world customer journey, and the online equivalent. I know I'll certainly be taking a lesson or two from their example next time I am wire framing up a site layout.

In this article I examine the compilation feature of ColdFusion, and explore why you would want to do this to your release code.

A project that I worked on in the recent past was being hosted on a remote server, which was being supervised by a third party company. We were still responsible for the code base and suspected that some 'hot fixes' had gone in as live code changes implemented on the server.

Obviously this is not ideal, the sanctity of your code base is paramount, and if it is your responsibility you have to be absolutely sure you know what it contains, especially if there are tinkerers.

Another good use for this functionality is where you are selling the software as a service (SAAS). The normal occurrence here is that the client is renting or leasing the functionality of your application, not the actual code base itself. So a good way to deter them from peeking under the hood is to compile it.

In the code above the first line executes the cfcompile command, using the –deploy switch. This tells the compilation engine to take the source directory (the second line) and compile it, and move it into the destination directory (the third line). Be careful not to specify the same directories here, as it will flip out. Also there is a chance it will overwrite your source dir, which is bad as you cannot undo this.

The destination directory should now contain an exact copy of your code base, but compiled. Open a file it looks like garbage, but works exactly like the original.

Note that Compiling is different from Encrypting. With encryption you can decrypt the code base, as long as you know the seed, or hash. Compilation is irreversible, you cannot un-compile it, so be careful with your original un-compiled code base!

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.