Whenever the topic of project management comes up in a crowd of architects and engineers, it doesn’t take long before the conversation tips in the direction of scope management. Indeed, it’s a theme worthy of discussion because the scope we establish is the one the entire project team lives with for the life of the project. It is the working document that becomes either the center of consensus or contention.

Though all projects are unique in some way or another, there are some elements relative to scope design that no project can afford to ignore. I could spend all day talking with you about procedures for developing a stronger scope of services, but since I only have this small column space, I’ll cover the must-haves:

The process. Like anything else, the scoping effort needs a mapped-out process and baseline to follow to ensure we fulfill the client’s requirements. For many firms, this looks like a comprehensive checklist of services and components— obviously trimmed or supplemented depending on the project. This is the time to be meeting or talking with the client as much as possible and to have all the questions you need answered. These questions may not necessarily deal with the scope directly, but it will help you get closer to defining it. This process also includes getting sign-offs at the various stages of design— simply as a measure of clarity and acceptance for all parties— because deciphering what the client wanted after the fact doesn’t make you look like you know what you’re doing. Guiding the client toward a better scope is the best ounce of prevention against later disappointment and dispute. Keep this in mind: if the client isn’t sure about what they want, it’s your fault, not theirs.

The documents. In the realm of project management, it’s difficult to say which is the most important document of all— the charter, project management plan, Work Breakdown Structure, or scope statement, to name a few. From the questions being raised in our training and consulting practice, it appears more misunderstanding arises from the scope of services presented right at the start, than from any other document. Not all projects are straightforward. However, the level of detail we articulate about the services we’re providing determines how well we’ll be able to control that scope later on. Even with uncertainty, we should be certain of these things: the scope matches the client’s objectives and requirements, it establishes boundaries and guidelines for anything outside the scope, it identifies constraints, and it records our assumptions. This is the paper you’ll be measured against. So remember, if the client doesn’t understand what you’re providing and the associated value, it’s your fault, not theirs.

The deviations. Changes are inevitable— but having a policy in place to deal with any alterations, additions, and deletions keeps these changes fair to everyone. Scope creep and rightfully getting paid for legitimate client adjustments goes hand in hand with the frustrations most architecture and engineering firms mention when discussing scope of services. This isn’t surprising, since deviations mostly arise from the client expecting something more than we anticipated providing— and that’s because the scope had some fuzziness to it to begin with. More often than not, firms avoid conflict and hope the issue will go away quietly or they satisfy the request and eat the costs. Over time, this isn’t sustainable, and in today’s economy we can’t afford to do this too often. Most firms I work with detail the boundaries with certain inclusions, exclusions, limits (specific number of reviews, tests, visits, etc.) and confirm an hourly and reimbursable rate for additional work. There is a fine line between nickel-and-diming the client to death and getting paid for our professional work— so setting your appetite and financial limit per project is very important. You have a business to run, so not getting paid for changes is your fault, not the client’s.

The outcome. Firms are often reluctant to try anything new or slightly different for fear of backlash from clients who have become conditioned to our practices. Other firms implement everything at once— which is too much to handle. It’s advisable to work on one area at a time until we feel comfortable with it, have tested it with various clients, shared lessons learned, tweaked it as necessary, and looked for the benefits of that change. Firms are instantly discouraged when something doesn’t work once— and so they never really improve— but still complain about it. If you think something can be done better in the scoping process, start working on it. The next time you find yourself in a conversation about the annoyances of the scoping process, hopefully you won’t have anything but helpful hints to contribute.