In The Super-Good Project Planner, I talk about defining the "Scope of Work" for any project. This is really the golden rule of project labor.
Don't Let Your Scope Creep
One of my very first clients was a nice guy who couldn't focus on a job until it was complete.
We agreed on the job to be completed, and on the price. But when the day came for me to set to work, he had a whole list of additional work. One task he heaped on the pile was to look at his home computer. But I refused to do any work until I'd completed the list we'd agreed upon.
The day was spent with one distraction after another. And finally, when it was over, he was furious. Yes, I'd solved all his problems. But I was way over the three hours I'd quoted. Of course I'd done everything except clean the bathroom floor!
We wrestled a bit and met half way.
But then the exact same thing happened again. I wrote him a goodbye letter and bought myself one of those big, fat, oversized markers. And ever since then I try to draw a very clear line between what's included and what's excluded; what's covered and what's extra; what's inside the scope of the project and what's outside the scope of the project.
Most people think that defining the scope of the project is simply about keeping track of hours worked on the project, and hours added outside the scope.
That tracking is essential if you want to get paid for all of your hours. But focusing on the scope of work goes beyond that. You want to actually define "the project" so you can bring it to a conclusion. To the extent possible, you want to set aside all that other labor while you work on the project. Thus, the project is completed in a timely manner.
When the project's done, you can tie a ribbon around it and invoice the client. But, most of all, you can define clear boundaries around the project.
Define the Scope
When you define the scope of the project, you should do so in writing. It doesn't have to be a long, detailed explanation. If you use Autotask, Tigerpaw, Shockey Monkey, or some other ticket-tracking system, you should have a title for the job and a one-paragraph description. For example:
Title: Install Firewall for new ISP
Description: Install and configure new firewall. See firewall installation checklist. Verify connectivity. Point outbound traffic to new gateway address. Reconfigure DNS (for in-bound traffic). Re-direct Exchange Defender for email filtering. Test all functionality. Disconnect old ISP.
How can this go wrong? Let me count the ways! Clients tend to look at technology as a series of function-based boxes. Once the function works, they ignore it and leave it alone. So, when you want to make changes, you're opening the box. And once it's opened, the client wants to do all related work.
For example, they might take the firewall job as an opportunity to install the BlackBerry server. Or move the web server. Or make that major change you've planned for email domains. Or rack the servers!
Whatever the suggestion is, you must say these words over and over again: That's outside the scope of this project.
We've all had great success installing a firewall and moving to a new ISP. We've also had the move from hell, where everything that could go wrong did go wrong. If you've also moved all the servers, unplugged and replugged every wire, and installed a new email filtering configuration, this could be the longest day of your life.
Q: What's the first rule of troubleshooting?
A: Change one thing at a time.
It is extremely important that you focus on the job you came to do. Be successful. Show the client that it works. In this way, you completely avoid the scenario where the client starts second-guessing whether the primary goal was accomplished before all the other jobs made troubleshooting so complicated.
Install the firewall. Test. Be 100% successful. THEN see if you have time to get started on another job. But don't ever put yourself in the spot where you have to troubleshoot a new firewall and new spam filtering at the same time.
When you have limited and well-defined projects, troubleshooting those projects is also limited and well-defined.
And that means profitable.
For the client, this process will always save money. After all, if you limit how much troubleshooting you need to do, you limit the number of hours required. If you keep each job isolated and self-contained, you limit the number of hours required.
Speak in Human Terms
One final tip for getting client buy-in for this process: Speak as a business person and not a techno-goober.
Your internal process might say something like "Configure one-to-one network address translation and redirect port 442 traffic from the insecure WAN IP to the primary server LAN IP."
Blah blah blah blah, Ginger.
What does the client want to know? You're going to properly configure the firewall, document it, and test it. That actually means something to the client -- and it's worth paying for.
- And setting up a new service has to be done after the firewall is properly configured, documented, and tested.
- And setting up spam filtering has to be done after the firewall is properly configured, documented, and tested.
- And racking the servers has to be done after the firewall is properly configured, documented, and tested.
- And moving to a new web server has to be done after the firewall is properly configured, documented, and tested.
So, you see, defining the scope of the project does a lot more than protect your revenue for a specific job. It improves success on the current job, and all those other jobs. It improves success on all jobs. It improves your relationship with the client. It saves the client money. It reduces downtime. It reduces the need for troubleshooting.
It's the golden rule of project labor.