Top Flight Web Strategy

Until recently, many companies pursued Web development in much the same way that early pilots approached crossing the Atlantic--just trying to make it to the other side alive. If you're still trying to navigate the stormy weather of online ventures by dead reckoning, it's time you started thinking about developing a Web strategy. Here, we show you how to devise a sound plan of action.

When Charles Lindbergh undertook his historic flight across the Atlantic, he was armed with no more than a compass to guide his way; ultimately the success of his plan was measured by whether or not he survived the journey. Lindbergh got the job done, but later aviators began concentrating on making the job less risky, using avionics, navigational equipment, radar, GPS, and collision-avoidance systems. Until recently, many companies pursued Web development in much the same way that early pilots approached crossing the Atlantic--just trying to make it to the other side alive. If you're still trying to navigate the stormy weather of online ventures by dead reckoning, it's time you started thinking about developing a Web strategy.

To help you devise a sound plan of action, we'll show you how to chart a course with well-defined goals, develop the groundwork to implement your project on time and under budget, and measure the success or failure of the overall strategy.

Pretakeoff site planning
The first step in getting a Web strategy airborne is to isolate goals, map out components, and set benchmarks.

Piloting your Web project
Hammer out a strategy and negotiate conflicts when you aren't quite sure who's flying the plane.

Paging air traffic control
Make sure your project proceeds in an orderly and efficient manner by staging your strategy to isolate what is mission critical and what can wait for later.

Avoiding delays and cancellations
Developing an accurate project budget and timeline will keep all your passengers happy.

Flight debriefing
It's time to take a step back and bask in your success--or learn what made your project crash-land.

Pretakeoff site planning

The first step in developing a Web strategy is isolating goals for your online property and ensuring that these match the larger business goals of the company. Your director of business development should already have the business goals established. Your job is to decide how your Web strategy will address these goals and to lay a course for success.

The initial draft of a Web strategy should present:

  • a direct correspondence between the Web strategy and specific business goals. For example, if your company's main goal in the coming quarter is to increase revenue, how will a plan to develop new editorial content address that objective?

  • a high-level road map of strategy components. Eventually, these components will be developed in detail, but during the initial planning stages, more broadly defined elements should suffice.
  • demonstrable benchmarks, such as projected page views, revenue, mailing list subscriptions, and other measurable data.

As an example, let's examine the Web strategy of a company that sells coffee tables and has a peripheral online property. For the upcoming quarter, the company plans to expand into the bar stool market, and overall business goals include repositioning the company brand and increasing revenue.

A Web strategy designed to address these dual business goals might include elements such as developing new content related to both bar stools and the new corporate brand, restructuring the site's architecture or implementing a multiphase redesign, adding new e-commerce components, and selling additional advertising space. Besides setting benchmarks for projected revenue, one of the strategy components might be a user survey that would generate data on brand perception and the relative success of the strategy's brand-repositioning efforts.

While developing your short-term and long-term Web strategies, don't forget to:

  • undertake a competitive analysis before formalizing any large-scale implementation;
  • stay informed on future business goals and how they may affect the scalability of your current strategy;
  • talk to your business director about future partnerships or third-party relationships that could facilitate the implementation of your strategy;
  • plan ahead for the integration of offline and online data.

Piloting your Web project

While devising and implementing a Web strategy, one of the most challenging aspects of the project is navigating the relationship with your client, who, for an internal project, is also your boss or business director. Not only do you have to consider your position in the hierarchical power structure of the company and your boss's expectations of you as an employee, but you also have a vested interest in the final implementation of the strategy. Unlike a third-party consultant, you'll be around long after the barnstorming is over, and you might even be held accountable for the success or failure of the project. To make sure there aren't too many captains in the cockpit, utilize particular negotiation tactics and define appropriate times for your boss to intervene to offer input or final approval.

During the initial strategic planning phases and brainstorming sessions, your primary role will be to understand your boss's goals and vision of the project and then offer a strategic plan of action. Depending on what type of client your boss most resembles, he or she might have either specific or general ideas concerning the architecture, content pieces, and visual design, and you'll want to offer a solution that addresses your boss's needs and desires while drawing on your own knowledge of best practices when it comes to Web strategy. This means that, throughout the planning and implementation phases, you'll have to walk a fine line between acquiescing to a superior's desires and asserting your authority as the Web strategist.

How to handle conflict resolution when your boss becomes a difficult client:

  • When negotiating alternative solutions, focus on the underlying goal of your boss's proposal. Offer alternatives that still meet the desired goal.
  • When demonstrating why your solution is more viable, focus on bottom-line implications that matter to decision makers--namely, time and money.
Once you get past the initial discovery phase with your boss, you'll want to formally delineate the points at which your boss should be involved in offering feedback and sign-off. If your boss has a hands-off management style, it's important to get his or her approval at regular intervals to avoid large-scale changes at the end of the project implementation. If, on the other hand, your boss tends to micromanage, you should define specific points at which input would be useful and valued in order to streamline the process. You can formalize these points by drafting a process document that indicates milestones where final sign-offs are needed.

Paging air traffic control

While formalizing the big picture of your Web strategy, you can begin staging the development of the project components in order to decide the sequence in which the parts should be built. Generally, the order in which project elements are built and implemented will depend first on time constraints and then on the relative value of individual components. For instance, if the product needs to launch in four weeks but the entire build time is two months, you'll have to decide which parts are absolutely necessary for the project to launch and which are secondary or tertiary and, thus, can be built later.

To return to our example of the coffee table company expanding into new markets, part of our Web strategy includes adding a new area on the site for bar stools. As part of our implementation on the front end of the site, we might specify a top-level directory, subdirectories for wooden and metal stools, and specific product pages. For the company's own administrative use, we'll also need to build a tool that will give us statistical data on sales as well as the ability to track orders, process payments by check, communicate with specific groups of customers, and perform a variety of other tasks.

First, list all of the individual components of the project:

    Front-end site components
    top-level bar stool directory
    wood bar stool subdirectory
    wood bar stool product pages
    metal bar stool subdirectory
    metal bar stool product pages
    order-processing component

    Administrative components
    statistics section
    order records
    payment processing
    order fulfillment
    customer communication center--batch and automated e-mail functionality
    search

Next, order the components based on the relative value of each element (this order will vary based on your own project analysis):

  1. front-end product pages
  2. front-end order-processing component
  3. admin. order records
  4. admin. payment processing
  5. admin. order fulfillment
  6. front-end subdirectories and top-level directory
  7. admin. search functionality
  8. admin. customer communication elements
  9. admin. statistics section

After staging the project to determine the build sequence, establish how much the project will cost and how long it will take to complete.

Avoiding delays and cancellations

Perhaps the most important skill to develop as a Web strategist is the ability to accurately gauge how much a project will cost and how long it will take to build. Most of the costs incurred while implementing your strategy will come from labor and resources used, and this should be fairly easy to calculate once you have your development timetables set. Developing an accurate itinerary is trickier, but this only gets easier as you get more projects under your belt.

When developing a timetable, you may find it helpful to use a project management application such as MS Project, but it certainly isn't necessary. Simply follow these steps when developing a timetable:

  • Break down each component of the project into discrete processes and elements handled by various resources or departments, such as conceptualization (specifications, site maps, and page schematics), visual design, HTML coding, functional programming, content creation, marketing campaigns, and QA testing.
  • Estimate how long each development process will take to complete. Be realistic. Business directors might imagine that a strategy can be implemented on short notice, but an initial conceptualization phase alone might take three to four weeks to finalize.
  • If you need to get sign-off after certain phases, factor these in as independent elements in your timetable.
  • Determine which processes are dependent and which can be developed simultaneously. For instance, coders will probably have to develop the HTML templates before programmers can integrate functionality, but editors and writers can work on content while other elements are being developed.
  • After you've mapped out all processes and assigned each a duration, determine start and stop dates for each element. The stop date of the final process of the last component will be the date you'll be ready to launch.

When developing timetables, it's paramount that you allow enough time in your schedule for edits, revamps, QA testing, bug fixing, and final sign-offs, since these are the most difficult elements to quantify. At the beginning of a project, there's no way to estimate the number of iterations the project will go through, the amount of technical bugs QA testing will reveal, or how long it will take to track down a decision maker to get final approval. To allow for these unknowns, it's generally wise to double your original timetable estimates.

After finalizing your timetable, determining project costs will be fairly straightforward. For each resource, simply multiply the number of hours necessary by the corresponding hourly rate, or, if you're paying consultants and freelancers on a project basis, obtain bids and estimates based on the project specifications. Other costs to consider might include additional hardware, software, and partnerships with third-party vendors. Again, when it comes to money, it pays to be realistic in the initial planning stages. If the strategy is going to cost the company more than a fleet of Concorde jets, it's better to sound the warning bell at the beginning of the process rather than having to defend a stack of bloated invoices at the project's conclusion.

Flight debriefing

After the dust has settled on your project, it's time for a final critical examination of your Web strategy. You should undertake the project's postmortem while the proverbial body is still warm, either directly after the conclusion of the project or campaign or at a predetermined date relevant to your company's fiscal calendar. The postmortem is the vital final step in a well-developed and well-executed Web strategy, offering the opportunity for both team members and managers to analyze the project's success or failure and to cogently synthesize knowledge gained.

When composing a postmortem report, focus on two main elements: measurable goals met and lessons learned. Directors and decision makers will want to know if your strategy met outlined business goals and whether the product was delivered on time and within budget. The remaining portions of the postmortem should provide a detailed record of what worked and what didn't so that you and your team can apply this knowledge to your next Web strategy. More specifically, the project postmortem report should address the following questions:

  • Were the strategic goals initially outlined actually realized?
  • What was the actual development timetable and budget for the project? How accurate were your original projections?
  • In what ways was the strategy a success? What elements of the implementation worked particularly well?
  • If you had to do it over again, what would you do differently? For you and your Web team, this will be the most valuable aspect of the postmortem examination. Be sure to detail any technical problems, unanticipated user errors, positive and negative feedback, resource issues, and any other lessons learned that might be applied to future ventures.
You don't have to wait until the project is dead and buried to learn valuable lessons, however. You should be thinking of your final investigation throughout the development and implementation cycles. Before you hit full throttle, begin keeping a log of elements that work and don't work, and be sure to maintain a constantly updated specification. After continual improvements and bug fixes, your original specifications will not precisely reflect the finished product, and you'll want a record of the project as it actually went down--not just as you initially planned it--in order to properly dissect and understand what you've created.