Lessons From A Website Overhaul Project #1: Getting Started

I’ve recently wrapped up the launch of a long overdue website overhaul for my company in my role as the Sr. Web Developer.  First, let’s discuss my role in this title, it’s more to support IT with managing and working with the ever increasing scope of cloud applications, cloud services, webhooks and API glue that often comes with them for things like:

  • Amazon AWS and Microsoft Azure hosted virtual servers as well as some “cheap host” VPS systems that need to be maintained.
  • Email relay services like Amazon SES, Mandrill, Sendgrid, or whatever has been hooked up to do automated mailing outside of Exchange.
  • Salesforce / CRM systems because “you’re a webguy, you can get this to work”.  I’ll have to blog about this another time and then edit for profanity. Quick observant note, getting a company to use CRM tools efficiently is more about adoption, advocacy, strict process and accountability for personnel than any technical solution, if that doesn’t exist, it will fail.
  • Various other web applications like ETQ, JIRA/Confluence, the list goes on.

Another important note, this lesson is from the company/client perspective who is doing their own website with an internal team.

So, a brief history on this project before I discuss the things I learned.  This website overhaul project begins in earnest in May ’17. Early discovery and some poking about with some side projects had been ongoing since maybe November ’16. The entire project had been “talked about” and was under consideration since well before I joined the company in 2014.

From November ’16 on, I had overhauled a product website and also launched a business group specific, sub-directory website, within the existing monstrosity.  This was sort of the precursor to doing the entire corporate site, a proof of concept if you will, that I was (with a small internal team) capable of doing the work.  You see, up until this point the company had allowed Marketing (which consisted of 1 or maybe 2 employees at any given time) to manage the website rather than IT. The result of this was that the website had been perpetually managed, designed and updated through vendor contracts, which leads me to lesson 1.

Lesson 1: Internalizing a Company Web Development Team

There are a number of roadblocks to establishing an internal web development team for a company that has traditionally outsourced it’s website development, management and to some extent content management to a web design firm.  These include

  1. Proving the work can be done internally and why.
  2. Getting stakeholder buy-in and support.
  3. Defending cost, hours and time-frame estimate.
  4. Breaking the vendor dependency.

Proving the work can be done internally and why.

The first thing that you need to do is present a case for dropping vendors and internalizing some of the workload of website management and development. From a neutral perspective, there are many arguments for and against dropping a web development vendor, so I came up with a list of questions to ask, to come to an honest conclusion. The first rule of thumb for someone who is a solutions architect, which is what my title should really be, is to make the right choice. Don’t in-house your web development if it makes better business sense to contract that work.

  1. Will there be a cost savings? Make sure to factor in the hours and wages of the in-house team vs. the developer contract.  There are two phases to this in an design overhaul.  First is the project upfront, and then there is the continuous improvement costs.  Factor in who will be doing long-term content work to figure out this number.  Don’t forget that the 3rd party option still requires an employee liaison or team to dedicate some time to project management, QA and approvals. Hiring out the job doesn’t mean your company won’t have people in-house working on it also, so factor in that time.
  2. Do we have the talent or can we get it? Proving cost savings is one thing, but in a company that may or may not have web developers, graphic designers, and content editors on staff, acquiring a talent team for the project could also be a task. There will be no shortage of people who want to inject their opinions, but getting a small, tight team of 3-5 subject matter experts to really do the work is very important, and if you have to hire, can you hire temps or what will the longer term role be?
  3. Will the quality of work suffer? This is hard to answer without doing some proof work internally, then comparing it to the work of the contractor. It is also dependent upon the team you’ve put together and if you’ve been able to get a budget for the purchase of tools and services than can help improve quality, like Adobe Creative Suite for quality graphics, or a professional grade content management system with theme and plugin support instead of WordPress (my blog is WordPress, so nothing against WordPress, there are awesome some sites on WP).
  4. Will it get done?  A contracted web developer will want to complete the project within a given time-frame, they base their quote and potential profit around this delivery of a final product, then possible a support contract afterward, so as a decision maker this is a reassuring motive for completion. With an in-house team, will you spend time and wages on a group that may take a long time, if ever, to complete the project?

Answering these questions honestly to yourself first, will prepare you for what is next if you decide to go with the in-house solution. You will need to present the argument that you believe is the best way forward to executive decision makers.

Getting stakeholder buy-in and support

Ultimately the people who make the decisions at the top will determine the course of action. In my case the stakeholders had been wanting to get the website updated, but the cost estimates that Marketing in 2015 was getting from vendors was prohibitive. In this case the Marketing director at the time as a stakeholder, was the roadblock to progress, as he had a personal relationship with our existing web developer. That, on top of a prevailing attitude that was opposed change really prolonged getting a website revamp off the ground.

The marketing director was replaced in mid-2015, and the new marketing director also became a roadblock to stakeholder support, but in this case more because of various egos (including mine) and internal politics. By mid-late 2016 I was convinced on the argument to in-house the website and drop our web development firm, who I had been butting heads with since my first day on the job. The new marketing director (who I refer to from hereon as MD) wanted to re-hash the entire argument all over again, as well as implement their own brand of “ideas” and creative control over the process that was frankly, in my opinion “over-the-top” for our company. By mid-2016 the major stakeholders for the website overhaul were now starting to push harder for the project to begin, and MD had been faltering to get the project moving. I decided to put my ego aside and work with MD to gain their support as a stakeholder on in-housing the web design and development team. I went over the questions from above to prove that work could be done internally, and why. MD then, with my work in hand, went to the executive stakeholders and presented it as their own.

Am I bitter? Maybe a bit. I have a long history of being firewalled by management and supervisors from getting recognition for my work, but that’s a topic for another day. 

We managed to assemble an initial team of 3, not including MD. Besides me, there was a highly talented individual who was both a graphic designer and technical writer that was on-staff, and there was the marketing assistant to MD who would run the tasks of gathering user requirements and project management.  Our goal was to prove to the executive stakeholders that the in-house team option was viable, and to do so from early December ’16 to end of January ’17, we completely redesigned an existing product website and built an entirely new subsidiary website. The quality of work could have been better, but we were asked to meet a very aggressive timeline and we did. This proof work is what it really took to win the stakeholder support to get the green light to move forward with the company website overhaul project.  Then came the actual project planning phase…

Defending cost, hours and time-frame estimate.

We got the stakeholder support, should be all downhill from here right? Nope. Getting executive stakeholder support on doing a website overhaul with an in-house team was a win, but now we also had to deal with executive oversight of the project. We now had to layout a timeline, costs, and vision. The communication with executives, project planning and kickoff was in the hands of MD from Feb ’17 to May ’17.  I provided information and suggestions on time and cost estimates,  9-12 months for the entire corporate website overhaul, increase team size from 3 to 5, costs to get some premium pre-fab site themes we could work with, hi-res stock photos, maybe professional photography and video work.  By the time MD was let go in May ’17, they had caved to the executive board on the time estimate down to 3 months and to expanding the team by just 1 temp, not 2 full-time employees like I had suggested.  Not sure why exactly MD was let go, but that left the team short a manager and 6 months less to get the proposed work done, that we hadn’t really started yet.

Not really sure what the takeaway from this is, but those estimates are important. They need to be defended or else the result will be little support, short time-frame, and high levels of stress. Executive stakeholders are going to try an needle down those numbers, because all they see is dollars and cents. Just on premise they are going to push against the estimates to make sure their employees are not just padding the project a bit in an attempt to buffer against inefficiency.

It’s also a bad idea to intentionally overestimate in anticipation of being worked down on estimates. Give a confident initial estimate and stick to it. This is sort of what we ended up doing, while we ended up agreeing to an Aug-Sep site launch, we also revised the project scope to a set of release and post-release goals, and moved the targets into buckets to make the imposed timeline more agreeable. Basically an okay, we’ll try to have n features completed that are “good enough” to launch with, then wrap afterward.  More about this when I blog Lesson #2.

So, we managed to get the in-house team approved and get the project started, got a temp hired for a team total of 4, and my boss, the IT Director keeps asking me when we’d be able to drop the contract for our web design firm, which leads us to the next part.

Breaking the vendor dependency.

This can turn out to be really hard to do and there are a number of important things to consider when trying to do this.

  1. What does any existing contract specify and what does termination imply?
  2. Do they have proprietary rights to the design or content or any of their work that you may be keeping?
  3. Do they own domain names, web hosting or other services that your company has come to depend on?
  4. Overcoming the safe feeling of ‘outsourced responsibilities’.

Depending on the situation, you may find that your vendor has their hooks in deep. I’ve been on both sides of the fence. Once upon a time working as a web developer for an advertising firm, it was our intention to design sites in a complex way to force continued maintenance contracts, to get ownership of the domain names, and to control the site hosting account, basically holding a company’s website hostage to our contract.  During that same period, I also witnessed other firms that had done the same thing to clients that wanted to switch to us, and then had to navigate the untangling of issues to get everything sorted out. Luckily, our web overhaul project was not in a terrible situation because I had spent a good deal of time and effort getting a lot of our company’s assets and services migrated from vendors and our marketing department, in to the control of IT well prior to the project coming about.

The final hurdle was just getting people to accept that from a certain point in time, we would now be responsible for our website, it’s design, content, security and backups among other items. Having a vendor handle something like this is like having peace of mind, especially at a company that is a product manufacturer and hasn’t traditionally had people on staff with the knowledge and skill sets to do this work.

Along with the web developer, we had a separate SEO firm that was in my opinion, outrageously expensive. When I spearheaded disconnecting from them nearly a year before we started the web overhaul, it was even harder than normal with their slick talking CEO initially convincing our decision making stakeholders not only to continue the contract, but to increase it.  So one final piece of advice, cut the chord remotely if you know it’s over, like any bad relationship, don’t let them try to win you back in person with slick talk or crocodile tears. I managed to get that killed eventually, but we wasted a good deal of money that went underused with little to no ROI.

Conclusion

Well, this is just lesson 1 of the things I learned while doing a major website overhaul. I’ve done major overhauls before, but as a contracted developer working for a firm.  This time was different for me because it was from the perspective of the client. The major takeaway from lesson one has little to do with actual design and development, and everything to do with management, navigating complex corporate relationship dynamics, and overcoming self-imposed obstacles.

In my next post, lesson 2, I’ll discuss things I learned during the development phase. Then I will followup with lesson 3, the post launch fallout. Stay tuned, it gets even more exciting.

 

 

Leave a Reply

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