Missed deadlines, poorly thought out requirements, and a lack of leadership are enough to doom anyone's project. How do you put such a train wreck back on track? Benny Sisko shares his experience of having to take control of a project gone wrong.
The story begins in 2005 long before my arrival. The company's web site was identified as a weak spot in need of an overhaul so IT and marketing got together with a whole lot of other people - so-called "stakeholders" - and undertook the task of starting from scratch with a new content management system, new content update policies and a lot of ideas. Now, to be fair, since I wasn't there, I don't know exactly how conversations went. However, from the conversations I had after my arrival, it appeared that the new site was the epitome of "design by committee" and that there was no one willing to just say no when it came to an idea. As a result, the overall design ended up being a watered down mess with elements that simply made no sense; everyone's wishes were met but the end result was less than spectacular.
To make matters worse, about halfway into the process, the then-CIO, my predecessor, left the organization for greener pastures and the company installed one of the existing IT staffers as an interim CIO while a search was conducted. This interim CIO continued with the project, but definitely had his own spin and timetable. He was intent on finishing the project on his watch, no matter what.
About three weeks before I started in the position, I had my first status call with the interim CIO. Now, at this point, I was aware only that the web site project was underway; beyond that, I had no particulars. During the call, he told me that the project was going well and that the site would launch soon. I asked for a link to the beta site and, upon visiting it and expressing serious concern given that the design was poor, navigation was unfinished and very, very little content was available, was assured that everything was on track. Not being the "official" CIO yet, I didn't push too much. After all, I'd be on site in a scan three weeks and could get a better lay of the land at that time.
Then came the Monday morning call from the senior vice president of the organization. The Monday in question was the day before I was supposed to start. I was helping my wife unpack boxes in our new house and planned to be in the office bright and early on Tuesday. Plans changed and I ended up in the office Monday afternoon with the senior vice president, the web developer, the interim CIO and one of the content people expected to manage content for a critical section of the site.
The interim CIO had launched the site over the weekend without my knowledge; the weekend before my arrival. To be fair, the site wasn't launched in a vacuum; the interim CIO obtained approval from the executive team before throwing the switch. To say that the site was a wreck would be a kind assessment. The design was awful - navigation elements existed in no less than three places on every page and the design itself included nicely rounded interior corners in the main content section with non-cropped square cornered pictures crammed in leaving really, really ugly white space. In short, the site looked amateurish. As for content, less than one-third had been migrated from the old site to the new, leaving gaping content holes and error pages all over the place. Worse, the main customer portion of the site was still on the old content management system, complete with links to both the old content and the new - some working and some not. Finally, one of the critical areas of the site used to get new customers no longer worked.
Perhaps most telling was the front page of the site. It was a train wreck with no focus. Sure, it had news and links to all kinds of things, but didn't target any primary audience. Every stakeholder in the organization was well-represented on the front page, though.
Failure in this project existed at every level. The group responsible for the project needed clear leadership and expert guidance, but got neither. Realistic deadlines were not set and no one held anyone accountable. The content management system itself was flawed as well. Not enough licenses were purchased to cover everyone that really needed to do content updates for the site. As a shoehorn, the IT department, who was overseeing the overall effort since marketing had smartly moved away to escape fallout, attempted to augment job descriptions for people outside the IT department to include dotted line reporting responsibility to the web coordinator to institutionalize web content updates and to hold people accountable for them. No one pushed back on the job description changes and they were approved but without a whole lot of thought really going into them. When I inquired about the design issues, I found that many items had been last minute tweaks implemented to satisfy this or that member of the overall web committee. For example, the little rounded corners idea came at the very last minute and rather than push back and say no to the request, it was designed in and no time was left for any of the existing pictures to be cropped to fit the new space.
I quickly disbanded the web committee upon my arrival and a new web developer and I took it upon ourselves to correct the most egregious flaws in the new site. By the end of that year, the site was in reasonable shape after having undergone some design tweaks intended to make the site passable. A whole lot of time was spend moving the remaining 70% of the content that had not been moved prior to the launch. We also fixed the customer-facing forms so that we could do business!
Once the site was stable, we took a stock of where we were. Could we use it? Was it worth building on? Was the underlying content management system viable?
After a lot of hard though, the answer to all three questions was no. In fact, shortly after we decided that the CMS would not be used for the next iteration of the site, the vendor announced that the product was going end of life.
From that point, we spent the next year designing the next version of the corporate web site. Based entirely on SharePoint 2007, we would no longer be limited to having to allow only specific users to make content updates. The learning curve proved to be immense, but the end result was worth it.
This time, we moved forward with a very small group consisting of me, my web developer, our marketing director, sales director. SVP and CEO. We and we alone chose the new design. When it came time to build navigation, we met individually with every department in the organization and helped them define a navigational structure for the new site, but enforced some structure. Further, we identified clear audience pathways on the front page. In fact, we designed the whole front page around the needs of our primary customers; other visitors have audience links that take them where they need to go. This elimination of clutter from the front page created some consternation in the organization, but we stuck to our guns.
The end result is a product that far outperforms its predecessor in every measurable sense. In fact, the site has been measured by neutral third parties and the metrics clearly indicate that the new site is a winner.
In both cases, no one "went it alone" to achieve the goal. However, in the second case, a smaller group was employed to complete the project and people were brought in as needed to make recommendations and to help develop their individual areas. This time, the team wasn't afraid to say that certain elements simply would not make it to the site as they didn't fit the design or intent. We also planned regular milestones, which were mostly met, so that progress could be gauged and people knew when to expect the final product and so that we could make necessary course corrections if necessary. We gave ourselves a year this time around from project inception to launch. I will admit that we missed our hoped-for launch date... by one week.
The takeaway here is simple. Even the best decision-making teams need leadership, direction and sanity checks along the way. Keep initial implementation teams relatively small and bring people in as needed. Set milestones and stick to them as best you can. And, most imporantly, be honest with yourself. If the project is failing or it's obvious that the end result will suck, fix it!