Reduce time to market of a new corporate website

By Maciej Lukianski

Corporate websites are really complex. It takes a lot of time and effort every time they need to be rebuild. Sometimes it may feel like the website as soon as it is finished, could be re-build again. Let’s look at why this happens and what to do about it.

Cor­po­rate web­site pro­jects take too long

But long-running website projects create all sorts of risks and additional costs which we could avoid if they were shorter. Let’s have a look.

Additional costs of managing changes

Had your website redesign project been shorter, you could have just waited for it to finish and introduce changes afterwards. If it, however, is to last the next 10 months, you cannot wait — You will put your business at risk of losses because of an outdated website. You will have to adjust the project.

There, of course, is a process to introduce changes to an ongoing project. Especially if the project is run in an agile methodology. Most changes, however, will increase cost and will extend the project further. They are also difficult to introduce while the project is ongoing.

Additional costs of double maintenance

Cost of not updating the current website

- says a sales rep in a company which decided not to have the cost of double maintenance.

Of course, the cost is there still. It’s just in the lost opportunities.

Leaving the old website “as is” until the new one is ready is probably the worst choice, because you will be losing business and will not even know how much. Your marketing and sales departments will be stalled for a long period of time, not being able to compete.

So how to re­duce time to mar­ket?

1. Simplify

  • complex mechanisms might be replaced by something simpler (An API might be replaced with an import/export tool, A complex system operation might be exchanged by an import/export from excel, where you can perform operations
  • custom features could be replaced by off the shelf or SAAS solutions (eg tracking & analytics, content personalisation, emailing solutions, backups, custom online store with Shopify or similar)
  • some of the configuration options may be left out. It will require dev team to change these down the line but quite often we plan for too many options at the outset and eventually many are never used.

2. Phase the development

For phase one pick only the most important parts. The critical parts which just have to be there and those that are the most critical in your website (eg. products sections, contact forms etc.). Plan for releasing just these in the ‘Phase 1’. Everything else will be delivered in ‘Phase 2…3’.

There are many benefits of a phased approach. In particular:

  1. The elements that make the biggest impact are delivered quickly. They are not stalled by the “about us” sections and the likes. You get to reap the main benefits even before the whole website is complete.
  2. You can focus better on the core important features without being disturbed by less important sections.
  3. It is much easier to sell phased development to stakeholders compared to de-scoping less important entirely. And experience shows that after phase 1 is launched, there is often new room to re-evaluate again what should go into phase 2, phase 3 etc.. You get the point.
  4. Releasing phase one quickly, allows you to test your assumptions quicker and adjust faster and cheaper.
  5. After phase one is released, you learn a lot and the next phases are better then they would be if everything was delivered at one go.

And how to tackle the remaining, less important, but still required elements which are not scheduled for phase 1? There are 2 ways:

  1. Fake them — create simple temporary solutions for these sections (eg. by copying over HTML from the old website). This solution might be good for the “about us” and other fairly static sections.
  2. Use a proxy to redirect traffic between the old and new website depending on whether the user wants to visit something that is already on the new website or still on the old one. This requires some tinkering with the design to ensure that users do not get baffled by sudden changes in appearance (between old and new) but is overall a very effective method of gradual migration.

The phased approach probably does not make sense if the whole project will last less than 4–6 months. In all other cases, I would recommend considering it.

3. Cut Scope

  • 1 — critical — this has to be there no matter what. We cannot launch without it. (eg. homepage, SEO, contact forms, products)
  • 2 — important — really important for the business we could manage without it but perhaps for a few weeks only (enhanced analytics, new blog vs old one, social sharing buttons, lazy-loading images on mobile)
  • 3 — nice to haves — this would help us a lot but we can work around it for a longer period of time (new integrations, editorial features helping us publish quicker, REST API for an external service etc)
  • 4 — helpful but not required

When you create such an order it is really easy to decide what has to be delivered and what can be de-scoped (or scheduled for “next phases”) to make your project shorter.

4. Increase the team

First of all, it makes sense do deliver projects in phases and think about what is really important and what is not.

However, what is especially important is the law of diminishing returns. The bigger the team, the lower the output of one person is. Small teams are agile, quick, connected and informed. Big teams have to spend a lot of time agreeing, planning, reviewing and updating themselves on the current status. It is difficult to manage a large team and it costs way more overall.

For example, if you want to use agile methodologies, your team should not really exceed 8 people. If you need a much larger team, it is still possible but you should really split it into several smaller sprinting teams, each working on a subset of your system. Plus you have to have oversight of what each team delivers and how this fits into the overall picture.

To sum up — increasing a team might work, but after 8 or so people it suddenly starts to get exponentially more difficult to manage and gets exponentially more expensive.

DO NOT com­pro­mise on qual­ity and processes

Introducing automation (eg. Continuous Integration) and automated testing to your project might seem like an unnecessary cost, but it is not. You will save an enormous amount of time, which you would otherwise have to spend on fixing bugs and testing manually. Your teams’ iteration time will be drastically reduced and number of regression errors will be much lower if your QA processes are in place and are automated.

Enterprise websites built with best Open Source solutions. We are an Agile software development company. We create big websites with Drupal 8, Symfony and React