Support and Operations

Sam the Entrepreneur

Sam is an entrepreneur who runs a small business that sells a variety of specialty computer components from a busy web site. He has two staff members who help run the business out of Sam's garage, handling fulfillment. Sam's business has very tight margins, and he is accustomed to running a no-frills operation.

For years, Sam has run his web site using individual consultants who help handle development and support. The consultants all have regular jobs and support Sam's company on the side to earn extra money. As Sam's web site has grown in complexity, he finds that the part-time consultants are not able to keep up with his demands—and importantly—provide support when he demands it.

A few months ago, Sam hired an offshore firm that promised to have two developers working full-time on his web site for only a little more than he was paying his last consultant. This worked out well for a month, until Sam noticed that various parts of his web site stopped working and he had trouble communicating clearly with the developers on the project.

Finally, Sam decided to hire a local web consulting firm to manage his web site. He was surprised at how much more the firm charged than his previous consultants. He decided that it might be worth it if the firm could solve some of his recurring problems and implement several new features that had been stalled for months.

Sam was dismayed when the firm required an initial audit of the web site. The audit was expensive and turned up more than 20 security and performance problems. Sam initially thought that the consulting firm was trying to take advantage of him and sent the audit to his previous consultant, who validated the majority of the issues and reminded Sam that he had also warned him about these problems.

Sam agreed to implement the most critical security fixes, but refused to address some of the others. He wanted the new firm to focus on a few stalled projects. The new relationship worked out well, and Sam was very happy with the new consulting firm—especially the project manager—who provided regular progress reports and communicated clearly.

Sam increasingly relied on the new firm—including calling for emergency after-hours support—whenever he had an issue that needed to be resolved. After all, what else is emergency support for?

As project costs continued to increase, Sam felt that he had become an important client. Sam used a technique that had been successful for him with other service providers. He became more demanding and began refusing to pay certain costs for which he did not think he should be responsible. After all, he was in business to make money—not pay a consulting firm. And since he needed to keep his margins thin, so did the consulting firm.

Sometimes the company would run into problems with the low-cost software or approach Sam requested the firm use to save money. Sam would hold firm on these cost overruns. After a particularly egregious problem—where a new module that the firm was building conflicted with a component of the server that Sam had earlier refused to upgrade—Sam pushed back and refused to pay for the work. “I'm keeping these guys in line,” he thought.

Sam was startled and angry to receive a letter from his consulting firm advising him that they would be discontinuing services within 60 days. “I can't believe that these jerks don't want my business,” Sam thinks.

The primary challenge with Sam the Entrepreneur was that the true cost of support was not made clear. When the security-and-performance audit was presented to Sam, it was clear that he was not ready to invest in the level of support that the firm needed to provide. This mismatched expectation foreshadowed the issues to come, and it may have been better for the two parties not to have made a support agreement in the first place.

The transition from completed project to support is a delicate one that requires careful management of expectations. In addition to outlining how to make the transition into support, in this chapter we also look in detail at how to effectively provide support on projects you did not develop. We also discuss the importance of support orientations and providing quick responses to your clients. Finally, we wrap up with a simple technique you can use to provide proactive support to your client.

Providing Support

Hopefully, your projects will launch successfully, be used and leveraged by the client, and thrive for years. No matter how well-designed and documented and implemented and tested, however, an application in active use will always need periodic enhancements. This is natural. Businesses change, workflows change, personnel changes. Your client may want to move more workflows than were originally intended onto your platform once it proves stable and easy to use.

After managing a project from development through launch, you will often be asked to take the lead on providing ongoing support. There are really two ways support work can be arranged:

• Ad hoc. In this model, the client e-mails you asking for a modification and they are billed for the time it takes to make the refinement. There is no task queue, regular patch schedule, or predictable rate of requests. A better name for this kind of support might be “Inbox triage.”
• Monthly support. With regular support, your client has access to a set amount of time (often a set number of hours per month, or one large retainer) from which to draw when working on refinements. For anything beyond 4 hours a month or 16 hours in a single retainer, you likely will have a laundry list of refinements to work on.

Generally, the most important component to providing great support is to enjoy the process of providing great customer service. The phrase “customer service” has become a loaded statement because some companies think that hanging a sign with “provide great customer service” on the office wall will actually make their employees care.

As any trip to a dilapidated rental car office will tell you, this is decidedly not true. What does help is if you enjoy taking care of clients and take pride in your work. If you get a little smile in your mind when you think about the last time you made a client happy, then you do not need this tip. If you find that you do not enjoy working with clients, being a project manager may be exceptionally challenging.

Beyond learning to enjoy taking care of your customers, here are some specific tips for providing great ad hoc support:

• Be responsive (see “Be Responsive,” later in this chapter).
• Fix everything two ways. Software blogger Joel Spolsky coined this phrase in his excellent article, “Seven Steps to Remarkable Customer Service” (see the reading list provided in the Appendix). Fixing everything two ways is pretty simple: Fix the issue that happened (immediate) and fix what caused the issue to happen in the first place (deeper issue). When you get an ad hoc support request, take a moment to think, “What else can we do to prevent this or something similar from happening again?” Ask the developer this question if you are stuck. Fixing it completely when the first issue report comes in might take longer than just addressing the immediate issue, but it will take less time than dealing with it when it happens again (and it will).
• Be honest. If this issue was something you or the team did wrong, admit as much clearly and succinctly. Then move on.

Long-term Support

In a long-term support environment, you likely have a list of feature requests and issues provided by the client for the project. You likely will also have some sense from the client and your own knowledge of the project on which tasks are a priority.

One of the best ways to improve monthly/retainer support is through patch management. Instead of completing and pushing each refinement individually to production, bundle several refinements into a single patch that is installed as a unit to the production server. You can push individual completed features to a staging server (see tips later in this section) as you complete tasks for the forthcoming patch.

This has several benefits:

• You will move the client away from always wanting just one more change pushed this afternoon. That kind of hectic patch schedule is stressful to your developers, inefficient, and inaccurate.
• You will save the client time by having to perform the patch process once for several features, rather than once per feature.
• You can maintain momentum and force client decisions by using a patch schedule. Pick a set date—say, the third Monday of every month—to automatically kick off bundling of all completed tasks in the past month into a patch for review and deployment.

We have used this patch schedule successfully with many clients:

1. On the third Monday of the month, bundle up all completed tasks into a patch.
2. Deploy the patch to the staging server.
3. Send a patch summary e-mail to the client with a list of the completed items in the patch and links to the staging server for their review. State that you will need final feedback by Tuesday at close of business and that the patch will be installed live on Thursday.
4. On Thursday, deploy the patch.
5. Send a summary e-mail to the client that the patch was successful.
6. The following week, prepare a summary e-mail to the client outlining what is to be included in the next patch and what items remain in the hold queue. (See the following additional tips.)

Here are some additional tips for providing outstanding monthly/retainer support:

• Use a staging server. You should always deploy a refinement to a staging server first for proper testing and client review. A staging server is a system set up as similar to production as possible (hardware, location, network connection, real and recent data, installed components, configuration, etc.) and that has access limited to just your team and the client's team.
• Keep your patches small. Even with a month between patches, you will only have time for four or five refinements. Just accept that higher priority items will appear from the client without warning and that tasks will take longer than anticipated. Keep your initial patch list small.
• Develop a checklist for deploying patches to production to ensure that a consistent, high-quality deployment process is maintained over time.
• Send a summary e-mail when you start working on a new patch. Prepare an e-mail to the client that clearly lists the four or five items you have put into the next patch and all of the remaining items in the hold queue when you start a patch. State that you will proceed with these items unless you hear otherwise. This gives your client a chance to alter priorities, but also ensures that you have a decision preloaded into the interaction to move forward. Momentum and onward!
• Be proactive. With a limited set of support, your client may often be reluctant to make decisions because those decisions have a measurable impact on how much support time they have left. Help them make decisions by using proactive project management (see “Proactive Project Management” in Chapter 6 for more information).
• Leave a little extra time. If you have a monthly retainer it will be helpful to leave a small chunk of time unused to deal with unexpected support issues that tend to arise.

Support Orientation

Regardless of the type of support you will provide, consider holding a brief support orientation call with your client. This call can serve many purposes:

• It makes explicit the level of support you will be providing;
• It clearly marks the shift from development to support; and
• It makes sure your client knows how to request support.

Consider preparing a brief outline of the major topics you want to discuss. These might include

• How to request support (e-mail, telephone, ticketing system, etc.)
• Expected response time
• Financial details of the support plan (for example, if there is a maintenance plan or if it is hourly)
• What support does (and does not) include
• What to do in an emergency if the site goes down

Urban Insight (see Figure 11-1) has achieved a 90% 5-year client retention rate. We have found that support orientations can dramatically improve your long-term ability to support your clients by making sure that clients understand what to expect.

Figure 11-1. A support orientation template (detail; shows first of two pages)

Be Responsive

Over all of the projects, challenges, successes, failures, mistakes, oversights, miscommunications, and badly handled expectations, there is one central trick that will help maintain a positive relationship with the client time and time again: be responsive.

If you take one thing from this entire book, it should be this: being available and responsive always generates appreciation from the client and sets your interactions with them apart from the others with whom they deal.

Remember, to the client you are just a vendor, like a plumber or an electrician. You have promised to do some task that they do not know how to do themselves and for which you charge a lot of money. Anyone would feel powerless in this relationship. Being responsive and available will make the client feel more in control of the situation and more confident in the outcome.

Why?

Because when things go badly, being responsive makes it easy for the client to handle internal questions about the problem. Say the client e-mails you about an issue and you reply within half an hour that you are aware of the issue and you have someone looking into it. Your client can happily answer a call from his or her boss and say, “Yes, I've let the consultants know about it and they said they are looking into it right now.” That is a much better answer than, “I let them know but I haven't heard back.”

Uncertainty breeds doubt, confusion, and anger. Constant updates, responsiveness, and easy access alleviate most concerns. Since checking your e-mail can reduce your productivity, consider spending 10 or so minutes each hour checking your e-mail so you can quickly respond to clients, put out fires, and nudge developers in the right direction.

Supporting Projects Developed by Someone Else

It is challenging to provide ongoing support (issue fixes, new features, training, etc.) on a project that your team did not develop. The project is unfamiliar, it was not developed to your standards, and you might be blamed later on for poor decisions made by the initial developers.

Here are the top five challenges in providing client support, complete with tips to help mitigate them:

Challenge #1: The Project Is a Mess

The greatest challenge to taking on support for any project is the quality of the project itself. The fact that the original developers were not selected to provide support probably indicates that the relationship with the client was not positive. If the relationship was not handled well, the development of the software probably was not either.

Challenge #2: The Client Has Unrealistic Expectations About the Schedule

By the time you take over support, the client has likely been building a large wish list of feature requests and issues, all of which appear to be urgent to the client.

Challenge #3: The Development Workflow is Not Set Up Correctly

To support a project properly, you need a production system and a staging system, which lives in the same place as the production system and uses similar hardware and software. This often does not exist in projects you take over.

Challenge #4: The Site Lacks Stability

The site is generally unstable and critical issues occur at least once a month with no decrease in frequency. These could be problems with the hardware, the network, the software itself, the design of the interface, or a combination of these factors.

Challenge #5: The Client is Not Well Informed

If the client is coming to you for support, then the relationship with the original developers has probably soured. If this is the case, then it is likely that the client has not had assistance with the site for some time, and when they did, they did not feel informed or updated of progress.

Pointer #1: Start Support with a Project Review and Recommendations Document

A great way to protect your team against starting support on a problematic project is to perform a review of the application and prepare a summary recommendations document. The summary recommendations document is a listing of all of the problems with the project, complete with a short description of what to do to address each issue. You can organize the recommendations into three sections: high priority, medium priority, and low priority.

When you deliver the document to the client, clearly state that you will begin working down this list of recommendations in tandem with whatever new features and issue refinements the client has requested.

A recommendations document has many advantages:

• It provides your team time to get acquainted with the application.
• The review should identify all of the problems in the site so you are not surprised later.
• You can clearly state all of the site's problems ahead of time should a more serious problem develop later.
• The review offers the opportunity to make additional recommendations to further bring the project to your own standards.

Pointer #2: Don't Overtly Blame the Previous Development Team

Focus on addressing the issue with the client's best interests in mind. If the client asks, you can state that this was a mistake of the previous developers. But you do not want to get in the habit of blaming the previous team for two important reasons:

• The client selected the previous team. Reminders of any mistakes of this team may be taken personally by the client.
• Placing blame is unseemly and reduces your credibility. Take responsibility and move forward.

Pointer #3: Use Regular Patches to Maintain Momentum, but Save Time on Deployment

Patches let you queue up several refinements together so that you can release them to production as a group, which is more efficient than releasing them one at a time. If you start using the patch language with the client you can schedule regular releases (read: monthly), which has the effect of maintaining momentum with development and keeping the client focused by having a release date to share with colleagues.

Pointer #4: Take the Time to Set Up the Right Workflow

At the start of the project, take the extra time to set up the proper development workflow. This likely includes

• A password-protected staging server
• A way to easily sync the data from production to staging
• Bringing the code under version control
• Bringing the staging and production sites under version control
• Bringing the database under version control

Pointer #5: Provide Regular Updates

Communication is vital and builds confidence between you and your client. Take the time to write a detailed but clear¹ summary of all outstanding tasks, regardless of whether they are in development, on hold, queued for the next release, or complete.

______________

Bonus Pointer: Use a Monthly Checklist to Proactively Identify Issues

A great way to increase the stability of a project is to put together a checklist that you can run each month on the system to look for common indicators that will cause more serious problems throughout the entire stack of the project. See “The Launch Checklist” in Chapter 10 for more information.

Pretend You're Leaving

Justin occasionally spends a few moments thinking to himself, “If I was leaving tomorrow and showing my replacement everything they had to know to take over, what would I be embarrassed about handing over? What project or site or module just isn't where it should be?”

It's likely that something—some project, module, web site, section, or configuration—is going to come to mind, something that was not finished right, was not completed to your own standards or those of your organization, or something that is just so slapdash that you need to finish it the right way.

This situation commonly happens when a project is in support, and not in active development. While developing a project is a proactive task—you lead the team that is seeking out what needs to be built and are building it—support is often a reactive process, in that you and your team act only when there is something that needs to be fixed or the client asks for something new.

In such a reactive environment, it's easy for non-critical tasks to be consistently deprioritized over incoming support requests. But this sort of “cruft” does build up over time and could eventually impact your project. If possible, it's best to address these items as quickly as you reasonably can, to prevent any pile from forming.

Whatever does come to mind, fix it. This little embarrassment gnawing at the back of your head is the most likely topic to come up without warning in a meeting (thus requiring embarrassing answers) or to have some kind of system issue that interrupts the client's ability to do work.

You do not need to do this often, but when you do, it is revealing.

Wrapping Up

We've come to the end of the road, both for our book and our sample project. It is our hope that the hard-earned lessons in this book will increase your effectiveness as a project manager, and save you a little pain in the process. We've shown you how to move a project from an idea into a signed scope of work, from a set of requirements to a working beta, and from a launched project to post-project support.

Not every project will neatly follow this process. Many projects will not use every step we outlined, or you may only be involved in specific stages. We also tried to provide specific advice on common tasks in the life of a web project manager, including writing professional e-mails, creating checklists to ensure consistent quality, running effective meetings, and extracting what is needed from your client to ensure a successful project.

We've covered the mundane but critical tasks, such as how to write an agenda, how to gather requirements, how to prepare a project schedule, and how to take notes. We've talked about difficult situations, like handling out-of-scope requests, getting answers from reluctant clients, and keeping an eye on your team without micromanaging.

In some ways, the job of the project manager is unglamorous. You schedule meetings, you take notes, you keep the project moving, and you watch the project budget like a cheap father obsessing over the thermostat.

A great day for a project manager ends with sending a clear summary from an effective meeting and a quick glance at an on-schedule project budget. It is the developers and the designers and the wireframers and the technical architects who get to exercise their creativity. It is you, the project manager, who “herds cats” and makes the project successful.

Without effective project management, designers and developers and architects would have far fewer projects to work on, far fewer interesting problems to solve, and far fewer opportunities for creation.

Project management is sometimes a bit like roadwork. As long as you keep the potholes filled and traffic moving, your team takes your work for granted. But as soon as someone hits a pothole, well…

However, those clients who have experienced poor project management (and many have) will quickly recognize your project management acumen, and you will become a sought-after team member because people will remember your calm efficiency and competence.

If it was possible to have a project free of problems, there would be no need for project management. While we believe that the advice in this book will serve you well in your future endeavors, we know that your challenges will be unique and varied. We would like to leave you with some parting advice that we hope will be helpful in your professional life, be it project management or otherwise.

Be unflappable, positive, and persistent.