Deployment

A Failed Deployment

Josh was ready for the project to be over. He had written many change orders and handled lots out-of-scope requests from the client. Worse, the project was behind schedule and the budget was depleted. Josh wanted to launch the web site and put this project behind him. The quicker this project became a memory, the better.

The launch involved importing a large data set and user accounts and upgrading a live, production web site. The development team had done the import once during testing. Although they had hit a few bugs, they had updated the script so that it would work better during the next import. However, due to the tight budget, they had not actually tested the new import script. Josh figured it would be a breeze and didn't worry about it. He scheduled the launch date and time with the client, met briefly with the lead programmer the day before launch to make sure everything was ready, and went to bed the night before hoping everything would go well.

When they started the launch the next morning, the situation started off poorly, and quickly got worse. Transferring several gigabytes of legacy data between the legacy network and the new server took much longer than anticipated. The data import failed during the first attempt, and the import script had to be updated and run again. This put pressure on the launch schedule for every subsequent item. Then, during the legacy user import, the system “accidentally” generated an unexpected e-mail to each user.

By the time the new site was scheduled to be live, the data import had yet to be completed and users were calling the client to ask about the e-mail notifications they received. An hour after the scheduled launch time, the client called off the launch and the old site was put back online. The launch failed and the client was frustrated.

Josh made a lot of mistakes here. First, and probably most damaging, is how the client will evaluate the project. Like it or not, the client will judge much of the project's success on how the launch went. A failed launch is embarrassing to you as a project manager, but it's likewise embarrassing for the client who has to answer to his superiors.

Secondly, Josh's preparations for the launch were inadequate. Launches are complex events that require planning and coordination among many parties, systems, and processes. A good launch is planned ahead of time and practiced, so the client and development team know exactly what to expect.

Josh's last mistake was failing to perform a full test of the data import. Data imports are fickle affairs that rely heavily on the network conditions between the two systems involved. The best way to ensure a smooth data import is to test the entire import process—every step, not just the actual import step—ahead of time, until you have it running smoothly.

In previous chapters we covered the steps and stages of a project in development, from idea to deliverable. Since deployments are so vital, we focus on this topic exclusively in this chapter. We provide a clear outline of how to prepare for a launch and share in detail the launch checklist we use to make sure that new sites go live smoothly.

Deployment Process and Planning

Launch day is an exciting (an end to a bleeding budget! Yay!) and stressful (what do you mean you need 12 hours to run the import?) event. With a little preparation, you can reduce the stress and increase the chances of a successful launch.

The launch event merits planning time, not only because you want it to be a success, but also because this is a time in the project when the client will be watching closely. A smooth launch builds credibility, trust, and faith. A disastrous launch is a source of frustration. (Remember: your client has to tell his or her boss why the thing did not go live.)

This often-used but rarely heeded advice is relevant for launch planning: plan for the worst, hope for the best. Everyone likes a secretly prepared optimist. No matter the planning, something bad will happen on launch day. The more of these potential “gotchas” you eliminate well in advance of the launch, the more time you have to address the hiccups when time is tight.

Here are some pointers for improving launch:

Pointer #1: Create a Launch-day Checklist

Not to be confused with the web site launch checklist we outline later, a launch-day checklist is really a step-by-step schedule of what needs to happen during the actual launch process. You can start this early in the project, the moment you come across something that will need to happen at launch (do this no matter how distant launch may seem or how simple the task might be). Once you have this document, it will be easy for you to add items to it over time.

This does not need to be a long formal document. It should be a simple list of concise steps for launch. Consider adding the initials of the team member responsible for completing the task at the end of each step. If a task requires more than one person, just pick one and assign them.

The launch-day checklist should include every discrete step needed for launch, including steps for

• Configuration changes
• Data imports
• Backups
• Code updates
• DNS changes
• Hosting changes
• Version control refinements
• E-mails to clients and team members (see “Tips for Writing E-mails” in Chapter 8)
• Scheduling new tasks for post-launch marketing
• QA testing (see Pointer #8)

Pointer #2: Double Your Estimate for the Time Needed to Launch

When telling the client how long a launch will take, be sure to double your estimate. Problems will occur; give yourself a bit of breathing room.

Pointer #3: When Possible, Perform a Soft Launch

A soft launch is when you make an application live ahead of when it will first be seen or used by a larger audience. If you are launching a new site or application and not replacing an existing tool in production use, you can likely roll out the project a day in advance of when it is advertised to be ready. This will ensure that if there is a problem, there will be time to address it. If your client is planning a marketing blitz for a new site, launch in the afternoon the day before the “marketing launch day.”

Pointer #4: Be Leery of Time Estimates for Data Imports

If your launch includes a data import step, be sure to run a complete test on the import well ahead of the launch to confirm that it will run in a reasonable amount of time. Ensure that your test uses both the same amount of data and the same transmission path as the launch import will to check for network-induced delays.

Pointer #5: Meet with the Development Team Several Days Before Launch

No matter how straightforward you expect the launch to be, have a meeting with the development team that will be launching the project. Bring your draft launch-day checklist, and spend the meeting going over the steps you will use to launch the site. Ideally, this will help your team identify any potential issues you have not thought of, giving you time to plan out how to mitigate them.

Additionally, use this meeting to make clear what you expect from each team member on launch day and how you will communicate. For example, if you are launching on Sunday morning and everyone is working from home, you can agree to meet over instant messaging and invite them to a group chat.

Pointer #6: Update the Client When You Start and Complete the Launch

Be sure to send a quick note to the client when you start the launch and when you finish it. This will make them feel involved and reduce ambiguity over how the process is going.

Pointer #7: Double-Check Your Third-Party Integration

Your site likely has some dependence on third-party tools, be it a simple newsletter sign-up form or a more complex centralized authentication mechanism. Launches involve big configuration changes, so double-check that nothing needs to be updated in your project for the external integration to continue to work (like different credentials intended for production use).

Pointer #8: Test!

Once the actual launch is complete—but before you have told anyone so—you should perform testing on the site. Ideally, your launch-day checklist should have a series of quick tests that you and the team can perform on the site to check for any issues.

Here are some general tips:

• Breadth over depth: make sure you hit every major section of the application, rather than test every detail.
• If you need ideas for what to test, review your testing checklist for the project.
• Try to keep the list short (10 to 25 items).
• Ensure that each testing item can be easily validated.
• Speed up testing by dividing the checklist items throughout the launch team.

Only after you have tested the site should you feel confident about announcing the launch is complete.

Training

Training is a key step in the successful launch of a project, both because it prepares users to properly beta test the application and because users will be unaware of features they will think are missing.

Here are some tips for delivering training:

• Have a clear training agenda. Like a normal meeting, it is important to have a clear agenda of the topics you will cover. This has two benefits: trainees will have a sense of what to expect in the training, and you will likely remember to include topics in your agenda that you might normally gloss over.
• Do not assume that something is obvious. As a project manager for a web project, your own history of using, developing, and enjoying web applications means that you have a catalog of knowledge about how various interface mechanisms work. You might think the client has this knowledge, but they do not.
• When you start the training, make it clear that questions are welcome. The client team in your training is likely to include people who have not been on the project team. These people do not know you and are often more junior than the core client team. They need to know you are friendly and happy to answer questions or go over something again.
• Don't show, do. It is more helpful to a trainee to see how you do something than to hear how it's done.
• Have the users try, too. Showing is great, doing is better. If you have the facilities for each team member to be online, consider showing a feature and then having the client try what you just showed. You do not need to do this for every feature, but focusing on a core set will produce some good questions from the client.
• Practice makes less bad. Be sure to run through your training agenda before you deliver the training. You want to catch any embarrassing bugs or configuration issues that could impact training before you are in front of the client.
• Make training the beta kickoff. There is not much to be gained from training the users on the system without a clear goal or next step. Make the training session the kickoff for the beta testing. This way, you will follow up a training session with an immediate reason for the client to actually use the application, helping to increase retention.
• Take notes. Because the training session is likely the first time you are showing the client a functioning application, be sure to capture any misconceptions in design from feedback. You will not have time to do anything with these now, but have them written down so they can be included in the post-beta wrap-up.
• Have your materials ready. During training you are likely to need media assets, such as images, when demoing features. Have these ready before your training and, if possible, make them relevant to the project. (For example, you can pull images from the client's web site.)

The Launch Checklist

We have already discussed the power of checklists. Used effectively, a simple, targeted checklist can be very effective in reducing errors and decreasing the likelihood of future issues in a project. A checklist is especially vital when launching a web site because the project will be evaluated in the first 5 minutes the client spends reviewing the site once it is live. For better or worse, there is a very limited window when the impression of your work quality is formed.

To help ensure the smooth launch of web site projects, we run this checklist against a site shortly before launch. Although not every element in our list will be appropriate for your projects, this should help you to write your own checklist.

The Web Site Launch Checklist

This Launch Checklist is not a replacement for quality assurance testing. Rather, this Launch Checklist is a final opportunity for you to ensure that you have taken care of the many important details that are sometimes overlooked in the rush to launch a web site.

• Cross-Browser Check

  Test the site in the three most common browsers in use¹ (double-check that your list includes the browsers you know to be in use at the client's office) and ensure the visual layout is consistent.

• Basic or Advanced Web Accessibility Measures

  If the project includes Section 508 accessibility compliance, make sure that the site still meets these criteria by using an automated assessment tool available on the web.

• Forms Check

  Fill out a form on the site (like a “contact us” form), and ensure the form submission works and the spam protection is active.

• Graceful Degradation

  Turn off JavaScript in your browser, click-browse through five pages, and verify that the site is still usable.

• Print Style Sheet

  Print the homepage and ensure that unnecessary elements are hidden (such as side navigation).

• Install an SSL Certificate

  If the site has any kind of login, purchase and install a valid certificate² and ensure the login page forces connections over SSL.

• Domain Standardization

  Ensure that requests without the “www” are redirected to the same page with the “www,” and that by default the web server is compressing all text files (like CSS, JavaScript, and HTML pages).

• Analytics

  Update the analytics settings for your site to use the profile associated with the production domain name. If available in your analytics software, set up a monthly report to be e-mailed to the client.

• Custom 404 Error Page

  Check that the site has a nice 404 (not found) page. Search the web for “cool 404 pages” for some ideas.

__________

• Page Titles

  Ensure that every top-level category page has a different clear and concise page title.

• Home Page Meta Description

  Add a one-sentence description of the site in a META tag in the header.

• CMS Refinements

  It is likely you are using some kind of content management system for the site. Ensure the settings for your CMS match the requirements provided by the vendor for production web sites.

• CMS Accounts

  If your project uses a content management system, ensure that an account for the client has been created and that the permissions assigned to that account are sufficient for all client needs, but do not include super-user level access.

• Automated Site Link Check

  Use the W3C Link Checker tool to quickly identify and fix any dead links.

• Broadcast E-mail Integration

  If your project includes integration with a third-party e-mail system, verify that the subscription form correctly subscribes people to the desired mailing list, the list is sensibly named, and the subscribe and unsubscribe pages are branded with the client's logo.

• Favicon

  Ensure the web browser favicon is loading correctly.

• QA Review

  Being involved with a project for a long time often blinds you to problems that might be present. Ask a team member who did not work on the project to spend 30 minutes performing some basic tests of the site and provide feedback on possible bugs and sections that do not make sense.

• Review Proposal, Amendments, Requirements

  Double-check the project proposal and requirements documents to ensure that all site components have been addressed.

• Send Launch E-mail

  Usually, the launch of a site will trigger a new phase in the project (such as a 30-day post-launch support window). Send a friendly note to the client congratulating them on the launch, alerting them the site is officially active, and documenting that support has begun.

• Send a Gift!

  The client has worked hard over the past several months to help you launch the site. Commemorate their achievement by sending a gift basket.

• Marketing

  Consider mentioning the project launch on the company blog, the company Twitter account, to colleagues that might be interested in the project, and as an article or case study in the articles section on your site.

The characteristics of your own projects will define what kind of launch checklist is most appropriate, but do take the time to create and document one. The benefits will become quickly apparent.

The Importance of Defining Post-Launch Support

It is a truth universally acknowledged that a project, once launched, must be in want of a set of a bug fixes. Creating software is hard, complicated work. Though you and your team worked diligently to ensure a product of high quality, there will always be issues that you cannot identify during testing, refinement, and launch.

Less experienced clients may expect you to support the software you created indefinitely, but this is impractical for all involved. It is fair that the time your team spends making refinements is compensated, and post-launch support cannot go on forever. However, you want to be sure to balance protection of your budget with showing that you are dedicated to the successful launch of the project.

If you are not up front about how post-launch support will work, then the client will be left with only their own expectations to guide their behavior. Those expectations will inevitably be at odds with your own.

The best way to achieve this is to define well ahead of time a specific cut-off time for post-launch support. You can and should put this in your scope of work. You can also clearly state how post-launch support will work when you are sending an e-mail update to the client about the upcoming launch.

Be explicit. Here is an example:

Hi Team,

I wanted to write to give you an update on the launch schedule.

The web site launch will kick off a 30-day support window. We will address any issues reported during the 30 days after launch under the original scope of work. Any issues identified after the support window will be addressed on a time-and-materials basis or under a separate support plan (if you prefer to set one up).

Kindly let me know if you have any questions, concerns, or wish to discuss further. I'm happy to set up a conference call if you like. Just let me know.

Thanks,

{call sign}

By clearly stating how the process will work, there should not be any frustrations or surprises when, a month after launch, support is a new cost.

Wrapping Up

Hopefully this chapter will help guide you through a successful deployment for your project. A properly planned and tested launch will ensure a positive capstone to what we expect was an otherwise successful project, a happy client, and a satisfied project team. However, launching is not the end.

An important client expectation to manage is how the project will be managed and supported by your team after launch. You can't support a project forever under the existing scope that defined the creation of the project, but you can ease the transition by making it clear how support will work.

In the next chapter, we cover the topic of post-launch support in detail. We start with a look at a challenging support client, discuss the different kinds of support you can provide, outline the key topics for an effective support orientation, and argue the importance of being responsive. We also provide tips you can use to deal with a common problem faced by project managers: supporting a project your team did not build. We conclude by outlining an easy technique you can use to provide effective proactive support.