Project Management close to a deadline

I don’t know how many (Internet development) projects I’ve been on, but it’s quite a lot through the years. One thing happening over and over again is that all the ambitious goals of the project isn’t quite reached before the launch – and something is either cut short or not quite as polished as it should have been. Lately I’ve been wondering weather this is the right approach. Many of the things you leave out when the deadline starts getting closer is “the finishing touch” – this is especially true for back-ends and other invisible details everywhere. Last time I changed this site, I didn’t get to write a back-end for “site maintenance” where all those things driven by databases – figuring I could do it later – and loaded the initially needed data into the database. I did never get on to write the backend – instead I got used to maintaining the database contents from a mysql client and moved on to doing other little projects.

While this site is a personal playground, I’ve seen a similar case over and over again – and with much larger (and resource requiring workarounds) – and often they go on and on for years before been fixed years after in a completely different project.

The collective term I know these “things to be fixed post-deadline” is usually as “afterburners” and while it sounds good – well scoop up every forgotten detail soon after the initial launch people move on and really never go back to a “finished project”.

While it seems a good idea to cut in details everywhere and don’t leave anything major hanging when a site is launched – I’m actually beginning to believe this is a wrong approach. If you do wish to fix the site – as it should have been – chose something major, something obvious and maybe something everyone can see is missing – that way you may have a chance at getting it fixed – if it’s some small details everywhere I’m confident you’ll learn quickly that they stay on the “to be fixed soon list” until you decide they really aren’t worth doing.