Project Scope: Delivering What Your Client Is Paying For

[MMcCarthy]

As a freelance IT consultant for over 10 years, I’ve come to appreciate well defined project scopes. A project scope is a common understanding between you and your client as to what work is included in, or excluded from, a project.

In a study done by CA towards end of last year, one third of all projects end up over budget and over-spend typically 10-20% of the original budget. Primary reasons include poor forecasting(50%), and project scope increasing during implementation(39%). src: Computer Associates

Here are 6 easy to use tips you can take to build the right scope for the next project you take on:

1. Ask Questions

Ask as many questions as you can about the project outline the client hands you. Never assume your client has given you all the necessary information required for you to complete the project on time and properly. Ask leading questions to verify that they have fully understood their own requirements.

2. Your client is always right

Though you may have the know-how to get the project done for your client, you should always be receptive to your clients needs. Avoid being confrontational when you might not agree with your client's direction and goals. Instead lead them to another way of thinking by using well formed questions and well sourced research and statistics. Sometimes it’s necessary to go along with what your client is asking for even if you feel it’s not correct. They might just have more insight to their business than they are willing to share.If at any time you find yourself being proven right after the fact, never say I told you so. It might breed animosity and jeopardize any future business.

3. Get existing Processes

Ask for a copy of any existing hard copy or soft copy processes relevant to the project. Very often seeing examples of what your client is currently doing will go a long way towards building your understanding of the project. You might be able to save them money in the new implementation by using old resources. There are many other benefits to understanding how they are dealing with their case pre-project.

4. Build a relationship

It is important to build a friendly relationship with your client. This makes it easier to discuss possible changes of scope in a friendly manner. It also means your client is less likely to be defensive about any suggestions you might make.

5. Document everything

As a freelancer, particularly when not working onsite, you will often have important conversations with your client regarding the scope of the project. It is very important to document these. It may seem like a lot of extra work but it’s for your own protection.

• Keep a brief set of notes on any meetings with your client and include any points of relevance

• Keep a diary on any telephone conversations with your client and note any important points discussed

• Save all emails received from your client as well as any emails you send

6. Get Client Sign-Off

Make sure that your client signs off on any changes to the scope of the project. Create a document outlining the changes as well as any impact on time scale and cost. Then get your clients signature on that document.

These are some of the wisdoms I’ve gathered during my years as a Freelance IT Consultant. They are not foolproof but they will help you to correctly scope out any projects you undertake.

[Motoma]

I would like to emphasize how important step number 3 is. There is a level of understanding that can only be gained through a hands on understanding of the existing processes and systems in place.

The most successful software project I worked on started with me going on site to the client's office to train with their existing system as if I were a new employee. It taught me the business behind the work, and allowed me to see the system from the client's perspective.

Being able to do this--actually sitting down and seeing what the user does with your own two eyes--not only give you a greater understanding of what your goal is, but it also allows you as a developer to say "Hey, I can make this easier for you!" Which in the long run is how your project will be judged.

[MMcCarthy]

I would like to emphasize how important step number 3 is. There is a level of understanding that can only be gained through a hands on understanding of the existing processes and systems in place.

The most successful software project I worked on started with me going on site to the client's office to train with their existing system as if I were a new employee. It taught me the business behind the work, and allowed me to see the system from the client's perspective.

Being able to do this--actually sitting down and seeing what the user does with your own two eyes--not only give you a greater understanding of what your goal is, but it also allows you as a developer to say "Hey, I can make this easier for you!" Which in the long run is how your project will be judged.

I totally agree. :D

[missinglinq]

In a study done by CA towards end of last year, one third of all projects end up over budget and spend typically 10-20% of the original budget.

This is a typo, Mary; should be

"over-spend typically 10-20% of the original budget."

Wouldn't it to great if most projects spend typically 10-20% of the original budget!

A great article, Mary! I agree that you really need to see first hand how things have been done in the past, especially in an industry you're not experinced in. How you would organize data entry, and how a company's staff have been doing it for years, might be different. Keeping things as close to the past as possible (without redundancy, of course) on the GUI causes less resistence to the new system. A data entry sequence that flows the same way as hard copies used for reference is a real plus.

And I'm a real believer in being up front about costs. When you define the scope of the project and put in that bid, make sure they understand the costs associated with changing the scope/specs after that point. And, if at all possible, get in writing who has the final say on changes.

Linq ;0)>

[MMcCarthy]

This is a typo, Mary; should be

"over-spend typically 10-20% of the original budget."

Wouldn't it to great if most projects spend typically 10-20% of the original budget!

A great article, Mary! I agree that you really need to see first hand how things have been done in the past, especially in an industry you're not experinced in. How you would organize data entry, and how a company's staff have been doing it for years, might be different. Keeping things as close to the past as possible (without redundancy, of course) on the GUI causes less resistence to the new system. A data entry sequence that flows the same way as hard copies used for reference is a real plus.

And I'm a real believer in being up front about costs. When you define the scope of the project and put in that bid, make sure they understand the costs associated with changing the scope/specs after that point. And, if at all possible, get in writing who has the final say on changes.

Linq ;0)>

Agree with everything you say Linq. On the issue of the error I can't really change it as its a direct quote from their article. In other words the mistake is theirs not mine. LOL