Improving Your Process: Project Timeline Development
Published 5 years 11 months 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?