Working within Your Project Constraints

By Stanley E. Portny

Naturally, you’d like to operate in a world where everything is possible — that is, where you can do anything necessary in your project to achieve your desired results. Your clients and your organization, on the other hand, would like to believe that you can achieve everything they want with minimal or no cost to them. Of course, neither situation is true.

Defining the constraints you must work within introduces reality into your plans and helps clarify expectations. As you plan and implement your project, think in terms of the following two types of constraints:

  • Limitations: Restrictions other people place on the results you have to achieve, the time frames you have to meet, the resources you can use, and the way you can approach your tasks
  • Needs: Requirements you stipulate must be met so you can achieve project success

Working within limitations

Project limitations may influence how you perform your project and may even determine whether or not you (and your project’s drivers and supporters) decide to proceed with your project. Consult with your project’s drivers and supporters to identify limitations as early as possible so you can design your plan to accommodate them.

Understanding the types of limitations

Project limitations typically fall into several categories. By recognizing these categories, you increase the chances that you’ll discover all the limitations affecting your project. Your project’s drivers and supporters may have preset expectations or requirements in one or more of the following categories:

  • Results: The products and effect of your project. For example, the new product must cost no more than $300 per item to manufacture, or the new book must be fewer than 384 pages in length.
  • Time frames: When you must produce certain results. For example, your project must be done by June 30. You don’t know whether you can finish by June 30; you just know that someone expects the product to be produced by then.
  • Resources: The type, amount, and availability of resources to perform your project work. Resources can include people, funds, equipment, raw materials, facilities, information, and so on. For example, you have a budget of $100,000; you can have two people full time for three months; or you can’t use the test laboratory during the first week in June.
  • Activity performance: The strategies for performing different tasks. For example, you’re told that you must use your organization’s printing department to reproduce the new users’ manuals for the system you’re developing. You don’t know what the manual will look like, how many pages it’ll be, how many copies you’ll need, or when you’ll need them. Therefore, you can’t know whether your organization’s printing department is up to the task. But at this point, you do know that someone expects you to have the printing department do the work.

Be careful of vague limitations; they provide poor guidance for what you can or can’t do, and they can demoralize people who have to deal with them. Here are some examples of vague limitations and how you can improve them:

  • Time-frame limitation:
    • Vague: “Finish this project as soon as possible.” This statement tells you nothing. With this limitation, your stakeholders may suddenly demand your project’s final results — with no advance warning.
    • Specific: “Finish this project by close of business June 30.”
  • Resource limitation:
    • Vague: “You can have Laura Webster on your project part time in May.” How heavily can you count on her? From Laura’s point of view, how can she juggle all her assignments in that period if she has no idea how long each one will take?
    • Specific: “You can have Laura Webster on your project four hours per day for the first two weeks in May.”

When people aren’t specific about their constraints, you can’t be sure whether you can honor their requests. The longer people wait to be specific, the less likely you are to adhere to the limitation and successfully complete your project.

Looking for project limitations

Determining limitations is a fact-finding mission, so your job is to identify and examine all possible sources of information. You don’t want to miss anything, and you want to clarify any conflicting information. After you know what people expect, you can determine how (or whether) you can meet those expectations. Try the following approaches:

  • Consult your stakeholders. Check with drivers about limitations regarding desired results; check with supporters about limitations concerning activity performance and resources.
  • Review relevant written materials. These materials may include long-range plans, annual budgets and capital appropriations plans, cost-benefit analyses, feasibility studies, reports of related projects, minutes of meetings, and individuals’ performance objectives.
  • When you identify a limitation, be sure to note its source. Confirming a limitation from different sources increases your confidence in its accuracy. Resolve conflicting opinions about a limitation as soon as possible.

Addressing limitations in your scope statement

List all project limitations in your scope statement. If you have to explore ways to modify your project plan in the future, this list of limitations can help define alternatives that you can and can’t consider.

You can reflect limitations in your project in two ways:

  • Incorporate limitations directly into your plan. For example, if a key driver says you have to finish your project by September 30, you may choose to set September 30 as your project’s completion date. Of course, because September 30 is the outside limit, you may choose to set a completion date of August 31. In this case, the limitation influences your target completion date but isn’t equivalent to it.
  • Identify any project risks that result from a limitation. For example, if you feel the target completion date is unusually aggressive, the risk of missing that date may be significant. Your goal is to develop plans to minimize and manage that risk throughout your project.

Dealing with needs

As soon as possible, decide on the situations or conditions necessary for your project’s success. Most of these needs relate to project resources. Here are a few examples of resource-related needs:

  • Personnel: “I need a technical editor for a total of 40 hours in August.”
  • Budget: “I need a budget of $10,000 for computer peripherals.”
  • Other resources: “I need access to the test laboratory during June.”

Be as clear as possible when describing your project’s needs. The more specific you are, the more likely other people are to understand and meet those needs.

Sometimes you can identify needs very early in your project planning. More often, however, particular needs surface as you create a plan that addresses the drivers’ expectations. As your list of needs grows, check with your project’s supporters to decide how the new needs can be met and at what cost. Check with your project’s drivers to confirm that the estimated additional cost is justified, and modify your project documentation to reflect any changes in planned results, activities, schedules, or resources.