Lessons From A Website Overhaul Project #3: Post-Release Anguish

So to the final chapter in this saga. As I write this it’s closing in on the 3 month mark since the launch of my company’s completely overhauled website, in which a small team of internal developers and designers worked 60-70 hour work weeks to meet an impossible deadline, and bring a severely dated website into the modern age. We should be basking in the light of general workplace adoration. Nope.

As it turns out, this is apparently an occasion in which suddenly everyone feels the need to come out of the woodwork and declare themselves to be professional web design critics. From HR, Sales, Management, Cleaning Staff and The Lunch Lady with criticisms from “I like the old site better” to “There are too many graphics” to “The site doesn’t even work!”

Well, that last one was true.

Broken Site Reason 1:  Internally at the company, the website and the corporate network running Microsoft Active Directory use the same domain name, due to mistakes made by IT many years ago. This causes the website to be treated internally as an “intranet website” in which the default settings for Internet Explorer are to present intranet websites in “Compatibility Mode”.  Basically IE7 settings. Users are not admins of their computers and therefor generally haven’t installed Chrome or Firefox, nor are they able to adjust their system settings controlled by group policy.   As you can imagine, loading a modern website in IE7 Compatibility Mode with JQuery and Bootstrap among other things, simply results in a WSoD (White Screen of Death).  Eventually we got this sorted out with IT enforcing settings to turn off compatibility mode.. but on initial release day the damage was already done, internally, everyone thought the rest of the world was seeing our site in the same way and the tone had been set, very very much negatively.

Broken Site Reason 2: Now the site wasn’t loading due to SSL Certificate issues. I’m an expert in SSL and web security, my web server settings are impeccable and set to the highest standards. Yet, for some reason, again from within the corporate network, people were having issues either loading the domain at all, or getting security errors. Turns out, IT runs all web traffic through a 3rd party proxy/monitoring software not configured to support TLS 1.2, and my server adhering to the NIST Guidelines, supports ONLY TLS 1.2.

After getting those internal issues out of the way, setting the tone that the company’s internal web design team were a bunch of screw-ups, the new site bashing started. There were two distinct groups of people that became “bashers”; people who had the opportunity to participate in the design phase and didn’t, and people who were upset that they were not included in the design phase.

Admittedly, we did drop the ball on that latter group to some extent. We needed to identify “stakeholders” who would have programs or products that needed representation… on the other hand, it’s really the executive board that dropped the ball on this one, because we (the dev team) asked them for the stakeholder list, and then worked with what we were given.  In the end, some departments came out terribly underrepresented and that caused some issues for sure.

I imagine that even if our roll-out was flawless and smooth, we still would have had some criticisms, but I think the botched roll-out really amplified it. You don’t get a second chance to make a first impression.  The crazy part is, we tested rigorously on all browsers, made a massive effort to have solid, responsive design… and then it all fell apart because we failed to test from within the company environment with basic user group policy permissions as all the development team were given elevated permissions in order to do the simple things we needed to do without calling IT every 5 minutes to download and install Notepad++ or FTP files to the web server.

If I had to do this all over again, here are the lessons I would take with me and try to adhere to.

  • Have an appointed leader or project manager. The equal and democratic team just does not work, eventually the most career ambitious person will try and make the project all about them and damage the rest of the teams morale, perhaps even imposing themselves as the leader.
  • That said, the project manager should defer to the subject matter experts and massage the project rather than dictate. Specifically within an endeavor with some artistic flair, artists dislike dictators.
  • Stick to your estimates. You know how long the work is going to take, then add another 15%. The more you cave on deadline the more disappointing the result will be.
  • Build out the entire project tasks, to the extend that you can.  A website is not an agile development process, it’s waterfall.  Managing an existing website may fit the agile model, but not a revamp or start from scratch project.  Think of everything you possibly can before the first line of code or animated gif (j/k).  Then, create stories/tasks for the unknown, quality testing, changes, more testing and deployment.  Make sure to assign actual “hours” to these things unless your stakeholders understand the abstraction of story points or else it won’t get through their heads, then show them the damn chart.  This thing is going to take 9 months, not 3.
  • Before you launch, consider who will be your critics, what browser they are using, and what arcane corporate network policies they have forced upon them.

Well, that’s it.  I’m going to end my blog rambling and maybe for my next post get back into my usual technical or coding style articles.  ‘Til then, probably another month or two….

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *