Project Schedule Constraints and Assumptions

When you prepare your project plan, you may be faced with factors that have a negative impact on the project and your planning activities. Two such factors are project constraints and assumptions.

Project constraints and assumptions can be a source of frustration for the project team, especially when the constraints are too stringent and the assumptions invalid. To reduce frustration and enhance efficiency you need to carefully manage constraints and assumptions as you prepare the project schedule.

Constraints
Constraints, as inputs to schedule development, are factors that limit the project management team's options. There are two main types of constraints that project managers must consider when developing the project schedule: imposed dates and major milestones.

• Imposed dates - Completing certain deliverables by a specific date may be required by project sponsors, customers, or other stakeholders.
• Major milestones - You may also be asked to complete a certain phase or aspect of the project by a certain date.

These dates will act as constraints, requiring you to make decisions to see that imposed dates and milestones are reached on time.

Assumptions
PMBOK defines assumptions as, "factors that, for planning purposes, will be considered to be true, real, or certain."

Project managers must often make assumptions in planning the various stages of a project. Assumptions generally involve a degree of risk, therefore they must be carefully monitored during a project's life cycle.

Consider this example. Tell-4-Funds, a telemarketing company, has recently been contracted by a client to lead a national fundraising campaign. The client would like to have the campaign finished in three weeks, in order to begin the next phase of its long-term plan. Tell-4-Funds has just begun the project's schedule development. It has made the assumption that the telemarketers can create the calling lists in two days and begin calling people on the third day.

Project managers use the process of project schedule development to determine realistic start and finish dates and to ensure their project is finished on time. Most constraints can be overcome with proper planning and, in many instances, assumptions can be verified, at least to some degree. Understanding how proposed constraints and assumptions affect the project schedule will reduce frustration while helping to keep your project on time and within budget.

Documents Used to Plan Project Resources

When planning your projects, have you ever wondered whether you have enough resources for the project or whether the resources assigned to the project are able to perform the tasks in the allotted time?

The resource requirements and resource pool descriptions are valuable inputs to schedule development. Together, they will help you determine the resources needed to successfully complete your project.

Resource requirements detail the human and material resource required to complete a given project. In assigning resources to a project, you will want to consider that the duration of most activities will be significantly influenced by the resources assigned to them. For example, three people are required to work on Task 2, from week 6 to week 13. If two are working part-time and the other full-time, the full-time employee will finish twice as fast as the part-time employees.

Project managers use a process called resource planning to determine what physical resources, and what quantities of each, are needed to complete a project's activities. Physical resources include people, equipment, and materials.

When developing a project schedule, you need to know what resources are potentially available. A resource pool description is a list of the resources that will be available, times that they are available, and in what quantities. The amount of detail may vary depending on the project.

Resource requirements and resource pool descriptions go hand in hand for project schedule development. The resource requirements determine what type of resources are needed. Whereas, the resource pool description determines what type of resources are available.

Three Ways to Diagram Projects

Before leaving on a trip you gas up the car and then check the road map for the best route. Project managers also have road maps that they can follow to choose the best route for their projects.

The project network diagram, also known as a project manager's road map, is one of the inputs to schedule development. It is a schematic display of the project's activities and their logical relationships or dependencies. It may be produced manually or on a computer, and may include full project details, or have one or more summary activities. The diagram should be accompanied by a summary narrative that describes the sequencing approach.

Project managers use three principal types of network diagrams: precedence diagramming method (PDM), arrow diagramming method (ADM), and conditional diagramming method (CDM).

Precedence diagramming method (PDM)
The precedence diagramming method (PDM) uses nodes to represent activities. Arrows join the nodes together and indicate the dependencies between activities. This technique is also known as activity-on-node (AON) and is the method most widely used by project management software.

The precedence diagramming method is based on four types of dependencies: finsh-to-start, finish-to-finish, start-to-start, and start-to-finish. The first activity in a dependency relationship is referred to as the "from" activity. The second is referred to as the "to" activity.

• In a finish-to-start dependency the "from" activity must finish before the "to" activity can start. For example, on a courseware development project, you must finish the scripting before the graphics can be developed.
• In a finish-to-finish dependency, the "from" activity must finish before the "to" activity can finish. For example, car body and engine production can be started at the same time. The last step in the engine production phase is to install it in the body. Therefore, the body must be finished before the engine can be finished.
• In a start-to-start dependency, the "from" activity must start before the "to" activity can start. For example, on a telemarketing project the compilation of phone lists must be started before people can actually be called.
• Finally, in a start-to-finish dependency, the "from" activity must start before the "to" activity can finish. For example, if your car refuses to start, you may need to jump start the battery with booster cables. The engine must start before you can finish jump starting the car.

In the precedence diagramming method, finish-to-start is the most commonly used type of dependency.

Arrow diagramming method (ADM)
The arrow diagramming method (ADM) uses arrows to represent the activities and connects them at nodes to show dependencies. This technique is also known as activity-on-arrow (AOA). Although less common than the PDM, it is still the technique of choice in some application areas.

In an ADM, "dummy activities" are used to show logical relationships when logical relationships cannot be completely or correctly described with regular activity arrows. A dummy activity uses no resources, has a duration of zero, and is represented by a dashed arrow.

Conditional diagramming method (CDM)
The conditional diagramming method (CDM) allows you to diagram activities that must be repeated more than once. This technique also allows you to diagram non-sequential activities. The two most widely used techniques for creating a CDM are graphical evaluation review technique (GERT) and system dynamics.

Activities that must be repeated more than once are known as loops and can affect the project schedule if their durations are not calculated properly. An example of a loop may be the testing component of a project that needs to be repeated more than once.

When your project has an activity that only occurs under the right conditions, you will need to add conditional branches to the schedule. For example, a conditional branch may be added following an inspection activity. This would indicate that if errors are detected in the product, changes to the product's design may be needed.

Project managers use standardized network diagrams to create project network diagrams faster than they could by drawing them out using a pen and paper. These networks can include an entire project or only a portion of it. Portions of a network are commonly referred to as subnets or fragnets. Subnets are especially useful when a project has several identical or near identical features. Examples of subnets include constructing floors in a high-rise office building, or doing clinical trials on a pharmaceutical project.

Project network diagrams can be used as a guide for your project team and to help your management team better monitor project progress. This ultimately increases your chances of executing a successful project.