D-Day : ending or milestone?

Openweb.eu.org > Articles  > D-Day : ending or milestone?


So you’ve been working for months on the new version of your Website? I guess you’re pretty sure that the day this new version will go online will be a very important date for the users, for your customers, or for the Web, maybe. But it won’t. The day your new version goes online is not an ending but the beginning of a story with your users.


(Note: this article was previously published in French –if you have any feedback on the translation made by Nicolas Hoffmann and Coralie Mercier, please let us know.)

Today, I’m going to address one of the most significant challenges in managing a web project. A common error is to consider the official date of release of the site as the end date of the project. This perception is wrong, and it has major consequences not only on the quality of the site, but also on the motivation of the teams. This is why I speak of this matter to you today.

Considering the release date of a site as the end of a web project is a quite natural mistake. The teams responsible for the production of the site are indeed judged by their hierarchy at this time and not necessarily on the next phase, that is to say, when the site takes life and evolves. Moreover, focusing on creating the site is much more attractive, as it’s a very varied step, often exciting, than focusing on the life phase of the site, which is much less rewarding. And yet.

The official release date of a site, always long awaited, is often disappointing for the teams of the Web project. Certainly for project teams and their managers who are waiting for a new version, whose production takes several months, this date actually marks a completion.

However, for the site itself and its users, it is a date that marks the beginning of an even more important phase. In fact, the release date of the website marks the beginning of the life phase, of adjustments and production of new contents and services.

Whatever your efforts, your rigor and competence during the site creation phase, nothing will replace the feedback of real users of the site that will come during the life of the site. Sure, you can anticipate a lot of things, but if you choose to offer at the official release date a complete and perfect site, you make a beeline for failure and disappointment.

The success of an online service comes in the long run. Whatever your skills, the volume and quality of your content, the feedback and congratulations that you may have when releasing the site will only be temporary, and bear very little importance after years following the release date.

It is indeed in the months and years that follow the release date of the site you can show that your site is not a set of content and services introduced one time at a particular date, but a set of content and services in constant evolution.

Operationally, this vision can lead to apply major rules to drive your Web project. And since nothing beats a recipe, here are seven wink

  • Accept imperfection: As I have often written, it is the first fundamental step in the Web business. This acceptance is a required step to adopt a continuous improvement process and not perpetually suffer the inherent imperfections of Web business.
  • Do not dream: If you do not want to be disappointed, do not expect too much out of your site release, and get ready to work for a long time.
  • Anticipate updates: separate fundamental contents from those that can be published later on. The impression that will be left by a large amount of information will never be as good for your site as a regular publication of new content.
  • Limit your ambitions: plan changes after the site release, and if the project seems too heavy, move optional components intended for the first version to future publications.
  • Plan ahead: allocate the budget of your site on the long term and integrate costs related to its further development. Do not bury your head in the sand. Right from the design of the functional specifications, it is possible to detect items and identify human resources necessary to maintain the site.
  • Be careful: remember that each feature, each section, each content mentioned in the specifications of your future site implies costs. Those costs will be spent much later.
  • Standards are for you, not for the others: compliance with web standards, best quality practices, accessibility rules are not just constraints, they will lead you to improve the scalability of your site. You will make mistakes. You will! Standards should especially be used to ensure that these mistakes are easy to correct and do not cost you too much.

There you go! Good luck for the release of your site. If you can grasp the D-day as a milestone and not as the end, you will not be disappointed wink

About this article

  • Openweb.eu.org
  • Profil : Décideur
  • Thème : Méthodes, Qualité
  • Author:
  • Published on:
  • Updated on: 22 March 2016

Comment on this article

Who are you?

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here
  • This form accepts SPIP shortcuts [->urls] {{bold}} {italics} <quotes> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Follow the comments: RSS 2.0 | Atom