There are many metrics for measuring a Drupal project's success. Matching budget estimates, minimizing scope creep, and hitting a launch date are vital goals for any project. However, the key factor for success is good communication throughout the project.
Require Details During Discovery
Like the blueprint for a house, a detailed set of requirements must be established. Without clearly defining each feature, requirements can be identified at unexpectedly during development. This is bad. For example, a client might say, "I want a blog on the website" but what if they assume that means anonymous users can write blog entries? Depending on the client's involvement in the project, additional user-specific features might already have been added. Addressing an issue like this means more development hours. Potentially, the launch can be delayed if enough issues like this crop up.
Rather than reworking a feature, possibly multiple times, spending an extra 15 or 30 minutes doing a detailed review of that feature's workflow can save countless hours. By walking the client through a feature, more details can be gathered and there is an opportunity to offer constructive criticism or suggest better alternatives. Of course, the first step may be explaining the value of devoting a significant chunk of time to requirements gathering.
Define Requirements in Detail
Once requirements are reviewed and refined, a detailed "functional specification" document should be created. This document serves as the primary development roadmap but it should act as an unambiguous legal contract with the client that says, "We will build the site described in this document."
No matter how much effort is put into the discovery phase, or if the specification is treated as a "living document" via an agile process, there will still be change requests, particularly when a project has multiple stakeholders. The document will help avoid duplication and inconsistencies. Additionally, this allows us to more accurately estimate the necessary resources needed for the actual implementation phase, and act as the main reference point for changes. Even though the document will serve as a guide for the overall project, the specifications are not completely rigid. Mediacurrent employs an Agile development methodology that encourages frequent inspection and adaption.
For large projects spanning multiple months, original requirements can be forgotten unless they are properly documented. Defining requirements in detail is the best defense when a client says, "But I thought we said it would work like this..."
Proactively Identify Pre-Launch Changes
Do not wait until the last two weeks of development to invite client to use or review their new site. While in the midst of development, it may be tempting to keep updates brief or to minimize client involvement until more is done, but demoing features or workflows as they are complete will give the client an earlier opportunity to express any concerns. Plus, spreading out training can make the learning curve less steep, particularly for less tech-savvy individuals. A lot of people will learn better by doing or by example, so some of these approaches may help:
- Give clients previews where they log in and walk through a workflow.
- Provide screenshare demos
- Have the client share their screen while reviewing the site.
Client feedback should be gathered frequently and in detail. This reduces the chance that a major pre-launch change will be identified late in the game.
Respond Promptly, Update Frequently
One of the easiest ways to maintain a good relationship with the client is to respond promptly. If the client sends an email at 10 p.m. on a Saturday night, respond, even if you are only acknowledging receipt of the message. This shows you are taking a project seriously and, in conjunction with frequent updates and dialogue during development, it can help the client gain confidence that you know what you're doing.
What clients want isn't always what they need, so selling an alternative approach can be much easier when you have a good rapport.
Follow up Post-Launch
There will always be post-launch change requests, many of which may have been identified and postponed during development.
Although a formal QA phase should be required pre-launch to eliminate any major issues, the ultimate QA happens post-launch when the client begins to gain experience using the new site.
It is vital to follow up several times post-launch to ensure client satisfaction and to identify and prioritize post-launch change requests early. It can be tempting to launch a site and forget it. Instead, try to identify issues while details about the site are still fresh in your mind and before the site is filled with new content. Be sure to respond to post-launch concerns and issue as urgently as you would approaching a launch. Some post-launch issues can become worse over time if they are related to content management or perhaps an automated process.
Ultimately, good communication keep you on the same page as your client. Quick responses, proactive feedback requests, and diligent requirements management are essential components of a successful project.