By definition, a project network diagram, logic diagram (Wysocki, 2009) or project schedule network diagram (PMBOK, 2008) is a logically

sequenced (Wysocki, 2009) graphical representation of the scheduled progression of the tasks needed to complete a project and their logical relationship or dependency (PMBOK, 2008). In this definition, the importance of the process of establishing task dependencies is implicit, as these will define the sequencing between tasks. When establishing task dependencies, the relationship between tasks is ultimately conditioned by the type of constraint operating between these tasks (Wysocki, 2009). Based on the type of constraint operating, PMBOK determines three types of dependencies: mandatory dependencies (those inherent to the nature of the work), discretionary dependencies (those determined by the project team) and external dependencies (those usually out of the control of the project team) (PMBOK, 2008). Similarly, Wysocki identifies four types of constraints and the type of dependencies determined by these: technical constraints (determined by a technical dependency between tasks), management constraints (management-imposed dependency), interproject constraints (result of the dependency between projects related to one another) and date constraints (imposed by the start or finish date of a task) (Wysocki, 2009). The usefulness of determining these constraint types when establishing the logical relationship between tasks is evident in the process of effectively identifying predecessors and successors for each task, which would ultimately end up affecting the sequencing of tasks when creating the project network diagram using the precedence diagramming method. In my experience in the outsourcing services industry, the most commonly found of these constraints affecting sequencing tasks in projects are those arising from technical dependencies between activities, more specifically those determined by the project manager based on best practices assimilated through experience in repetition of similar situations (Wysocki, 2009). An example would be when an experienced project manager decides a logical FS dependency is to be replaced by a combination of SS and SF dependencies: when updating a project to cloud based applications, the IT department is required to maintain the soon-to-be-legacy configuration operational, while gradually migrating and testing work stations to the new system configuration; only when all workstations have passed the tests can they proceed to complete the migration with the new applications. This usually is done regardless of the clients demand, driven by cost factors, that migration should be completed within an unrealistic timeline, and with minimum test-related expenses. In regards to this example, a parallel can be drawn with Swikael and Globersons findings that in services industries, the highest quality of planning (2006, p.696) is done by project managers perhaps because of the shortcomings in strategic support inherent in the industry and that customers may be more interested to achieve high technical performance rather than to keep the project on schedule and without cost overrun (p.693). Reference List Project Management Institute Inc. (2008) Project Time Management. In: Project Management Institute Inc. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Pennsylvania: Project Management Institute Inc., pp.129-164. Swikael, O. & Globerson, S. (2006) The benchmarking of project planning and success in selected industries. Benchmarking: An International Journal, 13 (6), pp.688-700, Emerald Group Publishing Limited [Online]. DOI: 10.1108/14635770610709059 (Accessed: 28 March 2012) Wysocki, R.K. (2009) How to Plan a Project. In: Wysocki, R.K. Effective Project Management: Traditional, Agile, Extreme. Indianapolis: Wiley Publishing, pp.109-193.