Types of activities

The different types of activities are relevant to scheduling and forms of changing and crashing (accelerating) a schedule:

Resource-dependent activities

Projects are generally complex attempts to achieve something. However, a precise schedule model allows the project to be abridged into manageable groupings or phases. Project performance is reported and monitored when progress against these activities and milestones is recorded. The different types of activities are relevant to scheduling and forms of changing and crashing (accelerating) a schedule. This practice standard is organized in five main sections:

• Section 1 - Define the Project's Activities. This section provides the definition of the project's activities.
• Section 2 - Sequence Activities
• Section 3 - Determine Resources for Each Activity
• Section 4 - Determine the Duration for Each activity
• Section 5 - Estimation of Activity Durations

Define the Project's activities

The development of a good schedule model is accomplished through the rational application of sound practices. Experience acquired over time helps to select proper responses to the design requirements for the schedule model. One of the key steps is to define the Project's Activities which is equal to create a list of activities that need to be implemented to complete the project, based on the WBS and expanded by the team responsible for the execution of the work. These activities should represent the expected sequence of the activities and represent the manner of how the work will occur. An activity is a measurable and discrete element (or block) of work that is a tangible element of the project scope. Reference!!!Activities are specific actions that are performed to produce the project deliverables. The characteristics of a well-defined activity include:

• Activity owner. Multiple resources may be required to accomplish the activity; however a single person is responsible and accountable for its performance. That individual should also report progress on the activity.
• Activity description. Activities describe the work that needs to be accomplished. As such, the description for each activity starts with a verb and contains a unique, specific object. Despite the fact that `pour concrete to the wall` may be descriptive of a task, the activity description needs to be more specific. Adjectives may be helpful to clarify uncertainties. Each activity description should be unique and leave no room for confusion, that is, it can be identified without ambiguity and it should be independent of the schedule presentation grouping or organization.
• Continuity of work activity. The work represented by an activity, once started, should be capable of proceeding to completion without interruption (except for naturally occurring nonwork periods in the calendar). When the work on an activity postponed or delayed, it is often beneficial for the activity to be split. This is noted by a single summary bar shown above the activities to reflect what is shown under that bar and coded to the appropriate group. Note that the start and finish dates reflect the early start date and the early finish date-not the late dates. Also the duration reflected on the summary bar matches the elapsed time from start to finish of the group activities. Some software programs accomplish this summarization automatically within the software. In doing so, the software rolls up the data according to specific rules and depicts it as a bar extending over the specific duration. Another example of a summary activity is an activity that can take longer than 2 or 3 update periods such as a procurement activity performed by someone outside the project and expected on the site at a particular date. The status of the work effort can not be incorporated in the schedule other than accounting for time until the event occurs.
• Level-of-effort (LOE) activity. A level-of-effort (LOE) activity is incorporated into the schedule to track , account for, and spread resources over a period of time. However, this does not accomplish a discrete, specific deliverable product. Generally, LOE activities should not appear on the project critical path nor drive the project end date. One example of this is accounting for project hours associated with administrative support. In this case, the activity duration should reflect the anticipated time for the activity. Care needs to be given to LOE activities, because when they are given static durations equal to the length of the entire project, they should never end up on or driving the critical path. By their very nature of supporting detailed work activities, LOE's cannot drive the project duration and cannot be critical. It is a good practice to define LOE activities in such a way that they will take their duration from the detailed activities that they support. Generally, the duration of an LOE is determined by its logical relationships and shown as a start-to-start (SS) predecessor tie and a finish-to finish (FF) successor tie and no others. When completed, the LOE activity list describes 100% of the work required to be completed for the project, although not all activities need to be fully detailed when rolling wave planning is used. Resource leveling should not be performed on LOE-type activities. Constraints should not be applied on LOE activities. LOE activities can have specific assigned resources and calendars to determine their start and finish dates.
• Hammock activity. A hammock activity is a bridging activity that uses and is confirmed by the SS and FF relationships to supporting activities. An LOE activity is unlike a hammock activity because LOE activities may have many types of relationships associated with them.

Sequence activities

The sequencing of activities and milestones together with logic is the foundation of any schedule model. The method of connection is defined as a relationship. Every activity and milestone except the first (with no predecessor) and the last (with no successor) should be connected to at least one predecessor and one successor activity. With the exception of the start milestone, a preceding activity needs to finish or start prior to any activity starting, and in turn, that activity should be totally or partially completed to allow another activity to start. Typically, each predecessor activity finishes prior to the start of its successor activity (or activities). This is known as a finish-to-start (FS) relationship. Sometimes it is necessary to overlap activities. In this case, an option may be selected to use start-tostart (SS), finish-to-finish(FF) or start-to-finish (SF) relationships. Whenever possible, the FS logical relationship should be used. When other types of relationships are used, they should be used sparingly and with an understanding of how the relationships have been implemented in the scheduling software. Ideally, the sequence of all activities is configured so that the start of every activity has a logical relationship from a predecessor and the finish of every activity has a logical relationship to a successor. These practices prevent the schedule from being plagued with open ends. Lag(s) may also be assigned to some relationships. A lag imposes a delay between the preceding and succeeding to some relationships. A lag imposes a delay between the preceding and succeeding activity. A lag imposes a delay between the preceding and succeeding activity. A lag on a SS dependency delays the start of the successor, and a lag on a FF dependency delays the finish of the successor. For example, if an activity has a SS dependency with a lag of +4 days, it would delay the start of the successor activity until 4 days after the predecessor activity has started. The scheduler should use lags with care and understand their impacts. Lags should only be used to represent delays that are physically necessary, represent no work, and have duration. Lags should not be used to represent a period of time when work is actually occurring, such as review of a document before the next phase proceeds. It is recommended that this type of work be shown as an activity in the schedule model instead of using a lag. When included, such activities may be coded to show that these are activities for which another party(for example the client), is responsible. These activities are sometimes referred to as a schedule visibility tasks (SVT). This practice allows for better control of the project and makes it obvious when a specific entity is impacting the project. Using more than one calendar in a schedule model may impact the calculated lag results within the schedule model. Additionally, understanding how different software packages handle multiple calendars is extremely important. It is also possible to assign constraints to activities and milestones that require an activity or milestone to start or finish at specific points in time. It is imperative to study the various types of constraints that are used and understand the effects and distinctions their use has upon the schedule model. The generally accepted practice is that constraints and lags should not be used to replace the addition of activities and relationships. However, the use of constraints is generally acknowledged as necessary to meet contractual obligations. Each activity should have a driving predecessor relationship - an FS or SS predecessor - which determines logically when the activity should start. In a similar manner, every activity should also drive a successor activity through an F-S or F-F successor relationship. When these types of logical relationships are not found in the schedule, the activities are known as dangling or open. This creates uncertainty and likely presents invalid data into the schedule model. resulting in the production of inaccurate project information.

Open-Ended activities

An open-ended activity is an activity lacking either a predecessor or a successor or both. Open-ended activities obscure the logical relationships between project activities, create a false appearance of float in a project, and reduce the apparent impact of risk during a schedule analysis. In such cases, it brings into question the logical relationship of what is required to start the activity or what this activity accomplishes so that subsequent work evolutions can occur. This lack of logic damages the validity of the entire schedule model. The only open-ended activities in a project should be the start and finish milestones at the beginning and end of the project. Unless linked to other projects, a project's start and finish milestones always contain open ends. Open ends occur either through omission (the user fails to assign a relationship) or by the result of progress being reported on the project or relationships that do not close a path sometimes referred to as virtual open ends.

Problem-dependent activities

• Activities to solve a problem.
• Innovation is paramount. Can be difficult to estimate the duration
• Examples: design tasks, development, creative tasks
• Speed up example: difficult, through intermediary deadlines or forcing an end - 'time boxing'