A Few Tips On Estimating Web Projects

June 01, 2005 | 20 Comments

If there is one thing I’ve had to struggle with at my new job it’s account management. To be quite frank, I don’t like it and I don’t think I’m very good at it. But I’m learning, as making mistakes is a great way to learn, and some of what I’ve learned my be of use to y’all.

Today I want to talk about how to estimate projects and ensure that your estimates work for you as well as your clients. I’ve found this can be really tricky and if not done correctly can cause real headaches down the road. A proper scope assessment is key to the success and smooth going of any Web project and the project estimate is a big part of a good scope assessment.

As well, how that estimate is handled and used throughout the process can have a great effect on the bottom-line of the project.

What do I mean by “estimate”?

I want to define for you what I mean by “estimate” before I move on and explain where the tips come from. The reason why is that before I started my new job I’d never really dealt with estimates in the way I do now. Most often we’d scope out projects in terms of hours and deliverables and there was very rarely a paying 3rd party client involved.

(Which came with it’s own hassles, trust me.)

As well, with all the freelance work I’d done, I gotten lucky in that I’d not run into any real issues with my estimates, but then again, I was doing some of what I’m going to talk about here and most of the projects were really straightforward. As a part-time freelancer with a steady income I could simply “not do” projects I thought might become complicated. You know? The kind Andy warned us about.

Anyway, I’m getting off track, sorry. By “estimate” I mean the formal document, and related process, you provide to a client that states what you’ll be doing for them and how much you estimate it’ll cost. These tips come directly from lessons I’ve learned (ahem—mistakes) on the job.

The Tips

Be very, very specific. When outlining deliverables take great pains to describe in detail what you will be handing off. Any ambiguity can leave you with shaky ground to stand on when it comes to negotiation of a change request. “HTML Templates”, for example, can mean a great many things.
Outline the review process in detail and stick to it. If you’re client doesn’t understand he’s actually buying off on a design, for example, he can inflate your scope rather quickly with multiple revisions.
Bring up any red flags early. If you see your project start to outstrip you estimate, it’s probably a good idea to bring it up before it gets to far out of control. Make sure your client understands when something is even slightly out of scope. You don’t want to set a precedence by agreeing to this little thing and that little change. Trust me, this can balloon very quickly.
Give yourself an out. Make sure that in the estimate it states what the process is for scope creep and negotiation of change. Make sure the client understands that process.
Have an “estimate check in” with the client. An idea I’ve been trying to work out is to have an initial estimate for the scope assessment itself. This way you can do another estimate once you have a better understanding of the scope of the project. This might be hard to get a client to buy into however. What you might be able to do is revisit the original estimate after you’ve finished whatever scope assessment phase you’ve got and make any needed changes then. Kind of like an upfront and planned change order negotiation.

This should help your clients as well

I realize this all might seem to be to the detriment of your client, but I assure you it’s not meant to be. The main goal is yes, to protect the designer, but sometimes a client can be his own worst enemy.

Sometimes project get out of scope for no good reason and while your client might be thinking they’re getting more from the project, by adding to the scope and getting away with it, they may just be spinning their wheels and creating a situation where the work will never get done.

On the Web being timely is huge. I’m a big proponent of “just get it out there” and I’ve seen too many good projects over the years wallow in a misguided attempt to be perfect, or worse, to cram every damn thing under the sun into the project.

When it comes to estimates; a bit more detail up front, the proper mechanisms for change and some tough love can help you and your clients.

Filed under: Web General
Keyword Tags: web+process estimates web+design clients

Comments

1. Kevin said:

I rather like the idea of the “estimate check in”. I recently started working with a client who didn’t not have a well defined plan but it was clear that the scope of the project would be rather large. Rather than make things up we agreed to an assessment phase where we studied the organization, learned about their needs, and developed an informed project plan. We agreed to a timeline and estimate for the assessment and signed the contract with a clause to review the project plant and use that as the scope portion of the contract moving forward.

It worked out very well. Rather than make guesses about what the client needed we were able to really talk to them, study their business, and develop a project plan to build something tailored to their needs. It also meant that we could make much better estimates for the actual design and development.

If you can swing it I strongly recommend starting clients off with an initial evaluation phase, depending on the project size it may be a few days or even weeks. It will pay off for you and the client later when you are working from well informed project specifications.

Posted on June 1, 2005 02:17 PM | #

2. Mike D. said:

And don’t forget the most important rule of all: When you give delivery dates, don’t give them based on a calendar. Give them based on when you receive prerequisite materials from the client. For example:

Bad: We’ll have the website launched on September 1st.

Good: We’ll have the website launched exactly six weeks after receiving copy from you. Currently you are scheduled to deliver copy on July 18th. That would create a launch date of September 1st.

Posted on June 1, 2005 03:08 PM | #

3. Keith said:

Mike – OR, you can not mix your schedule with your estimate at all. You hit on something I left out on purpose. The rule you give is a very, very sound one, but unless you have to (which has been rare for me, but it has happend and it wasn’t good) tying a shedule to your estimate should be avoided at all cost.

Posted on June 1, 2005 03:39 PM | #

4. Dave P said:

Although in support of Mike, I can’t imagine a competent client letting you get away with not setting a definite project end date. Even if you don’t explicitly set one, you can bet they have one in mind; this could cause problems for you.

Good Project Management means defining a realistic end point. Not only will it define a measurement for marking the project “late”, it’s also a basis for the more favourable “delivered on time/early” statement. The key there is (as you said) to have regular milestone meetings and to ensure the client is aware that changes to the “estimate” (more formally called a Project Charter) can result in changes to the delivery date.

Posted on June 1, 2005 04:32 PM | #

5. Keith said:

Dave – All I’m saying is you don’t include a schedule as part of your estimate. We almost never do that. I’m not sure if you’re in disagreement with that or what? ;) I mean, Mike is kind of advocating no definite project end date at all, which I agree with in theory, although you’re right, very few clients are going to let that go.

You also mention a project charter, which is used in traditional software development project management, which is far to rigid (IMHO) for many Web projects.

I think we may be talking about different sorts of projects and different sorts of project management. I’d like to avoid a semantic debate if possible. An “estimate” in this case is something you have a client sign off on to determine the cost and deliverables for a project. It’s not a schedule, or charter, or creative brief…

Posted on June 1, 2005 04:44 PM | #

6. Dave P said:

Keith: I see what you’re saying, and I don’t really disagree with it, but a more traditional PM approach seems to me (at first glance at least) to be designed to have already addressed a lot of the “issues” you are trying to cover.

I think I misread your definition of “estimate” to be a little more formal then you describe.

You also mention a project charter, which is used in traditional software development project management, which is far to rigid (IMHO) for many Web projects.

Recognized PM techniques aren’t just for software projects, but for everything from building a stadium to conducting an office move. I certainly wouldn’t advocate following it to obsessive detail for something as “simple” as a standard web project, but the methology is still sound, and can help a great deal.

Perhaps I’m misunderstanding you, but why wouldn’t you use standard PM techniques? Both you and Mike are doing things already that mirror PM methodogies: Your estimate is like a mini-charter from what you desribe, and Mike’s timeline is identifying a critical path, while both of you are gathering data for a risk assessment.

Am I not seeing something here, or do you flat out disagree? If so, why? - I’d like your thoughts, since your experience with the web is more complete than mine.

Posted on June 1, 2005 05:16 PM | #

7. Keith said:

Dave – Oh, I’m not disagreeing with you at all. Thing is, I’m not a project manager, but I have to manage projects and I know from experience that the type of project management your talking about is way too much for most the projects I work on. That kind of strict methodology creates problems of it’s own.

Plus it would take a dedicated PM to deal with it all – see my previous post about Web design skills, and think about all the freelancers trying to managage the process of managing a project like that. If we could do that I do imagine it could help in some cases. What usually happens is we adapt to suit the project and with Web projects (in my experience) the formality of kind of process your thinking of is too much. I use the same methodologies just scaled to fit.

Most the projects I work on need to be lightweight, flexible and nimble. The kinds of problems I encounter are difficult to avoid and even the structure I’m talking about here is pushing the limit as far as strict structure.

Having said that, we follow a very formal process, part of which is estimating. The reason why this might be hard for you to grasp is because I’m pulling out one small piece and talking about it on it’s own. It might seem like the schedule is left out of the process but I assure you it’s not.

The other big difference I’m sure is a semantic one. The kinds of project and the kinds of clients I work with need a different nomenclature. I imagine most agency account managers would be more familiar with that than your traditional PMs like what you’re probably used to.

Posted on June 1, 2005 07:29 PM | #

8. Kevin Tamura said:

All good points Keith. I’ve seen many projects spiral out of control because no one actually outlined the review process with the client—they kept making change after change after change and the budget got eaten up in the process.

There is one point I would add and that is post launch maintainance. Many clients, in my experience, don’t understand that it’s up to them to keep the site uptodate and running after launch. Usually there is a grace period (or “warranty”) on the work you’ve done; but once that’s up, it’s all theirs. We had on client who would go in and break things months after the site had launched and then expect us to come in and fix their mess at no charge.

Posted on June 1, 2005 11:34 PM | #

9. Dave P said:

Thanks for the input Keith, very good points!

Posted on June 2, 2005 09:19 AM | #

10. Mike D. said:

Yeah, I guess it all depends on the scope of your estimate. If you’re only out to provide a list of deliverables and associated costs, I suppose you don’t even need to mention timelines at all. I like to clue clients in pretty early how long things will take though. If it’s not in the initial estimate, it’ll certainly be in the next document.

But yes, I think any confusion here is semantic. I’m referring to a “time estimate” as much as a “cost estimate”.

Posted on June 2, 2005 10:03 AM | #

11. Joshua Zamrycki said:

As a budding web design team, we find ourselves facing all of these issues (it’s great to read about it here). Learning from our mistakes as we go. To leave things as clear as possible with the client, all of these issues should addressed from the very beginning. But do you use a formal “contract” document that you both sign? This seems like the most transparent and easiest to reference method. If so, does anyone have an example of a contract stating all these issues that they use with clients that we may learn from?

Posted on June 3, 2005 05:24 AM | #

12. Chris K said:

Great entry Keith. I find myself in the same boat, recently taking on a lot more project management with new clients, as before in other jobs not having to worry about it as much. I found that having other professionals with more experience in this area to bounce ideas off of helped me greatly.

I can see both sides of Keith’s and Mike’s/Dave’s POV. Like Keith, I’ve kept the scheduling part out of the initial estimates and included that either in the project contract (which I think is essential in this business) or in documented client interaction (usually e-mail).

Posted on June 3, 2005 05:30 AM | #

13. Everton said:

A sample contract with this points will be very util for all reading this….

Posted on June 3, 2005 10:14 AM | #

14. Darrel said:

I’ve found that you need a project timeline for both yourself AND the client. Whether that’s part of the estimate, or part of the proposal, or just a separate document is up for debate, I suppose.

But without a defined timeline, with deliverables that both you need to provide the client and deliverables the client needs to provide you, you run into some issues. The big ones being the client asking you why the site isn’t up (well, it’s because you didn’t sign off on things two weeks ago!) or you asking the client ‘hey, when do you want to finish this?’

The latter is often the biggest problem. A project going smoothly for 4 months then nothing. Maybe the client gets sidetracked or something. Either way, you can’t be sitting there with a non-billed, unfinished project. A definite timeline allows you to cut things off at a certain date. Bill it out, and then start a new project if/when the client finally comes back to finish things.

Posted on June 3, 2005 02:13 PM | #

15. Rich Brooks said:

Keith,

This couldn’t have been posted at a better time. We’re currently revamping our own process with the help of our project manager, who had come in from another Web design firm.

Two issues specifically that we’re getting into that might be of interest.

1. What you call “estimate check-in” we call Discovery. If there’s any programming (PHP, for example) we require Discovery. We give an estimate for Discovery and a ballpark (by which I mean a really wide estimate) for Build. We have deliverables for Discovery: storyboards, wireframes, keyword analyses, or whatever the job requires. We also include a narrower/revised estimate for the Build phase of the job. The client pays us for this Discovery work, regardless of whether we actually build the site.

Once the Discovery is done, the client has the rights to shop our price around. We haven’t been doing this long enough to determine if we lose business this way, but I’ve had clients shop around my proposals before, so why not at least get reimbursed for the work we’ve done?

2. Production calendar. After being prompted by my new project manager and visiting a yacht-building client and seeing their production calendar, I agreed we needed to run our business more like a manufacturing company. The bottom line is that we only have so many worker hours in any week. My clients always seem to deliver their content on the same day…as if they’ve called each other up to coordinate it! This frustrates us and them, as invariably we have to delay one or more jobs.

My project manager’s old company used to fine customers who didn’t deliver content and feedback on time! (She claims no one was ever late on content.) I can’t bring myself to do that, but I found a similar solution: we build a certain percentage into the job and then offer a refund if the client hits all of our agreed upon delivery dates. This includes content delivery (final version,) approval of certain design elements, and a final punch list of requested changes.

Again, haven’t been doing this long enough to determine its effectiveness, but I’ll keep you informed.

Hope this helped someone out there!

Posted on June 3, 2005 04:54 PM | #

16. Stevan Majstorovic said:

I just want to point, that sometimes we (web developers) are put our clients in problems, instead to offer solutions. This is very tricky, and this can lead to bad estimates. This can sounds theoreticaly, but let’s skip to example:

Let’s say that your agreed with your client that you will put some short intro text about it’s company. From our side this is solved… but on the client’s side this generates problems (chalanges) like: who will wrote it, what to put in it, what style should it takes, what should be the the message of that text…
Event if client is good in writing, all we know that on the web writing style is a but diferent.

The bottom line is… that we need to take this part also if we want to have satisfied client, on time, on budget. We need to provide solutions, not the problems.

Posted on June 4, 2005 07:49 AM | #

17. john said:

I was wondering if someone could elaborate on “Outline the review process in detail…” Specifically what exactly is the review process.

We’ve encountered a couple of clients who would make changes over and over again, generally to the layout design. This of course ate through the budget. I assumed that these kinds of clients are expected, but if there is a way to protect is, then I’m all for it.

Posted on June 8, 2005 06:08 AM | #

18. salli said:

anyone got any examples of a web production project timeline - from start to finito?

thanks
Salli

Posted on June 8, 2005 12:19 PM | #

19. Daniel Schutzsmith said:

I am confused because it seems no one is really talking about including a schedule in an estimate. By the very nature of an estimate you must include these key things:

Scope

Deliverables

Price

Timeline

Without these four elements it doesn’t seem you would have much of an estimate to provide? Now with a more formal proposal you would include additional items such as:

Process - Design and Technical

Site Map

Initial Concept/Solution

Testing & Hand-Off Procedure

Legal Terms

Does anyone else agree with me on this or am I just the odd one out?

Posted on June 20, 2005 07:36 AM | #

20. penelope Phillips said:

excellent-but what I have googled in vain for is a list of basic deliverables
for someone designing a project-I am NOT competition I am a student trying to do something for charity and hijacked into a university course in the effort- I have had my notes stolen - I just need the list eg for pre- production planning what is required- am hoping to put up something like the hunger site-I do not want money- am hoping to get sponsors to
pay a proportion in funds to
Care and other agencies in return for being on the site and to bait it with an English ppeaking learning program and any other free programs I can offer
Could you please just give me a list of documents I have to prepare- you needn’t even tell me how to do it I can begin to research that

Posted on August 12, 2005 11:16 PM | #