Web Time: Our Clock vs. the Client's
As developers, we do not live on the same clock (or calendar even) as our customers. This is true for programmers outside the context of web-development as well, but is often alarmingly more obvious (and even painful) for the web-developer. Two major themes obtain here - managing clients' sensibilities and avoiding burnout.
Our customers are mostly regular people, working the 9-to-5 thing. They have deadlines and understand the notion of "urgency" as it relates to their own work, but often, their approach is ("a la" Kipling) "doin' things rather-more-or-less."
We web-IT types live in a microcosm that demands, not only that we meet specifications according to schedules, but (on the Front-End especially) that we do so for a bunch of annoyingly differently programmed display platforms, i.e., web browsers, and often with almost zero tolerance for error. No, I'm not pretending that we work for NASA or Bristol-Myers Squibb, where lives are on the line, if we miscode a line, but our customers and PMs often feel that way about it. So, with the sense of urgency that clients have about our products, you'd expect them to supply content, review presentations, test forms, etc., in general do all the jobs we warned them they'd have to in order to meet "THE DEADLINE" in timely fashion. If you hold that expectation, you will be disappointed. Without careful management by YOU, the web-dev-er your client will become THE bottleneck in your development process. This will put your schedule at risk, and the client WILL BLAME YOU. In the truest sense, you ARE at fault, since you should have managed them better.
Managing customers' in the performance of their duties with respect to an IT project, especially web-development, must become an integral facet of your general project management methodology. The Agile guys get this to such an extent that clients are fundamental contributors who are required to participate side-by-side with their more geekly counterparts. There are a few older project management schemes (ever heard of JAD or RAD?) that "encourage" this ongoing demand for frequent even daily client participation, but many that don't. Regardless of whether you adopt a formal "school" of project management, your practices must incorporate a recognition that regular, frequent input from the client/business-unit is required. If you rely on the customer for the provision of actual content elements, this is critically more important. When it comes to testing beyond the unit level, customer efforts are vital from both a proving-correctness perspective for use-cases and for usability assessment and feedback.
Clients don't want your (read their) project to miss deadlines, but rarely appreciate how they could cause that to happen.
It must be one of your responsibilities to ensure that customers do grasp the importance of their roles in the process. Analyze your project time-lines to identify the must-have-by dates for client deliverables and actions. Reassess these frequently and keep the client informed. Detect schedule risks early and often, and share openly and directly any concerns you identify. Remember that the customer is busy, doing whatever it is that constitutes their real business. This doesn't excuse them from completing the tasks you require for your project, but does explain why the client may overlook or mis-assess the priority of those duties.
You have an additional responsibility to your developers. You must not allow the project schedule to become compromised in a manner that leads to a combination of dead-time followed by 60-hour work-weeks, or, for that matter, consistently 60-(or more)-hour work-weeks, period. I enjoy working whenever I want, but I purely telecommute. Evenings and weekends are fine, as long I am free to choose and manage my own time according to project demands. However, I do not enjoy "MUST WORK 30-HOUR WEEKEND" situations that devolve from an attempt to keep a deadline that's at risk, because a client failed to meet a content delivery schedule. No (sane) developer enjoys that.
If you fail to keep your clients on track for deliveries of their parts, and don't adjust schedules, you risk burning out your developers (even if that's only yourself). You will generate anxiety and resentment and a lower quality of product. You will reduce morale and customer confidence.
Recognize and manage your customers as a part of your development team to the fullest extent possible. Make clear early and remind often of upcoming delivery targets. Accept that it is absolutely up to you to focus the clients' awareness of the time-sensitive nature of their contributions to the project.
Clients do not live by our clock and need our help "telling time" project-wise.