Two important things that will keep a project on track

Published on December 12, 2012 under Customer Education, Business, Web Development

Scope of Work

As designers and/or developers, we encounter a wide array of customers and clients throughout our careers. They can be freelance customers or just clients from whatever employer we work for. Regardless of if you're the client or the service provider, it's guaranteed you've been involved in the typical story of that short project that turned into a long drawn-out drama.

A colleague of mine, we'll call her "Dana", had a recent incident. She read my article on Justifying the price of a website, and had reached out to me both here and on LinkedIn about a recent problem she had with what was supposed to be a quick and easy Wordpress site.

Dana's client wanted what was supposed to be a basic 6-page site. The plan was the client would select a premade Wordpress theme, Dana would set it up, and she would make any small modifications agreed to, as well as fix any actual bugs.

The end result turned into a very long drama where the client would keep handing Dana lists of "bugs" that often were more beauty tweaks and modifications. The client would be extremely nitpicky and would keep requesting more than the project was supposed to be. Suffice to say, Dana had to eventually "fire" her client.

Sounds like a story you've been in? Here's how to hopefully prevent it from happening to you.

Always have a detailed Scope of Work

Project planningNow Dana did tell me she had a Scope of Work in the contract with her client, but you would be surprised how many horrific tales of web design I've heard where there wasn't one. A Scope of Work is a detailed summary of what will be in a project and what the exact deliverables will be. It's set up so there is little to no "gray area" when the project is underway. Both sides know what is expected and what they will receive.

I've had projects go the direction Dana's did in my past. Sometimes it was the client constantly asking for or trying to nudge more out of me than what was agreed to. One such case was a client who simply wanted a static website with no CMS, but suddenly they had this monthly PDF newsletter they wanted on the site with a search function put in. I had to decline because it was not within the Scope of Work we agreed to.

I've also had "trouble from within" where account persons or producers will suddenly overpromise to a client and neglect to tell me. It's come down to points where upper management would drag the "guilty parties" into a conference call with the client and set things straight.

Writing a Scope of Work isn't very hard, but it takes planning and negotiation to reach this point. Often times as a freelancer you might have to even wait on a down payment until you get this in order...simply because you might not know how big the project will be. If you ever read my article on The procedure on building a website, the Scope of Work should be written in the "Discuss, brainstorm, and plan the site" part of the project.

So in Dana's case, when she sat down with her client and planned out the site she was going to build, she should have first determined the business goals of her client, and what sections of this 6-page site he wanted. So perhaps he wanted a home page, about page with two staff bio pages, an online store, and a contact page. Dana would then write in the contract that she would use Wordpress (in this instance) to build the six sections using a premade template. She would install the contact form plugin and whatever online store plugin she determines as the ideal solution.

In her Scope of Work she should pretty much spell out how she will go about this project. She will state that the client will find a template for her to use, and even go into detail how much or little she will modify that template visually. In my opinion, she should have looked for the template on her own based on his likes/dislikes in websites, but that's another discussion. Still, setting the limits would have kept the client in check when he kept asking for physical changes, claiming they were "bugs". Sometimes you might even have to define these terms (the difference between a "bug" and a "beauty change") in your Scope of Work.

Dana should then list each section and what will entail in the building. So the home page will contain perhaps a news slider and a few product callouts. The about section will contain the company story and links to bio pages for each staff member. The store section would be "powered" by the plugin she picked, and the product layout pages would not be changed from how the plugin lays them out. The contact page will simply contain the company's address, phone number, and a form from where someone could email them.

It's important to immediately state how far you as a designer or developer will go from section to section. Note how I suggested Dana state that she will not modify the store plugin to display products differently. You need to state things like this so a client or even a coworker won't suddenly push to totally change how a 3rd-party plugin works. Not unless more money is going to be given for a custom setup.

You should also make it clear that what a client receives is what is in this Scope of Work. Don't put anything vague in the scope, and make it clear that outside items one would assume are "included" are not. An example would be social network pages, or if Dana's client suddenly hired on ten more people, and thus wanted Dana to make ten more bio pages for those employees. You have to be specific so the client knows his limits and you have a solid document to stand by when they push for more.

Now...if a client pushes for more, and you feel that it's not much trouble, then do it. Even then, set limits. Let's say Dana's client wanted a Facebook page set up for his business, and she felt like it's not a lot of trouble. She should still make it clear it's only a setup. So if he suddenly wants her to post new statuses and seek out fun stuff to post, she can simply say "no, it's not in the scope of work".

Create a solid Timeline and Penalties

Project timelineLooking at Dana's case, one other problem with her project plan was that there was no clear timeline. She stated how after three weeks the client had not selected a template to use, and even then the project would drag on further with other critiques, beauty changes claimed as "bug fixes", and more. Again, I'm sure many of us have been in her shoes, and thus it's why a firm timeline has to be made when you create your Scope of Work.

It's as easy as it says. You can even integrate this with the Scope of Work and a payment plan. You simply set things up in a calendar sense of when the project begins, time allotted for tasks, deadlines for deliverables, and time allotted for client feedback and revisions. At the end of it is a launch date and perhaps a few weeks for any last minute bug fixes and such.

You should also make it clear when certain milestones are passed, that the client has signed off on the deliverables and cannot go back to make changes. So let's say Dana's client picked a template, and she set up the home page, about section, staff bios, and the store. Suddenly the client woke up one morning and thinks the site would look better in blue than green, or he wants his logo and phone number bigger. Because of the set timeline, Dana can simply say "no", or tell him if he wants these changes he'll have to pay more money and delay the launch.

Penalties in the contract might sound mean, but they at times necessary to keep both sides of the equation in order. I don't recommend them unless you can tell this client will be a future problem, but penalties can be anything from a delayed launch date to monetary fines due to missed dates.

So the client gets a layout and has one week to review and return with revisions. It's now a month later and you keep chasing him/her for feedback, but they're always busy. You could push the launch date by every day the client was late, or charge them a monetary amount per day for delaying you. You just have to make sure it's in writing from the beginning and the client agrees to this.

To the clients and customers

I know this article is making you out to be the bad guy, and some might then ask why we're not bending over back for the people who are paying us, but I'd also toss in here that a Scope of Work and a firm timeline also helps and protects you. As much as I'll hear designers and developers speak of "clients from hell", I've met plenty of clients and potential clients who have spoken of providers who vanished or didn't deliver what was promised.

Let's think in reverse. Imagine if Dana had taken a $500 down payment from her client with a very basic Scope of Work and no timeline. Now it's two months later and the client has not heard a word from Dana. No layouts, no templates to look at, nothing. So the client chases her down, and maybe finally gets some templates to look at, but again...another month passes without a peep.

The client continues to push and get angry, but finds Dana has been taking on and finishing other web jobs that pay more money while ignoring the client. How about if you ask for staff bio pages, but Dana says she only promised one about page? Can you see then why a Scope of Work and timeline protects the client as well?

Even if this "reverse-Dana" was not irresponsible, your time is money and you have a business you want launched. You can't afford to spend a year nitpicking every pixel of your website while your competition grows bigger. Believe me, I've seen many startups fail because they spent too much time and angel funding by nitpicking the wrong details...when they should have gotten their business going online.

Developers like myself and Dana would rather see your business launch online, grow successful, and then we can do a new deal later for a bigger and more lucrative website. We are looking out for your best interests as professionals.

Have you ever run into "projects from hell" because of a lack of Scope of Work or timeline? Share your stories.

Tags: project management, scope of work, timeline, setting limits, clients

comments powered by Disqus