Reduce time to market of a new corporate website

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.

Corporate website projects take too long

Corporate website rebuilds are complex. There are many things that have to be taken into account, many stakeholders to be involved, high expectations which have to be met. If we add to that a lot of requirements, and a lot of content and functionalities, we end up with a massive undertaking. And massive projects take time.

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 

If your corporate website takes 18 months to deliver, it is almost certain that there will be changes to the business in that period. Marketing and sales plans will be updated or changed. Products and market strategies also may undergo updates. Typically, all such changes require changes to the website. Sometimes these might be cosmetic tweaks, but they might just as well be substantial.

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

While the new website is being built, the old one is still doing all the work for the business. If you have to introduce changes, you will most probably have to implement them to the new website but also to the current one. And we know you will have to if your new website is still far away. This creates additional costs of maintaining 2 websites at the same time. A very painful decision to make by any executive, especially when he knows that one of the websites will be thrown out in less than a year.

Cost of not updating the current website

“Sorry, we have the new offer but it is not on the website. We’re building the new website now. Let me send you a pdf.”

      - 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 reduce time to market?

There are many ways to reduce website time to market. The best way is to take a bit from each one to minimise the time of the project.

1. Simplify

When we plan, we let our imagination flourish. We pick the best solutions available, look at what others do and how and we try to replicate and build on all the best practices. While this is great, it is also often complicated and expensive. After you developed a list of requirements, you should inspect it in detail looking for things that can be simplified without compromising on desired results. for example:

• 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

After you’ve gathered all specifications for the website and have done all the wireframing, you will usually end up with a really big scope. The easiest way to reduce it is to 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

If you went through a full planning phase and talked to all stakeholders and captured all the requirements, you will have a lot to deliver. A good way to reduce this scope is to prioritise things. Mark everything in the order:

• 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

Increasing the team is a fairly obvious way if increasing output in a fixed time. I am putting it on the fourth place however, because it is not a panacea for all the problems. 

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 compromise on quality and processes

In reference to our Drupal consulting experience, the bigger the project and the more complex the requirements the more important it is to have processes, workflows and tests. Big projects can really stumble under a huge amount of errors and issues if there are no processes to address these.

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.