Working with Project Constraints

Working
with Project Constraints

A constraint is a boundary or limit based on the project. You’ve
dealt with constraints before: a preset budget for your project, an inflexible
deadline, limited availability of computer hardware, locating a resource with a
specific skill. Constraints are any factors that can limit your options. They
must be documented, their risks examined, and then the project manager must plan
on how to meet the project objectives with the identified constraints.

When it comes to scheduling activities, you can also create
constraints on the relationships you assign between your activities. For
example, an FS relationship is constrained by the completion of the predecessor
before the successor can begin. This is a natural constraint. This relationship
between activities is sometimes called hard logic. Hard
logic describes the matter-of-fact order of activities. For example, you
must install the operating system before you install the application. On the
other hand, soft logic is when the project manager decides
to do tasks in a particular order based on experience, conditions in the
project, time, or other reasons. This logic is also called discretionary logic.
For example, it is a good practice to have completed all the coding before
beginning the testing phase. It is not mandatory— you can unit test certain
modules that are complete before all the coding is done— but it is preferred to
have all the coding complete before any testing begins.

Date
Constraints

Often in project management, projects have preset deadlines
that require project managers to work backward from the assigned completion
date. The problem is that the person establishing the deadline may not realize
the work required to complete a project by that given date. Unfortunately, this
is often the way project management works: you’re assigned a deadline and then
you have to figure out how to complete the tasks by that date.

Whenever possible, avoid using specific dates for tasks unless it
is absolutely required. The reason that you should avoid date constraints is
that you are signifying a certain task must happen on a specific date regardless
of the completion of tasks before or after it. The best method of assigning
tasks is to use a unit of time and then predict when the task may happen based
on the best- and worst-case scenario for the predecessor tasks’ completion.
There are three types of date constraints:

No earlier than This constraint specifies
that a task may happen any time after a specific date, but not earlier than the
given date.

No later than This constraint is deadline
orientated. The task must be completed by this date—or else.

On this date This constraint is the most
time orientated. There is no margin for adjustment, as the task must be
completed on this date, no sooner or later.

These constraints can be set on a task using your project
management software.

Management
Constraints

Management constraints are dependency relationships imposed
because of a decision by management—this includes the project manager. For
example, a project manager is overseeing the development of a web-based learning
management system. The web site will allow students to register for classes,
check grades, and pay for their tuition, all online. The e-commerce portion of
the project and the database development portion of the project are scheduled to
happen concurrently. Because of the unique relationship between the two tasks,
the project manager decides to rearrange the work schedule so the database
portion of the project must finish first and then the e-commerce portion of the
project may begin. The project manager accomplishes this by changing the
relationship between the tasks from start-to-start to finish-to- start. Now the
database task must be completed before the development of the e-commerce
portion. This is another example of soft logic.

Technical
Constraints

Technical constraints stem from FS relationships. Most often
within an IT project, tasks will be logically sequential to get from the start
to the end. These constraints are the simplest and most likely the ones you’ll
find in a project. The technical constraints you may encounter when building
your network diagram fall into two major categories:

Discretionary constraints These
constraints allow the project manager to change the relationship between
activities based on educated guesses. Imagine two tasks that are scheduled to
run concurrently. Task A, the design on the web interface, must finish, however,
before Task B, the development of the web application, is well under
development. Because of the cost associated with the programmer, the project
manager changes the relationship between the tasks from SS to FS. Now the first
task must finish before the second task begins.

Resource constraints A project manager may
elect to schedule two tasks as FS rather than SS based on a limitation of a
particular resource. For example, if you are managing a project that requires a
C++ programmer for each task and you only have one programmer, then you will not
be able to use SS relationships. The sequential tasks that require the
programmer’s talents will dictate that the relationship between tasks be
FS.

Organizational
Constraints

Within your organization there may be multiple projects that
are loosely related. The completion of another project may be a key milestone
for your own project to continue. Should another project within your
organization be lagging, it can impact your own project’s success. For example,
a manufacturing company is upgrading its software to track the warehouse
inventory. Your project is to develop a web application that allows clients to
query for specific parts your company manufactures. The success of your project
requires the warehouse inventory project be complete before your project can
end. These relationships are entered into your network diagram as FS, with the
origin activity representing the foreign project.