Lessons from Relaunching an Online Community

Background

In July 2007 I undertook a project to relaunch a web site for an online technical community. The 30,000+ member community consisted of application developers, report designers, dashboard designers, and IT administrators. There were three full-time employees (manager, colleague, and me) on the team, plus one somewhat technical contractor. The contractor was hired originally to help with some site design and maintenance, and given the shortage of available developers, I brought him on the project, even though I had my reservations about his technical abilities. As project manager, I had two main goals: 1) perform a technical migration of the underlying platform, and 2) redesign the look, feel, and navigation of the site.

The Project

I plunged head on into the project, developing and ranking business, user, and technical requirements, identifying stakeholders, developing project plans, and creating page layout designs and navigation flows. The original goal was to relaunch the community just before the user conference in early October, which gave me 3 months to pull this off. I was excited about making my vision of the community happen even though I had never managed a technical project before. After identifying all the requirements and getting sign-off from the key stakeholders, I worked with our contractor to identify all the customized code modules and then asked him to determine how to implement the same functionality on the latest platform. The customizations proved difficult and time-consuming to resolve and put the project 4 weeks over schedule. I was not going to make the early October launch so I revised the schedule again to target a late November launch, although I did not actively advertise this.

We had set up a development server with the latest software and had started to build out the pages by early September. Over the next month we tackled one technical issue after another but the issues never seemed to cease. I felt I was spinning many extra cycles putting out fires, making design changes, building and modifying pages at the expense of communicating with stakeholders, for example. In retrospect, by not committing to a launch date I allowed myself to be in constant develop and test mode. I learned that I should have prioritized better what I needed to accomplish and also held the contractor responsible for delivering on time. Better yet, we should have paid him a set amount for the project, contingent on delivering as agreed upon. Upon further reflection, I also made the mistake of looking to him to manage the project because I felt I was in over my head and not willing to take full ownership and control over the project.

By late November, I wanted to launch over the weekend. I had a go-no-go meeting with my Manager beforehand, but failed to impress him with my launch plan. It was apparent that there were too many gaps that could have put the community at risk. With a bruised ego, I reset the launch date to the weekend of December 8 and 9. By now I HAD to launch because we were way over schedule. During this time, I was contacted by our web marketing team. Based on an initial discussion, I made the mistaken assumption that they were not interested in my project but they came in at the last moment to request that all the designs follow the corporate standard. In a meeting with the team, I lost my temper as I was told by one member that he was going to recommend that the launch should be delayed AGAIN because the look and feel did not conform to standards. In the end, I pushed through this obstacle and was able to implement all the changes they requested but this was a stark reminder not only to err on the side of over communicating with all stakeholders but also to defend your project. Coming up to the launch weekend, we worked relentlessly to meet all the requirements but I felt I could have “worked the plan” better by being more stringent on the milestones. In the end, we worked all weekend and well into the night and delivered the new site, but had to sacrifice testing time. We did some testing right after we went live and everything seemed to be OK so by midnight Monday morning, we all went home. By the time I woke up the next morning, my inbox was overflowing with email about technical difficulties that employees were having with the site. While the launch was received well overall, we spent the next several weeks over the holidays fixing bugs and other issues.

Key Lessons

My key lessons were to do my homework before making time estimates, “plan the work and work the plan”, commit firmly to an end date, break the project into phases (that is a technical migration phase followed by a redesign phase), allocate generous testing time, hire the right people to be on the project, involve the stakeholder early and often, plan the resources required, and develop a more comprehensive project plan (scope, WBS, etc.) by closely following sound project management principles instead of just doing what I thought was logical.