In 1999, the Mars Climate Orbiter, a satellite that was to study Martian atmosphere and climate, disintegrated and crashed on the red planet. Upon investigation, NASA found that one piece of software was communicating using English units (inches, feet, pounds), and another piece of software that received these data was expecting metric units (kilograms, meters, Newtons). The root cause of the disaster, as with so many human-caused disasters, was poor communication and bad assumptions.
Web site projects usually are not as costly as Mars missions, but they can be derailed just as easily by poor communication. Here are some ways to keep the communication lines open so that web development projects are completed on time and to the satisfaction of all stakeholders.
Define the Scope, Roles, and Responsibilities Up Front
Before any actual development work is started, the project expectations should be documented and agreed upon. This should include not only the number, type, and design of the pages, but any special functionality. Where are the design files coming from, and when will they be delivered? What format will they be in? Who will provide the text/video/photo content, and when? What types of interactivity will the site need – Flash applications, video players, photo carousels, user registration, e-commerce…the list goes on. Every detail should be noted, leaving no room for assumptions by either the client or the provider. Having everything on paper (or its electronic equivalent) also avoids “scope creep” later in the project—if it isn’t in the list, it won’t be a part of the project without proper consideration of the impact on cost or scheduling.
Limit the Points of Contact
Each side—the client and the developer—should ideally have one point of contact for project communications. That way, there is no confusion over who to communicate with for different aspects of the project, and communications are less likely to end up in the black hole of the wrong person’s inbox. Of course, in a larger or more complex project, having one point of contact can be a bottleneck. In this case, it’s appropriate to have secondary contacts, but the additional contacts should be for specific, defined topics, and the primary contact should be copied on all communications so that no decisions are made “under the radar.”
Have Frequent Touchpoint Meetings
At a frequency mutually agreed upon, client and provider should meet to discuss the progress of the project, air any questions or concerns, and report and resolve any roadblocks. These meetings generally should be short and to the point. The idea is to get everything out there on the table so there are no surprises.
When a question or concern comes up between touchpoint meetings, and it’s important enough that it can’t wait for the next meeting, it should be communicated at once and responded to promptly. (In the project document, there should be a provision for this type of communication and an agreement on how long it should take to acknowledge the communication and resolve the question or concern.) It’s in the best interests of both sides to respond to and resolve these issues as quickly as possible, to reduce anxiety (Did they get my email? Are they doing anything about it?) and keep the project on track.
Have a Project Post-Mortem
No project goes perfectly, but you can get a close approximation if you understand what went right and wrong in previous projects. Both client and provider can learn how to do things better the next time by having a “post-mortem” or “lessons learned” meeting after project completion.
By having regular, reliable, open communication, a web project will go more smoothly, the customer will be happy that the end product was delivered to expectations, and the web developer will establish a reputation as the go-to team for web projects.