David Newcorn, Director New Media, PackWorld.com and AutomationWorld.com, has a Web development story that puts most others to shame. Newcorn and his team needed to redesign and relaunch two websites to deal with an issue facing many online publishers: outdated technology and limited in-house capacity to keep up with fast-changing Internet technology.

They thought a big, experienced vendor would provide the development expertise and customer service they needed. “I was romanced by a company that said, ‘We have 150 developers; our content management system is enterprise class.’ It was really appealing to have this big company behind you, but launching the websites became a comedy of errors.”

Instead of receiving an enterprise class website in the promised nine months, they got trapped in a 15-month ordeal that included firing the first vendor and the replacement company -- without receiving a scrap of usable technology in exchange for the tens of thousands of dollars spent on botched development.

Eventually, they hired a third vendor that delivered two completed websites in 10 weeks. Newcorn didn’t get any of their money back, but he learned several important lessons about managing a big Web development prospect that all publishers need to know:

-> Lesson #1. Check references

It’s the most common advice when hiring any contractor, but Newcorn admits they never called the first vendor’s references. Instead, they saw some prominent publishers on the company’s client list and figured that was endorsement enough.

Only after firing that vendor did they learn that some of the existing customers were unhappy with the company and were thinking about dumping them. But Newcorn also learned that references don’t tell the complete story. They checked references for the second vendor and heard strong endorsements from customers, but still found the company’s culture and design ideas incompatible with their own.

For example, Newcorn wanted a collaborative process, but felt the vendor didn’t value their suggestions and, instead, dictated ideas and approaches from their “expert” position. “Don’t overlook the importance of different corporate cultures. It sounds touchy-feely, but it’s one of the main things that sunk this process.”

-> Lesson #2. Prepare the right documentation

Newcorn and his team spent days writing what they thought were comprehensive design notes and functionality requirements for the vendor to follow. Yet, when they finally saw preliminary designs a few months later, it looked like the development team hadn’t even read their notes.

Only later, when Newcorn showed the documents to a friend in the IT industry, did he learn that they hadn’t given the vendor a proper requirements document -- an essential starting point for Web development. Nor did the vendor request one.

Their first approach was more a collection of ideas, samples of other sites they liked, design preferences and open-ended questions Newcorn thought the vendor could answer because of their expertise. Instead, a requirements document should spell out in concrete terms exactly what you need from the new site. Here are Newcorn’s tips:

o Outline each page you need designed, from the home page to how individual stories or other content will be displayed
o Be as literal as possible in describing every aspect of the page or, better yet, have an in-house designer mock up the look of each page
o Clearly define the functionality and navigation architecture

From this document, the vendor should prepare a specifications document, outlining how they intend to build the site to incorporate those requirements.

-> Lesson #3. Take an iterative development approach

Newcorn’s first vendor promised to do the work with minimal interruption to Newcorn’s daily life once they received the requirements. “They said, ‘You tell us up front what you need, we go away for six months, then deliver a finished product.’ ”

It sounded too good to be true, and it was. Newcorn and his team learned that Web development requires constant synchronization between the customer and the vendor, allowing you to provide frequent feedback and continual refinement of the site during the process.

His recommendations:

- Instead of establishing a few big, long-term deadlines, work with your vendor on smaller, shorter deadlines, such as designing and developing one piece of the site at a time. This approach allows you to “course correct” or react to changes in the marketplace that may call for changes that weren’t spelled out in the original requirements document.

- Ask to see designs of every major template on the site before any programming functionality is added. This way, any changes you need won’t require programmers to go back and redo work.

-> Lesson #4. Demand a project manager

A complex site construction requires someone skilled in formal project management. The first vendor, instead, put the lead developer in charge of the project -- but Web development and project management are two different skill sets.

When problems arose, Newcorn says, the developer’s reaction was simply to dig in and furiously write code rather than take a step back and determine whether another step, such as refining the approach to the project, was necessary.

Constant communication between the client and the vendor is also essential, and they eventually demanded that the vendors use an online project management tool, where they could track the progress of the project.

That tool included:

o A breakdown of the project into a series of discreet tasks
o Information on who is responsible completing those tasks
o Status reports tracking the weekly progress of each task
o All documentation related each task

“We heard pushback from some vendors who didn’t want to use a collaboration tool or wanted to charge us extra for doing it, but you don’t want to have to dig through old emails to keep track of all your communication.”

-> Lesson #5. Build incentives and penalties into your contract

The first contract Newcorn signed was 28 pages long and filled with “legalese.” Although it contained targets for delivering a finished website, it didn’t contain any language binding the vendor to that deadline. Instead, Newcorn's company was the only party on the hook for the monthly development payments specified in the contract.

By the time they found their third vendor, Newcorn decided to ask if they would accept a system of rewards and penalties around the project deadline:

o They agreed to pay a bonus if the vendor completed the website two weeks before their deadline
o The vendor agreed to pay a penalty if the website was delayed by two weeks and additional penalties for every month delay after that

The vendor delivered both websites early. “That incentive money was the best money we ever spent on technology. It ensured they would always pay more attention to my project.”

-> Lesson #6. Know when to start over

It’s not easy to dump a vendor when you’ve invested tons of time and thousands of dollars into a project. Unfortunately, there’s no secret for knowing exactly when to walk away.

Newcorn and his team finally made the decision to fire the first vendor after more than nine months, because of two warning signs:

o Little or no progress in solving the problems
o A loss of trust in the vendor

Jumping ship at the first sign of trouble isn’t smart, because the vendor may be able to solve the problems and get the project back on track. Instead, Newcorn and his team waited until they saw a pattern of unmet promises and little progress toward a completed site.

Walking away from the money already invested became easier once Newcorn realized they didn’t want this vendor as a partner for the long term. Even if the project could be salvaged, they knew they would be tied to this developer for the foreseeable future for any updates or tweaks to the site. If you’re not comfortable with the vendor’s process, you don’t want that kind of long-term relationship.

-> Lesson #7. Don’t build everything from scratch

Building a huge content website entirely with custom code may be necessary in only extremely special cases. Before they started, Newcorn was attracted to several off-the-shelf software components, such as content management systems, but says their first vendor had Not Invented Here Syndrome -- meaning if it wasn’t built by them, it probably wasn’t any good.

The new sites they ended up with, though, employed functionality from third-party developers, including an open source content management system, which Newcorn says offers the benefits of good technology without tying them to one developer for future updates.

His advice: If you find good off-the-shelf software that offers the functionality you need, your vendor should be able to integrate it with the custom code and design that you’re paying for.

Lesson #8. Avoid unnecessary complexity

Just because you’re building a new site, don’t assume anything and everything is possible. In retrospect, Newcorn realizes they asked for too much with their first vendor. For example, they wanted a complex, integrated reporting tool that would allow different teams in his office -- advertising, editorial, business operations -- to get data in one place.

At the time, they thought the vendor should have given more feedback about certain features that would take months to build and add significant cost, but now Newcorn says it’s the project owner’s responsibility to critically think about what features are must-haves.

His rule of thumb: Unless a feature will directly increase revenue or decrease costs, put it on your wish list. “Anytime someone wants to make a change or propose a new feature, ask what the business reason for it is. A lot of these projects bogged down in minutiae.”


Useful links related to this article

OpensourceCMS - a resource for tests and reviews of open source content management systems:
http://www.opensourcecms.com/

Joomla! - the open source content management system that Newcorn:
http://www.joomla.org

M29 - who ultimately built the two websites:
http://www.m29.com/

AutomationWorld.com
http://www.automationworld.com

PackWorld.com:
http://www.packworld.com