Projects don't have to bite

Our recent work designing and developing a new site for MedNous presented some interesting challenges. Apart from the regular challenges, such as porting sizable amounts of custom content from an old and very very bespoke CMS, there was one thing that forced us to stop and think - time.

No surprises there then - isn't every project out there due yesterday?
(If you happen to have a project that isn't due yesterday then we would very very much like to buy you some lunch!)

The problem with developing websites is that you often need a lot of this thing called time. Even more so if you need to get something old working in something new. This is where we have found an important approach to take while planning and handling client expectations.

I have frequently found myself leaving early project planning meetings where 'new features' have excitedly been discussed by the client (quite rightly) but having seen enough of the existing website guts to know that even getting ourselves to the 'new features' point is going to be challenge enough.

Put a cap on it!

Handling client expectations at an early planning phase of such a project is so important. It's not about saying 'no' to new features but probably a 'not yet'. There is a real need to make every effort to get the client to understand that they have an old system, probably with nooks, crannies and hidden surprises and that means we're going to need some time. Time to port everything across into Drupal, get it working in a similar way and test that it really does work in a similar way.

Around the same time that we were putting together the proposal documents for the MedNous project, I recall getting some great advice from the Lullabot podcast on porting sites into Drupal. Basically, make sure that recreating the site in Drupal should be the first and ideally the only priority for the first phase of the project. Get the site live in Drupal and be sure it is working in pretty much the same way as it did before. Then start looking at new features.

Great advice indeed. It is so easy to fall into a false sense of security about what can be achieved with relative ease in Drupal. Especially when planning. But it is so important to keep in mind the broader issues that change will bring. Issues such as training, testing time, usability and time to prepare your users for how things are about to change. These sorts of tasks can swallow big time, time that is often hard to find when working under a tight deadline.

A Blueprint

Another great advantage in restricting the development scope of a first project phase is that the old site offers an immediate blueprint. Sure, things might need a little tweaking because Drupal does things a little differently but the requirements are already laid out and that means there is much less likelihood for confusion amongst all parties.

This is the approach we took with the MedNous website. We are now entering a new phase of development where we can start adding new features and enhancing the way the site looks and works. There is no big time pressure to get a new site live and that means new features won't suffer from being rushed. They can be properly planned and prepared for.

Most importantly, by keeping the scope compact and clearly defined to what was already known, the project ran to budget, schedule and didn't bite!