Needs + Resources + Location + Schedule + Budget = Scope

By Whitney Hess

Published: December 7, 2009

“Your goal in the contract negotiation process is not to determine the best price, but to most accurately define the scope of your project. This is possibly the most critical factor in the success of your project….”

Now that you’ve convinced a client they want to work with you, it’s up to you to define the terms of your working agreement. Your goal in the contract negotiation process is not to determine the best price, but to most accurately define the scope of your project. This is possibly the most critical factor in the success of your project, and it’s something most consultants completely fail to follow through on.

A Statement of Work (SOW) formally defines the scope of the activities and deliverables for a project. BusinessDictionary.com defines scope as the “chronological division of work to be performed under a contract or subcontract in the completion of a project.”

Some clients have a very specific chunk of work in mind, while others just know they need help. In either scenario, use your expertise to determine the appropriate amount of work to tackle, according to several key variables: needs, resources, location, schedule, and budget.

You must—I repeat, must—get all of these variables nailed down before you sign a contract or start a stitch of work. I will go into the details of contracts in another column, but suffice it to say that making the effort to determine the specifics ahead of time is always worthwhile, to ensure your contract clearly defines and establishes the terms of engagement with your client.

I’ve used the equation in my title quite purposefully: Needs + Resources + Location + Schedule + Budget = Scope. If you reduce any of the variables of your project, you must also reduce the overall project scope—and vice versa. A smaller budget, smaller scope. Fewer resources, smaller scope. Better location, bigger scope. Greater needs, bigger scope. To best understand this synergistic relationship, let’s go through each variable one by one.

Needs: Why?

“When a client presents the desired goals for a project, you shouldn’t necessarily take them at face value. You are the expert. They are hiring you precisely because you know more than they do in this particular area….”

The very first questions you must answer when considering working with a new client are: Why does this project need to happen? Why does the client want to hire you? Why is now the time they want to start this work? Why are your core skills necessary to help resolve the problems the client is facing?

Some clients may come prepared with a long list of business requirements they’ve gathered from a variety of stakeholders throughout their organization. They might even have prioritized them for you. However, those items may just be on someone’s wish list—not really requirements that are based on the needs of their customers. Has the client done any research? Who is determining the organization’s internal strategy, and what are their motivations? While you might not be able to explore the details of some of these questions until the project kicks off and you can conduct stakeholder interviews, it is still important to ponder them during this initial project-definition process.

Remember, you are the one who has better knowledge of what is actually feasible to achieve—and do well—and the tools to determine whether it really should be done. When a client presents the desired goals for a project, you shouldn’t necessarily take them at face value. You are the expert. They are hiring you precisely because you know more than they do in this particular area, so don’t shy away from the responsibility of providing input based on your knowledge and experience. Take the time to ask the right questions and figure out what the wiggle room is.

It is essential to analyze why a client wants to engage you on a project in the first place. Don’t enter into an agreement with the client before wholly understanding the project’s purpose and intent. You don't want to be blindsided down the road by a newly revealed ulterior motive or a wild change in priorities. Of course, this sometimes happens anyway, but you needn’t encourage it.

Resources: Who and How?

“Once you know why a project is important to a client, you must consider who is going to help you get all of the work done and how.

Once you know why a project is important to a client, you must consider who is going to help you get all of the work done and how. Here are three things to chew on: Who is on your team? Who is on their team? How will the two teams collaborate?

Let’s start with you. What people do you have pegged for your team? What are their skills and availability? How well do you expect all of them to work together? How much management will they need? You shouldn’t commit to a project before you have your team lined up, because you don’t want to be the cause of delays. Plus, it’s the strength of your team that largely determines the extent of what you can accomplish.

If you have a consistent team in place for all projects, that’s great. You might already have a lot of these kinks worked out. But if you’re piecing together a new team just for a project, particularly a team that has never worked together before, you don’t really want to be working out your problems on your client’s dime, do you? Review all of your options before making what could be an irreversible decision.

In some cases, you may be a team of one. Often, I work completely solo on my projects for clients. That raises a whole different set of questions. What is my availability? How many projects am I juggling? Am I equipped to take on the required set of tasks? Do I have the expertise and experience to do so successfully? How can I supplement my skills to provide better service to my clients? As the sole resource, your responsibilities may be extremely varied—and often in conflict with one another—so it’s best to go in prepared with potential solutions in case you find yourself in a tough spot.

“You need to fully understand the time commitment the client is prepared to make before you can determine the appropriate amount of work to take on and a realistic schedule in which to get it done.”

Now that you have your team assembled and have considered the consequences of taking on a project, turn your attention to the client. Who will your client dedicate to making the project a success? Who will be coordinating meetings? Who—likely a different person—has final approval on your work? You may also need access to some subject-matter experts in the client’s organization. Who are they, and are they aware of the project? What is their level of commitment? Might there be some company politics to navigate?

You need to fully understand the time commitment the client is prepared to make before you can determine the appropriate amount of work to take on and a realistic schedule in which to get it done. While you might be on time with each and every deliverable, if the client takes a week to get back to you and delays the project, it’s still your deadline that gets jeopardized. You need to go into the project with all the necessary intelligence to craft the best plan of action.

Finally, evaluate the last aspect of resources that needs to be on your radar screen: How is your team going to get everything done? Having the people in place isn’t enough to ensure they have the means to collaborate and produce their work.

What tools are at your disposal? Are you comfortable using them, or do you need training? If you don’t currently have the necessary tools, do you need to acquire them on your own, or will your client provide you with access to them or funding for them? The answers to these questions affect the budget, the timeline, and the human resources you need for a project, as well as what is feasible to produce and the location in which the work will get done.

Location: Where?

“Travel time is still time you’re dedicating to a project, because it takes away from the time you could be spending on another client or on yourself.”

Where a project takes place is another critical factor in determining the appropriate project scope. Your office is here. The client’s office is there. How will the distance between you affect the outcome of the project? Will your client require you to work on site? Will you need to travel a significant distance? Will satellite offices be in play?

Remember, travel time is still time you’re dedicating to a project, because it takes away from the time you could be spending on another client or on yourself. Travel becomes tiring and will likely extend your schedule. There are also cost implications and the accommodation of your resources to consider.

Recognizing the location or set of locations for a project also forces you to determine how much of your or your team’s time you need to allocate to the project. This issue is related to, but somewhat different from the project schedule. You aren’t noting just when you’ll get things done, but how often your client will expect you to do them. Working on site at a client’s place of business means you’re working on their time. Attempting to do work for a client at another client’s office isn’t just tricky to pull off—it’s pretty unethical.

To avoid putting yourself and your team in a compromising position, you need to be clear ahead of time on how the work locales will affect your productivity, performance, and timing. To ensure you don’t commit your resources to something the work environment simply won’t allow, adjust your scope of work accordingly.

Schedule: When?

“While it can be incredibly difficult to predict what obstacles you’re going to face before you’ve even started a project, you need to have realistic goals for how much time each phase of the project will require and when you can complete them.”

The second biggest question on your client’s mind is: When is everything going to get done? While it can be incredibly difficult to predict what obstacles you’re going to face before you’ve even started a project, you need to have realistic goals for how much time each phase of the project will require and when you can complete them. Realistic is the key word here. Don’t promise you’ll meet a ridiculous deadline, then drive yourself and your team crazy to meet it. Your work will invariably suffer, your attitude will be pitiful, and the overall project morale will plummet. That can be a very difficult thing to recover from, so don’t even go there.

Be honest, ahead of time, about how much time you will need to conduct each activity and produce each deliverable. Do yourself a favor and add some cushion time for good measure. Don’t neglect to schedule thinking time, learning time, breathing time, and changing-your-mind time. All are necessary components of your success. There is no need to rush, even when the client says so.

What is the desired end date of the project? Do you need to start work immediately to make that date, or can and should the project begin at a later date? How much back-and-forth between your team and the decision makers on the client’s end will the project require? How many rounds of review are you baking into the process? What flexibility do you need for additional reviews of a particular deliverable, if a conflict arises? What holidays do you need to keep in mind? Do you need to accommodate anyone’s vacation time?

If there is a drop-dead date the client must meet for external reasons—for example, a scheduled event or advertisement your work will support—now is the time to reduce the scope of work. Take on only what you are absolutely positive you can achieve in the amount of time available. On the other hand, if a deadline is looser or, more commonly, arbitrary, weigh the pros and cons of reducing a project’s scope versus extending its deadline. More often than not, when you present a client with this choice, the client will relent on the timeline, in an effort to get the work done to its fullest extent—and get it right the first time.

You won’t be able to predict a detailed schedule of events for a multi-month project before it has even started, but you should provide your client with a high-level, week-by-week approximation of what you’ll be working on when. Give your client a sense of how long it takes to get things done, providing a time range, if necessary. For some run-of-the-mill projects, you could fairly accurately pin down some key dates, while for other projects, you might want to avoid committing to any dates at all, but instead define the duration of each phase of a project. If you suspect a client might cause delays, because of internal bureaucracy, lack of experience, or conflicting goals, don’t commit to specific calendar dates.

There are always clients who want to get things done faster. If you ask, When do you need this by?, their answer will be Yesterday. The classic project triangle provides an apt response: Cheap. Fast. Good. Pick two. I like to add that I’m not willing to do work poorly, so really their decision is between cheap and fast. If your client must stay within a specific budget, they’ll soon realize it’s time to prepare their team for a longer timeline than they had originally hoped for. But if they absolutely need me to hustle on their project, I’ll need to bolster my resources and put aside other work, and that’s going to cost the big bucks.

Budget: How Much?

“Jared Spool … taught me to always make clients tell me their budgets for projects.”

Ah…, the age-old question: How much is this gonna cost me? One of the first things most prospective clients ask me for is my hourly fee, and I tell them I don’t have one. I’m not willing to work by the hour, because I don’t believe the value of my work can be measured by the amount of time I spend working on it. What if I discover a genius insight and get the work done in half the expected time? Does that mean I deserve to be paid half as much? On the flip side, what if I spend twice the amount of time I’ve allocated to a project, reworking a solution, because I wasn’t pleased with the first design? Does this mean the client deserves to pay twice as much?

Jared Spool, a fount of knowledge and a consultant for almost his entire career, taught me to always make clients tell me their budgets for projects. It’s certainly not an easy thing to do, and you need a thick skin to do it well, but I try my damnedest to do it every time. Understanding a client’s budget up front lets you determine the appropriate scope of work for their project, taking into account all of the other variables I’ve described. If you name a price first, you create one of two scenarios:

  1. Your price is wildly outside the client’s budget or out of line with competing vendors’ price tags, and the client decides they don’t want to work with you.
  2. You devalue yourself.

I would argue that the latter is far, far worse.

“Price is negotiable. It’s always negotiable—no matter what anyone says. Price is the explicit value a client assigns to their project’s outcome.”

Price is negotiable. It’s always negotiable—no matter what anyone says. Price is the explicit value a client assigns to their project’s outcome. If you increase its value, they’ll be willing to increase the price. But if they lower the price, you have every right to decrease the value as a result. Remember, you are entering into a business relationship. You aren’t taking on a project out of the kindness of your heart. You are an expert, and you provide a service that is worth paying for. If a project’s budget is limited, reduce the assigned resources, adjust the schedule accordingly, make greater demands regarding where you’ll work, and limit the activities you’ll conduct and deliverables you’ll produce.

The worst thing you can do to yourself as a consultant is to do work at any cost, out of desperation. There will always be more work, even in a down economy. If you take whatever clients are willing to pay, despite the scope of work, you not only risk the success of the project, you depreciate the value of the services you’ve provided to other clients at a higher price. The ultimate consequence would be that you’d turn what you do into a commodity. The prices of commodities fluctuate with the market, but expertise is an inelastic good, the price of which always stays high. You have the skills to warrant the price you demand. Furthermore, the bigger a project’s budget, the more respect your client will give you, and the more determined they will be to help make the project a success.

If a client isn’t willing to pay you what you’re worth, they aren’t worth working for. Explain how you can adjust the scope of their project to fit within their budget. If you define a smaller, more condensed, more focused project for your first engagement with a new client, you give yourself the opportunity to prove the impact you can have on their organization and pave the road for future, bigger-budget projects.

= Scope: What?

“The why, who, how, when, and how much all add up to the what on a project—the scope. It’s a common misconception that the scope should determine all of the other variables, but the reality is that needs, resources, location, schedule, and budget really are the pre-determined constants in the situation.”

The why, who, how, when, and how much all add up to the what on a project—the scope. It’s a common misconception that the scope should determine all of the other variables, but the reality is that needs, resources, location, schedule, and budget really are the pre-determined constants in the situation. What you’re going to produce—the scope—results from all of those other constraints.

In order for anything to ever get done, projects need to constitute self-contained chunks of work you can realistically accomplish, given the current environment in which you and your clients find yourselves. You’ll likely need to explain that to your clients—largely because they live and breathe their work every day. Since they’re stuck with it for the long term, they might not be used to thinking about their activities in segmented phases. You’re the expert. You need to guide them through this decision-making process, and you need to do it before putting your signature on the dotted line.

Clearly defining a project’s scope before the project begins sets you up for success. Establishing shared expectations between your company and your client makes you stronger partners, reduces the distractions misinterpretations can cause, and lets you both focus on what really matters—making a product that improves people’s lives.

3 Comments

Thanks for sharing, Whitney.

Strictly speaking, your definition is wrong. Needs + Resources + Location + Schedule + Budget = Project. Scope is part of a project—and more or less equivalent to what you call Needs. Scope is a set of requirements for project deliverables. Deliverables can be documents, reports, or software packages—or bundle of other scopes, or work packages—whatever is applicable.

To make things more complicated—during contract execution a number of projects that are based on scope may exist inside each party. For example, a customer must execute a project to perform acceptance testing of deliverables expected for scope. A sub�contractor may have its own project to deliver a component or piece of work derived from scope.

It is the scope, schedule, and budget that are, most commonly, subject to contractual agreement between parties. Any normal contractual agreement must have a provision for changes in either part. The solutions for overruns vary from acceptance to contract cancel—with or without financial obligations. Except some requirements, I’m not sure my customers care who executes the project where if said three basic parts are met. An example of such specific requirements can be 24/7 support in the local language, with an option of, say, on�site presence.

To return to your explanation—for example, smaller budget = smaller scope—I should point to the standard project triangle—cost, schedule, scope—Project Management Triangle (Wikipedia).

It is an ideal situation where you can factor all uncertainties into the contract, select schedule and budget with enough buffer, and prevent scope creep during execution. However, in reality, this is not always the case. This is where risk management comes into the picture. How to identify where something can go wrong, how likely it is, how much damage a project may incur, and what you can do to prevent or mitigate it. And once we know all of this—track and adjust, track and adjust. :)

Of course, it depends on the scale of projects we are talking about. Maybe what I said above is overkill for a 1-page report that took couple of days to prepare and write.

Such a great article! The biggest takeaway for me is that Scope is the product, not the driver. I think that this is important—not just for consultants, but for internal teams as well. It makes so much sense when we think about it. A client gives a scoped project to a team. Then, they try to find resources to fit that need. It’s always overscoped, then needs to be de-scoped. This point of view is essential in preventing this situation.

Thanks, Whitney.

“If you take whatever clients are willing to pay, despite the scope of work, you not only risk the success of the project, you depreciate the value of the services you’ve provided to other clients at a higher price. The ultimate consequence would be that you’d turn what you do into a commodity. The prices of commodities fluctuate with the market, but expertise is an inelastic good, the price of which always stays high.”

Enjoyed this part around value. I think this says something toward not only the value we provide, but the perceived value we are creating for the UX community as a whole. As soon as we start to undercut or undervalue what we do, it can potentially hurt in the long run.

The question is: Where are the sweet spots for UX value in what we do?

Join the Discussion

Asterisks (*) indicate required information.