Improving Your Process: Project Timeline Development

Published 6 years 1 month ago on March 2, 2009 — 5 min read

Project management in Web design always manages to be a challenge for my team. With every advance we make in refining our process, something new seems to find its way on to our playing field and again we need to compensate.

I’m a strong believer that effective timeline establishment directly relates to the overall success of a project. If you’re late with deliverables, it’s as though you shouldn’t have tried in the first place. We’re in the client service business, and if timelines aren’t met effectively, your reputation will quickly diminish.

“I need this ASAP!”

One of the biggest issues we’ve come across is the recurrence of additional work for existing clients. While it sounds absurd to call new work an “issue”, it’s extremely difficult on our timeline development. This sporadic work is sometimes rare, and other times a daily occurrence.

It’s troublesome because we want to do everything we can to satisfy our clients. Having an existing client call you up because they know you do good work and you won’t let them down puts on a bit of extra pressure to make sure you get things done. The only truly effective method of ensuring rush job completion is to have someone on staff ready and willing to take on the work when your account rep hangs up the phone. That’s anything but cost effective, however. Keeping someone on salary under the assumption that rush jobs will consistently arrive is a less than stable strategy.

There’s the possibility of charging a rush rate to the client should their project fall into the “ASAP” category. You can charge a bit more than your standard hourly rate, to compensate for the overtime you’ll now be paying either to yourself or your employee. The company gets an extra spot of work, and the employee is compensated for her overtime work.

We have tried working with rush rates for some time. As we began explaining the situation to clients, we were surprised to hear how many times the “ASAP” part of the phone call turned into much less of a rush than originally explained. Not many clients took us up on a rush rate, and unfortunately the small projects or updates originally requested were most often put on a back burner and then forgotten; not something we wanted. We wanted to provide our clients with everything they thought of, and felt that there must be a better way to accomplish that without working 70 hour weeks.

Our timeline development process

Briefly, our timeline development process isn’t very elaborate, and we’re wondering if that’s the root of some scheduling conflicts we’ve run into lately.

Our process begins during the kickoff phase of any project. We’ll ask the client if there is a drop dead handoff or launch date and we’ll work backwards from that date. We’ll segment the projects into phases of deliverables or status changes, and do our best to determine where any possible milestones can fall. A response window is discussed with the client, establishing how long we should expect to wait for feedback prior to moving into the next phase of the project. This window can vary depending on the client company structure. Sometimes it will be our primary contact with the only feedback, and other times it will be up to an entire board of stakeholders. That turnaround time can affect the overall timeline substantially. If we should plan to wait three business days for final feedback, we need to know that as soon as possible. We have made it a point to establish this turnaround time for feedback, and attempt to make it clear that delays in feedback will, by default, push all subsequent milestones, including the final delivery date. Clients are often very receptive, and it helps establish consistency before the project takes flight.

It’s a terribly difficult process, because not only do we have to consider the project at hand, we’ve also got to keep in mind the existing project as well as any potential jobs that may come through the door throughout the life of the project.

We’ll strategize a bit with the milestones, trying to buffer in a couple days to compensate for the many fires that get started from month to month, and make the timeline public with our client. From there, we internally strategize how to meet our timelines on a consistent (usually weekly) basis.

When things become less strict

Our biggest problem as of late is actually a lack of drop-dead launch dates for projects. Even our larger scale projects don’t have a specific month for launch let alone a specific date in mind. A lesson we’ve learned as a result of multiple dateless projects in our queue is this: make our own deadlines.

It is already quite difficult to determine a timeline for a project that is both effective and feasible given the number of variables involved with team based projects for multiple clients. Leaving any project without a final milestone is disastrous for everything on your plate. If our client doesn’t have a date attached to his project, we simply assign one and notify the client. From there, we’re able to more accurately determine a realistic lifespan of the project in conjunction with everything else currently active.

Leaving a delivery date open ended has shown me that you’re asking for trouble. If a project is left without a due date, more often than not it will take much longer than the client anticipated, simply because you don’t feel pressured to get it done. Although the client didn’t express any rush in getting the work done, that doesn’t mean it can take as long as you need. Make sure you’ve established deadlines, and on top of that, make sure your client knows about it.

What are your timeline guidelines?

What have you come up with as an effective strategy for outlining milestones? What have you tried that hasn’t worked out so well? How do you deal with the inevitability of existing clients coming in with a new rush job? How do you handle the amount of dedication it takes to effectively stay on top of changes in your timelines?

There's a conversation brewing

  1. I’m new to web development and design. The process is something that as intrested me since learning about it in college. I’m gathering as much info as possible to ensure that I develop a process that is bullet proof. It seems like that goal is impossible. Thanks for the info.

  2. Good article, thanks. I think a major challenge with deadlines is when they hamper your creativity as an agency. It can be really frustrating to have to park ideas or change the scope of a project purely because of a deadline. To address this, we will often make sure the initial scoping and wireframing work covers the full plan and then we agree what is delivered in phase 1. This is dictated by the deadline and/or the budget.

    It is tricky to do this but it does mean we get to deliver the creativity and ideas clients come to us for even if they are parked for later versions.

    Cheers,
    Stuart.

  3. Your goal for existing clients should be *maintenance contracts*. Meaning, they pay some amount each month for a corresponding amount of work from you. (The details can vary.) If they’ve agreed to this, then their additional requests just fall under hours they are already paying for (and thus that you should have already allocated for). If they ask for more work than you have hours for, ask them for a separate work order, or to wait until next month, or better yet, have an overtime clause in the contract (but ALWAYS ask them first before going over hours).

    A client without a maintenance contract should always have to get a new estimate and sign a new work order for any additional work (other than fixing obvious bugs that are your responsibility). That way you can control how it fits in with you other work and charge an appropriate amount for it.

By all means, contribute

Leave a comment