When you are ready to resolve conflicts, keep the following in mind:
— Look at the project to see which version of the object is being used.
— Look at the object history to see the relationship between the object in conflict and the object that is being used.
— Look at which tasks are associated with the objects you are interested in.
— Consider whether its task should be added to the update properties for the project. If it should be, find out why it is not being included already: Is the release value for the task incorrect?
— If this task for the object should not be added to the update properties for the project, look at its successors, and consider whether their tasks should be removed from the update properties for the project. If they should be, find out why they were included: Are the release values set incorrectly?
Remember that each team has its own unique process and method for keeping track of changes. This will impact what your team considers to be a conflict. One team might consider a specific conflict as part of their methodology, and that team would turn off that particular conflict. Another team might view that same conflict as a problem to be corrected immediately. Be sure that your team agrees on the kind of conflicts that should be addressed as early in your development process as possible.