Scoping Projects

November 16, 2005 | 28 Comments

It’s been a little while! I’ve been working really hard the last few weeks and have had very little extra time, thus the silence. Blue Flavor has been going very well, I’ve been greatly enjoying it and it’s demanded almost all my attention! ;0)

We’ve got clients now. Quite a few of them in fact. And projects! You know—work and all that. We’re still a small team (although that may change relatively soon) and we’ve all been having to wear multiple hats. One day I’m doing client work. The next business development or project management or something else that needs doing.

It’s funny because some of the tasks that I used to hate I’m now growing to enjoy. Working for yourself can do that. In any case, one of the things that’s been on all our minds is how best to scope and budget our projects.

Avoid starting without proper scoping

Determining the scope of any project isn’t an exact science. There is a whole lot of educated guesswork that goes into it. If that weren’t enough, there’s often negotiation that needs to happen, as a potential client might not place the same value on things as you do.

We’ve had a few projects so far and most have gone pretty well. A few haven’t gone so well. Those that haven’t have had one glaring thing in common — they weren’t adequately scoped out.

Sometimes it’s hard to avoid. If a client wants to kick off without proper scoping, for example, you may just roll with it to get the work. Or, you might have a really short timeframe and feel you need to get a jump on things.

My advice is to be very careful about doing any project that hasn’t been thoroughly scoped out in advance. Even if you’re starving for work. By “thoroughly” I mean that you, the client, your mom and your dog all know in fairly granular detail what’s expected and when.

Have a statement of work that everyone is agreed to before you start. Be specific as you can when it comes to review cycles and iterative design or development. In my experience if you leave any wiggle-room you’ll end up wiggling.

The more specific you can be, the happier you’ll be when you’ve come up against something that doesn’t quite fit.

Account for scope creep

“Scope creep” is kind of a cliched term. However, it’s also a very real risk, especially when it comes to Web projects. I’ve found that it’s very hard to estimate a Web project right off the bat. You’ll almost always discover more work as you go.

One of the things we’ve been trying to do is have our clients agree to a scoping phase up front. We did this a PBDH and it worked pretty well. The idea is that you set aside some time for proper scoping and project planning as part of the project.

Some clients go for this. Some don’t. In the end it’s usually beneficial to everyone involved, but it often takes a little selling.

The idea is to spend some time with the client trying to cover every possible thing that could change or go wrong. Then, after you’ve got the best idea possible about the project, you can re-estimate it if in fact you’ve discovered things outside of the original scope.

Another idea is to write your statement of work, contract, etc. so that it’s clear how you’ll handle changes. This is especially important if you’re doing project-based work vs. hourly. The goal here is to protect yourself against last minute changes, huge shifts in direction, and other unforeseen bumps in the road.

If you’ve got a client that will take an inch, they’ll probably take a mile as well and chances are they’ll be wanting similar protection from you.

Standards-based sites

I think a bit of special attention needs to happen when it comes to scoping out a standards-based site. When it comes to development and production of a standards-based site the biggest risk factor is still support for Internet Explorer. In case you had forgotten, I’ve got a news-flash for you: IE still sucks.

Initial development of a standards-based site can take time, effort and quite a bit of creative problem-solving. It’s also a fairly rare skill. All of this should be accounted for in the initial scope of a Web project.

It’s pretty easy to get overconfident. I know I’ve done it many times and later regretted it. Until IE support is no longer a factor, it makes good sense to account for potential problems there.

Basically what I’m saying is that you should have some extra time in your schedule and not treat standards-based development as a commodity. I’ve had quite a few projects go south because I figured I’d have “no problems” in this area. ;0)

A few random tips

• Beware the “fun” project. If you think a project or client seems like “fun” be wary. You may be tempted to jump right in, or maybe even cut them a deal. This is a bad idea. It may not end up being fun at all, and if you compromise it’ll end up even worse for everyone in involved. Treat fun projects as you would any other.
• Beware the “easy” project. No project can be named “easy” until after it’s completed. Sometimes what seems to be easy may be hiding something difficult. Proper scoping will help make sure you know the difference.
• Stick to your guns. There are huge differences in how people see the value of a typical Web project. Don’t let a potential client talk you into taking less than what you see the value as. It’s a bad way to start and will most likely end up with an unhappy you and an unhappy client.
• Be flexible, but protect yourself. Clients want someone who can be flexible. You’ll want a process and scope of work that can account for changes fairly easily but at the same time keep you from getting taken advantage of.
• Give yourself extra time. Sometimes a few days can make all the difference in the world. We often get caught up in “hours” when it comes to projects. I’ve found that I don’t mind putting in extra hours if needed, as long as I’ve got enough “days” to keep my stress level down. If you can, my advice is to add a week or two to your schedule to account for minor slips. If you can accommodate those, you’re client will be very happy and you’ll come out looking good. (This is especially important if you are deadline driven as I am. If you’re fine missing deadlines, this might not be a big deal.)
• Realize that a perfect project doesn’t exist. I know I have to keep reminding myself of this. Every project has its problems and all you can do is try and do your best to set yourself, your client and your team up for success. The more planning you can do, the better. However, chances are you’ll still run into problems along the way.

Filed under: Project Management
Keyword Tags: project+management scope+creep project+planning business

Comments

New Comments Disabled