jurvetsonSetting a launch date for your new web site is common practice. Even though nobody knows what exactly the site might look like and even less how much effort it will be to launch it, the release date is fixed. This can have positive and negative effects.
The Good
The positive side of having a defined release date is that you have a guiding post for all your decisions. If you’re aware that you only have that much time, you can make the difficult, but crucial, decisions about scope. Without a set date, you always put more and more into the first release. This leads to a bloated product based on your dreams and has a good chance of never getting finished.
The Bad
Setting a launch date can put too much pressure on your team. Fear is not a good decision maker. If your team doubts it can make it, they will be demotivated or, even worse, become cynical. These effects can easily overshadow the positive ones. Take care that everyone buys into the launch date. It should be challenging but not insane. You’ve got to work with your team and address their concerns. If they are desperate, tell them to scrap non-essential stuff. Make them understand the advantages of limited resources. Though it sounds harsh, it will make for a better product.
The Ugly
The ugly side of a tight release schedule is bad code. If developers feel rushed, they won’t write tests and hack away instead of producing clean, maintainable code. Make sure they understand that code quality is paramount. Coding cannot be expedited. It takes it’s time. If you cut quality now you will create technical debt (just like charging up those credit-cards). If you have to cut corners, make sure that everyone understands the consequences: You will have to put a multiple of the efforts required now to fix the mess later. In other words: You’ll have to pay interest on your technical debt. If you borrow too much, you’ll have to declare technical bankruptcy.
What are your experiences with setting challenging launch dates or working in a project with a tight release schedule? Let us know in the comments.
Agile Web Operations 
While I agree with your point about a release date being a decision guide, I believe this doesn’t come naturally for a developer. When setting a release date, I like to give the team explicit permission to review priorities and renegotiate requirements on their way. Even though it might have been said before and whether or not the team is embedded in a process that already encourages constant reevaluation of requirements.
LikeLike
Henning, thanks for pointing out that it is very important to tell the team that they should negotiate scope. Given a fixed date and assuming you do not want (and you definitely should not) reduce quality, the only variable is scope. The beauty of using a backlog is that even if you reduce scope it is ensured that the most important stuff gets built.
LikeLike
We launched a major redesign of our website on a fixed release date, then got a couple of new contracts to work on. We didn’t back up on anything, and as a result, the clients are satisfied with their websites, but we have a somewhat finished release with hardly any content.
I’m satisfied we were able to deliver for our clients, but now feel rushed into creating the necessary quality content on our own web crib… Some pain there.
Thank you for the interesting article, have been following you on twitter for a while.
LikeLike
Thanks for sharing your experience, Hector. I see, that it is painful, but at least you have something up and running! That’s usually the hardest part. Now you can iterate your way to quality content step by step.
LikeLike