Lack of priority information is the death of management and the bane of leadership. It is also the single most common problem project managers run into when trying to filter activities into a critical path. The sophistry behind “They are all As” doesn’t even begin to merit a response. At some point, usually too late, someone will have to decide what people will actually DO with their time. People simply cannot do everything at once no matter how much modern business theory says they should.

When we find ourselves stuck between the rock of responsibility and the hard place of ambuiguity, we need to sort out what is really important for our teams to do. The simplest, and probably least useful, way for us to do this is to pull together a critical path or project plan (or both) based solely on our project’s immediate needs. We lay out the tasks in chronological and/or dependency order, organize our resources, and execute. Other considerations become obstacles to be overcome, modifiers to our iron triangle which we will remove in order to optimize our own performance.

The above represents the simplest and most traditional approach to project activity. It also reinforces a simple cognitive fallacy — the idea that our projects operate in a vacuum, or that our success in one area somehow prevents or alleviates failure in another. By intentionally setting the horizon to close to our own immediate interest, we become vulnerable to both outside interference and the political ramifications of having too few allies. Worse, our projects might start to fail and we will not know why. We end up saying things like “We did everything right, why did they cancel our project?” when the company is about to fold.

Another, more complex approach involves the coordination of basic activities between projects. Say, for example, that our critical path involves the installation of a VPN connection to an outside provider. We could just get the networking group to install our VPN and be done with it. Alternately, we could coordinate with the other project managers who also needed VPNs installed, create a standardized form for VPN information, and arrange with networking to have a “VPN day” when we built a bunch of VPNs. The first approach would get our own work done more quickly. The second would slow our project down a bit but would allow the network department to use their time more effectively, clean up several projects at once, and make sure the resources were on hand in case we needed advanced troubleshooting.

This kind of thinking (grouping and organizing activities among projects) creates what management books like to call “synergy.” This is not a real synergy – it’s just basic coordination. Real synergy comes about when we leverage the work of one project to enhance the result of another.

For example, imagine we have the resources to deploy three workstations along with the new system we are to install. The site actually needs 12 new workstations to get full value from the new system. We could wring our hands or tell them to buy a bunch of new computers. Alternately, we could coordinate with other project managers who also have resources to install new workstations. If we can coordinate it so that two or three workstations for three or four projects all arrive relatively simultaneously, we meet our client’s need without exceeding anyone’s budget.

So, if we have three basic approaches to take, which should we choose? When do we bull ahead, when do we coordinate our activities, and when do we seek out synergy which creates a result greater than the sum of its parts? The answer to that gets back, in a meandering way, to our question about setting priorities.

No one may want to prioritize, but we can tell by who receives rewards which of these three approaches receives approbation, additional resources, and raises. In most environments, it’s safest to just charge ahead. In a few, the managers encourage project managers to coordinate their activities. In a rare handful the executive team seeks out and rewards true synergy, even when synergy creates a situation where one or more of the individual projects falls behind.

What kind of environment do you work in?