Types of activities
The different types of activities are relevant to scheduling and forms of changing and crashing (accelerating) a schedule:
- Duration can be changed.
- The duration of the activity can be halved if the resources are doubled (experienced employees).
- Examples: programming, digging drawing work
- Speed up: add more people
- Activities where the duration is determined by a process that must be implemented to achieve the desired result
- Characterized by that it can't be rushed
- Examples: pregnancy, curing of concrete, training and education of employees
- Speed up example: Difficult, in some cases through e.g. change of equipment
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.
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.
- 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'