The Site

The site is http://www.gradlink.edu.au - a resource designed primarily to help graduates find jobs. It also helps both employers in graduate recruitment and careers services in assisting graduates find jobs.

The site was first build in the mid 90's with it's own job vacancy system. This was later outsourced and is now seek campus. The rest of the site consisted of static html and underwent a number of redesigns. Prior to this project, the most recent redesign was in 1998.

Initially all maintenance of the site was outsourced to web development firms but over time, GCCA developed enough in-house skills to manage the majority of the site themselves. Unfortunately, over the four year period since the last redesign & rebuild, the site had become difficult to manage and maintain. It was time for an overhaul.

The Brief

Before even considering designs or CMS packages, with our assistance GCCA conducted a user survey to get an idea of who was using gradlink, what they were using it for and what improvements users would like to have. The results of the survey were eye opening. The site had always been split into three main sections, one for students, one for employers and one for careers services. The survey showed that over 80% of people visiting gradlinkwere students, approximately 10% careers services and only 2% employers. And the overwhelming reason for students coming to the site was to find a job, a facility that GCCA had outsourced to Seek.

There were four key outcomes that GCCA wanted from the rebuild of gradlink.

1. give the site a modern, clean professional look

2. integrate a job search facility that used the Seek Campus job database,

3. implement a CMS that would enable GCCA to maintain the site in house

4. and ensure any change to content had global impact on the site

Defining the solution

In order to choose a CMS, we started with a requirements gathering phase that was conducted over a series of long meetings (approx 3 - 4 hours each). This produced a document which was a list of written statements of what GCCA wanted for the new gradlink site. The next step was to translate the requirements into a functional specification. We did this by creating a site map and then producing wire frames for each main section of the site, defining each of the elements of the screen and any business rules.

The requirements gave us what the site was supposed to achieve.

The functional specifications gave us how we were going to do it.

Staged Approach

Once we had the full requirements and functional specifications, the scope of the project (and budget) was much larger than expected. The problem was all of the functionality was important and necessary but could not be afforded at this point in time. So we prioritized the requirements to establish the minimum functionality required for the initial launch and called this Stage 1. The rest of the functionality was then prioritized into Stages 2 and 3 to be implemented later.

This prioritized approach was primarily driven by budget, but we also felt it was important to get the CMS up and running and have GCCA work with it for a while, after which we could review Stage 2 and 3 with more knowledge and experience with the system.

Choosing the CMS

There were two key elements that we had to consider in choosing a CMS. The first and most important was budget - the more the CMS was going to cost, the less that could be spent on design and implementation. The second element was the functionality. Ideally, we were hoping to find an open source solution that had all the functionality but no license fee associated with it. Of course, there is no such thing as free lunch and the chances were an open source solution would require more work to implement than a commercial product. It was a matter of balancing the effort required to implement against the gain of an open source product with no license fee.

Our first step in choosing a CMS was to distill the requirements and functional specification into a list of functions. We found there were 18 areas of functionality that the CMS had to provide. When went about searching on-line for potential solutions and we found there were dozens of open source solutions.

In selecting the end solution, the first step was to see if the solution provided the full set of functionality. This eliminated many of the solutions we found and we ended up with a shortlist of 10 possible options that we documented in an evaluation matrix. For the 10 shortlisted solutions we then looked at each of them more closely and looked at factors such as:

• was it actively maintained by the open source community

• how mature was the solution, eg. had it evolved over several versions

• had the solution been used for commercial sites

• was there good documentation and support

This shortened the list to 3 possible solutions. Then we got a copy of each solution and installed them to get a closer look at the underlying architecture and structure as well as getting an idea of how easy the solution was to use from the client's perspective. In the end the solution that we thought was the best option on all fronts was eZ publish, produced by eZ systems in Norway.