A precedence diagram is a building block for more advanced techniques in operations and project management. Precedence diagrams are used as inputs to PERT and Gantt charts, line balancing, and Critical Path Method (topics of future installments of “The Third Degree.”) Many resources discuss precedence diagramming as a component of the techniques mentioned above. However, the fact that it can be used for each of these purposes, and others, warrants a separate treatment of the topic. Separate treatment is also intended to encourage reuse, increasing the value of each diagram created. A discussion of the nature of task dependencies is a useful preface to one on precedence diagramming. While it is conceivable that a useful precedence diagram could be created without a deep understanding of dependencies, it would be consequentially suboptimal. If dependencies are not well-understood, contingency planning and decision-making are much less effective. Task, or activity, dependencies are defined by two binary characteristics: mandatory vs. discretionary and external vs. internal. A mandatory task dependency often involves a physical limitation; i.e. it is not possible to perform Task B until Task A is complete. For example, it is not possible to frame a house until the foundation has been poured, or to roof it before it has been framed. It may also involve a legal, regulatory, or contractual obligation; i.e. the “tasker” – the individual, group, or organization performing the task – is bound by law or agreement to adhere to a specified task sequence. Continuing the house-building example, inspections of electrical and plumbing installations must be complete, to verify compliance with building codes, before sheetrock can be hung. A contractual mandatory dependency is created when the bank financing the construction requires specified milestones to be reached and approved before subsequent funds are released. A discretionary dependency is a procedural choice defined by the tasker or customer. It often represents an accepted best practice, such as the most efficient use of resources to complete a given series of tasks; it could also simply be a preference. A builder may prefer to paint all rooms before hanging any wallpaper, but a shortage of paint for the living room need not delay wallpapering of the dining room. Discretionary dependencies reflect desires, but flexibility to respond to changing circumstances is retained. An external dependency exists where a “non-project” milestone must be reached before a project activity can begin. In the example above, electrical and plumbing inspections are external activities that must be complete before drywalling (internal activity) can begin. An internal dependency involves only project work and milestones. Stated another way, internal dependencies are relationships between activities within the tasker’s control. As such, activities with internal dependencies may be subject to expediting efforts. Possible combinations of these characteristics define four dependency types:
Understanding dependency aids decision-making when adapting project execution to changing circumstances. To establish precedence, a temporal component must be added; the temporal information is the key component of a precedence diagram. Precedence describes the logical relationship between predecessor and successor activities in a project or process. There are four possibilities:
Precedence diagrams can be drawn in two pictorial formats – Activity on Node (AON) and Activity on Arrow (AOA); both are types of network diagram. In an AON diagram, the task or activity descriptions are placed at the nodes and the arrows represent precedence relationships. The example in Exhibit 4 has no precedence identifiers on the arrows; therefore, it is assumed that only FS constraints exist in this task sequence. In an AOA diagram, activity descriptions are placed on the arrows and the nodes serve as milestones. As shown in Exhibit 5, an AOA diagram may require “dummy” activities to represent additional precedence relationships. In this example, the dummy activity is added to show that both Activity A and Activity B are predecessors of Activity C. Again, a purely sequential execution is assumed because no precedence notation has been used; FS is the default. A third method of presenting precedence relationships is in tabular format. An example precedence table, created by a tennis tournament planner, is shown in Exhibit 6. Each activity is described and assigned a code to simplify references to it. Predecessor activities are then identified by assigned codes. A pictorial diagram can be generated from the information contained in this table in either AON format (Exhibit 7) or AOA format (Exhibit 8). The reverse is also true; precedence information can be transferred from a pictorial diagram to a table. The choice of format(s) to use is usually a simple preference. Many find the AON diagram intuitive and easy to use, while dummy activities may be more difficult to process rapidly. An experienced practitioner may choose to forego a graphical diagram; it is a simple matter to enter the information in a spreadsheet, but graphical capabilities may be limited or cumbersome. If one can process the information with sufficient ease in tabular format, a graphical diagram is unnecessary.
The diagrams in Exhibit 7 and Exhibit 8 use the codes assigned in the table of Exhibit 6 rather than full activity descriptions. The subscript number attached to each activity code is its estimated duration, found in the rightmost column of the table. Durations are not required on precedence diagrams and are normally added only when advanced techniques, mentioned in the introduction, are employed. The use of estimated durations will be discussed in future installments when these techniques are explored. At times in this presentation, constraint has been used as a synonym for precedence relationship. This is a valid substitution, as precedence requirements create constraints on the execution of a task sequence, limiting flexibility available for the tasker to exploit. Some resources refer to precedence relationships, as defined here, as dependencies; the performance of one task is dependent on the performance of another. If the context is understood, the overlapping terminology is not catastrophic. Differentiating between dependency and precedence and including the discussion here was chosen because it seemed the best fit for the information. Both are fundamental building blocks of the advanced techniques to be presented later. Precedence diagrams are used to document production and construction processes, in project management, and in event planning. One could even be used to tame the chaos of a busy family’s daily life. Managing soccer games, band practice, visits to the veterinarian, and PTA meetings may be less daunting if these activities are clearly sequenced in advance. Readers are encouraged to experiment with different presentation formats and practice identifying dependencies and precedence relationships. Planning daily activities is a judicious use of a new tool. Ideally, the first application of any technique is a low-risk endeavor, providing a comfortable learning curve, limited potential consequences, and a solid foundation on which to build skills with advanced techniques. For additional guidance or assistance with Operations challenges, feel free to leave a comment, contact JayWink Solutions, or schedule an appointment. For a directory of “Commercial Cartography” volumes on “The Third Degree,” see Vol. I: An Introduction to Business Mapping (25Sep2019). References [Link] PMBOK® Guide - Sixth Edition. Project Management Institute, 2017. [Link] “PDM – Precedence Diagramming Method [FS, FF, SS, SF] (+ Example).” Project-Management.info. [Link] “Precedence Diagram Method (PDM).” AcqNotes, January 1, 2023. [Link] “Arrow diagramming method.” Wikipedia, September 18, 2021. [Link] Service Management, 8ed. James A. Fitzsimmons, Mona J. Fitzsimmons, and Sanjeev K. Bordoloi. McGraw-Hill/Irwin, 2014. [Link] “Look at four ways to set precedence relationships in your schedule.” tommochal. TechRepublic, January 28, 2008. Jody W. Phelps, MSc, PMP®, MBA Principal Consultant JayWink Solutions, LLC jody@jaywink.com
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorIf you'd like to contribute to this blog, please email jay@jaywink.com with your suggestions. Archives
November 2023
Categories
All
![]() © JayWink Solutions, LLC
|